We need to lose the redundant naming convention seen on a number of the
thirdparty directories:
beanshell-beanshell
dom4j-dom4j
jacorb-jacorb
javagroups-javagroups
etc. Let's not continue this naming convention any further. I don't
think its worth renaming these at this point, but no reason to
I though we'd *already* dropped this scheme?
e.g. trove would have been gnu-trove under the old scheme.
On Tue, 2005-05-10 at 14:20, Scott M Stark wrote:
We need to lose the redundant naming convention seen on a number of the
thirdparty directories:
beanshell-beanshell
dom4j-dom4j
I have the old build ready locally for both the jboss-head and
JBossRemoting. Now I need to change the CVSROOT/modules file. I want
to take the _jboss_remoting module (the current one under jboss-head)
and rename the alias to something like remoting-integration. Could
really use suggestions
Some of the legacy thirdparty names were recreated in the new
repository.jboss.com as all that I listed are there. Newer additions are
not progating this, but I wanted to be sure its clearly stated that it
was a bad convention.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
We need to stop using the cvs module as the merge mechanism. I don't
think integration code should be a seperate cvs module. I would view it
as code inherent to jbossas, so the integration code for the various
services should just be subdirectories of the jbossas module:
jbossas/build
So you want?
1. The jboss-head/remoting directory and its contents (which now only
contains integration code on my local disk) to be moved under the
jboss-head/jbossas directory (including src/main and src/tests).
2. Then update the jbossas build so it will be its new remoting
subdirectory.
So the first change in perspective is that there is no jboss-head,
jboss-4.0, etc as these are hacks around the fact that the jbossas
definition is a composite of independent modules that could not be
maintained from a versioned build descriptor because of the mistep of
using the cvs modules file.
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20050510185024Lbuild.123
BUILD COMPLETE-build.123Date of build:05/10/2005 18:50:24Time to build:19 minutes 55 seconds
Unit Tests: (0) Total
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-jdk-matrix?log=log20050510191037Lbuild.111
BUILD COMPLETE-build.111Date of build:05/10/2005 19:10:37Time to build:16 minutes 17 seconds
Unit Tests: (0) Total
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20050510192707
BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:66: The following error occurred while executing this line:
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite?log=log20050510205026
BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:66: The following error occurred while executing this line:
Now the problem is how we get there. Its going to take the creation of a
jbossas cvs module and copying the existing inherent and integration
code modules into jbossas so as not to lose cvs history. As features
like remoting and cache are broken out, we add the integration code to
the jbossas
Yes, go ahead. After I finish the 4.0 thirdparty setup I'll migrate it
to the jbossas build on head as well. The code that will continue to
live in jbossas like the legacy ejb container, jbossmq, etc. should be
copied into the jbossas module with its cvs history to get rid of the
modules file
13 matches
Mail list logo
