Re: Module restructure
Dain Sundstrom wrote, On 5/30/2005 10:43 PM: On May 30, 2005, at 4:25 PM, Jeremy Boynes wrote: The problem we have currently is that there is no continuity between our releases - the APIs, deployment plans, etc. have all changed incompatibly between them. This was fine with milestones; however, when we do a production release users need to have confidence that things won't break with the next one. Ah we finally get to the root of what you are talking about. I believe that if we address this issue directly the technical structure of the svn tree will be obvious. I agree, it makes no sense in talking about the how until we iron out the what. Said another way, the technical discussion of the svn tree will never get anywhere without addressing this core issue first. I think that Jeremy's point is one part of the discussion. The other is how do we break up Geronimo so that people can mix and match pieces and still get a stable, functioning, product. Regards, Alan
Re: Module restructure
On May 30, 2005, at 4:25 PM, Jeremy Boynes wrote: The problem we have currently is that there is no continuity between our releases - the APIs, deployment plans, etc. have all changed incompatibly between them. This was fine with milestones; however, when we do a production release users need to have confidence that things won't break with the next one. Ah we finally get to the root of what you are talking about. I believe that if we address this issue directly the technical structure of the svn tree will be obvious. Said another way, the technical discussion of the svn tree will never get anywhere without addressing this core issue first. -dain
Re: Module restructure
On May 30, 2005, at 8:10 PM, Aaron Mulder wrote: On Mon, 30 May 2005, Geir Magnusson Jr. wrote: Well, it does if you want to avoid getting the entire history of the project when you do a co. That's really the issue. That's really a layout issue. You put the trunk, branches, and tags, "somewhere". If you put them all under the same parent, and check out the parent, then sure, you get a lot. If we want to avoid that problem, we need to find a layout with better "parents" so you if you grab the right parent(s), you get only what you want and nothing else. Right - and it's not an issue w/ CVS, which is how most of us think about this. We forget (or I do) that you have to change model w/ SVN. That's why it's become a layout issue. The bigger issue, which started this, was jeremy's suggestion that we get a stable track for things that doesn't interfere w/ people experimenting. geir So I guess the place to start is, what do we want you to get (and want you to not get) in a single checkout? I'm also not tied to using a single "parent", since I always use Maven to checkout anyway, so we could have 20 separate dirs it checks out for different modules -- one to get the main Maven scripts and admin stuff, then you run that to grab the correct configuration of everything else that you're after. Aaron -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On 5/30/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> Bruce Snyder wrote:
> >
> > There most certainly is tagging in SVN. Albeit the concept of tagging
> > in SVN is very different from CVS. The same is true for branches in
> > SVN as well. SVN just makes copies of everything because the SVN
> > developers made the assumption that disk space is cheap. This doesn't
> > mean that we can't continue to utilize tagging just the way we have
> > with the mileston releases so far.
> >
>
> The problem we have currently is that there is no continuity between our
> releases - the APIs, deployment plans, etc. have all changed
> incompatibly between them. This was fine with milestones; however, when
> we do a production release users need to have confidence that things
> won't break with the next one.
>
> This is the primary purpose of the stable tree - consider it a major
> branch point where we make sure that applications running on it continue
> to work from release to release. There may be multiple branches inside
> that tree, and multiple tags along each branch, but what we are
> committing to with the tree as a whole is that continuity for users.
>
> Constrast with the unstable tree where we may want to change APIs,
> schemas or pre-reqs (e.g. JVM level) to add new features that are not
> backwards compatible.
>
> Yes, this is all just branches but users still need to know which
> branches provide this stability and which do not.
Right. IIUC, you're saying it's not an all or nothing type of strategy
like we have right now. We need a strategy (and a well documented one)
for addressing the new strategy (when we decide what that is).
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
Bruce Snyder wrote: There most certainly is tagging in SVN. Albeit the concept of tagging in SVN is very different from CVS. The same is true for branches in SVN as well. SVN just makes copies of everything because the SVN developers made the assumption that disk space is cheap. This doesn't mean that we can't continue to utilize tagging just the way we have with the mileston releases so far. The problem we have currently is that there is no continuity between our releases - the APIs, deployment plans, etc. have all changed incompatibly between them. This was fine with milestones; however, when we do a production release users need to have confidence that things won't break with the next one. This is the primary purpose of the stable tree - consider it a major branch point where we make sure that applications running on it continue to work from release to release. There may be multiple branches inside that tree, and multiple tags along each branch, but what we are committing to with the tree as a whole is that continuity for users. Constrast with the unstable tree where we may want to change APIs, schemas or pre-reqs (e.g. JVM level) to add new features that are not backwards compatible. Yes, this is all just branches but users still need to know which branches provide this stability and which do not. -- Jeremy
Re: Module restructure
On Mon, 30 May 2005, Geir Magnusson Jr. wrote: > Well, it does if you want to avoid getting the entire history of the > project when you do a co. That's really the issue. That's really a layout issue. You put the trunk, branches, and tags, "somewhere". If you put them all under the same parent, and check out the parent, then sure, you get a lot. If we want to avoid that problem, we need to find a layout with better "parents" so you if you grab the right parent(s), you get only what you want and nothing else. So I guess the place to start is, what do we want you to get (and want you to not get) in a single checkout? I'm also not tied to using a single "parent", since I always use Maven to checkout anyway, so we could have 20 separate dirs it checks out for different modules -- one to get the main Maven scripts and admin stuff, then you run that to grab the correct configuration of everything else that you're after. Aaron
Re: Module restructure
On May 30, 2005, at 6:59 PM, Bruce Snyder wrote:
On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On May 30, 2005, at 4:18 PM, Bruce Snyder wrote:
On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I'm too dim to figure out how, because no matter what, since
there is
no notion of a tag or branch, no matter how you slice and dice,
either you branch to a different root when you cut a version, or
you
have to get the whole history anytime you checkout anything...
On many other projects, I have always relied heavily on tagging.
Me too - and then converting tags into branches if need be. But you
can't do that in SVN.
All
work is conducted on the HEAD unless it's highly experimental and
then
it occurs in its own branch. Once the HEAD is ready for a release I
tag it and do the release. But I can see the value in keeping things
separate as in trunk and sandbox. The tagging can then take care of
stable vs. unstable.
Bruce... there is no tagging in SVN :) That's the problem.
There most certainly is tagging in SVN.
agreed. the revision # :)
Albeit the concept of tagging
in SVN is very different from CVS.
Yes. That's why I say it isn't tagging. It's just copying.
The same is true for branches in
SVN as well. SVN just makes copies of everything because the SVN
developers made the assumption that disk space is cheap. This doesn't
mean that we can't continue to utilize tagging just the way we have
with the mileston releases so far.
Well, it does if you want to avoid getting the entire history of the
project when you do a co. That's really the issue.
geir
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 3:59 PM, Bruce Snyder wrote: There most certainly is tagging in SVN. Albeit the concept of tagging in SVN is very different from CVS. The same is true for branches in SVN as well. SVN just makes copies of everything because the SVN developers made the assumption that disk space is cheap. svn doesn't create duplicate data. It simply creates a link in the new dir, saying that "this dir" is a copy of "that dir" using revision xxx. The "copy" effectively uses 0 disk space. This doesn't mean that we can't continue to utilize tagging just the way we have with the mileston releases so far. Exactly. Also, you can still diff and merge from a tag/branch using svn. -dain
Re: Module restructure
On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> On May 30, 2005, at 4:18 PM, Bruce Snyder wrote:
>
> > On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> >
> >> I'm too dim to figure out how, because no matter what, since there is
> >> no notion of a tag or branch, no matter how you slice and dice,
> >> either you branch to a different root when you cut a version, or you
> >> have to get the whole history anytime you checkout anything...
> >>
> >
> > On many other projects, I have always relied heavily on tagging.
>
> Me too - and then converting tags into branches if need be. But you
> can't do that in SVN.
>
> > All
> > work is conducted on the HEAD unless it's highly experimental and then
> > it occurs in its own branch. Once the HEAD is ready for a release I
> > tag it and do the release. But I can see the value in keeping things
> > separate as in trunk and sandbox. The tagging can then take care of
> > stable vs. unstable.
>
> Bruce... there is no tagging in SVN :) That's the problem.
There most certainly is tagging in SVN. Albeit the concept of tagging
in SVN is very different from CVS. The same is true for branches in
SVN as well. SVN just makes copies of everything because the SVN
developers made the assumption that disk space is cheap. This doesn't
mean that we can't continue to utilize tagging just the way we have
with the mileston releases so far.
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
On May 30, 2005, at 1:18 PM, Bruce Snyder wrote: On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I'm too dim to figure out how, because no matter what, since there is no notion of a tag or branch, no matter how you slice and dice, either you branch to a different root when you cut a version, or you have to get the whole history anytime you checkout anything... On many other projects, I have always relied heavily on tagging. All work is conducted on the HEAD unless it's highly experimental and then it occurs in its own branch. Once the HEAD is ready for a release I tag it and do the release. But I can see the value in keeping things separate as in trunk and sandbox. The tagging can then take care of stable vs. unstable. We have created a "tag" in geronimo for each release we have done. You can seem them here: http://svn.apache.org/repos/asf/geronimo/tags/ -dain
Re: Geronimo subprojects?
On May 30, 2005, at 3:28 PM, Jeff Genender wrote: Geir Magnusson Jr. wrote: On May 28, 2005, at 1:41 PM, Jeff Genender wrote: 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. Technically speaking, you couldn't make that claim. Does the law of transitivity not apply here? If Jetty passes the TCK, would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not mean that we are using the passed component for web? Strangely enough, apparently not, unless we used Jetty in exactly the way it was packaged when it passed. My point was: Full G Change (where it passes) ---> G Lite contains passed code. but G Lite is changed -> May impact full G's passing of TCK. Please clarify how this claim may not be valid. I don't quite understand. Your reasoning is logical, but the TCK is a simple statement about the binary tested. It passes, or it doesn't pass. That information isn't transitive to other binaries that aren't the same. You need to test those too... Jeff -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 30, 2005, at 11:22 AM, Geir Magnusson Jr. wrote: On May 28, 2005, at 12:38 PM, 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. That may be where it went to out of confusion, but I think the original point was how to get organized so we can have a stable tree that is what those of us interested in a sable certified release work in while other work can continue. Nice. I'm interested in a stable tree for certification. I just want to avoid unnecessary complexity and all of the module restructuring plans so far seem like a svn merge nightmare 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 I would have gone the other way - branch out the stable and let work continue in trunk, and loony things go off to a sandbox. Agreed. That was a typo, but you got the meaning. 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. The problem with trying to force the language to be "subproject" rather than "module" is that "subproject" is a loaded word at apache with different meaning - in that it has historically, from jakarta, tended to mean separate, autonomous projects that live under a project umbrella. I don't think anyone here is advocating that, and I'd prefer we not have to explain what we mean over and over to the rest of the Apache community I am advocating that we take stuff like the tx an j2ca implementation and make it a "separate, autonomous projects that live under a project umbrella". That way, those that are interested and understand those technologies can choose how to develop the code. They can choose when to branch, when to do releases, how to structure their modules, and so on. There seems to be an interest in this from the community. -dain
Re: Java One?
On May 30, 2005, at 4:49 PM, Dain Sundstrom wrote: On May 30, 2005, at 11:13 AM, Geir Magnusson Jr. wrote: On May 29, 2005, at 6:46 PM, Jeff Genender wrote: -1 on Saturday. +1 on Sunday. I get in Sunday. The only issue on Sunday is that we have "J2EE Licensee Day" that afternoon, and I assume that many doing the J2EE certification work will wish to attend that. I suppose we can shoot for later in the evening... Considering how useless last year's licensee day was, I don't plan on going. Do they have something interesting planned for this year? I have no way of knowing. I'd suspect that it's going to be more of the same, with the addition of a riveting discussion about brand and naming changes. Hopefully, there's going to be more detailed discussion of EJB3 as well. geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 30, 2005, at 4:18 PM, Bruce Snyder wrote:
On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I'm too dim to figure out how, because no matter what, since there is
no notion of a tag or branch, no matter how you slice and dice,
either you branch to a different root when you cut a version, or you
have to get the whole history anytime you checkout anything...
On many other projects, I have always relied heavily on tagging.
Me too - and then converting tags into branches if need be. But you
can't do that in SVN.
All
work is conducted on the HEAD unless it's highly experimental and then
it occurs in its own branch. Once the HEAD is ready for a release I
tag it and do the release. But I can see the value in keeping things
separate as in trunk and sandbox. The tagging can then take care of
stable vs. unstable.
Bruce... there is no tagging in SVN :) That's the problem.
geir
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: Java One?
On May 30, 2005, at 11:13 AM, Geir Magnusson Jr. wrote: On May 29, 2005, at 6:46 PM, Jeff Genender wrote: -1 on Saturday. +1 on Sunday. I get in Sunday. The only issue on Sunday is that we have "J2EE Licensee Day" that afternoon, and I assume that many doing the J2EE certification work will wish to attend that. I suppose we can shoot for later in the evening... Considering how useless last year's licensee day was, I don't plan on going. Do they have something interesting planned for this year? -dain
Re: Module restructure
On 5/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> I'm too dim to figure out how, because no matter what, since there is
> no notion of a tag or branch, no matter how you slice and dice,
> either you branch to a different root when you cut a version, or you
> have to get the whole history anytime you checkout anything...
On many other projects, I have always relied heavily on tagging. All
work is conducted on the HEAD unless it's highly experimental and then
it occurs in its own branch. Once the HEAD is ready for a release I
tag it and do the release. But I can see the value in keeping things
separate as in trunk and sandbox. The tagging can then take care of
stable vs. unstable.
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?
Jeff Genender wrote: Geir Magnusson Jr. wrote: On May 28, 2005, at 1:41 PM, Jeff Genender wrote: 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. Technically speaking, you couldn't make that claim. Does the law of transitivity not apply here? If Jetty passes the TCK, would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not mean that we are using the passed component for web? My point was: Full G Change (where it passes) ---> G Lite contains passed code. but G Lite is changed -> May impact full G's passing of TCK. Please clarify how this claim may not be valid. I believe natural laws do not apply here given lawyers are involved :-) Certification applies only to specific binary distributions, so if Jetty released a binary and certified it then they could claim compatibility for that version (and even then only on a specific set of platforms). Any other binary, including Geronimo, that incorporated Jetty would not be able to claim compatibility unless the combined work was tested. Similarly if Geronimo incorporates Jetty and certifies then it does not mean that Jetty standalone can claim compatibility. What makes matters worse is that some specifications (for example EJB, J2CA) currently cannot be licensed separately from J2EE making it impossible to claim compatibility with them standalone. -- Jeremy
Re: Geronimo subprojects?
Geir Magnusson Jr. wrote: On May 28, 2005, at 1:41 PM, Jeff Genender wrote: 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. Technically speaking, you couldn't make that claim. Does the law of transitivity not apply here? If Jetty passes the TCK, would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not mean that we are using the passed component for web? My point was: Full G Change (where it passes) ---> G Lite contains passed code. but G Lite is changed -> May impact full G's passing of TCK. Please clarify how this claim may not be valid. Jeff
Re: Geronimo subprojects?
On May 29, 2005, at 2:08 AM, Bruce Snyder wrote:
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.
Right. I don't think we need sub-projects or want sub-projects. I
think we just need to modularize better and be able to have a stable
J2EE assembly tree to help the push towards a certified 1.0 Geronimo
release.
geir
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 2:02 PM, Brian K. Wallace wrote: -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.] Yes. If you want to know if the servlet part works on it's own, you need to test it on it's own geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 1:41 PM, Jeff Genender wrote: 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. Technically speaking, you couldn't make that claim. However, as it stands, passing is an all-or-nothing propsition. Yes. We do have licenses for stand-alone TCKs for projects that we have. I'd be hard-pressed to argue that we should be able to get TCks for things we don't have, like JMS. geir 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. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 1:20 PM, Brian K. Wallace wrote: -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? No. Nothing. The binary that passes the TCK is the only thing about which claims can be made. ~ 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?). I think that the most logical partitioning, which we've talked about for a lng long time, is having the server framework separate, done in a way that's easily reusable by others, free of J2EE cruft, etc. Then the other parts that are J2EE - in entirety, like the J2EE assembly - or in parts, like TX, could be separate. geir My thoughts... Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo nG3rKqN5K3CNVFIEWPDSKjg= =BFcE -END PGP SIGNATURE- -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Geronimo subprojects?
On May 28, 2005, at 12:38 PM, 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. That may be where it went to out of confusion, but I think the original point was how to get organized so we can have a stable tree that is what those of us interested in a sable certified release work in while other work can continue. 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 I would have gone the other way - branch out the stable and let work continue in trunk, and loony things go off to a sandbox. 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. The problem with trying to force the language to be "subproject" rather than "module" is that "subproject" is a loaded word at apache with different meaning - in that it has historically, from jakarta, tended to mean separate, autonomous projects that live under a project umbrella. I don't think anyone here is advocating that, and I'd prefer we not have to explain what we mean over and over to the rest of the Apache community geir -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
I'm too dim to figure out how, because no matter what, since there is no notion of a tag or branch, no matter how you slice and dice, either you branch to a different root when you cut a version, or you have to get the whole history anytime you checkout anything... geir On May 28, 2005, at 11:25 AM, Jeff Genender 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. 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 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Java One?
On May 29, 2005, at 6:46 PM, Jeff Genender wrote: -1 on Saturday. +1 on Sunday. I get in Sunday. The only issue on Sunday is that we have "J2EE Licensee Day" that afternoon, and I assume that many doing the J2EE certification work will wish to attend that. I suppose we can shoot for later in the evening... +1 on Beers + Coding ;-) Thank goodness for version control... geir Aaron Mulder wrote: How about a coding/planning meeting on Saturday or Sunday? Not that there's anything wrong with beers, but if a lot of us are going to be there, perhaps we can do more. Aaorn On Sun, 29 May 2005, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 5:32 PM: 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. I shall be there too! Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Java One?
We should try to get formal BOF if not too late, and an informal one otherwise nearby. However, given that JavaOne isn't universally attended anymore, I want to be careful that we don't engage in decision making where everyone can't attend. I suppose that we can certainly hash out some ideas and float on the dev list for comment... geir On May 29, 2005, at 7:05 PM, Aaron Mulder wrote: How about a coding/planning meeting on Saturday or Sunday? Not that there's anything wrong with beers, but if a lot of us are going to be there, perhaps we can do more. Aaorn On Sun, 29 May 2005, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 5:32 PM: 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. I shall be there too! Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Java One?
My exile to the bay area will be complete by then and so I can hook up any time people would like. Regards, Alan Jeff Genender wrote, On 5/29/2005 6:46 PM: -1 on Saturday. +1 on Sunday. I get in Sunday. +1 on Beers + Coding ;-) Aaron Mulder wrote: How about a coding/planning meeting on Saturday or Sunday? Not that there's anything wrong with beers, but if a lot of us are going to be there, perhaps we can do more. Aaorn On Sun, 29 May 2005, Alan D. Cabrera wrote: Geir Magnusson Jr. wrote, On 5/28/2005 5:32 PM: 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. I shall be there too! Regards, Alan
Re: Who wants an M4 release?
David Blevins wrote: Everything is pokable at this point. If you have an app or two laying around, try and deploy them and see if they run well enough. If there is anything thing we find doesn't work, and isn't a showstopper, we can add a JIRA item and include it in the release notes as known issues. Count me in. With the recent VMware license purchase and its snapshot capability, testing is not a problem anymore. Each run with a fresh, clean environment is what I'd missed a lot. It's time to take some VMware lessons by doing real work ;) -David Jacek
Re: Testing
You can look at http://wiki.apache.org/geronimo/Deployment to get you started. Stefan Arentz wrote: Ok cool, I did a build on OS X 10.4.1 / Java 1.4.2_07 took an hour (I was also watching a movie on my slow powerbook). The build works, and the server starts. So what is next? :-) I have a bunch of Spring applications that I would like to deploy. I think I'm just going to see how that works and give feedback. S. -- Dondi Imperial Software Engineer Exist Software Labs Marketing Coordinator Penthouse I, Prestige Tower, F. Ortigas Jr. Ave. (formerly Emerald Ave.), Ortigas Center, Pasig City 1605 Philippines +632.687.7653 www.exist.com
