Yes Tom you can do this. We would have to setup a directory for each test as if it was a sub-project in a multiproject Maven build. In this way you can change the dependencies for the project.
Where would we publish the web site and the downloadables for the project such as test coverage graphs, documentation, etc. You get all this pretty easy with Maven.
What would be the root of the build in CVS? I see us creating a multiproject build that can handle jbpm.3, jbpm.bpel, jbpm.db, etc. yet allow you to just use it within the jbpm.3 directory if you wanted.
I have experience doing multiprojects in Maven. I have a base Maven project that we can start with.
Be aware, however, that it would be best to make some changes to directories and so forth to match the Maven standards.
our sub project structure suck... which is good news cause we can just restructure it a bit to fit maven.
do you know how far the maven structure is from the traditional jboss source code structuring ?
also i would like to think about extracting the identity component and the web appilcation as separate components...
maybe we must fit them all into one cvs module.
but care must be taken with respect to the graphical designer eclipse plugin. that one has an *extremely* difficult build process.
the best would indeed be to create a kind of playground module in which we can play. once we know how we are going to do it we can convert the real source code. makes sense ?
take a look, give your suggestions and let's keep on discussing this.
maven does not fit well with the default jboss structure as we build multiple artifacts in a project source tree and this is not the maven model. Ruel is looking at how we could possibly use maven with minimal change to the existing project structure.
Ruel's told me about it. Since we are in the same office, we can easily come up with a structure that works for jBPM and hopefully serves as departing point to mavenize JBoss. Unfortunately he's on vacation until next year, so this will have to wait a little.
and what source code structure would you recommend if we revise jbpm ? the jboss structure, the maven structure or doesn't matter ?
i think opting for the maven structure might be the easiest path to getting it all build. no ?
I would talk to Ruel. The maven structure requires a source tree per artifact as I understand it, and I find this too anal. If you like it then there is nothing wrong with it.
Scott is correct. Maven works best with one artifact per project. I like to have one "super project" to handle the distribution of the whole set of artifacts and then sub projects (subdirs) for each artifact to be produced.
Now that's just the easiest way to do it with Maven.
Maven 1.0.2 is very flexible and would allow more complex structuring than this if you want more than one artifact per project.
Another major question, should we start with Maven 1.0.2 or go ahead and use Maven 2.0. As I last checked not all the plugins are updated for 2.0 such as emma, but then again we can use clover because we have a free open source license for that and the clover plugin is ready for 2.0.
Tom, I'll build a "playground" structure for a miniature jBPM project outside the main source tree so we can all see it, touch it, and talk about it.
I think it would be great to agree on a methodology across JBoss product lines, particularly the JEMS stack. A good use of Maven also will impact the JBoss web site if we publish all the reports and doc that Maven can produce.
i would like to take it step by step. main thing i'm after is using the jboss repository to build jbpm against multiple versions of its dependencies.
docs and other things are optional. and it needs to be easy to integrate them in the current jboss web site. we should have control over which parts of maven we use and which parts not.
I've done a small project with jBPM that I have done in Maven...if you like I can publish it to the development team.