orchestra structure

[tom.baeyens]

this is the structure that i would like:

build.xml
src
 + java
 + doc
 + ...
target
 + classes
 + testclasses
 + testresults
 + javadoc
 + pvm.jar

build.xml includes ../build/project.build.xml. So each project would depend on build and its dependend projects.

To consider maven, 2 things would have to be resolved:
* the structure given above must be easily managed in maven
* repository.jboss.com should be usable as the repository. i'm not sure how much maven information is in there. i know there is a repository.jboss.com/maven2 repo, but I don't know if all the libraries are in there.

[mvaldes]

To consider maven, 2 things would have to be resolved:
* the structure given above must be easily managed in maven

This structure, or quite similar, could apply to each maven module in Orchestra, otherwise, if there is no module, maven would not be useful. Why you don't like the default maven structure ? Is just a matter of packaging, there is no implication in the source code...

* repository.jboss.com should be usable as the repository. i'm not sure how much maven information is in there. i know there is a repository.jboss.com/maven2 repo, but I don't know if all the libraries are in there.

So, either we could include required libraries in your maven repository or just use another maven repository...

regards,
Miguel Valdes

[tom.baeyens]

I must have a similar build structure over all the pvm projects and subprojects.

I think the maven default structure is too complex

But maven is still an option for me, though i currently don't like it cause i don't know it (tried once but failed). this could be something that we discuss when i come to grenoble next time.

[kukeltje]

from what I see the structure you want is not that different from the maven structure. It even has the src/main/java, src/test/java etc structure that is now in jbpm.3, or do you want to get rid of this?

[tom.baeyens]

the structure on itself is not that important. but the problem i see is this

* 1 maven project has a fairly understandable directory structure. although, it could be simpler.

* but maven requires you to make all kinds of subprojects for things that could easily be managed in one project. so you get a lot of sub projects and that results in waaay too many directories and extra complexity.

* even then maven is hard to customize. (not if you know it completely, but that is not the case for most of us. And even then...)

Hard to customize is a big issue as i see a lot of difficult things i want to get done in the build. especially the continious integration matrix. Running tests with different classpaths to check library dependencies. Running different database configuration tests. Running appserver tests.

I'm afraid that a lot of these things fall outside the regular maven scope. And that the customizations for that will result in even more complexity of the build system.

But i know that i'm not that familiar with maven i only tried it once during our last build refactoring. So if someone can show me that all this rules that maven enforces deliver some good value, then I'm all ears

[sauthieg]

Hi Tom

Miguel asked me to answer some of your questions about maven2.

1 maven project has a fairly understandable directory structure. although, it could be simpler.

The maven project structure is only a default structure, you can use properties to overrides theses settings and change the directory structure.
Note that you do this only once in the top level pom, and this setting is inherited by all child poms.

<project>
 ...
 <build>
 <sourceDirectory>src/java</sourceDirectory>
 </build>
 ...
</project>

One of the advantages of using the default structure is to ease new contributions as developers are used to manipulate maven conventions.

Yes, everything is about conventions, the maven project structure is a convention adopted by a lot of users, where ant let you place your sources in any place that fits your will, but there is no formal convention in ant...
I don't say that src/main/java is better than src/java, I just say that new users are not lost when they first come to a project using maven conventions...

but maven requires you to make all kinds of subprojects for things that could easily be managed in one project. so you get a lot of sub projects and that results in waaay too many directories and extra complexity.

In some way, this is true, maven enforce modularization of things, so you usually ends with many sub-projects, each of them focusing on 1 task you want to perform.

In my mind, this make the build clearer, as work items are clearly separated.

Another point is that, usually, theses projects have no source code, maybe some configuration files, but almost everything is in the pom.xml.
So there are not too many directories for me.

even then maven is hard to customize. (not if you know it completely, but that is not the case for most of us. And even then...)

I agree that there is a maven philosophy that is completely different of ant's one. So the switch may be difficult if some continue to think the build the ant's way...
Just as a side note, you can still continue to execute ant tasks inside of maven. This way you can start with some kind of hybrid build system.

Concerning the AS tests you may want to run, just take a look at the cargo project (http://cargo.codehaus.org).

Maybe I can just add some points about the added value of maven usage:

* dependency management: all your dependencies are clearly defined and you classes cannot use classes that are not defined as dependencies.
* module re-usability: as everything has to be in maven repositories, jar files can be easily shared between projects
* continuous integration: you can have an almost real time continuous build system with maven, all the automatic builds deploy the SNAPSHOTS artifacts to the snapshots repositories, enabling dependent code to get the latest bytes to try it.