[adrian.brock]

Ok, I thought Maven didn't support the flat structure without reverting to ant?

On the number of top level projects. I guess I'm trying to say that if
the contract/api projects are separated and delivered to the consumer
projects (including the implementation project) as binary
then that would encourage good abstraction and make people think
twice about the changes they make. ;-)

[starksm64]

Yes, but if we stick to the artifact per source tree approach, the top-level vs nested really does not lend itself to intermingling of api with implementation. As far as I can see each impl project still has to declare a dependency on the api project and interacts with that project through the binary artifact, be it a local repository or remote. A nested project does not interact through a shared output/classes directory like currently exists.

I'm just going to work through some prototypes with the common logging classes to get a feel of the tradeoffs including intellij/eclipse integration as a basis for promoting one approach as the jboss standard. As part of this, where are the licensing plugins you worked on Ruel/Ryan? I want to use these.

Some other things I want to look into include creating a sar plugin, and a jar plugin that has a distinct client jar/full jar notion.

[starksm64]

I updated the cycles section with a run against the latest changes where I also removed the javax.xml.namespace.* classes.

The last big cycle is:

org.jboss.util
 |
 | org.jboss.util.platform
 | org.jboss.util.property
 |-> org.jboss.util

do to util exceptions depending on platform, depending on property. The only real use of platform is the PID thing by the id.VMID which really just equates to random number. This can't really be removed due to serialization compatibility, so I'm just going to break the dependency by getting rid of the throwable usage.

[starksm64]

Another broken dependency is between the org.jboss.util.xml.Dom2Sax util class and the org.jboss.xb.binding.Constants, org.jboss.xb.binding.NamespaceRegistry imports. This class needs to be moved to the org.jboss.xb package.

The only real use of this class that I see is the org.jboss.ws.jaxb.JAXBMarshallerImpl in the webservice module.

[starksm64]

Another org.jboss.util.xml to org.jboss.xb.binding cycle are all of the SchemaResolver* related additions. They are all defaulting to org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver and using the org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver interface.

These are not generic classes and should just be in the jbossxb package as far as I can see.

[ruel.loehr]

I'm just going to work through some prototypes with the common logging classes to get a feel of the tradeoffs including intellij/eclipse integration as a basis for promoting one approach as the jboss standard. As part of this, where are the licensing plugins you worked on Ruel/Ryan? I want to use these.

Source is here: http://anonsvn.labs.jboss.com/trunk/labs/jbossbuild/projects/maven-plugins/maven-validate-plugin/

You can define it in your top level pom file like this:

<!-- define that we wish to validate the dependency poms -->
 <plugin>
 <artifactId>maven-validate-plugin</artifactId>
 <inherited>true</inherited>
 <version>1.1</version>
 <executions>
 <execution>
 <id>validate-pom</id>
 <phase>validate</phase>
 <goals>
 <goal>validatePom</goal>
 </goals>
 </execution>
 <execution>
 <id>validate-licenses</id>
 <phase>validate</phase>
 <goals>
 <goal>validateLicenses</goal>
 </goals>
 </execution>
 </executions>
 </plugin>

I'll start working on a guide for jboss projects which instructs how to build a pom file.

[starksm64]

So my first uber common tree structure is working, including figuring out that the common-logging-spi needs to be built first due to the common core having a dependency on it. The structure is:

common
 + pom.xml (modules=common-core, common-logging)
 + common-core
 -- + pom.xml
 + common-logging
 -- + pom.xml (modules=common-logging-spi, common-logging-jdk, common-logging-log4j)
 -- + common-logging-spi
 ----- + pom.xml
 -- + common-logging-jdk
 ----- + pom.xml
 -- + common-logging-log4j
 ----- + pom.xml

I included all the org.jbos.util.* excluding logging in core for now.

[sstark@sstark common]$ mvn install
[INFO] Scanning for projects...
[INFO] React[sstark@sstark common]$ mvn install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] JBoss Common
[INFO] JBoss Logging
[INFO] JBoss Logging SPI
[INFO] JBoss commong frameworks
[INFO] JBoss JDK Logger
[INFO] JBoss Log4j Logger
...
[INFO] Reactor Summary:
[INFO] -------------------------------------------------------------------------
---
[INFO] JBoss Common ........................................... SUCCESS [0.578s]

[INFO] JBoss Logging .......................................... SUCCESS [0.000s]

[INFO] JBoss Logging SPI ...................................... SUCCESS [1.594s]

[INFO] JBoss commong frameworks ............................... SUCCESS [1.313s]

[INFO] JBoss JDK Logger ....................................... SUCCESS [0.234s]

[INFO] JBoss Log4j Logger ..................................... SUCCESS [1.703s]

[sstark@sstark common]$ find . -name '*.jar' -print
./common-core/target/common-core-1.0.0.GA.jar
./common-logging/common-logging-jdk/target/common-logging-jdk-1.0-SNAPSHOT.jar
./common-logging/common-logging-log4j/target/common-logging-log4j-1.0-SNAPSHOT.jar
./common-logging/common-logging-spi/target/common-logging-spi-1.0.0.GA.jar

Does the version have to be in the artifact name?

The idea:idea intellij target creates a project that correctly creates subprojects for each of the subprojects and even has the dependcies correct. I'll try eclipse next.

[starksm64]

<!-- define that we wish to validate the dependency poms -->
 <plugin>
 <artifactId>maven-validate-plugin</artifactId>

 </plugin>

I'll start working on a guide for jboss projects which instructs how to build a pom file.

I'm not finding this in a repository:

[INFO] A required plugin was not found: Plugin could not be found - check that t
he goal name is correct: Unable to download the artifact from any repository

 org.apache.maven.plugins:maven-validate-plugin:maven-plugin:1.1

from the specified remote repositories:
 central (http://repo1.maven.org/maven2)

 org.apache.maven.plugins:maven-validate-plugin:maven-plugin:1.1

from the specified remote repositories:
 central (http://repo1.maven.org/maven2)

I also have the jboss maven repository defined:

 <repositories>
 <repository>
 <id>jboss</id>
 <name>JBoss Inc. Repository</name>
 <layout>default</layout>
 <url>http://repository.jboss.com/maven2/</url>
 <snapshots>
 <enabled>true</enabled>
 </snapshots>
 </repository>
 <repository>
 <id>central</id>
 <name>Maven Repository Switchboard</name>
 <layout>default</layout>
 <url>http://repo1.maven.org/maven2</url>
 <snapshots>
 <enabled>false</enabled>
 </snapshots>
 </repository>
 </repositories>

[ruel.loehr]

Add a plugin repository to your build. This simply tells maven where it should look for plugins (other than the default ibiblio location).

<!-- define the plugin repository we wish to use -->
 <pluginRepositories>
 <pluginRepository>
 <id>central</id>
 <name>jboss plugin repository</name>
 <url>http://repository.jboss.com/maven2</url>
 <layout>default</layout>
 <snapshots>
 <enabled>true</enabled>
 <updatePolicy>never</updatePolicy>
 </snapshots>
 </pluginRepository>
 <pluginRepository>
 <id>lsu.edu</id>
 <name>LSU maven2 mirror</name>
 <url>http://ibiblio.lsu.edu/main/pub/packages/maven2</url>
 <layout>default</layout>
 <snapshots>
 <enabled>false</enabled>
 <updatePolicy>never</updatePolicy>
 </snapshots>
 </pluginRepository>

[starksm64]

Ok, it worked after I added that. Explain the repository/pluginRepository settings in your doc as well has how to override this via a user settings.xml. I used settings.xml to move the local repository out of the crappy winxp default /Documents.../* location.

[starksm64]

The eclipse:eclipse plugin also appears to work fine with dependencies betweens subprojects and repository jars created.

[starksm64]

Another org.jboss.util.xml to org.jboss.xb.binding cycle are all of the SchemaResolver* related additions. They are all defaulting to org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver and using the org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver interface.

These are not generic classes and should just be in the jbossxb package as far as I can see.

I want to move these classes into the jbossxb org.jboss.xb.* package namespace to get to the point of being able to seperate the jbossxb project. Due to the coupling to org.jboss.xb.binding.sunday.unmarshalling.* classes, that is where they should go.

[starksm64]

All of the cycles outside of the jbossxb packages are cleaned up and the jbossxb classes can be pulled out into a seperate project. Its just a question of how many modules to break the core into, and whether this needs to be done up front.

[ruel.loehr]

All of the cycles outside of the jbossxb packages are cleaned up and the jbossxb classes can be pulled out into a seperate project. Its just a question of how many modules to break the core into, and whether this needs to be done up front.

So the module division is shaping up to look like:

1) an org.jboss.xb project
2) an org.jboss.logging project
 * with 3 subprojects?
3) a core project
 a) org.apache.xerces.*
 b) org.jboss.net.*
 c) org.jboss.util.*

Adrian had suggested splitting up the core into these pieces:
- collections
- net (url handlers)
- property editors
- thread pool

Now that the code problems are corrected and we can go ahead and split out xb, we can split the rest of the commons core out in the future.

In order to proceed with Maven we need to:
1) Agree on what the ultimate file structure strategy is (nested vs. top level), as well as agreeing on the multiple artifact situation. Is our long term strategy to split the source trees? Now that you have worked with this, do you have any opinions?
2) Pull out the xb

I started a wiki for Maven build instructions. I'll be adding to it as questions arise:

http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation

[starksm64]

If one is going to build multiple modules, there has to be a master maven pom.xml that includes all of the modules to build, so at some level there is an aggregating pom.xml. The only difference between the fully nested module like common vs several top level common projects seems to be ease of ability to checkout the structure. Even this can be done other ways such as cvs module alias, and I suppose svn has a similar notion. At this point I would say use nested when there are seperate artifacts that are logically related/dealt with as a compound source tree. Otherwise a top level module that can be integrated into others should be used.

In terms of the immeadiate breakout of the common module, I would say it is just:

logging: common-logging-jdk, common-logging-log4j, common-logging-spi
common-core
jbossxb: includes the org.apache.* and org.jboss.xb.* packages.

the common-core can be further broken up as needed.

In terms of the maven guide, I would like to have a page of the plugins we use with examples to help with proper use. This should include both the bundled maven plugins, thirdparty plugins, and jboss plugins.