JBossDeveloper

Currently, when you check out from subversion you will get more modules than are being built. As my work has proceeded, I have inlcuded each additionaly module into subversion for backup purposes. The current release version only builds a subset of these, the next release version will include them all. (This will be finished up this week).

Now for some specifics.......

The groupId is a unique identifier. Everything in maven will get two things, a groupId, and an artifact name. These 2 pieces of information are used for both placing and pulling items from the maven repository. The naming schema is user defined. For example, each module in our build will get a unique groupId, and each module will have 1 output artifact which can be placed in the repository (although we can still build as many output artifacts as we want).

We have a notion of two repositories, a local and remote. On the first build dependencies are copied from the remote to the local repository. Some dependencies as you described are not present in the remote repository. They are created at build time and placed in the local repository.

The next point is very important and concerns how inter-module classpath referencing takes place. When a module is built a jar artifact is created. This artifact is then copied into the LOCAL repository using the groupId , artifactId, and version as path descriptors. The local repository on a windows box by default is in your c:\documents_and_settings\user\.m2\repository directory. Linux users will find it in ~/.m2. When module b references a depenency from module a, what is placed on the compilation classpath is the path to the local repository/groupId/artifactId/version for module a.

The version you are looking at on ibiblio was possibly added by a thirdparty as releasing to cache to ibiblio is not currently part of the release process.

That being said, Cache is an excellent candidate for being released to ibiblio and I would like for that to become a standard part of the release process (this could later be extended to other jems projects). I'll engage the cache developers on this and work with them on getting it set up.

The best source of pom documentation can be seen here:

http://maven.apache.org/maven-model/maven.html

It lists all possible tags for the pom and what the usage is. This is currently the best source of information regarding the pom. If there are any vague tags descriptions, I can fill in the blanks.

Yes, the flat file structure argument is an ongoing one. It stems from the fact that Maven suggests a file system (one with nested projects) which eclipse does not yet support.

They handle it just as you describe. A normal checkout would take place, and then each project and subproject is imported as a top-level proj into eclipse.

I agree 100%. IMO, it makes more sense to have all top level projects as this would correspond to the structure that eclipse handles. There are implications to this schema as well.

This relates to something you posted over the weekend.

-- from the dev list

On the maven build in general, I don't like the kind of thing
seen below. We might as well use ant than learn a new tool
to do this???

Good: Declarative information known to the build system
Bad: Scripting or any other hack that breaks the information trail

Is this just because our projects are hopelessly entangled?

 <artifactId>maven-antrun-plugin</artifactId>
 <version>1.0</version>
 <executions>
 <execution>
 <phase>package</phase>
 <configuration>
 <tasks>
 <mkdir dir="${basedir}/output/lib"/>

 <!-- Build jboss-common.jar -->
 <jar
jarfile="${basedir}/output/lib/jboss-common.jar"
manifest="${basedir}/src/etc/default.mf">
 <fileset dir="${basedir}/output/classes">
 <include name="org/jboss/**"/>
 <include name="org/apache/xerces/**"/>
 </fileset>
 </jar>
snipped the rest