-
45. Re: Breaking up common in jboss-head
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.
-
46. Re: Breaking up common in jboss-head
This is now setup in a subversion test repository. I setup 3 projects each of which maps to a seperate subversion repository.
This can be seen here:
http://anonsvn.jboss.org/repos/
To checkout each project use the following commands:svn co http://anonsvn.jboss.org/repos/common-logging/trunk common-logging svn co http://anonsvn.jboss.org/repos/common-xb/trunk common-xb svn co http://anonsvn.jboss.org/repos/common-core/trunk common-core
To build each project simply issue a mvn install:cd common-logging mvn install cd ../common-core mvn install cd ../common-xb mvn install
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:cd common-xb svn log build.xml
-
47. Re: Breaking up common in jboss-head
My favorite log message:
$ 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)... =) ...
-
48. Re: Breaking up common in jboss-head
"rloehr@jboss.com" wrote:
To checkout each project use the following commands:svn co http://anonsvn.jboss.org/repos/common-logging/trunk common-logging svn co http://anonsvn.jboss.org/repos/common-xb/trunk common-xb svn co http://anonsvn.jboss.org/repos/common-core/trunk common-core
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:[starksm@banshee9100 workspace]$ ls common-logging-jdk/ common-logging-log4j/ common-logging-spi/ src/
I'm using the latest (0.9.108) subeclipse plugin from tigris.org.
The command line checkout works fine. -
49. Re: Breaking up common in jboss-head
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.
To follow in the fashion of point #2
In eclipse perform a svn checkout of http://anonsvn.jboss.org/repos/common-logging/trunk/common-logging-jdk
http://anonsvn.jboss.org/repos/common-logging/trunk/common-logging-spi
http://anonsvn.jboss.org/repos/common-logging/trunk/common-logging-log4j
This can be done in a single step.
Then in each of the projects
mvn install
mvn eclipse:eclipse
refresh project in eclipse -
50. Re: Breaking up common in jboss-head
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. -
51. Re: Breaking up common in jboss-head
If I am interpreting this correctly......
Checking out subprojects on a one by one basis, building and generating eclipse classpaths should not generate project references, only binary references.
e.g. logging-jdk should include a binary reference to logging spi
Maybe we can touch on this tomorrow during our call and clear up any ambiguties. -
52. Re: Breaking up common in jboss-head
Ok, we need to tie this up. What is left?
1. Merge in any changes from cvs that have occurred since the migration.
2. publish the binaries to the repository
3. Modify the build in 4.0 and head to use the repository for these jars instead of module outputs.
Anything else? -
53. Re: Breaking up common in jboss-head
The one other thing to consider is whether you will continue to maintain two distinct branches of this codebase...one for jboss-head and one for 4.0.
E.g., jboss-cache as a standalone product only publishes a single binary which is used for both head and 4.0. Will common follow the same precedence? -
54. Re: Breaking up common in jboss-head
Yes. If code needs to become jboss5 specific in the future that will require a 2.0 branch of common.
-
55. Re: Breaking up common in jboss-head
So what are the remaining issues that stop us from moving the common module from CVS to SVN?
The last IDE issue that I am aware of is that the SVN plugin for IDEA did not work as expected. Is this a showstopper? -
56. Re: Breaking up common in jboss-head
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.
-
57. Re: Breaking up common in jboss-head
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.
They setup the repo last night:
https://svn.jboss.org/repos/common/ -
58. Re: Breaking up common in jboss-head
The svn repository for common is now in sync and buildable.
https://svn.jboss.org/repos/common/trunk/
To check out and build:[rloehr@dev02 ]$ svn --username xxxx@jboss.com co https://svn.jboss.org/repos/common/trunk jboss-common ./build.sh
This matches what is currently in head.
The next steps are:
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. -
59. Re: Breaking up common in jboss-head
The artifacts have been published to the http repository.
http://repository.jboss.com/jboss/common/snapshot/
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?