The org.jboss.logging.util.* depending on log4j need to be moved to the common-logging-log4j module. Any uses of these classes needs to be replaced with common-logging-spi variants as there should be no log4j depdencies outside of the common-logging-log4j module.

Some of the points to notice are that the logging project was created in the nested format (3 subprojects). Once a project is in subversion it trivial to change the structure and retain all history or remove additional files (e.g. legacy build files).

Another point to note is that all history is available for these files. To view an example of this:

$ svn log http://anonsvn.jboss.org/repos/common-logging/trunk
...
------------------------------------------------------------------------
r19 | user57 | 2002-02-16 07:47:06 -0500 (Sat, 16 Feb 2002) | 7 lines
o i just can't stop... i want to sleep, but I can't stop... ahhh
caffeine was my friend about 3 hours ago, but now its like that buddy
who isn't really your friend that keeps eating all of your chips and
cookies that dosen't know when to get the hell out of your house. Well
I am about to take him out side and smack him up side the head with a
baseball bat (and then go steal his car)... =)
...

If I checkout the http://anonsvn.jboss.org/repos/common-logging/trunk using the eclipse import/checkout project from svn I get an unusable common-logging project. There is no common-logging root directory and the pom.xml and other toplevel files are missing:

I was not able to replicate the error, when checking out in the same fashion I received all of the files. However I did see this once before when checking out from the command line. I'll dig further to see if others have has similiar svn issues.

However....

I wanted to make sure and include a nested style project to hash out how it would work with eclipse. If the checkout in the above fashion did work, it still would not be of use as eclipse doesn't handle the nested structures.

There are two ways of dealing with this (from maven docs on eclipse integration:

1) Check out the whole project from the command line, run mvn eclipse:eclipse. Then import the subprojects into your eclipse workspace.

2) In case of large projects with many people it can be quite tedious to check out all modules and keep them up to date. Especially if you are only interested in one or two modules. In this case using binary dependencies is much more comfortable. Just check out the modules you want to work on with eclipse and run mvn eclipse:eclipse for each module (see also Maven as an external tool). Of course all referenced artifacts have to be available from your maven repository. This includes the top level pom file.

What does not work is using the File/Import/Checkout Projects from SVN

If I checkout the contents using the svn explorer view the structures are fine. After running install and the mvn eclipse:eclipse command, I don't see that the project references are correct. For example, the common-logging-jdk project does not have a reference to the common-logging-spi project.

1. Merge in any changes from cvs that have occurred since the migration.2. publish the binaries to the repository3. Modify the build in 4.0 and head to use the repository for these jars instead of module outputs.

Nothing. We just need to synchronize cvs/svn and then update the existing usage to depend on the binary. For the 4.0.4.GA just leave the 4.0 branch common alone. We can look to update this in the next release.

Since the repos were out of sync I've asked IT to create a new one for me and reimport the source. Once the source is there I'll fix the build so that it is standalone and we can publish an artifact to the http repository. At this point development can begin out of subversion. We can then safely perform any refactoring and not worry about syncing code between two version control systems.

1) publish the artifacts to the http repository 2) test them with 4.0 and head 3) announce this change to the dev list 4) cut off cvs write access

For something like common which we are extracting for the first time will we start off its versioning with a 1.0.0 version? I've also queried Alex as regards to what the version of JBossXB should be. I'm assuming it will be snapshot for now.

I've made changes locally to allow head and 4.0 to build from the thirdparty artifacts. Head works fine.

The 4.0 branch is not in sync with head though. For example in the common module for head we have a package org.jboss.util.collection which contains a class, CollectionsFactory. This is not present in the 4.0 branch.

What is the best way to handle this?

Publish two seperate sets of artifacts (1 for head, 1 for 4.0) or to go ahead and cutover and then adjust 4.0 source errors as necessary?