Re: Geronimo subprojects?
On 5/28/05, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> I think that people would like to see components broken down so that
> they can mix-n-match the pieces that they want, rather than having to
> always swallow the whole enchilada.
>
> The question then is, how do you break up these pieces so that we can
> support this.
Very well said, Alan.
As a group excercise, and just to make sure everyone involved
understands this discussion, I think that all involved should come to
Colorado to experience Big Head Todd and the Montsters on June 4 at
Red Rocks Amphitheatre. We can commense a meeting that afternnoon. ;-)
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Geronimo subprojects?
On 5/28/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Each subproject has an inherent amount of overhead. For example,
> each subproject needs a separate project management committee, each
> one will need to produce releases (not an easy task) and so on. I
> would sat that "there is a demonstrated desire" when we have enough
> people showing up to handle the overhead and work on the code. I
> personally would say one person is not enough, and seven is more then
> enough.
I don't think that every subproject needs it's own PMC unless it's a
subproject wholly separate from the existing Geronimo modules. For
example, if the Spring kernel were brought in as a subproject, it
would need its own PMC, but I don't think splitting up the existing
modules and forming individual PMCs is necessary.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Java One?
On May 28, 2005, at 1:43 PM, Jeff Genender wrote: Its getting close to the big event... Should we be thinking about a small Geronimo get-together for some beers? How about a big Geronimo get together for some beers? I'm in. geir I hear the IBM guys are celebrating by buying a night of libations (j/k)! It would be great to meet everyone. Should we plan a place and meeting time? Jeff -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
I think that people would like to see components broken down so that they can mix-n-match the pieces that they want, rather than having to always swallow the whole enchilada. The question then is, how do you break up these pieces so that we can support this. Regards, Alan David Jencks wrote, On 5/28/2005 1:57 PM: So far I am completely unconvinced by any arguments in this thread. As a thought experiment, lets suppose we had already released a certified geronimo, say last month, and we had solved most of our build problems, say with maven2. So, we have a certified branch and trunk, and all the geronimo developers are happily working on new features on trunk. In this scenario exactly what needs changing and why? thanks david jencks On May 28, 2005, at 10:38 AM, Dain Sundstrom wrote: On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote: Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. Absolutely My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? It depends on the specifications the subproject is implementing and if Sun has a stand-alone tck for the specifications. For example, if it were the Geronimo 'just a webserver edition' we could certify it for servlets and jsp because they have standalone tcks, but if it were tx and jca we could not certify it since there are no standalone tcks for those specs. On the other hand, I'm sure if enough people are interested, sufficient pressure could be applied to Sun to carve a stand-alone tck out of the j2ee monolith. ~ 2. In stating "there is a demonstrated desire", what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a "demonstrated desire" to have? Each subproject has an inherent amount of overhead. For example, each subproject needs a separate project management committee, each one will need to produce releases (not an easy task) and so on. I would sat that "there is a demonstrated desire" when we have enough people showing up to handle the overhead and work on the code. I personally would say one person is not enough, and seven is more then enough. Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). I think there are technical and realistic limits to this. Some modules are simply to small to be full projects. For example the rmi classloadder is like 5 classes. Also some modules naturally fit together and have a high degree of coupling. For example the Tx manager and the j2ca implementation naturally fit together. Now you can use the Tx manager standalone, but you can't really use j2ca without a Tx manager. Because of that linking the modules normally move together. I would say we put both in one sub project and have them release two jars. -dain
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: | So far I am completely unconvinced by any arguments in this thread. | | As a thought experiment, lets suppose we had already released a | certified geronimo, say last month, and we had solved most of our build | problems, say with maven2. So, we have a certified branch and trunk, | and all the geronimo developers are happily working on new features on | trunk. | | In this scenario exactly what needs changing and why? | | thanks | david jencks | I don't believe there's anything wrong with your 'thought experiment'. My view is, however, that never is there work to be done everywhere in a project. Taking your scenario above - all developers are happily working on new features on trunk and there's a security problem in a particular module. What went from "there's nothing wrong with this approach" now shifts to "we need to get this fixed as soon as possible" for a particular module. Again, this is most certainly doable with the structure as-is. However, a faster fix/test/release cycle would be possible if the module was able to handle it at that level instead of involving the whole of geronimo's code and developer base for everything from "if your code involves this module" (perhaps a 'new feature' not in any way involved with what the bug is) to testing and documentation. I don't think there is a "right" or "wrong" way to do it. Both work. I personally believe smaller is better - then integrate. I also believe this would promote multiple 'pre-built' deployment options (not "make it possible", just promote). But I'm only one person. Just proposing options for greater flexibility. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmLSJaCoPKRow/gARAg35AJ9IfDwevATEMfyEuwv2JWMVoHygugCdFmLU qat86jpRD2Qu4ifDT4Upe48= =gXBM -END PGP SIGNATURE-
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | |> My questions at the root of this are: |> ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of |> a 'minimal' Geronimo? Is it able to claim anything with regard to the |> TCK? | | | It depends on the specifications the subproject is implementing and if | Sun has a stand-alone tck for the specifications. For example, if it | were the Geronimo 'just a webserver edition' we could certify it for | servlets and jsp because they have standalone tcks, but if it were tx | and jca we could not certify it since there are no standalone tcks for | those specs. Understood. My main question was if there was some sort of 'prohibition' on the use of 'full system' pass/fail statistics for those pieces that do, in fact, have their own tcks. [I don't view this as a roadblock to anything, but a definite plus if each individual piece that was able (due to having and passing their own tcks) could state it passes.] | | On the other hand, I'm sure if enough people are interested, sufficient | pressure could be applied to Sun to carve a stand-alone tck out of the | j2ee monolith. This I would see as a 'good thing'. Amazing how software has progressed (*cough*) to 'smaller components combined into larger applications', but tests (even certifications) aren't quite there yet. | |> ~ 2. In stating "there is a demonstrated desire", what roadblocks or |> opposition is there to having each of the current modules (short of the |> kernel, common, core and presumably deployment - and anything else |> needed for the server to start-up and do nothing) each be |> 'self-contained'? Obviously the 'base' server would have to know what |> it's really capable of (unless you go off the deep end with discovery), |> but over and above that base it seems that a WebConnector - be it Jetty |> for user 1 or Tomcat for user 2 may be used with or without Naming, with |> or without Spring and/or Transactions, etc. Why would there be a need to |> limit modules just to what there is a "demonstrated desire" to have? | | | Each subproject has an inherent amount of overhead. For example, each | subproject needs a separate project management committee, each one will | need to produce releases (not an easy task) and so on. I would sat | that "there is a demonstrated desire" when we have enough people | showing up to handle the overhead and work on the code. I personally | would say one person is not enough, and seven is more then enough. Agreed. My view here would be to take the position "Here is the 'best laid plan', who is willing to make it work" instead of "Here is how people are working, what's the best plan we can come up with that doesn't affect that". Granted, there will probably be pieces that should probably be split out without resources to manage it, but if you aim high you have a better chance of getting an optimal solution in place. And nothing says that this can't be further refined down the road. | |> Making everything as small and self-contained (even if they don't 'run' |> on their own) seems to be a smart move in allowing a bug in one module |> to be fixed and made available without waiting on anything else (how |> many times have we wanted a typo fixed that had to wait for a completely |> new feature to be implemented?). | | | I think there are technical and realistic limits to this. Some modules | are simply to small to be full projects. For example the rmi | classloadder is like 5 classes. Also some modules naturally fit | together and have a high degree of coupling. For example the Tx | manager and the j2ca implementation naturally fit together. Now you | can use the Tx manager standalone, but you can't really use j2ca | without a Tx manager. Because of that linking the modules normally move | together. I would say we put both in one sub project and have them | release two jars. | | -dain Agreed here as well. The RMI classloader is what I consider 'too small to make it worth it' and fell in to my "as small and self-contained" as possible. Possible should be read with the implication of 'realistic'. My view on the tx/j2ca type of 'module' is tempered with "overhead costs" and agree that those types of modules may be best combined as you stated. (although removal of that tempered view thinks they should be separate, with the j2ca simply having a dependency on tx.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmLImaCoPKRow/gARAvX6AJ9Q54WWyRF1M7K6drBBBsOtbSdtrACeMJW3 LhwcnkO+Bqm9EtvL9h0fSsA= =ssHt -END PGP SIGNATURE-
Re: Geronimo subprojects?
So far I am completely unconvinced by any arguments in this thread. As a thought experiment, lets suppose we had already released a certified geronimo, say last month, and we had solved most of our build problems, say with maven2. So, we have a certified branch and trunk, and all the geronimo developers are happily working on new features on trunk. In this scenario exactly what needs changing and why? thanks david jencks On May 28, 2005, at 10:38 AM, Dain Sundstrom wrote: On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote: Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. Absolutely My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? It depends on the specifications the subproject is implementing and if Sun has a stand-alone tck for the specifications. For example, if it were the Geronimo 'just a webserver edition' we could certify it for servlets and jsp because they have standalone tcks, but if it were tx and jca we could not certify it since there are no standalone tcks for those specs. On the other hand, I'm sure if enough people are interested, sufficient pressure could be applied to Sun to carve a stand-alone tck out of the j2ee monolith. ~ 2. In stating "there is a demonstrated desire", what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a "demonstrated desire" to have? Each subproject has an inherent amount of overhead. For example, each subproject needs a separate project management committee, each one will need to produce releases (not an easy task) and so on. I would sat that "there is a demonstrated desire" when we have enough people showing up to handle the overhead and work on the code. I personally would say one person is not enough, and seven is more then enough. Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). I think there are technical and realistic limits to this. Some modules are simply to small to be full projects. For example the rmi classloadder is like 5 classes. Also some modules naturally fit together and have a high degree of coupling. For example the Tx manager and the j2ca implementation naturally fit together. Now you can use the Tx manager standalone, but you can't really use j2ca without a Tx manager. Because of that linking the modules normally move together. I would say we put both in one sub project and have them release two jars. -dain
Java One?
Its getting close to the big event... Should we be thinking about a small Geronimo get-together for some beers? I hear the IBM guys are celebrating by buying a night of libations (j/k)! It would be great to meet everyone. Should we plan a place and meeting time? Jeff
Re: Geronimo subprojects?
I think I wrote something a little confusing...let me clarify... What we do to a subset of Geronimo has impact on the whether it passes. However if Geronimo passes the TCK, then a subset would include the features that passed. However, as it stands, passing is an all-or-nothing propsition. I hope that was less confuusing. Jeff Genender wrote: Brian K. Wallace wrote: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? TCK is all or nothing. You pass all tests or you don't pass certification. A minimal Geronimo would clearly be a subset of the "whole tomato", so TCK has no bearing on this, nor should there be concern. A minimal Geronimo is just disconnecting the features you don't want from the configuration. TCK and minimal Geronimo are mutually exclusive and do not impact each other in any way.
Re: Geronimo subprojects?
On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote: Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. Absolutely My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? It depends on the specifications the subproject is implementing and if Sun has a stand-alone tck for the specifications. For example, if it were the Geronimo 'just a webserver edition' we could certify it for servlets and jsp because they have standalone tcks, but if it were tx and jca we could not certify it since there are no standalone tcks for those specs. On the other hand, I'm sure if enough people are interested, sufficient pressure could be applied to Sun to carve a stand-alone tck out of the j2ee monolith. ~ 2. In stating "there is a demonstrated desire", what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a "demonstrated desire" to have? Each subproject has an inherent amount of overhead. For example, each subproject needs a separate project management committee, each one will need to produce releases (not an easy task) and so on. I would sat that "there is a demonstrated desire" when we have enough people showing up to handle the overhead and work on the code. I personally would say one person is not enough, and seven is more then enough. Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). I think there are technical and realistic limits to this. Some modules are simply to small to be full projects. For example the rmi classloadder is like 5 classes. Also some modules naturally fit together and have a high degree of coupling. For example the Tx manager and the j2ca implementation naturally fit together. Now you can use the Tx manager standalone, but you can't really use j2ca without a Tx manager. Because of that linking the modules normally move together. I would say we put both in one sub project and have them release two jars. -dain
Re: Geronimo subprojects?
Brian K. Wallace wrote: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? TCK is all or nothing. You pass all tests or you don't pass certification. A minimal Geronimo would clearly be a subset of the "whole tomato", so TCK has no bearing on this, nor should there be concern. A minimal Geronimo is just disconnecting the features you don't want from the configuration. TCK and minimal Geronimo are mutually exclusive and do not impact each other in any way.
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | I just read through the long "Module restructure" thread, and it to me | is seems like many people are talking about how we break Geronimo into | subprojects without using the word subproject. The goals of the | "Module restructure" thread seem to be: | | 1) allow modules to branch to unstable without requiring the geronimo | trunk to take unstable code | 2) allow modules to have independent release cycles so they don't have | to wait for geronimo trunk | | Regardless what we call it, that is a sub project. I think we should | bite the bullet and talk about what sets of functionality make sense as | a subproject. For example, I think there is a demonstrated desire to | have a TX/JCA subproject in Geronimo. | | -dain | | Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? ~ 2. In stating "there is a demonstrated desire", what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a "demonstrated desire" to have? Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). My thoughts... Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo nG3rKqN5K3CNVFIEWPDSKjg= =BFcE -END PGP SIGNATURE-
Geronimo subprojects?
I just read through the long "Module restructure" thread, and it to me is seems like many people are talking about how we break Geronimo into subprojects without using the word subproject. The goals of the "Module restructure" thread seem to be: 1) allow modules to branch to unstable without requiring the geronimo trunk to take unstable code 2) allow modules to have independent release cycles so they don't have to wait for geronimo trunk Regardless what we call it, that is a sub project. I think we should bite the bullet and talk about what sets of functionality make sense as a subproject. For example, I think there is a demonstrated desire to have a TX/JCA subproject in Geronimo. -dain
Re: Module restructure
On 5/28/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Actually, SVN's repo for geronimo could have been set up in a modular
> approach instead of a monolithic trunk, and act similarly to CVS.
Could have been? It still can be. See the svn move command. I've used
it to restructure SVN repos and it works great.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Module restructure
Actually, SVN's repo for geronimo could have been set up in a modular approach instead of a monolithic trunk, and act similarly to CVS. Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 7:10 AM: On May 27, 2005, at 7:46 PM, Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:38 PM: Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:26 PM: David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Why would we have two versions of transaction? I actually think there are going to be additional ones but was keeping it simple to indicate that "stable" came higher up than "transaction". Ultimately we might end up with (hypothetically) .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 requiring JDK1.5. I don't particularly care for odd/even designations for stable/ unstable. Maybe that was a coincidence in your example. We can easily support your scenario and keep w/ standard SVN usage by doing: geronimo/transaction/branches geronimo/transaction/tags/1_0 geronimo/transaction/tags/1_2 geronimo/transaction/tags/1_3 geronimo/transaction/tags/2_0 geronimo/transaction/tags/2_3 geronimo/transaction/trunk The problem here is when you do a co of geronimo/ to get all the modules, you get a major hose of bits... everything that was ever done. I hate to say it (and Fitz will prollie flog me with a trout...) but I can now identify one feature of CVS that I miss... Boy, I'm glad you said that. I gotta say, I kinda miss CVS. Regards, Alan -- Jeff Genender http://geronimo.apache.org
Re: Module restructure
Geir Magnusson Jr. wrote, On 5/28/2005 7:10 AM: On May 27, 2005, at 7:46 PM, Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:38 PM: Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:26 PM: David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Why would we have two versions of transaction? I actually think there are going to be additional ones but was keeping it simple to indicate that "stable" came higher up than "transaction". Ultimately we might end up with (hypothetically) .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 requiring JDK1.5. I don't particularly care for odd/even designations for stable/ unstable. Maybe that was a coincidence in your example. We can easily support your scenario and keep w/ standard SVN usage by doing: geronimo/transaction/branches geronimo/transaction/tags/1_0 geronimo/transaction/tags/1_2 geronimo/transaction/tags/1_3 geronimo/transaction/tags/2_0 geronimo/transaction/tags/2_3 geronimo/transaction/trunk The problem here is when you do a co of geronimo/ to get all the modules, you get a major hose of bits... everything that was ever done. I hate to say it (and Fitz will prollie flog me with a trout...) but I can now identify one feature of CVS that I miss... Boy, I'm glad you said that. I gotta say, I kinda miss CVS. Regards, Alan
Re: Module restructure
On May 27, 2005, at 7:46 PM, Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:38 PM: Alan D. Cabrera wrote: Jeremy Boynes wrote, On 5/27/2005 7:26 PM: David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Why would we have two versions of transaction? I actually think there are going to be additional ones but was keeping it simple to indicate that "stable" came higher up than "transaction". Ultimately we might end up with (hypothetically) .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 requiring JDK1.5. I don't particularly care for odd/even designations for stable/ unstable. Maybe that was a coincidence in your example. We can easily support your scenario and keep w/ standard SVN usage by doing: geronimo/transaction/branches geronimo/transaction/tags/1_0 geronimo/transaction/tags/1_2 geronimo/transaction/tags/1_3 geronimo/transaction/tags/2_0 geronimo/transaction/tags/2_3 geronimo/transaction/trunk The problem here is when you do a co of geronimo/ to get all the modules, you get a major hose of bits... everything that was ever done. I hate to say it (and Fitz will prollie flog me with a trout...) but I can now identify one feature of CVS that I miss... geir Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Who wants an M4 release?
David Blevins wrote: ...now that I have your attention :) More importantly, who is willing= to volunteer to test and give a "works" or "doesn't work" report? Any volunteers? Consider this the signup sheet. -David Sign me. You can count on my support. ciukes -- Znajdz swoja milosc na wiosne... >>> http://link.interia.pl/f187a
