Other than installing a subclipse plugin - is there a guide to setting up / using subversion with designer. I’m particularly interested in how to version objects, such as a portlet, for deployment, not just each file.
Is there any kind of integration between deployer and source control?
For instance how would I handle:
portlet A ver 1 checked into source
continue work on portlet A, create version 2
Deploy portlet A version 1 to production
Since work is continuing we wouldn’t want to pick up v2 from the source server using deployer.
We don’t have a guide for setting up / using subversion with Designer, but here are some tips:
In general, installing third-party plugins in designer should work the same as as a generic eclipse installation. So for subversion, the instructions provided on the subclipse website should work fine: http://subclipse.tigris.org/install.html
If you are developing portlets, have each developer own one portlet at a time, don’t try work on the same portlet at the same time.
If multiple people are working on different portlets of the same WebApplication at the same time, understand that there are some files that are ‘shared’ between portlets: portlet.xml, wm-portlet.xml and faces-config.xml are the most notable. For instance, everytime someone adds a managed bean to the application (which can be done by creating views, portlets webservice clients and many other operations) the faces-config.xml will be updated
Determining how many CAF Applications to have is not an obvious task. The more CAF Applications you have, the more you have to deploy/administer/configure. However, it might be a convenient way to separate work for your developers. One important thing to consider is that each CAF Application (which is really just a classic JEE Web Application) has its own class loader. Therefore, you can’t share classes across CAF Applications. If you have a common set of classes that you want to use across CAF Applications you’ll need to place those into Utility Projects.
Regarding your question about Deployer I am not 100% sure… but I think the answer is no.
Regarding your portlet versioning question: Portlets don
We have used SVN in 2 of our 7.1 implementations successfully. What we have followed is that we check-in the whole project except for the build folder. Classpath, project and settings files are shared by the developers and whenever a reference to a project is added these files are updated by the developers.
We have used SVN in 2 of our 7.1 implementations successfully. What we have followed is that we check-in the whole project except for the build folder. Classpath, project and settings files are shared by the developers and whenever a reference to a project is added these files are updated by the developers.
Can I ask a little more about “If you have a common set of classes that you want to use across CAF Applications you’ll need to place those into Utility Projects”
What would I need to do to create a utility project that has classes available to my portlet projects?
Classpath, project and Settings file we have put them on Subversion - What we do is that a developer creates a project, set all the references and commit the project. Now whenever if you want to add some new reference to this project, developer can make changes in classpath and settings file and then commit those changes.
Utility Project:
For common set of classes, we do create Normal Java Projects and then add these projects in our CAF projects using J2EE Dependencies section in project properties → build.
If you any questions about it you can also email me at khurram.majeed@systemsltd.com, as i don’t frequently visit this forum.
On your question about Deployer and source control, there is no direct link and we won’t try to implement this in Deployer. For now, Deployer relies on the ability to extract assets from deployed source servers. Future work with Centrasite integration as the core repository for the suite will provide a better framework for this kind of interaction with VCS environments and it is something I have on the roadmap (albeit a way down the road).