RE: [JBoss-dev] creating jboss thirdparty directory
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 usage as well to complete this. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Elrod > Sent: Tuesday, May 10, 2005 8:58 PM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] creating jboss thirdparty directory ... > > I think we are there. There is already a jbossas module > defined with nothing but the new build in it. Remoting is > ready to make this move (no better time actually). If you > give the green light, I will execute what I have described > below and we will be on our way to this new path. > > As other projects break off, they can do the same. I think > with the new build process, it would also be a big help to > network as will have modular, versioned components that will > be easier to do patch updates for. > --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating jboss thirdparty directory
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 module, and import the binaries using component references. I think we are there. There is already a jbossas module defined with nothing but the new build in it. Remoting is ready to make this move (no better time actually). If you give the green light, I will execute what I have described below and we will be on our way to this new path. As other projects break off, they can do the same. I think with the new build process, it would also be a big help to network as will have modular, versioned components that will be easier to do patch updates for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Tuesday, May 10, 2005 12:55 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory 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. 3. Remove the jboss-head/remoting directory (thus making it dead in jboss-head). I can't remove the _jboss_remoting module reference from within the jboss-head project definition because of previous versions will still need to have it available, right? (based on some tag earlier on jboss-head). 4. Change the component definition for remoting to use module="JBossRemoting" instead of module="jboss-remoting" within the new build. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head-testsuite Build Failed
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: /home/cruisecontrol/work/scripts/build-jboss-head.xml:37: Exit code: 1 See tests.log in Build Artifacts for details. JAVA_HOME=/opt/j2sdk1.4.2_05/Date of build: 05/10/2005 20:50:26Time to build: 87 minutes 12 seconds Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (0)
[JBoss-dev] jboss-4.0-testsuite Build Failed
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: /home/cruisecontrol/work/scripts/build-jboss-head.xml:37: Exit code: 1 See tests.log in Build Artifacts for details. JAVA_HOME=/opt/j2sdk1.4.2_05/Date of build: 05/10/2005 19:27:07Time to build: 80 minutes 3 secondsLast changed: 05/09/2005 16:58:53Last log entry: JBAS-1795: use the blue logo instead Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (12)1.3.6.2modifiedstate:console/src/resources/webconsole.war/css/jboss.cssJBAS-1795: use the blue logo instead1.2.6.2modifiedstate:tomcat/src/webapps/ROOT.war/jboss.cssJBAS-1795: use the blue logo instead1.2.6.2modifiedstate:tomcat/src/webapps/ROOT.war/logo.gifJBAS-1795: use the blue logo instead1.3.6.1modifiedstate:console/src/resources/webconsole.war/css/jboss.cssJBAS-1795 - update logos1.1.12.1modifiedstate:console/src/resources/webconsole.war/images/jboss.gifJBAS-1795 - update logos1.2.10.1modifiedstate:console/src/resources/webconsole.war/images/logo.gifJBAS-1795 - update logos1.2.6.1modifiedstate:tomcat/src/webapps/ROOT.war/jboss.cssJBAS-1795 - update logos1.2.6.1modifiedstate:tomcat/src/webapps/ROOT.war/logo.gifJBAS-1795 - update logos1.2.8.1modifiedstate:varia/src/resources/jmx/html/images/logo.gifJBAS-1795 - update logos1.2.6.1modifiedstate:testsuite/src/resources/jmx/proxy/META-INF/jboss-service.xmlMove the injection target mbean to the end to test that the dependency does not try to use the mbean before its started.1.32.4.3modifiedstate:system/src/main/org/jboss/system/ServiceConfigurator.javaUse the MBeanProxyExt lazyInit mode for the proxy that delays the loading of the attribute info until needed. Resolves (JBAS-1784) Injected mbean dependencies do not honor the dependency contract.1.6.4.3modifiedstate:jmx/src/main/org/jboss/mx/util/MBeanProxyExt.javaAdd a lazyInit mode for the proxy that delays the loading of the attribute info until needed. Resolves (JBAS-1784) Injected mbean dependencies do not honor the dependency contract.
[JBoss-dev] jboss-3.2-jdk-matrix build.111 Build Fixed
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 Errors and Failures: (0) Modifications since last build: (0)
[JBoss-dev] jboss-head-jdk-matrix build.123 Build Fixed
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 Errors and Failures: (0) Modifications since last build: (0)
RE: [JBoss-dev] creating jboss thirdparty directory
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. That was a big mistake. So where we want to get to is that there is a jbossas cvs module that is the codebase for the jbossas server project. Its build files which can be versioned incorporate the thirdparty dependencies and associated inherent and integration code for the given jbossas version. If we had escaped from the buildtragic scheme long ago, I would checkout the jboss-4.0.x jbossas codebase using: cvs co -r Branch_4_0 -d jboss-4.0 jbossas the head version would be checked out using: cvs co -d jboss-head jbossas 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 module, and import the binaries using component references. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Elrod > Sent: Tuesday, May 10, 2005 12:55 PM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] creating jboss thirdparty directory > > 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. > > 3. Remove the jboss-head/remoting directory (thus making it > dead in jboss-head). I can't remove the _jboss_remoting > module reference from within the jboss-head project > definition because of previous versions will still need to > have it available, right? (based on some tag earlier on jboss-head). > > 4. Change the component definition for remoting to use > module="JBossRemoting" instead of module="jboss-remoting" > within the new build. > --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating jboss thirdparty directory
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. 3. Remove the jboss-head/remoting directory (thus making it dead in jboss-head). I can't remove the _jboss_remoting module reference from within the jboss-head project definition because of previous versions will still need to have it available, right? (based on some tag earlier on jboss-head). 4. Change the component definition for remoting to use module="JBossRemoting" instead of module="jboss-remoting" within the new build. Scott M Stark wrote: 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 jbossas/microcontainer jbossas/naming jbossas/remoting ... I'm never going to use the _jboss_remoting by itself, so it should not exist as a top level module. We also need a cvs module naming convention as I have no idea what all this crap is: [EMAIL PROTECTED]:~$ ls -1 /cvsroot/jboss/ admin aop applications Attic blocks-jboss build build-jboss buildmagic cheese cluster-jboss common common-jboss console container contrib CVS CVSROOT docbook-support ecperf hibernate javassist jaxrpc jboss jboss-3.2 JBoss-3.2 jboss-admin-console jboss-all jboss-aop jboss-aop-eclipse jbossas jboss-aspects jboss-blocks jbossbuild jboss-cache JBossCache jboss-common jboss-compatibility jboss-console jbosscx jboss_deployment jboss-deployment jboss-docs jboss-ejb jboss-ejb3 jboss-ejb3x jboss-head jbosside jboss-j2ee jboss-j2se jboss-jms jboss-mail jboss-management jboss-mbeans jboss-media jbossmq jbossmqadmin jbossmqbench jbossmx jboss-persistence jbosspool jboss-portal jboss-portal-docs _jboss-portal-setup jboss-portal-thirdparty jboss-portal-tools jboss-profiler jboss-remoting JBossRemoting jboss-seam jboss-site jbosssx jboss-system jbosstest jboss-tomcat jboss-transaction jboss-v3.2.x jboss-xdoclet jbportal-upgrade jmx jmx2 jmx-remoting jnp jrunit junitejb manual microkernel netboot-demo newsite nukes nukes-2 nukes-2-thirdparty nukes-docs nukes-thirdparty nukes-tools nukes-website opennms person pn-website repository.jboss.com specj sun-ejb system2 test thirdparty tools tools-win32 webservice website website-forums website-snapshots website-survey wiki2html xpetstore-ejb3 xpetstore-ejb3.0 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Tuesday, May 10, 2005 11:42 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory 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 for a better name. This will contain only the integration code between JBossRemoting and JBossAS. Then I will declare another entry for JBossRemoting, which has the old alias remoting. This is so the new build will work. I will also need to add a new component for the remoting-integration. So, the new CVSROOT/modules would have the following entries: _jboss_remoting -d remoting-integration jboss-remoting-integration JBossRemoting -d remoting jboss-remoting Will also have to change the component declarations within the new build to have: module="jboss-remoting-integration" version="5.0-SNAPSHOT" > I don't think the JBossRemoting project is getting built via cruise control, so the jboss-remoting.jar snapshot will not be getting updated until we can get this added. Will also need to have it add jboss-remoting-integration.jar as well. Is there anything else I am missing for this to work? Once this change is made, am not sure exactly what people will need to get the update view of the source. Go to jboss-head root directory and run 'cvs co remoting'? Guess will need to do same thing for thirdparty (to get thirdparty/jboss/remoting/lib/jboss-remoting.jar)? --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This
RE: [JBoss-dev] creating jboss thirdparty directory
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 jbossas/microcontainer jbossas/naming jbossas/remoting ... I'm never going to use the _jboss_remoting by itself, so it should not exist as a top level module. We also need a cvs module naming convention as I have no idea what all this crap is: [EMAIL PROTECTED]:~$ ls -1 /cvsroot/jboss/ admin aop applications Attic blocks-jboss build build-jboss buildmagic cheese cluster-jboss common common-jboss console container contrib CVS CVSROOT docbook-support ecperf hibernate javassist jaxrpc jboss jboss-3.2 JBoss-3.2 jboss-admin-console jboss-all jboss-aop jboss-aop-eclipse jbossas jboss-aspects jboss-blocks jbossbuild jboss-cache JBossCache jboss-common jboss-compatibility jboss-console jbosscx jboss_deployment jboss-deployment jboss-docs jboss-ejb jboss-ejb3 jboss-ejb3x jboss-head jbosside jboss-j2ee jboss-j2se jboss-jms jboss-mail jboss-management jboss-mbeans jboss-media jbossmq jbossmqadmin jbossmqbench jbossmx jboss-persistence jbosspool jboss-portal jboss-portal-docs _jboss-portal-setup jboss-portal-thirdparty jboss-portal-tools jboss-profiler jboss-remoting JBossRemoting jboss-seam jboss-site jbosssx jboss-system jbosstest jboss-tomcat jboss-transaction jboss-v3.2.x jboss-xdoclet jbportal-upgrade jmx jmx2 jmx-remoting jnp jrunit junitejb manual microkernel netboot-demo newsite nukes nukes-2 nukes-2-thirdparty nukes-docs nukes-thirdparty nukes-tools nukes-website opennms person pn-website repository.jboss.com specj sun-ejb system2 test thirdparty tools tools-win32 webservice website website-forums website-snapshots website-survey wiki2html xpetstore-ejb3 xpetstore-ejb3.0 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Elrod > Sent: Tuesday, May 10, 2005 11:42 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] creating jboss thirdparty directory > > 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 for a > better name. This will contain only the integration code > between JBossRemoting and JBossAS. > > Then I will declare another entry for JBossRemoting, which > has the old alias remoting. This is so the new build will > work. I will also need to add a new component for the > remoting-integration. > > So, the new CVSROOT/modules would have the following entries: > > _jboss_remoting -d remoting-integration > jboss-remoting-integration > JBossRemoting -d remoting jboss-remoting > > Will also have to change the component declarations within > the new build to have: > > module="jboss-remoting-integration" > version="5.0-SNAPSHOT" >> >release="server/all/lib"/> > > > module="jboss-remoting" > version="5.0-SNAPSHOT" >> > > > > I don't think the JBossRemoting project is getting built via > cruise control, so the jboss-remoting.jar snapshot will not > be getting updated until we can get this added. Will also > need to have it add jboss-remoting-integration.jar as well. > > Is there anything else I am missing for this to work? Once > this change is made, am not sure exactly what people will > need to get the update view of the source. Go to jboss-head > root directory and run 'cvs co remoting'? Guess will need to > do same thing for thirdparty (to get > thirdparty/jboss/remoting/lib/jboss-remoting.jar)? > > --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Let's lose this x-x naming convention in the newrepository
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 PROTECTED] On > Behalf Of Adrian Brock > Sent: Tuesday, May 10, 2005 11:28 AM > To: jboss-development@lists.sourceforge.net > Subject: Re: [JBoss-dev] Let's lose this x-x naming > convention in the newrepository > > I though we'd *already* dropped this scheme? > e.g. trove would have been gnu-trove under the old scheme. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating jboss thirdparty directory
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 for a better name. This will contain only the integration code between JBossRemoting and JBossAS. Then I will declare another entry for JBossRemoting, which has the old alias remoting. This is so the new build will work. I will also need to add a new component for the remoting-integration. So, the new CVSROOT/modules would have the following entries: _jboss_remoting -d remoting-integration jboss-remoting-integration JBossRemoting -d remoting jboss-remoting Will also have to change the component declarations within the new build to have: module="jboss-remoting-integration" version="5.0-SNAPSHOT" > I don't think the JBossRemoting project is getting built via cruise control, so the jboss-remoting.jar snapshot will not be getting updated until we can get this added. Will also need to have it add jboss-remoting-integration.jar as well. Is there anything else I am missing for this to work? Once this change is made, am not sure exactly what people will need to get the update view of the source. Go to jboss-head root directory and run 'cvs co remoting'? Guess will need to do same thing for thirdparty (to get thirdparty/jboss/remoting/lib/jboss-remoting.jar)? Scott M Stark wrote: That is fine, but I'm creating a jbossbuild script that will generate the legacy thirdparty structure from the repository to get rid of the existing thirdparty cvs tree. I would like to have the option of not having to checkout the legacy thirdparty tree as part of the jboss-4.0/jboss-head co and instead build this on demand based on a synchronize target to avoid having to duplicate where thirdparty jars need to be checked in. I guess this will require a new cvs module alias (at least for jboss-4.0) to avoid breaking the build of existing releases. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Monday, May 09, 2005 1:34 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] creating jboss thirdparty directory Since I am now doing all new development in the JBossRemoting module, which is stand alone, I would like to make a few changes as to how jboss-head picks up the remoting code. First, I would like to make the remoting code visible to jboss-head as a binary. For the old build, this means adding it to the thirdparty directory and changing the old build scripts for the modules that need remoting to include the remoting jar from the thirdparty directory. I was going to create a new directory that looked something like: thirdparty/jboss/remoting/lib/jboss-remoting.jar For the new build, can just include the pointer to the repository for the remoting jar. I also want to keep the jboss-head/remoting directory, but make it contain the code for integration between JBossAS and JBossRemoting. So I will be removing almost all of the code that is currently there (which is the core remoting code currently). Please let me know if this is going to be a problem or if you have any other suggestions on how to do this. Thanks. -Tom --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Let's lose this x-x naming convention in the new repository
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 > 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 add any > new occurences. > > > Scott Stark > Chief Technology Officer > JBoss Inc. > > > > > --- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_ids93&alloc_id281&op=click > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Let's lose this x-x naming convention in the new repository
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 add any new occurences. Scott Stark Chief Technology Officer JBoss Inc. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
