[opencms-dev] OpenCMS Development in a team
Schliemann, Kai
K.Schliemann at comundus.com
Mon May 3 16:27:01 CEST 2010
Hi Thomas,
Von: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] Im Auftrag von Thomas Göttlich
Gesendet: Montag, 3. Mai 2010 15:33
An: The OpenCms mailing list
Betreff: Re: [opencms-dev] OpenCMS Development in a team
Hi Kai,
thanks for the explanation.
I already suspected there's no reasonable way around having a local infrastructure, especially with respect to the database/VFS.
We already planned to have local installations of JBoss and OpenCMS, so the real question was on whether to have a local database or not.
So what we will do is to provide a database per developer in our central DB server (this is preferred by our infrastructure team), but in essence that's the same as having a local DB server (except that the DB names are different).
This works well, too. We did the same in one of our projects.
I guess we can do the synchronization via Ant tasks as well (e.g. by calling CmsShell).
Yet, I'd love to use Maven in that project, but since the resistance of my co-workers could not be alleviated yet, we'll have to stick to Ant for now.
Maybe I have a chance to work out more benefits of Maven (or flaws of working with Ant) during this project that help to convince the rest of our team.
(Actually, the "killer argument" was that they'd have to scroll more in eclipse, due to the "one project -> one artifact" convention ;o) )
Finally, some last questions regarding your plugin:
I read that you use the standard opencms.jar now, but the build still seems to use a patched version of OpenCMS.
Is that true?
No, it is the original version. The maven build only attaches a version number to the jar.
Would that mean I'd have to use the patched version for development or is it just used during execution of your plugin?
Another thing is the configuration of the plugin: since parameters like DB etc. are provided in the POM, would that mean I need to rebuild the plugin each time one of those parameters changes?
Yes and no J When you change your DB params, you can just change them in your Webapp (opencms.properties) and the restart you application server to get the changes. But you have to do these changes in the webapp project of your maven project as well. Otherwise your next rebuild will not work (not use your new DB params).
Additionally, starting a new instance of OpenCMS (as does CmsShell) just for synchronization bears the disadvantage of "slow" startup (10 sec. on my machine).
The problem here is editing JSPs: Our designers don't want to wait a long time (several seconds for a synchronize) when they're just doing "pixel pushing".
The synchronization takes its time with the maven sync as well. It is not faster or slower as the OpenCms build in sync. But you are always free to edit your JSPs directly in OpenCms. The build in editor is not to bad after all. Or check out the webdav feature. This works well, too.
However, if it would be possible to just trigger a running OpenCMS instance e.g. via webservices (OpenCMS 8 ?) that synchronizing should be a lot faster.
Regards,
Thomas
Regards
Kai
2010/5/3 Schliemann, Kai <K.Schliemann at comundus.com <mailto:K.Schliemann at comundus.com> >
Hi Thomas,
ok, now I see your problem.
Actually this is no problem.
Let me explain, how our development process looks like.
1. Every developer has his own development infrastructure on his local machine. Including Tomcat, database (e.g. MySQL) and OpenCms. This means that every developer has his own OpenCms instance on his local machine.
2. So when he develops his templates, he does this either in his local OpenCms instance or he uses the synchronized file on his local file system. After changing his code, he synchronizes his local changes with the OpenCms VFS by using the maven goal mvn vfs:sync. The files in the OpenCms VFS are synchronized with the local files. This works in both directions (VFS->RFS; RFS->VFS).
3. All our VFS resources are Eclipse projects. So we can use all advantages of the IDE.
4. Java code is developed locally as well
5. When a developer finished his work, he checks in his changes to the version system. In our case svn.
6. The other developers can check out these changes and either synchronize (VFS projects) or do a rebuild of the complete project if there are changes in the Java code. Single Java projects can also be rebuild (mvn package) but have to be deployed manually to your application server.
7. For testing, we have a special maven profile with attributes for the test server. On our Hudson based build server is a task which rebuilds the project based on this maven profile every morning. This build is used for testing.
If you don't want to check in your code before testing I would recommend writing test cases and let maven run does tests on rebuild. So every developer has to do a successful rebuild of his project before checking in his code.
I hope this helps.
Regards
_________________________________________
Kai Schliemann
Senior IT-Berater
comundus GmbH
Schüttelgrabenring 3, D-71332 Waiblingen
Telefon +49 7151-50028-0
E-Mail k.schliemann at comundus.com
Internet www.comundus.com <http://www.comundus.com/>
Geschäftsführer Klaus Hillemeier
Amtsgericht Stuttgart, HRB 264290
comundus ist ein Unternehmen der IT EXCELLENCE Group
_________________________________________
Fehler! Es wurde kein Dateiname angegeben.
Die Kundenzufriedenheit bei comundus wieder verbessert -
Durchschnittsnote jetzt 1,7.
Von: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] Im Auftrag von Thomas Göttlich
Gesendet: Montag, 3. Mai 2010 11:37
An: The OpenCms mailing list
Betreff: Re: [opencms-dev] OpenCMS Development in a team
Hi Kai,
yes, it's really too bad, but I can't do anything against it (at least if there wasn't another killer argument in favor of maven).
However, I've still have a question (maybe this could be the required killer argument):
Would the maven plugin allow us to develop and test independently?
What I mean is, would we be able to modify a module and just deploy it locally (without synchronization with the the VFS) for our tests?
After the module was tested successfully there wouldn't be any problem in deploying it in the shared VFS.
However, for the primary tests, we'd like not to interfere with other developers.
How do you do that?
Best regards,
Thomas
2010/5/3 Schliemann, Kai <K.Schliemann at comundus.com>
Hi Thomas,
too bad, that you decided against maven.
All the problems you describe are the same, we had years ago before we decided to write the Maven plugin.
Hope you find a suitable solution for your development process.
Best regards
_________________________________________
Kai Schliemann
Senior IT-Berater
comundus GmbH
Schüttelgrabenring 3, D-71332 Waiblingen
Telefon +49 7151-50028-0
E-Mail k.schliemann at comundus.com
Internet www.comundus.com <http://www.comundus.com/>
Geschäftsführer Klaus Hillemeier
Amtsgericht Stuttgart, HRB 264290
comundus ist ein Unternehmen der IT EXCELLENCE Group
_________________________________________
Fehler! Es wurde kein Dateiname angegeben.
Die Kundenzufriedenheit bei comundus wieder verbessert -
Durchschnittsnote jetzt 1,7.
Von: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] Im Auftrag von Thomas Göttlich
Gesendet: Montag, 3. Mai 2010 10:54
An: The OpenCms mailing list
Betreff: Re: [opencms-dev] OpenCMS Development in a team
Hi Kai,
thanks for your suggestion.
Unfortunately, our project management recently decided against Maven for this project, so we will have to use Ant (there was one killer argument by fellow developers which made our management decide against maven - although I don't agree with that).
However, I guess it should be no problem to do the synchronization via the CmsShell or use a small plugin that exposes the necessary functionality as a webservice (in order to cut down the CmsShell startup times).
What is more of a problem is the actual development process.
Here's what we'd like to do (more or less)
1. Create/change a JSP or JAR
2. Deploy it in OpenCMS (locally!)
3. Test it
4. Commit the changes to Subversion
5. Deploy the JSP/JAR to the VFS
The problem here is the concurrent development of a JSP or JAR, i.e. if I make some changes and deploy it to the VFS in order to test it, I might overwrite another developer's code (if she did also deploy it to the VFS) or break the others' systems if my code doesn't work.
With a shared OpenCMS database we'd actually work on a single VFS and making changes there would have similar effects as commiting faulty code into version control (i.e. subsequent updates on other machines would break the software there).
Best regards,
Thomas
P.S.: I already found your Maven plugin and it looks great. However, I'd like to ask some questions even if we're not able to use it for our current project.
2010/5/3 Schliemann, Kai <K.Schliemann at comundus.com>
Hi Thomas,
you might have a look at the OpenCms-Maven Plugin on http://opencms-maven.comundus.com/.
The plugin uses Maven to automatically build OpenCms projects. A maven-vfs-plugin retrieves the data from the vfs an writes them to the file system (actually it is doing a vfs sync). Now it is easy to use your versioning system to exchange your code changes between the developers.
If you have any further questions, please don't hesitate to ask.
Best regards
_________________________________________
Kai Schliemann
Senior IT-Berater
comundus GmbH
Schüttelgrabenring 3, D-71332 Waiblingen
Telefon +49 7151-50028-0
E-Mail k.schliemann at comundus.com
Internet www.comundus.com <http://www.comundus.com/>
Geschäftsführer Klaus Hillemeier
Amtsgericht Stuttgart, HRB 264290
comundus ist ein Unternehmen der IT EXCELLENCE Group
_________________________________________
Fehler! Es wurde kein Dateiname angegeben.
Die Kundenzufriedenheit bei comundus wieder verbessert -
Durchschnittsnote jetzt 1,7.
Von: opencms-dev-bounces at opencms.org [mailto:opencms-dev-bounces at opencms.org] Im Auftrag von Thomas Göttlich
Gesendet: Montag, 3. Mai 2010 10:03
An: opencms-dev at opencms.org
Betreff: [opencms-dev] OpenCMS Development in a team
Hi there,
we're currently starting our first bigger project based on OpenCMS.
However, we have some questions on how to setup a development environment that is suitable for developing in a team.
Thus, any help, ideas and suggestions are highly appreciated.
First, I'd like to give a quick overview on our current development process:
So far, we used a single shared database for development, so that any developer can use the same test data.
Development occured in otherwise isolated environments, i.e. each developer had her own JBoss, own working copy etc.
Source code distribution happened via Subversion whereas test data resided in the shared data base.
Additionally, we told JBoss where to find the application (especially the JSPs) in our working copy.
Thus we could just edit a JSP and immediately see the changes in the running application.
All this allowed us to code quickly, use the same test data without any hassle etc.
However, OpenCMS doesn't seem to support that approach.
As far as I know, OpenCMS needs all JSPs (and maybe the jars, too) to reside in the VFS which would make using a shared database for OpenCMS quite difficult.
Additionally, if we used a database per development machine, it would be difficult to distribute the test data.
The third point would be the instant editing of JSPs which doesn't seem to work, since we'd need synchronization with the VFS.
Do you have any ideas?
Or any hint on how you do OpenCMS development in a bigger team.
Thanks in advance,
Thomas
_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev
_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev
_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20100503/9c26e724/attachment.htm>
More information about the opencms-dev
mailing list