JBoss Build Status Meeting Notes Feb 1, 2007

[pgier]

Remaining tasks to complete before micro container mavenization is complete
Add a snapshot version of JBossTest to the maven2 repository. (JBoss Test can also be mavenized soon).
JBossRetro will be called by the antrun plugin until a maven2 plugin version can be created.

POM structure
There should be a single parent pom that all JBoss proejcts will inherit default configuration from.
Microcontainer and JBoss common will initially each use the build/pom.xml as the parent pom. Later will be re factored to share a single parent.

Project artifact naming convention
Project groupId will be "jboss" for all projects.
artifactId will be the name of the project or subproject

Synchronization of jboss maven repository with main maven repo.
All JBoss project builds should be dependent only on the JBoss repository.
Uploading JBoss artifacts to main maven repository is low priority and can be manually done as needed.

Cleanup of Maven2 repository
Paul will begin removing old stuff from the jboss repository. Maybe we can create something automated to find artifacts that are not depended upon.
We will look into using ant tasks to pull artifacts from the maven2 repository instead of the current one for existing builds. This would allow us to merge the two repositories before fully converting to maven.

Subversion Migration
Will work with IT to migrate remaining projects from CVS to subversion. Starting with JBoss Serialization and then Seam, JBoss Remoting, and maybe JBossRetro and the maven repository.

Other notes
We will have a bi-weekly meeting to provide an update of the status of the build system.

[pgier]

"pgier" wrote:

Project artifact naming convention
<ul><li>Project groupId will be "jboss" for all projects. </li>
<li>artifactId will be the name of the project or subproject</li>
</ul>

We talked yesterday about using the "jboss" prefix for the project names. For example jboss/jboss-common-core vs. jboss/common-core. After thinking about it a little bit, I think that Scott is right that we really don't need the jboss prefix on the maven artifactId. Since the jars will always be downloaded into their appropriate subdirectory, there really isn't an issue of possible name conflicts with other organizations.

The jboss prefix on the artifactId seems redundant. The drawback is that there are already a lot of projects in the repository with jboss prefix in the name so it will take a little bit of work to change them.

[starksm64]

It may be redundent in terms of the repo structure, but you said this also determines the artifact name. common-core.jar vs jboss-common-core.jar is a good use of the jboss prefix, so that redundency is a good thing. I suppose it could be reintroduced by overriding the artifact name via a combination of groupId and artifactId.

[pgier]

I couldn't think of a situation where you would be looking at the jar outside of its jboss directory. If other projects are using jboss common for example, they could specify the dependency in their pom.xml and the jar gets downloaded into their local repository, and they never see it.

If we are packaging up jboss common with the app server for example, there is a maven assembly plugin that can be used to package a project with its dependencies, so you would never have to worry about the actual name of the jboss common jar file.

One situation where it probably would be useful to have the full name jboss-common-core.jar is for external non-maven projects that want to just extract the jars into their lib directory. But for this case we could produce a different name for the file (including the groupId) for non maven distribution.