Re: Module restructure
Alan D. Cabrera wrote: 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. I was also hoping being able to designate certain modules as stable would assist in the drive to certification by reducing the amount of regression testing needed (although of course we would still need to test everything before we released). Someone might even run some modules through the standalone TCKs ... -- Jeremy
Re: Module restructure
On May 30, 2005, at 10:56 PM, Alan D. Cabrera wrote:
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.
So lets do that.
Jeremy was proposing distinguishing between "stable" - where the
focus is getting to the next release - and "unstable" - where things
unrelated to linear progress to a release are done.
First - do we agree this is a good thing?
Second - if we do agree, besides the suggestion of separate roots
("stable", "unstable", "downright_wacky" (nee "sandbox")), what other
approaches are there?
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.
lets solve this one first. The other follows after that, IMO.
geir
Regards,
Alan
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
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: 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: 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: 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: 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: Module restructure
Alan D. Cabrera wrote: Anything in trunk or branch is unstable. Anything in tag is stable. A tag though represents a single point in time. We really need stable and unstable branches as I tried to characterise them in the mail that started this thread. 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 I saw with that was how someone would easily check out the whole tree in order to build from source. I think DB had the same concern. Hmm, that's a good point. I think that your example suffers the same problem, no? I think that you either are able to treat modules as separate projects and get the configurability that you want or you get a nice way to svn co; I'm not sure that we can get both. Brian's externals idea may address some of that but at the cost of additional commit complexity. -- Jeremy
Re: Module restructure
Brian K. Wallace wrote: Jeremy Boynes wrote: | Brian K. Wallace wrote: | |> |> Wouldn't the proper use of svn:externals take care of a lot of this? |> have svn co geronimo basically read from the externals to pull whatever |> modules (as well as other components) you want while letting each module |> handle its own stable/unstable structure? [obviously have a standard for |> that structure would be HIGHLY desirable] Might be a chore setting up |> those externals at first, but after that it'd just be there (unless new |> modules/etc were added) |> | | | All our modules are in the same SVN repo so we don't need to use | externals, we can just copy. This would be a good option for integrating | other projects if we needed to do that at the source level. AIUI though | they would also need to be on SVN and not all are. | | -- | Jeremy | | Don't need, and can't use aren't quite the same, tho'. This was the part that led me to believe (erroneously) that this thread was about deliverables only. In your example: .../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 I'd think that transaction (as well as all other modules) might have stable, unstable, as well as 'releases'. stable (above) could just externalize transaction's stable (along with all the other modules), as could unstable and 'releases' at that higher level. Obviously this would have to be an SVN only exercise, but if you can allow a user/developer to check out X and hide that X is made up of 50 different 'externals', but also allow them to check out just 1 of those 50 modules without having to dig through an entire structure... ? Not thinking you were on track to restructure quite that much, so I'll go back to 'observing'. :-) No, you're right to bring this up. This would be a good way to handle a module structure like Alan was proposing where the modules themselves were at the top level and we had a "J2EE assembly" module that just pulled the others together. AIUI though you can't commit across externals which would mean any work that spanned modules would need to be committed from each one which would be a little awkward. I would hope that the number of such changes will decrease so this will become only an occasional problem. One area where we will be doing work in multiple modules are the runtime/builder pairs - perhaps we can do a hybrid where e.g. jetty-runtime and jetty-builder become a pair of sub-modules under a jetty module. -- Jeremy
Re: Module restructure
David Blevins wrote, On 5/27/2005 7:51 PM: On Fri, May 27, 2005 at 04:38:45PM -0700, Jeremy Boynes wrote: 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 Oh, I get it. You're just proposing to add the linux kernel odd/even spin on what we have now and dump trunk. Anyone know the lore as to why they went odd even? Was it the case that the tool that they were using drove them to such an odd nomenclature? Regards, Alan
Re: Module restructure
Jeremy Boynes wrote, On 5/27/2005 7:52 PM: Alan D. Cabrera wrote: I don't particularly care for odd/even designations for stable/unstable. Maybe that was a coincidence in your example. I'm not tied to any of the names - it was deliberate but illustrative. I do think it would be useful for users to be able to tell just from a jar's name whether it was stable or not. Anything in trunk or branch is unstable. Anything in tag is stable. 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 I saw with that was how someone would easily check out the whole tree in order to build from source. I think DB had the same concern. Hmm, that's a good point. I think that your example suffers the same problem, no? I think that you either are able to treat modules as separate projects and get the configurability that you want or you get a nice way to svn co; I'm not sure that we can get both. Regards, Alan
Re: Module restructure
--- Stefan Arentz <[EMAIL PROTECTED]> wrote: > On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote: > > > > So, what I would really like to see wrt Geronimo is > an absolute > minimal server with add-on packages for things like > a web container, > jms provider, etc. You want to host a web app? Throw > in the Tomcat or > Jetty personality. Need JMS too, add ActiveMQ. > Persistence? Simply > add a hibernate deployer. Mix and match so that it > does what your app > needs. This is my dream! > > This is where Geronimo could shine and even take > away a large chunk > of Tomcat; most people just want to deploy their web > app and > optionally add some more services without having to > understand a full > J2EE stack. Geronimo can fill that void extremely > well I think. > (Simple Web Container .. .. J2EE Monolith) I strongly agree. People will have more trust in their server, if they understand 'everything' running inside it. As they understand more J2EE they can throw in more components. Thanks Anita > > Ok so just complaining doesn't work well for this > project, so what I > really would like to do is start figuring out how I > can give Geronimo > 'personalities' for popular combinations of > technology. Like, > > - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + > Hibernate > - Geronimo Kernel + Web Services > - Geronimo Kernel + JMX Enabled custom network > service > The minimal server (Kernel + Jetty) already works. I have been using it because of compiler error in openejb core (CORBA) on jdk1.5. I am working on making Jetty an add on component like Tomcat > and then do some writing about it on the wiki. Make > recipes for > people, or even complete packages that are > downloadable. > > I really think this is how Geronimo can also get > acceptance with a > much larger crowd. > > S. > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Boynes wrote: | Brian K. Wallace wrote: | |> |> Wouldn't the proper use of svn:externals take care of a lot of this? |> have svn co geronimo basically read from the externals to pull whatever |> modules (as well as other components) you want while letting each module |> handle its own stable/unstable structure? [obviously have a standard for |> that structure would be HIGHLY desirable] Might be a chore setting up |> those externals at first, but after that it'd just be there (unless new |> modules/etc were added) |> | | | All our modules are in the same SVN repo so we don't need to use | externals, we can just copy. This would be a good option for integrating | other projects if we needed to do that at the source level. AIUI though | they would also need to be on SVN and not all are. | | -- | Jeremy | | Don't need, and can't use aren't quite the same, tho'. This was the part that led me to believe (erroneously) that this thread was about deliverables only. In your example: .../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 I'd think that transaction (as well as all other modules) might have stable, unstable, as well as 'releases'. stable (above) could just externalize transaction's stable (along with all the other modules), as could unstable and 'releases' at that higher level. Obviously this would have to be an SVN only exercise, but if you can allow a user/developer to check out X and hide that X is made up of 50 different 'externals', but also allow them to check out just 1 of those 50 modules without having to dig through an entire structure... ? Not thinking you were on track to restructure quite that much, so I'll go back to 'observing'. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl7KKaCoPKRow/gARAqsSAJ9jd9TCHzDKo3Jevs9/3x22jEJLiQCg0rOd rI/bBEIW5t8tUn/Gkq1SPOI= =V9zh -END PGP SIGNATURE-
Re: Module restructure
Alan D. Cabrera wrote: I don't particularly care for odd/even designations for stable/unstable. Maybe that was a coincidence in your example. I'm not tied to any of the names - it was deliberate but illustrative. I do think it would be useful for users to be able to tell just from a jar's name whether it was stable or not. 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 I saw with that was how someone would easily check out the whole tree in order to build from source. I think DB had the same concern. -- Jeremy
Re: Module restructure
On Fri, May 27, 2005 at 04:38:45PM -0700, Jeremy Boynes wrote: > 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 > Oh, I get it. You're just proposing to add the linux kernel odd/even spin on what we have now and dump trunk. -David
Re: Module restructure
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 Regards, Alan
Re: Module restructure
Brian K. Wallace wrote: Wouldn't the proper use of svn:externals take care of a lot of this? have svn co geronimo basically read from the externals to pull whatever modules (as well as other components) you want while letting each module handle its own stable/unstable structure? [obviously have a standard for that structure would be HIGHLY desirable] Might be a chore setting up those externals at first, but after that it'd just be there (unless new modules/etc were added) All our modules are in the same SVN repo so we don't need to use externals, we can just copy. This would be a good option for integrating other projects if we needed to do that at the source level. AIUI though they would also need to be on SVN and not all are. -- Jeremy
Re: Module restructure
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. -- Jeremy
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? | | | Regards, | Alan | | | Wouldn't the proper use of svn:externals take care of a lot of this? have svn co geronimo basically read from the externals to pull whatever modules (as well as other components) you want while letting each module handle its own stable/unstable structure? [obviously have a standard for that structure would be HIGHLY desirable] Might be a chore setting up those externals at first, but after that it'd just be there (unless new modules/etc were added) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl67YaCoPKRow/gARAlgcAJ49h37F3OBvnPiPpR5V2GPj+XqCUQCg2s8b BhOfXzsntTFnFzw82VLIedY= =wtD9 -END PGP SIGNATURE-
Re: Module restructure
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? Regards, Alan
Re: Module restructure
David Blevins wrote: This one ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction -- Jeremy
Re: Module restructure
Bruce Snyder wrote: On 5/27/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote: One of the reasons for going with a modular structure in the first place was to make the totality more manageable while still being able to develop each module. For small projects I would agree it is probably not worth it, but most large distributed projects have gone that way: look at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse + plugins, ... The community is asking for subsets of functionality - we should use the module structure to give it to them rather than waiting for a release at the global level (especially with the overhead of certification testing). Are you now talking about what should be distributed to users as opposed to the dir structure of the SVN repo? Or are you talking about the two as one in the same (i.e. certain subsets of the project should be reflected in the SVN repo dir structure, not hidden in the build scripts)? The two are related as we are already generating artifact jars for each of the modules that fit the functions that people are asking for (e.g. transaction, connector). All I am really saying is that we should have stable/unstable versions at the module level so that they know which ones are safe to use. The structure I proposed does this but also allows someone to easily check out and build an entire stable or unstable tree. This also applies to us - for example, transaction is not changing so rather than build from a SNAPSHOT all the time we could use a known version. This would cut the build time too :-) -- Jeremy
Re: Module restructure
On Fri, May 27, 2005 at 06:33:49PM -0400, Geir Magnusson Jr. wrote: > > On May 27, 2005, at 4:25 PM, David Blevins wrote: > > >Yea, I was just about to post that. Stable/unstable refers to > >branches. > > > > But jeremy is right here (but forgot to say it) - because we're using > SVN, you want to keep the branches in a separate root so that > > svn co geronimo > > doesn't bring down every branch, but just gets you the current head. > > As long as we're in the same SVN repo, the fact that we have > different roots is irrelevant from the POV of making copies (aka > "branching"), but it's a big help for users. Yea, I get that. But I think Jeremy is proposing more of this: ../repos/asf/geronimo/transaction/unstable ../repos/asf/geronimo/transaction/stable than this: ../repos/asf/geronimo/unstable/modules/transaction ../repos/asf/geronimo/stable/modules/transaction Jeremy? -David > > geir > > >-David > > > >On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote: > > > >>Clearly, we need something like this to get organized around the > >>final push for certification and the 1.0 release, by why not just > >>branch for the stable, and head is unstable? > >> > >>geir > >> > >>On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: > >> > >> > >>>Stefan brings up the question of whether we want to release sub- > >>>modules of Geronimo separately. I think this is a good idea and > >>>would propose the following restructure of the tree to move in this > >>>direction. > >>> > >>>Rather than "trunk" in the root, we have three separate trees: > >>> > >>>stablesimilar to even-numbered versions of Linux, this tree > >>> would contain stable code intended for production use > >>> and operates with a focus on stability (i.e. well > >>> documented stable APIs, backward compatibility, no > >>> SNAPSHOT dependencies etc.) > >>> There will be multiple branches as needed. > >>> > >>>unstable similar to odd-numbered versions this is where new > >>> development is done and APIs etc. are much more > >>> likely to change. We may still do releases from here > >>> but they are quite likely to be incompatible; it may > >>> be all we package from here are nightlies. > >>> > >>>sandbox as now, a free-for-all area for trying out new ideas > >>> and experimenting with new technologies > >>> > >>>Given the size of the codebase, we need to preserve the module > >>>structure that we have in the current trunk. However, even now some > >>>modules are more stable than others (e.g. the transaction and > >>>connector ones Thierry is looking to use) and I think are in a > >>>position where they can be versioned separately. > >>> > >>>With the structure above in place, we can move modules into the > >>>stable or unstable trees as appropriate. For those that we consider > >>>stable (e.g. transaction) we can cut numbered releases that people > >>>can use standalone. > >>> > >>>This will also speed the unstable build as we won't need to check > >>>SNAPSHOTs for everything all the time. > >>> > >>>I would suggest we start on this as part of packaging for M4 and > >>>would be willing to co-ordinate. > >>> > >>>-- > >>>Jeremy > >>> > >>> > >>> > >> > >>-- > >>Geir Magnusson Jr +1-203-665-6437 > >>[EMAIL PROTECTED] > >> > >> > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] >
Re: Module restructure
On 5/27/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> One of the reasons for going with a modular structure in the first place
> was to make the totality more manageable while still being able to
> develop each module. For small projects I would agree it is probably not
> worth it, but most large distributed projects have gone that way: look
> at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse +
> plugins, ...
>
> The community is asking for subsets of functionality - we should use the
> module structure to give it to them rather than waiting for a release at
> the global level (especially with the overhead of certification testing).
Are you now talking about what should be distributed to users as
opposed to the dir structure of the SVN repo? Or are you talking about
the two as one in the same (i.e. certain subsets of the project should
be reflected in the SVN repo dir structure, not hidden in the build
scripts)?
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
David Blevins wrote: On Fri, May 27, 2005 at 09:40:52AM -0700, Jeremy Boynes wrote: Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - "trunk", "head", "unstable", whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. I think we are going to have a hard enough time managing and merging between stable/unstable branches of the code in general let alone at the submodule level. I'd prefer to get used to that before trying it at the submodule level. One of the reasons for going with a modular structure in the first place was to make the totality more manageable while still being able to develop each module. For small projects I would agree it is probably not worth it, but most large distributed projects have gone that way: look at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse + plugins, ... The community is asking for subsets of functionality - we should use the module structure to give it to them rather than waiting for a release at the global level (especially with the overhead of certification testing). -- Jeremy
Re: Module restructure
On May 27, 2005, at 4:25 PM, David Blevins wrote: Yea, I was just about to post that. Stable/unstable refers to branches. But jeremy is right here (but forgot to say it) - because we're using SVN, you want to keep the branches in a separate root so that svn co geronimo doesn't bring down every branch, but just gets you the current head. As long as we're in the same SVN repo, the fact that we have different roots is irrelevant from the POV of making copies (aka "branching"), but it's a big help for users. geir -David On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than "trunk" in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On Fri, May 27, 2005 at 09:40:52AM -0700, Jeremy Boynes wrote: > Geir Magnusson Jr. wrote: > >Clearly, we need something like this to get organized around the final > >push for certification and the 1.0 release, by why not just branch for > >the stable, and head is unstable? > > > > The names are just suggestions - "trunk", "head", "unstable", whatever. > > The important thing is that you can easily checkout and build each tree > on its own so we can't have both stable and unstable branches of modules > (e.g. transaction) under trunk. > I think we are going to have a hard enough time managing and merging between stable/unstable branches of the code in general let alone at the submodule level. I'd prefer to get used to that before trying it at the submodule level. -David
Re: Module restructure
Yea, I was just about to post that. Stable/unstable refers to branches. -David On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote: > Clearly, we need something like this to get organized around the > final push for certification and the 1.0 release, by why not just > branch for the stable, and head is unstable? > > geir > > On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: > > >Stefan brings up the question of whether we want to release sub- > >modules of Geronimo separately. I think this is a good idea and > >would propose the following restructure of the tree to move in this > >direction. > > > >Rather than "trunk" in the root, we have three separate trees: > > > >stablesimilar to even-numbered versions of Linux, this tree > > would contain stable code intended for production use > > and operates with a focus on stability (i.e. well > > documented stable APIs, backward compatibility, no > > SNAPSHOT dependencies etc.) > > There will be multiple branches as needed. > > > >unstable similar to odd-numbered versions this is where new > > development is done and APIs etc. are much more > > likely to change. We may still do releases from here > > but they are quite likely to be incompatible; it may > > be all we package from here are nightlies. > > > >sandbox as now, a free-for-all area for trying out new ideas > > and experimenting with new technologies > > > >Given the size of the codebase, we need to preserve the module > >structure that we have in the current trunk. However, even now some > >modules are more stable than others (e.g. the transaction and > >connector ones Thierry is looking to use) and I think are in a > >position where they can be versioned separately. > > > >With the structure above in place, we can move modules into the > >stable or unstable trees as appropriate. For those that we consider > >stable (e.g. transaction) we can cut numbered releases that people > >can use standalone. > > > >This will also speed the unstable build as we won't need to check > >SNAPSHOTs for everything all the time. > > > >I would suggest we start on this as part of packaging for M4 and > >would be willing to co-ordinate. > > > >-- > >Jeremy > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] >
Re: Module restructure
Stefan This is exactly what we have been aiming for :-) To a large extent you can already do this today. You can mix-and-match the different modules simply by providing a custom configuration plan. As a concrete example, this is what we did at Gluecode to build the JOE SE product which aimed at filling your : Servlet + JSP + JMS + services such as deployment, transactions and database access. Geronimo is not a J2EE monolith - it is a collection of system services and a kernel to bind them together. What we certify is a J2EE monolith because it has to pass *ALL* the CTS tests but that is just one assembled form. -- Jeremy Stefan Arentz wrote: On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Let me just explain my motivation a bit, maybe that will also help for the plan. In my original email I said something about not needing all the J2EE stuff. I exaggerated a bit of course, but most of the applications that I have been writing in the last couple of years are done mostly with a subset of the whole J2EE umbrella. Some apps were just some network service wrapped in (JMX) beans, a service exposed with Spring (Burlap, XML-RPC) other apps were simply a web app backed by a shared Spring context. I've never needed all the stuff in J2EE. So far I've always done this on JBoss. Their MBean stuff works ok, but I wish it was easier to 'downsize' jboss to just a container with the stuff I need. That never really seemed to be their goal however. The complexity of their configuration files shows that. So, what I would really like to see wrt Geronimo is an absolute minimal server with add-on packages for things like a web container, jms provider, etc. You want to host a web app? Throw in the Tomcat or Jetty personality. Need JMS too, add ActiveMQ. Persistence? Simply add a hibernate deployer. Mix and match so that it does what your app needs. This is where Geronimo could shine and even take away a large chunk of Tomcat; most people just want to deploy their web app and optionally add some more services without having to understand a full J2EE stack. Geronimo can fill that void extremely well I think. (Simple Web Container .. .. J2EE Monolith) Ok so just complaining doesn't work well for this project, so what I really would like to do is start figuring out how I can give Geronimo 'personalities' for popular combinations of technology. Like, - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate - Geronimo Kernel + Web Services - Geronimo Kernel + JMX Enabled custom network service and then do some writing about it on the wiki. Make recipes for people, or even complete packages that are downloadable. I really think this is how Geronimo can also get acceptance with a much larger crowd. S.
Re: Module restructure
David Jencks wrote: I'm worried that it would be a giant hassle to try to assemble a geronimo that is 90% stable and 10% unstable. I would have thought that would be an assembly that used 90% stable module versions and 10% unstable ones. Where would the hassle be? I also don't see the advantage of this plan over simply creating a branch whenever someone wants to do some disruptive experimentation, and merging the results back in when appropriate. This worked fine for me for the work I did rewriting the jetty deployer. If I understand the svn docs this is more in line with "standard svn practice". The big problem is the merge back. If the main branch is continually evolving then that becomes very painful. The intention here was to have an unstable tree that is continually and rapidly evolving and a stable tree where you can easily merge to because it isn't. The other challenge is to support collaborative development of new features where more than one person can be working on it. That means making it easy to checkout and build the unstable tree. There is nothing precluding what you are saying, either within the unstable tree or in the sandbox. -- Jeremy
Re: Module restructure
On 5/27/05, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
> | Security-wise it is also a nightmare. There is so much stuff running in
> | the container that I have no idea of. I usually bind the instance to
> | localhost and do port translation for those TCP/IP services that need
> | to be exposed, but even then there are still many ways to connect to it
> | from localhost that could potentially expose information or give
> | control to unauthorized people.
> |
> | S.
> |
> Exactly. And seeing another huge "everything to everyone" server is why
> I never got motivated to do more than observe Geronimo. I'd be better
> served keeping up on what I have to do to keep my existing 'monolith' as
> secure as possible. If it can be broken down, re-arranged, reassembled -
> and still "just work", it would be THE server to use - not just
> "another" server.
I think that this discussion thread now has two distinctly different topics:
a) Geronimo SVN repo restructuring
b) Geronimo modules packaging for user consumption
Can we please split this discussion and keep each one on topic?
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Arentz wrote: | ... | | Security-wise it is also a nightmare. There is so much stuff running in | the container that I have no idea of. I usually bind the instance to | localhost and do port translation for those TCP/IP services that need | to be exposed, but even then there are still many ways to connect to it | from localhost that could potentially expose information or give | control to unauthorized people. | | S. | Exactly. And seeing another huge "everything to everyone" server is why I never got motivated to do more than observe Geronimo. I'd be better served keeping up on what I have to do to keep my existing 'monolith' as secure as possible. If it can be broken down, re-arranged, reassembled - and still "just work", it would be THE server to use - not just "another" server. Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl2kZaCoPKRow/gARAtT0AKDTGdqFdKGwhwMqVOmsSGkKPLXkXgCeL2vr ua9uF67yfhbZMVPcztRL7IM= =qcty -END PGP SIGNATURE-
Re: Module restructure
I'm worried that it would be a giant hassle to try to assemble a geronimo that is 90% stable and 10% unstable. I also don't see the advantage of this plan over simply creating a branch whenever someone wants to do some disruptive experimentation, and merging the results back in when appropriate. This worked fine for me for the work I did rewriting the jetty deployer. If I understand the svn docs this is more in line with "standard svn practice". thanks david jencks On May 27, 2005, at 11:25 AM, Jeremy Boynes wrote: Aaron Mulder wrote: On Fri, 27 May 2005, Geir Magnusson Jr. wrote: so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? Who's responsible for merging changes between branches so that unstable gets all the changes that go into stable and trunk? That seems likely to be painful. We are. Stable is, well, stable, so there will be relatively few changes made directly there (mainly bugfixes). The biggest chore will be merging new features from (unstable,trunk) into stable as part of a new release. For a major release, we may just say the unstable tree is now stable and copy it over en-masse; for an incremental release we may need to merge. Also, is the expectation that a given module only goes in one place (so transactions, if high-quality, have source only in stable or whatever), or is the same code in all 3 and you're just expected to know where to work on it? If the latter, that sounds unwieldy too. If the former, then we should just have 2 or 3 separate dirs with their own trunk, branches, and tags, right? Taking transaction as an example, let's say we consider it stable now. We would have that as a module in the stable tree and the build would output a specific version (say transaction-1.0.1). We would not need a copy in the unstable tree, the unstable assembly could just use that artifact. Now, David decides to implement some new feature, he copies the stable branch into the unstable tree and starts implementing. At some point he wants to integrate that with the unstable assembly so updates it to use a SNAPSHOT version of his new module. When he's done and we all agree that this should be part of the stable build, we merge the changes back into the stable tree and re-release (say as transaction-1.2.0). The merge should not be too painful because there would not have been a lot of changes in the stable tree. If he's done, we can switch the unstable assembly back to using the new release build and delete the transaction module from the unstable tree; if he wants to keep working on it then we just leave it there. The idea is to create a balance between users who want stable versions that they can use and the desire to innovate. -- Jeremy
Re: Module restructure
On May 27, 2005, at 8:25 PM, Brian K. Wallace wrote: ... I'm not a committer, nor have I been more than an observer to what Geronimo is doing and where it's going - primarily because everything I've seen has placed it in the JBoss realm. I've used JBoss for quite a while and am always amazed at the functionality it has ingrained in it for which I just have no use. Most of my time spent upgrading is in finding out how to turn things off that have changed. Security-wise it is also a nightmare. There is so much stuff running in the container that I have no idea of. I usually bind the instance to localhost and do port translation for those TCP/IP services that need to be exposed, but even then there are still many ways to connect to it from localhost that could potentially expose information or give control to unauthorized people. S.
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Arentz wrote:
| On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:
|
|> Stefan brings up the question of whether we want to release sub-
|> modules of Geronimo separately. I think this is a good idea and would
|> propose the following restructure of the tree to move in this direction.
|
|
| Let me just explain my motivation a bit, maybe that will also help for
| the plan.
|
| In my original email I said something about not needing all the J2EE
| stuff. I exaggerated a bit of course, but most of the applications that
| I have been writing in the last couple of years are done mostly with a
| subset of the whole J2EE umbrella. Some apps were just some network
| service wrapped in (JMX) beans, a service exposed with Spring (Burlap,
| XML-RPC) other apps were simply a web app backed by a shared Spring
| context. I've never needed all the stuff in J2EE.
|
| So far I've always done this on JBoss. Their MBean stuff works ok, but
| I wish it was easier to 'downsize' jboss to just a container with the
| stuff I need. That never really seemed to be their goal however. The
| complexity of their configuration files shows that.
|
| So, what I would really like to see wrt Geronimo is an absolute minimal
| server with add-on packages for things like a web container, jms
| provider, etc. You want to host a web app? Throw in the Tomcat or Jetty
| personality. Need JMS too, add ActiveMQ. Persistence? Simply add a
| hibernate deployer. Mix and match so that it does what your app needs.
|
| This is where Geronimo could shine and even take away a large chunk of
| Tomcat; most people just want to deploy their web app and optionally
| add some more services without having to understand a full J2EE stack.
| Geronimo can fill that void extremely well I think. (Simple Web
| Container .. .. J2EE Monolith)
|
| Ok so just complaining doesn't work well for this project, so what I
| really would like to do is start figuring out how I can give Geronimo
| 'personalities' for popular combinations of technology. Like,
|
| - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate
| - Geronimo Kernel + Web Services
| - Geronimo Kernel + JMX Enabled custom network service
|
| and then do some writing about it on the wiki. Make recipes for people,
| or even complete packages that are downloadable.
|
| I really think this is how Geronimo can also get acceptance with a much
| larger crowd.
|
| S.
|
I'm not a committer, nor have I been more than an observer to what
Geronimo is doing and where it's going - primarily because everything
I've seen has placed it in the JBoss realm. I've used JBoss for quite a
while and am always amazed at the functionality it has ingrained in it
for which I just have no use. Most of my time spent upgrading is in
finding out how to turn things off that have changed.
This message caught my attention. For the first time, I've seen that I'm
not the only person who things this might be a good idea. I don't want
the world in a server - I just want to be able to add the pieces if/when
I need them to an existing server. This is something JBoss bypasses
entirely... you want to be able to add the pieces? voila - they're added
- - enjoy - whether you wanted them all 'built-in' or not.
I do think this will lead to greater adoption by new users (as well as
those others who want what I do - "the minimal server to do the job,
with expansion capabilities"), as well as greater 'user questions' ("Why
do I get this error?" "Because you don't have the Web Services package
installed/configured"). Questions can be documented all over the place
and users will still come to the mailing list and ask. That, however,
IMHO, is much better than those users already having a "monolith" and
sticking with it rather than move to a Geronimo "monolith" (monolith
used here not in a single application of monolithic proportions, but the
server with mandated functionality that, even when disabled, is still
taking up space). And I'm a firm believer that "it's on the Wiki" isn't
a substitute for good documentation included in the product - it's an
added method of documentation.
As for the pre-packaged versions - I think this would, indeed, be a boon
to Geronimo - - - as long as the individual 'services' were packaged for
some sort of 'drop-in deployment' into an existing Geronimo server as well.
My thoughts...
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCl2YbaCoPKRow/gARAnMNAJ9gxTlKzzp3pRHfd8i2GfQfvl8aIACgru71
6+OCdlthfHuBXTqUKB8JSR8=
=/uYw
-END PGP SIGNATURE-
Re: Module restructure
Aaron Mulder wrote: On Fri, 27 May 2005, Geir Magnusson Jr. wrote: so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? Who's responsible for merging changes between branches so that unstable gets all the changes that go into stable and trunk? That seems likely to be painful. We are. Stable is, well, stable, so there will be relatively few changes made directly there (mainly bugfixes). The biggest chore will be merging new features from (unstable,trunk) into stable as part of a new release. For a major release, we may just say the unstable tree is now stable and copy it over en-masse; for an incremental release we may need to merge. Also, is the expectation that a given module only goes in one place (so transactions, if high-quality, have source only in stable or whatever), or is the same code in all 3 and you're just expected to know where to work on it? If the latter, that sounds unwieldy too. If the former, then we should just have 2 or 3 separate dirs with their own trunk, branches, and tags, right? Taking transaction as an example, let's say we consider it stable now. We would have that as a module in the stable tree and the build would output a specific version (say transaction-1.0.1). We would not need a copy in the unstable tree, the unstable assembly could just use that artifact. Now, David decides to implement some new feature, he copies the stable branch into the unstable tree and starts implementing. At some point he wants to integrate that with the unstable assembly so updates it to use a SNAPSHOT version of his new module. When he's done and we all agree that this should be part of the stable build, we merge the changes back into the stable tree and re-release (say as transaction-1.2.0). The merge should not be too painful because there would not have been a lot of changes in the stable tree. If he's done, we can switch the unstable assembly back to using the new release build and delete the transaction module from the unstable tree; if he wants to keep working on it then we just leave it there. The idea is to create a balance between users who want stable versions that they can use and the desire to innovate. -- Jeremy
Re: Module restructure
On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Let me just explain my motivation a bit, maybe that will also help for the plan. In my original email I said something about not needing all the J2EE stuff. I exaggerated a bit of course, but most of the applications that I have been writing in the last couple of years are done mostly with a subset of the whole J2EE umbrella. Some apps were just some network service wrapped in (JMX) beans, a service exposed with Spring (Burlap, XML-RPC) other apps were simply a web app backed by a shared Spring context. I've never needed all the stuff in J2EE. So far I've always done this on JBoss. Their MBean stuff works ok, but I wish it was easier to 'downsize' jboss to just a container with the stuff I need. That never really seemed to be their goal however. The complexity of their configuration files shows that. So, what I would really like to see wrt Geronimo is an absolute minimal server with add-on packages for things like a web container, jms provider, etc. You want to host a web app? Throw in the Tomcat or Jetty personality. Need JMS too, add ActiveMQ. Persistence? Simply add a hibernate deployer. Mix and match so that it does what your app needs. This is where Geronimo could shine and even take away a large chunk of Tomcat; most people just want to deploy their web app and optionally add some more services without having to understand a full J2EE stack. Geronimo can fill that void extremely well I think. (Simple Web Container .. .. J2EE Monolith) Ok so just complaining doesn't work well for this project, so what I really would like to do is start figuring out how I can give Geronimo 'personalities' for popular combinations of technology. Like, - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate - Geronimo Kernel + Web Services - Geronimo Kernel + JMX Enabled custom network service and then do some writing about it on the wiki. Make recipes for people, or even complete packages that are downloadable. I really think this is how Geronimo can also get acceptance with a much larger crowd. S.
Re: Module restructure
On Fri, 27 May 2005, Geir Magnusson Jr. wrote: > so we have /trunk and /branches/stable and /branches/unstable, the > former for release work, and the latter for really nutty stuff that > people want to work on, and head is where mainline development > continues? Who's responsible for merging changes between branches so that unstable gets all the changes that go into stable and trunk? That seems likely to be painful. Also, is the expectation that a given module only goes in one place (so transactions, if high-quality, have source only in stable or whatever), or is the same code in all 3 and you're just expected to know where to work on it? If the latter, that sounds unwieldy too. If the former, then we should just have 2 or 3 separate dirs with their own trunk, branches, and tags, right? Aaron
Re: Module restructure
Geir Magnusson Jr. wrote, On 5/27/2005 12:27 PM: BTW, however we resolve stable and unstable, I really do like the idea of a separate sandbox tree. That will make things very clear to people. I like that idea as well. Regards, Alan
Re: Module restructure
On May 27, 2005, at 12:48 PM, Geir Magnusson Jr. wrote: On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote: Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - "trunk", "head", "unstable", whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. right - this is SVN, so the standard branching model actually doesn't work. We'll need the branches outside of /trunk anyway so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? (What I'm saying is that I agree with you... we have no real choice because of how SVN does branches. We clearly need to separate stable from unstable ongoing work) geir geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote: Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - "trunk", "head", "unstable", whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. right - this is SVN, so the standard branching model actually doesn't work. We'll need the branches outside of /trunk anyway so we have /trunk and /branches/stable and /branches/unstable, the former for release work, and the latter for really nutty stuff that people want to work on, and head is where mainline development continues? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? The names are just suggestions - "trunk", "head", "unstable", whatever. The important thing is that you can easily checkout and build each tree on its own so we can't have both stable and unstable branches of modules (e.g. transaction) under trunk. -- Jeremy
Re: Module restructure
BTW, however we resolve stable and unstable, I really do like the idea of a separate sandbox tree. That will make things very clear to people. geir On May 27, 2005, at 12:18 PM, Geir Magnusson Jr. wrote: Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than "trunk" in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Module restructure
Clearly, we need something like this to get organized around the final push for certification and the 1.0 release, by why not just branch for the stable, and head is unstable? geir On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote: Stefan brings up the question of whether we want to release sub- modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than "trunk" in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Module restructure
Stefan brings up the question of whether we want to release sub-modules of Geronimo separately. I think this is a good idea and would propose the following restructure of the tree to move in this direction. Rather than "trunk" in the root, we have three separate trees: stablesimilar to even-numbered versions of Linux, this tree would contain stable code intended for production use and operates with a focus on stability (i.e. well documented stable APIs, backward compatibility, no SNAPSHOT dependencies etc.) There will be multiple branches as needed. unstable similar to odd-numbered versions this is where new development is done and APIs etc. are much more likely to change. We may still do releases from here but they are quite likely to be incompatible; it may be all we package from here are nightlies. sandbox as now, a free-for-all area for trying out new ideas and experimenting with new technologies Given the size of the codebase, we need to preserve the module structure that we have in the current trunk. However, even now some modules are more stable than others (e.g. the transaction and connector ones Thierry is looking to use) and I think are in a position where they can be versioned separately. With the structure above in place, we can move modules into the stable or unstable trees as appropriate. For those that we consider stable (e.g. transaction) we can cut numbered releases that people can use standalone. This will also speed the unstable build as we won't need to check SNAPSHOTs for everything all the time. I would suggest we start on this as part of packaging for M4 and would be willing to co-ordinate. -- Jeremy
