Refactor directory structure and file locations into standard Maven structures

1) Moved src/main/org to src/main/java/org (Subversion revisions 5886, 5887, 5888)

2) Altered the Ant build descriptor (Subversion revision 5889)

1) Moved src/tests/utf/org to src/test/java/org

2) Copied src/tests resource files to src/test/java/resources

3) Made some code cleanup to src/test/java/org classes required post the move

4) Altered eclipse and checkstyle config files to reflect previous changes

Having said that I have no idea where ptf and ctf tests should be moved as they should not be mixed up with traditional unit tests that are now located under src/test/java as required by maven standard directory layout. As far as I understand the maven directory layout the html documents should go under site directory but there is nothing designed for documentation that need to be build first.

download with maven 2 or maven 2 anttask not working indeed (from http://www.ibiblio.org/maven2/);
modded my local .m2 repository to include castor as follows.

castor\castor\1.0\castor-1.0.jar
castor\castor\1.0\castor-1.0.pom
castor\castor-commons\1.0\castor-commons-1.0.jar
castor\castor-commons\1.0\castor-commons-1.0.pom
castor\castor-srcgen-ant-task\1.0\castor-srcgen-ant-task-1.0.jar
castor\castor-srcgen-ant-task\1.0\castor-srcgen-ant-task-1.0.pom
castor\castor-xml\1.0\castor-xml-1.0.jar
castor\castor-xml\1.0\castor-xml-1.0.pom

castor.1.0.pom:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>castor</groupId>
<artifactId>castor</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>castor</groupId>
<artifactId>castor-commons</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>castor</groupId>
<artifactId>castor-srcgen-ant-task</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>castor</groupId>
<artifactId>castor-xml</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>

castor-commons-1.0.pom:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>castor</groupId>
<artifactId>castor-commons</artifactId>
<version>1.0</version>
</project>

castor-srcgen-ant-task-1.0.pom:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>castor</groupId>
<artifactId>castor-srcgen-ant-task</artifactId>
<version>1.0</version>
</project>

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>castor</groupId>
<artifactId>castor-xml</artifactId>
<version>1.0</version>
</project>

for wath it's worth,
haroldw

Thanks, Harold. I am currently working to get deployment working through maven 2, so please bear with us a few more days .... .

The attached patch is definitely a step forward with regards to integrate Castor with Maven 2, so that Maven 2 in the end can (could) be used to deploy build artefacts into a (snapshot) Maven repository.

Comments:

• I have found a way to convince Maven 2 to think in 'modules', adding common/pom.xml, jdo/pom.xml, etc.
• At the same time, using various Maven 2 directives, it is not necessary to move sources around (at least not yet).
• Ad test integration: I am making progress to get all tests of the XML test suite running under Maven, but this is a hard fight ....

Some hints:

• it's possible to a Maven goal for the complete project, or just a sub-project.It all depends on where you are located when issueing a Maven command.
• e.g. calling mvn -Dmaven.test.skip=true package in the (new) xml directory will build a castor-1.0-xml.jar in the target directory of xml, etc.

Whilst this is not finished at all, it showcases a possible way forward without having to 'properly' break apart sources. In addition, it introduces four modules (common, jdo, xml, all) into our vocabulry. I am actually thinking about introducing a fifth, i.e. srcgen.

Nice work on this, Werner! I'm happy to see that progress is being made. My only comment is about the driving force behind using Maven.

FWIW, there's a Maven 2 book available for free from Mergere that would help us all:

http://www.mergere.com/m2book_download.jsp

This book is full of good info!

Bruce, what I have said about the main driver definitely is not meant to be exhaustive .. . There's tons of additional benefits that wait to be harvested once we have switched (or provided a Maven POM in addition to Ant for the time being).

Okay, here's a few questions where I am actually asking for help:

a) what's the feeling towards generating a separate deployment unit/module for the source generator ?
b) are there any more additional Maven modules/deployment units I have missed. If that's the case, what's a good criteria towards such a decision ? I have seen your (Ralf and Bruce) discussion the other day, and the feeling I got is that we might want (need) more.
c) What to do about those still failing JUnit tests when running under Maven ? Is there any alternative I am not aware off ?

Btw, I am planning to commit this patch rather sooner than later, so any comments appreciated .. .

Yeah, I'm fully aware that your list is not exhaustive. I've done a lot of Maven conversions in the past and I'm fairly familiar with Maven 2 already having used it a fair amount on ActiveMQ and ServiceMix now for a few months.

> a) what's the feeling towards generating a separate deployment unit/module for the source generator ?

I agree that we should have a separate artifact produced for the source generator, but I think there needs to be a deeper discussion about this topic. In fact, there's a wiki page that I created for notes on this topic here:

http://docs.codehaus.org/display/CASTOR/Subprojects

I think we should discuss this on the dev@castor mailing list.

> b) are there any more additional Maven modules/deployment units I have missed. If that's the case, what's a good criteria towards such a decision ? I
> have seen your (Ralf and Bruce) discussion the other day, and the feeling I got is that we might want (need) more.

Again, see the wiki page. This needs to be discussed because I don't believe we have any sense of completeness to the subprojects yet. IMO, there should probably be a castor-core that the JDO side and the XML side both depend upon, but I'm not sure if this makes sense. Maybe there will only be a castor-xml-core and castor-jdo-core and a castor-common - I have no idea yet. As I said above, I think we should discuss this on the dev@castor mailing list.

> c) What to do about those still failing JUnit tests when running under Maven ? Is there any alternative I am not aware off ?

We'll just need to work through them, possibly by filing JIRA issues for each failing test.

More or less done, with the notable exception of the XML core module that still needs to created. But as there's a few people working on existing code base right now (due to work on JAXB compliance), this will have to wait.