Module restructure

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Module restructure

Jeremy Boynes
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:

stable    similar 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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Geir Magnusson Jr.
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:
>
> stable    similar 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
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Geir Magnusson Jr.
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:
>>
>> stable    similar 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
> [hidden email]
>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Jeremy Boynes
In reply to this post by Geir Magnusson Jr.
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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Geir Magnusson Jr.

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
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Geir Magnusson Jr.

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
> [hidden email]
>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Alan Cabrera
In reply to this post by Geir Magnusson Jr.


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


Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

ammulder
In reply to this post by Geir Magnusson Jr.
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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Stefan Arentz-3
In reply to this post by Jeremy Boynes
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 .. <VOID> .. 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.

Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Brian K. Wallace
-----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 .. <VOID> .. 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-----
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Jeremy Boynes
In reply to this post by ammulder
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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Stefan Arentz-3
In reply to this post by Brian K. Wallace

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.

Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

David Jencks-2
In reply to this post by Jeremy Boynes
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Brian K. Wallace
In reply to this post by Stefan Arentz-3
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Bruce Snyder
On 5/27/05, Brian K. Wallace <[hidden email]> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Jeremy Boynes
In reply to this post by David Jencks-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Jeremy Boynes
In reply to this post by Stefan Arentz-3
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 <VOID>: 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 .. <VOID> .. 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

David Blevins
In reply to this post by Geir Magnusson Jr.
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:
> >
> >stable    similar 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
> [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

David Blevins
In reply to this post by Jeremy Boynes
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
Reply | Threaded
Open this post in threaded view
|

Re: Module restructure

Geir Magnusson Jr.
In reply to this post by David Blevins

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:
>>>
>>> stable    similar 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
>> [hidden email]
>>
>>
>
>

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


123