RE: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory
On Fri, 2005-05-13 at 00:59, Scott M Stark wrote: The jbossas module I have been talking about is a testcase for validating the breakout of the current jboss-head to validate use of the repository. I thought that is what this module was for and had no other uses. So let's clarify its current purpose. Is jbossas being used for anything? jbossas was a module I introduced to support the new build during the transition. It replaces the build module as the top level build information in the cvs repository. In terms of monolithic vs modular, I think were in agreement as the only source I am envisioning is the integration and management code. I am suggesting the legacy code that will never be standalone just be in jbossas as least initially. If your arguing that everything should be seperated from the start, ok, let's discuss it. The only thing that has been done as far as I know if removal of remoting from jboss-head to introduce the binary. I'm only working on reproducing the legacy thirdparty binary structure for use with the 4.0 build. Source trees have been added to the top level build and I thought you suggested that everything should be in one cvs module. I agree that that CVSROOT/modules is not the place to define the project struture. Equally, a directory structure inside a cvs module is not the place either. The correct place to define the project structure is in the versioned ant files for the top level builds and the referenced components. We need to clarify who is working on what. I don't think there is any real work to setup the next generation build right now. Maybe there is confusion over what jbossas currently is being used for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Thursday, May 12, 2005 5:19 PM To: jboss-development@lists.sourceforge.net Subject: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory Ok, so I missed this post. Why are we changing the build structure before we have the new build in place and for untested/unvalidated/undiscussed requirements? My concerns (basically trying to run before we can walk): 1) We still don't have a new build that reproduces the old build 2) Some of the changes we have discussed or articulated are being done almost without people getting chance to respond or review 3) None of these changes has any experiments or use case descriptions showing how it will work. I'm confused, god knows about the other developers who are less involved in the project or paying less attention to the discussions? e.g. a use case I described for the new build, and I thought Scott articulated in his original response to this thread was the following: I want to test a patch to jboss-4.0.5 with the new build without going through all the tedium of a full rebuild/recompile on every small change. With the new build, the way I envisioned it was it would work as follows: 1) Download the main structure from the relevent branch cvs co -r JBoss_4_0_5 jbossas cd jbossas 2) Tell the build system I'm only interested in binaries by editing my local properties and retrieve the binaries ant synchronize 4) Build the release from the binaries ant release 5) Checkout the module I want to patch as source make my changes and recompile ant release 6) Run all the tests in all the projects (the tests are binary artifacts/jars in the repository) ant test How is this going to be possible if everything is in one module under cvs? Equally, how does this work with other integrations like jbossas + portal jbossas + seam etc. that have their own notion of the build totality. e.g. I would doubt portal wants to build jbossas from source! Also, I've been arguing for a while now that putting everything in one big ball of mud (as Andy calls it) just leads to everybody referencing everybody else and an integration/dependency nightmare. I see this only getting worse if everything is under one source tree. What I'd like to see before we make more changes are: 1) A working new build 2) Definition of build uses cases/procedures/requirements 3) Experiments that show these are supported and work 4) A dry run through the whole release cycle to show the process is working By a dry run, I mean smaller test project(s) where we can experiment/test the procedures and use cases before implementing them with our real projects. Rather than hoping that the new build will eventually support what you are trying to do. --- 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_ids93alloc_id281op=click ___ JBoss
Re: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory
Scott M Stark wrote: ... The only thing that has been done as far as I know if removal of remoting from jboss-head to introduce the binary. Correct. I did two things. 1. Added remoting binary and changed the current builds to use the library instead of the module. 2. Added new integration code under jbossas/remoting directory. There are only a few files (for new aspect interceptor for remoting and security domain factory), which don't belong in core remoting. As for who is doing what, I'm done with anything build related for the time being. The only thing I have left to do is figure out if/when I want to use the new build in JBossRemoting for my test runs (which has been discussed on the build forum), but am going to wait till the new build is further along before tackling this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Thursday, May 12, 2005 5:19 PM To: jboss-development@lists.sourceforge.net Subject: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory Ok, so I missed this post. Why are we changing the build structure before we have the new build in place and for untested/unvalidated/undiscussed requirements? My concerns (basically trying to run before we can walk): 1) We still don't have a new build that reproduces the old build 2) Some of the changes we have discussed or articulated are being done almost without people getting chance to respond or review 3) None of these changes has any experiments or use case descriptions showing how it will work. I'm confused, god knows about the other developers who are less involved in the project or paying less attention to the discussions? e.g. a use case I described for the new build, and I thought Scott articulated in his original response to this thread was the following: I want to test a patch to jboss-4.0.5 with the new build without going through all the tedium of a full rebuild/recompile on every small change. With the new build, the way I envisioned it was it would work as follows: 1) Download the main structure from the relevent branch cvs co -r JBoss_4_0_5 jbossas cd jbossas 2) Tell the build system I'm only interested in binaries by editing my local properties and retrieve the binaries ant synchronize 4) Build the release from the binaries ant release 5) Checkout the module I want to patch as source make my changes and recompile ant release 6) Run all the tests in all the projects (the tests are binary artifacts/jars in the repository) ant test How is this going to be possible if everything is in one module under cvs? Equally, how does this work with other integrations like jbossas + portal jbossas + seam etc. that have their own notion of the build totality. e.g. I would doubt portal wants to build jbossas from source! Also, I've been arguing for a while now that putting everything in one big ball of mud (as Andy calls it) just leads to everybody referencing everybody else and an integration/dependency nightmare. I see this only getting worse if everything is under one source tree. What I'd like to see before we make more changes are: 1) A working new build 2) Definition of build uses cases/procedures/requirements 3) Experiments that show these are supported and work 4) A dry run through the whole release cycle to show the process is working By a dry run, I mean smaller test project(s) where we can experiment/test the procedures and use cases before implementing them with our real projects. Rather than hoping that the new build will eventually support what you are trying to do. --- 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_ids93alloc_id281op=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=7393alloc_id=16281op=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
Its done (will send out e-mail about the changes in a minute). The only issue now is exactly how we want to include jboss binaries within thirdparty. Right now, the entry brining in the jboss-remoting.jar is defined as: _thirdparty_jboss_remoting -d jboss thirdparty/jboss and _thirdparty_jboss_remoting is included in the _jboss_thirdparty definition. This means that a checkout of jboss-head will create: thridparty/jboss/aop/lib/jboss-aop.jar thridparty/jboss/aop/lib/jboss-aspect-library.jar thridparty/jboss/plastic/lib/ thridparty/jboss/remoting/lib/jboss-remoting.jar As far as I can tell, the thirdparty/jboss/aop is for 4.0 and is defined as: _binary_jboss_aop -d jboss-aop thirdparty/jboss/aop so that there is thirdparty/jboss-aop/lib/jboss-aop.jar thirdparty/jboss-aop/lib/jboss-aspect-library.jar Should I leave jboss-head the way it is or change to match the way aop is included in 4.0? Really just down to whether we want a bunch of thridparty/jboss-XXX directories or thirdparty/jboss/XXX with some of the XXX directories not being needed. BTW, looks like HEAD build is broken due to: C:\tmp\jboss-head2\jboss-head\aspects\src\main\org\jboss\aspects\security\AuthenticationInterceptor. java:43: cannot resolve symbol symbol : constructor SecurityException (java.security.GeneralSecurityException) location: class java.lang.SecurityException throw new SecurityException(gse); Scott M Stark wrote: 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_ids93alloc_id281op=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=7393alloc_id=16281op=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 personally would rather have a more heirachical structure in the thirdparty repository. We matched the existing flattened structure for easier integration with the existing build stuff so far, but for the jboss binaries I would go back to a tree. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Thursday, May 12, 2005 11:21 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory Its done (will send out e-mail about the changes in a minute). The only issue now is exactly how we want to include jboss binaries within thirdparty. Right now, the entry brining in the jboss-remoting.jar is defined as: _thirdparty_jboss_remoting -d jboss thirdparty/jboss and _thirdparty_jboss_remoting is included in the _jboss_thirdparty definition. This means that a checkout of jboss-head will create: thridparty/jboss/aop/lib/jboss-aop.jar thridparty/jboss/aop/lib/jboss-aspect-library.jar thridparty/jboss/plastic/lib/ thridparty/jboss/remoting/lib/jboss-remoting.jar As far as I can tell, the thirdparty/jboss/aop is for 4.0 and is defined as: _binary_jboss_aop -d jboss-aop thirdparty/jboss/aop so that there is thirdparty/jboss-aop/lib/jboss-aop.jar thirdparty/jboss-aop/lib/jboss-aspect-library.jar Should I leave jboss-head the way it is or change to match the way aop is included in 4.0? Really just down to whether we want a bunch of thridparty/jboss-XXX directories or thirdparty/jboss/XXX with some of the XXX directories not being needed. BTW, looks like HEAD build is broken due to: C:\tmp\jboss-head2\jboss-head\aspects\src\main\org\jboss\aspec ts\security\AuthenticationInterceptor. java:43: cannot resolve symbol symbol : constructor SecurityException (java.security.GeneralSecurityException) location: class java.lang.SecurityException throw new SecurityException(gse); Scott M Stark wrote: 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_ids93alloc_id281op=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=7393alloc_id=16281op=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_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory
Ok, so I missed this post. Why are we changing the build structure before we have the new build in place and for untested/unvalidated/undiscussed requirements? My concerns (basically trying to run before we can walk): 1) We still don't have a new build that reproduces the old build 2) Some of the changes we have discussed or articulated are being done almost without people getting chance to respond or review 3) None of these changes has any experiments or use case descriptions showing how it will work. I'm confused, god knows about the other developers who are less involved in the project or paying less attention to the discussions? e.g. a use case I described for the new build, and I thought Scott articulated in his original response to this thread was the following: I want to test a patch to jboss-4.0.5 with the new build without going through all the tedium of a full rebuild/recompile on every small change. With the new build, the way I envisioned it was it would work as follows: 1) Download the main structure from the relevent branch cvs co -r JBoss_4_0_5 jbossas cd jbossas 2) Tell the build system I'm only interested in binaries by editing my local properties and retrieve the binaries ant synchronize 4) Build the release from the binaries ant release 5) Checkout the module I want to patch as source make my changes and recompile ant release 6) Run all the tests in all the projects (the tests are binary artifacts/jars in the repository) ant test How is this going to be possible if everything is in one module under cvs? Equally, how does this work with other integrations like jbossas + portal jbossas + seam etc. that have their own notion of the build totality. e.g. I would doubt portal wants to build jbossas from source! Also, I've been arguing for a while now that putting everything in one big ball of mud (as Andy calls it) just leads to everybody referencing everybody else and an integration/dependency nightmare. I see this only getting worse if everything is under one source tree. What I'd like to see before we make more changes are: 1) A working new build 2) Definition of build uses cases/procedures/requirements 3) Experiments that show these are supported and work 4) A dry run through the whole release cycle to show the process is working By a dry run, I mean smaller test project(s) where we can experiment/test the procedures and use cases before implementing them with our real projects. Rather than hoping that the new build will eventually support what you are trying to do. On Wed, 2005-05-11 at 00:51, Scott M Stark wrote: 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_ids93alloc_id281op=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=7393alloc_id=16281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory
The jbossas module I have been talking about is a testcase for validating the breakout of the current jboss-head to validate use of the repository. I thought that is what this module was for and had no other uses. So let's clarify its current purpose. Is jbossas being used for anything? In terms of monolithic vs modular, I think were in agreement as the only source I am envisioning is the integration and management code. I am suggesting the legacy code that will never be standalone just be in jbossas as least initially. If your arguing that everything should be seperated from the start, ok, let's discuss it. The only thing that has been done as far as I know if removal of remoting from jboss-head to introduce the binary. I'm only working on reproducing the legacy thirdparty binary structure for use with the 4.0 build. We need to clarify who is working on what. I don't think there is any real work to setup the next generation build right now. Maybe there is confusion over what jbossas currently is being used for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Thursday, May 12, 2005 5:19 PM To: jboss-development@lists.sourceforge.net Subject: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory Ok, so I missed this post. Why are we changing the build structure before we have the new build in place and for untested/unvalidated/undiscussed requirements? My concerns (basically trying to run before we can walk): 1) We still don't have a new build that reproduces the old build 2) Some of the changes we have discussed or articulated are being done almost without people getting chance to respond or review 3) None of these changes has any experiments or use case descriptions showing how it will work. I'm confused, god knows about the other developers who are less involved in the project or paying less attention to the discussions? e.g. a use case I described for the new build, and I thought Scott articulated in his original response to this thread was the following: I want to test a patch to jboss-4.0.5 with the new build without going through all the tedium of a full rebuild/recompile on every small change. With the new build, the way I envisioned it was it would work as follows: 1) Download the main structure from the relevent branch cvs co -r JBoss_4_0_5 jbossas cd jbossas 2) Tell the build system I'm only interested in binaries by editing my local properties and retrieve the binaries ant synchronize 4) Build the release from the binaries ant release 5) Checkout the module I want to patch as source make my changes and recompile ant release 6) Run all the tests in all the projects (the tests are binary artifacts/jars in the repository) ant test How is this going to be possible if everything is in one module under cvs? Equally, how does this work with other integrations like jbossas + portal jbossas + seam etc. that have their own notion of the build totality. e.g. I would doubt portal wants to build jbossas from source! Also, I've been arguing for a while now that putting everything in one big ball of mud (as Andy calls it) just leads to everybody referencing everybody else and an integration/dependency nightmare. I see this only getting worse if everything is under one source tree. What I'd like to see before we make more changes are: 1) A working new build 2) Definition of build uses cases/procedures/requirements 3) Experiments that show these are supported and work 4) A dry run through the whole release cycle to show the process is working By a dry run, I mean smaller test project(s) where we can experiment/test the procedures and use cases before implementing them with our real projects. Rather than hoping that the new build will eventually support what you are trying to do. --- 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_ids93alloc_id281op=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: component id=remoting-integration module=jboss-remoting-integration version=5.0-SNAPSHOT artifact id=jboss-remoting-integration.jar release=server/all/lib/ /component component id=remoting module=jboss-remoting version=5.0-SNAPSHOT artifact id=jboss-remoting.jar release=server/all/lib/ /component 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_ids93alloc_id281op=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=7393alloc_id=16281op=click
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: component id=remoting-integration module=jboss-remoting-integration version=5.0-SNAPSHOT artifact id=jboss-remoting-integration.jar release=server/all/lib/ /component component id=remoting module=jboss-remoting version=5.0-SNAPSHOT artifact id=jboss-remoting.jar release=server/all/lib/ /component 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_ids93alloc_id281op=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: component id=remoting-integration module=jboss-remoting-integration version=5.0-SNAPSHOT artifact id=jboss-remoting-integration.jar release=server/all/lib/ /component component id=remoting module=jboss-remoting version=5.0-SNAPSHOT artifact id=jboss-remoting.jar release=server/all/lib/ /component 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
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_ids93alloc_id281op=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_ids93alloc_id281op=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=7393alloc_id=16281op=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
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_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[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
RE: [JBoss-dev] creating jboss thirdparty directory
Tom, JBossCache is in the same boat. Scott has mentioned that he will take care of that soon. So I will let him chime in on this one. Cheers, -Ben -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_ids93alloc_id281op=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
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_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
