Geronimo subprojects?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Geronimo subprojects?

Dain Sundstrom
I just read through the long "Module restructure" thread, and it to  
me is seems like many people are talking about how we break Geronimo  
into subprojects without using the word subproject.  The goals of the  
"Module restructure" thread seem to be:

1) allow modules to branch to unstable without requiring the geronimo  
trunk to take unstable code
2) allow modules to have independent release cycles so they don't  
have to wait for geronimo trunk

Regardless what we call it, that is a sub project.  I think we should  
bite the bullet and talk about what sets of functionality make sense  
as a subproject.  For example, I think there is a demonstrated desire  
to have a TX/JCA subproject in Geronimo.

-dain
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Brian K. Wallace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dain Sundstrom wrote:
| I just read through the long "Module restructure" thread, and it to  me
| is seems like many people are talking about how we break Geronimo  into
| subprojects without using the word subproject.  The goals of the
| "Module restructure" thread seem to be:
|
| 1) allow modules to branch to unstable without requiring the geronimo
| trunk to take unstable code
| 2) allow modules to have independent release cycles so they don't  have
| to wait for geronimo trunk
|
| Regardless what we call it, that is a sub project.  I think we should
| bite the bullet and talk about what sets of functionality make sense  as
| a subproject.  For example, I think there is a demonstrated desire  to
| have a TX/JCA subproject in Geronimo.
|
| -dain
|
|
Agreed. And this, if properly combined with 'common deployments', could
be a major step toward getting new users more interested. Undoubtedly it
will require a shift in developer processes, but in the long run it
would (in theory - application of that theory being more in procedure
than possibility) make fixes and enhancements swifter.

My questions at the root of this are:
~  1. Assuming the whole of Geronimo passes the TCK, what can be said of
a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK?
~  2. In stating "there is a demonstrated desire", what roadblocks or
opposition is there to having each of the current modules (short of the
kernel, common, core and presumably deployment - and anything else
needed for the server to start-up and do nothing) each be
'self-contained'? Obviously the 'base' server would have to know what
it's really capable of (unless you go off the deep end with discovery),
but over and above that base it seems that a WebConnector - be it Jetty
for user 1 or Tomcat for user 2 may be used with or without Naming, with
or without Spring and/or Transactions, etc. Why would there be a need to
limit modules just to what there is a "demonstrated desire" to have?
Making everything as small and self-contained (even if they don't 'run'
on their own) seems to be a smart move in allowing a bug in one module
to be fixed and made available without waiting on anything else (how
many times have we wanted a typo fixed that had to wait for a completely
new feature to be implemented?).

My thoughts...

Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo
nG3rKqN5K3CNVFIEWPDSKjg=
=BFcE
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Jeff Genender


Brian K. Wallace wrote:

> ~  1. Assuming the whole of Geronimo passes the TCK, what can be said of
> a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK?

TCK is all or nothing.  You pass all tests or you don't pass
certification.  A minimal Geronimo would clearly be a subset of the
"whole tomato", so TCK has no bearing on this, nor should there be
concern.  A minimal Geronimo is just disconnecting the features you
don't want from the configuration.  TCK and minimal Geronimo are
mutually exclusive and do not impact each other in any way.

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Dain Sundstrom
In reply to this post by Brian K. Wallace

On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote:

> Agreed. And this, if properly combined with 'common deployments',  
> could
> be a major step toward getting new users more interested.  
> Undoubtedly it
> will require a shift in developer processes, but in the long run it
> would (in theory - application of that theory being more in procedure
> than possibility) make fixes and enhancements swifter.

Absolutely

> My questions at the root of this are:
> ~  1. Assuming the whole of Geronimo passes the TCK, what can be  
> said of
> a 'minimal' Geronimo? Is it able to claim anything with regard to  
> the TCK?

It depends on the specifications the subproject is implementing and  
if Sun has a stand-alone tck for the specifications.  For example, if  
it were the Geronimo 'just a webserver edition' we could certify it  
for servlets and jsp because they have standalone tcks, but if it  
were tx and jca we could not certify it since there are no standalone  
tcks for those specs.

On the other hand, I'm sure if enough people are interested,  
sufficient pressure could be applied to Sun to carve a stand-alone  
tck out of the j2ee monolith.

> ~  2. In stating "there is a demonstrated desire", what roadblocks or
> opposition is there to having each of the current modules (short of  
> the
> kernel, common, core and presumably deployment - and anything else
> needed for the server to start-up and do nothing) each be
> 'self-contained'? Obviously the 'base' server would have to know what
> it's really capable of (unless you go off the deep end with  
> discovery),
> but over and above that base it seems that a WebConnector - be it  
> Jetty
> for user 1 or Tomcat for user 2 may be used with or without Naming,  
> with
> or without Spring and/or Transactions, etc. Why would there be a  
> need to
> limit modules just to what there is a "demonstrated desire" to have?

Each subproject has an inherent amount of overhead.  For example,  
each subproject needs a separate project management committee, each  
one will need to produce releases (not an easy task) and so on.  I  
would sat that "there is a demonstrated desire" when we have enough  
people showing up to handle the overhead and work on the code.  I  
personally would say one person is not enough, and seven is more then  
enough.

> Making everything as small and self-contained (even if they don't  
> 'run'
> on their own) seems to be a smart move in allowing a bug in one module
> to be fixed and made available without waiting on anything else (how
> many times have we wanted a typo fixed that had to wait for a  
> completely
> new feature to be implemented?).

I think there are technical and realistic limits to this.  Some  
modules are simply to small to be full projects.  For example the rmi  
classloadder is like 5 classes.  Also some modules naturally fit  
together and have a high degree of coupling.  For example the Tx  
manager and the j2ca implementation naturally fit together.  Now you  
can use the Tx manager standalone, but you can't really use j2ca  
without a Tx manager. Because of that linking the modules normally  
move together.  I would say we put both in one sub project and have  
them release two jars.

-dain
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Jeff Genender
In reply to this post by Jeff Genender
I think I wrote something a little confusing...let me clarify...

What we do to a subset of Geronimo has impact on the whether it passes.
  However if Geronimo passes the TCK, then a subset would include the
features that passed.  However, as it stands, passing is an
all-or-nothing propsition.

I hope that was less confuusing.

Jeff Genender wrote:

>
>
> Brian K. Wallace wrote:
>
>> ~  1. Assuming the whole of Geronimo passes the TCK, what can be said of
>> a 'minimal' Geronimo? Is it able to claim anything with regard to the
>> TCK?
>
>
> TCK is all or nothing.  You pass all tests or you don't pass
> certification.  A minimal Geronimo would clearly be a subset of the
> "whole tomato", so TCK has no bearing on this, nor should there be
> concern.  A minimal Geronimo is just disconnecting the features you
> don't want from the configuration.  TCK and minimal Geronimo are
> mutually exclusive and do not impact each other in any way.
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

David Jencks
In reply to this post by Dain Sundstrom
So far I am completely unconvinced by any arguments in this thread.

As a thought experiment, lets suppose we had already released a
certified geronimo, say last month, and we had solved most of our build
problems, say with maven2.  So, we have a certified branch and trunk,
and all the geronimo developers are happily working on new features on
trunk.

In this scenario exactly what needs changing and why?

thanks
david jencks

On May 28, 2005, at 10:38 AM, Dain Sundstrom wrote:

>
> On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote:
>
>> Agreed. And this, if properly combined with 'common deployments',
>> could
>> be a major step toward getting new users more interested. Undoubtedly
>> it
>> will require a shift in developer processes, but in the long run it
>> would (in theory - application of that theory being more in procedure
>> than possibility) make fixes and enhancements swifter.
>
> Absolutely
>
>> My questions at the root of this are:
>> ~  1. Assuming the whole of Geronimo passes the TCK, what can be said
>> of
>> a 'minimal' Geronimo? Is it able to claim anything with regard to the
>> TCK?
>
> It depends on the specifications the subproject is implementing and if
> Sun has a stand-alone tck for the specifications.  For example, if it
> were the Geronimo 'just a webserver edition' we could certify it for
> servlets and jsp because they have standalone tcks, but if it were tx
> and jca we could not certify it since there are no standalone tcks for
> those specs.
>
> On the other hand, I'm sure if enough people are interested,
> sufficient pressure could be applied to Sun to carve a stand-alone tck
> out of the j2ee monolith.
>
>> ~  2. In stating "there is a demonstrated desire", what roadblocks or
>> opposition is there to having each of the current modules (short of
>> the
>> kernel, common, core and presumably deployment - and anything else
>> needed for the server to start-up and do nothing) each be
>> 'self-contained'? Obviously the 'base' server would have to know what
>> it's really capable of (unless you go off the deep end with
>> discovery),
>> but over and above that base it seems that a WebConnector - be it
>> Jetty
>> for user 1 or Tomcat for user 2 may be used with or without Naming,
>> with
>> or without Spring and/or Transactions, etc. Why would there be a need
>> to
>> limit modules just to what there is a "demonstrated desire" to have?
>
> Each subproject has an inherent amount of overhead.  For example, each
> subproject needs a separate project management committee, each one
> will need to produce releases (not an easy task) and so on.  I would
> sat that "there is a demonstrated desire" when we have enough people
> showing up to handle the overhead and work on the code.  I personally
> would say one person is not enough, and seven is more then enough.
>
>> Making everything as small and self-contained (even if they don't
>> 'run'
>> on their own) seems to be a smart move in allowing a bug in one module
>> to be fixed and made available without waiting on anything else (how
>> many times have we wanted a typo fixed that had to wait for a
>> completely
>> new feature to be implemented?).
>
> I think there are technical and realistic limits to this.  Some
> modules are simply to small to be full projects.  For example the rmi
> classloadder is like 5 classes.  Also some modules naturally fit
> together and have a high degree of coupling.  For example the Tx
> manager and the j2ca implementation naturally fit together.  Now you
> can use the Tx manager standalone, but you can't really use j2ca
> without a Tx manager. Because of that linking the modules normally
> move together.  I would say we put both in one sub project and have
> them release two jars.
>
> -dain
>

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Brian K. Wallace
In reply to this post by Dain Sundstrom
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dain Sundstrom wrote:
|
|> My questions at the root of this are:
|> ~  1. Assuming the whole of Geronimo passes the TCK, what can be  said of
|> a 'minimal' Geronimo? Is it able to claim anything with regard to  the
|> TCK?
|
|
| It depends on the specifications the subproject is implementing and  if
| Sun has a stand-alone tck for the specifications.  For example, if  it
| were the Geronimo 'just a webserver edition' we could certify it  for
| servlets and jsp because they have standalone tcks, but if it  were tx
| and jca we could not certify it since there are no standalone  tcks for
| those specs.
Understood. My main question was if there was some sort of 'prohibition'
on the use of 'full system' pass/fail statistics for those pieces that
do, in fact, have their own tcks. [I don't view this as a roadblock to
anything, but a definite plus if each individual piece that was able
(due to having and passing their own tcks) could state it passes.]
|
| On the other hand, I'm sure if enough people are interested,  sufficient
| pressure could be applied to Sun to carve a stand-alone  tck out of the
| j2ee monolith.
This I would see as a 'good thing'. Amazing how software has progressed
(*cough*) to 'smaller components combined into larger applications', but
tests (even certifications) aren't quite there yet.
|
|> ~  2. In stating "there is a demonstrated desire", what roadblocks or
|> opposition is there to having each of the current modules (short of  the
|> kernel, common, core and presumably deployment - and anything else
|> needed for the server to start-up and do nothing) each be
|> 'self-contained'? Obviously the 'base' server would have to know what
|> it's really capable of (unless you go off the deep end with  discovery),
|> but over and above that base it seems that a WebConnector - be it  Jetty
|> for user 1 or Tomcat for user 2 may be used with or without Naming,  with
|> or without Spring and/or Transactions, etc. Why would there be a  need to
|> limit modules just to what there is a "demonstrated desire" to have?
|
|
| Each subproject has an inherent amount of overhead.  For example,  each
| subproject needs a separate project management committee, each  one will
| need to produce releases (not an easy task) and so on.  I  would sat
| that "there is a demonstrated desire" when we have enough  people
| showing up to handle the overhead and work on the code.  I  personally
| would say one person is not enough, and seven is more then  enough.
Agreed. My view here would be to take the position "Here is the 'best
laid plan', who is willing to make it work" instead of "Here is how
people are working, what's the best plan we can come up with that
doesn't affect that". Granted, there will probably be pieces that should
probably be split out without resources to manage it, but if you aim
high you have a better chance of getting an optimal solution in place.
And nothing says that this can't be further refined down the road.
|
|> Making everything as small and self-contained (even if they don't  'run'
|> on their own) seems to be a smart move in allowing a bug in one module
|> to be fixed and made available without waiting on anything else (how
|> many times have we wanted a typo fixed that had to wait for a  completely
|> new feature to be implemented?).
|
|
| I think there are technical and realistic limits to this.  Some  modules
| are simply to small to be full projects.  For example the rmi
| classloadder is like 5 classes.  Also some modules naturally fit
| together and have a high degree of coupling.  For example the Tx
| manager and the j2ca implementation naturally fit together.  Now you
| can use the Tx manager standalone, but you can't really use j2ca
| without a Tx manager. Because of that linking the modules normally  move
| together.  I would say we put both in one sub project and have  them
| release two jars.
|
| -dain
Agreed here as well. The RMI classloader is what I consider 'too small
to make it worth it' and fell in to my "as small and self-contained" as
possible. Possible should be read with the implication of 'realistic'.
My view on the tx/j2ca type of 'module' is tempered with "overhead
costs" and agree that those types of modules may be best combined as you
stated. (although removal of that tempered view thinks they should be
separate, with the j2ca simply having a dependency on tx.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCmLImaCoPKRow/gARAvX6AJ9Q54WWyRF1M7K6drBBBsOtbSdtrACeMJW3
LhwcnkO+Bqm9EtvL9h0fSsA=
=ssHt
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Brian K. Wallace
In reply to this post by David Jencks
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Jencks wrote:
| So far I am completely unconvinced by any arguments in this thread.
|
| As a thought experiment, lets suppose we had already released a
| certified geronimo, say last month, and we had solved most of our build
| problems, say with maven2.  So, we have a certified branch and trunk,
| and all the geronimo developers are happily working on new features on
| trunk.
|
| In this scenario exactly what needs changing and why?
|
| thanks
| david jencks
|
I don't believe there's anything wrong with your 'thought experiment'.
My view is, however, that never is there work to be done everywhere in a
project. Taking your scenario above - all developers are happily working
on new features on trunk and there's a security problem in a particular
module. What went from "there's nothing wrong with this approach" now
shifts to "we need to get this fixed as soon as possible" for a
particular module. Again, this is most certainly doable with the
structure as-is. However, a faster fix/test/release cycle would be
possible if the module was able to handle it at that level instead of
involving the whole of geronimo's code and developer base for everything
from "if your code involves this module" (perhaps a 'new feature' not in
any way involved with what the bug is) to testing and documentation.

I don't think there is a "right" or "wrong" way to do it. Both work. I
personally believe smaller is better - then integrate. I also believe
this would promote multiple 'pre-built' deployment options (not "make it
possible", just promote). But I'm only one person. Just proposing
options for greater flexibility.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCmLSJaCoPKRow/gARAg35AJ9IfDwevATEMfyEuwv2JWMVoHygugCdFmLU
qat86jpRD2Qu4ifDT4Upe48=
=gXBM
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Alan Cabrera
In reply to this post by David Jencks
I think that people would like to see components broken down so that
they can mix-n-match the pieces that they want, rather than having to
always swallow the whole enchilada.

The question then is, how do you break up these pieces so that we can
support this.


Regards,
Alan

David Jencks wrote, On 5/28/2005 1:57 PM:

> So far I am completely unconvinced by any arguments in this thread.
>
> As a thought experiment, lets suppose we had already released a
> certified geronimo, say last month, and we had solved most of our
> build problems, say with maven2.  So, we have a certified branch and
> trunk, and all the geronimo developers are happily working on new
> features on trunk.
>
> In this scenario exactly what needs changing and why?
>
> thanks
> david jencks
>
> On May 28, 2005, at 10:38 AM, Dain Sundstrom wrote:
>
>>
>> On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote:
>>
>>> Agreed. And this, if properly combined with 'common deployments', could
>>> be a major step toward getting new users more interested.
>>> Undoubtedly it
>>> will require a shift in developer processes, but in the long run it
>>> would (in theory - application of that theory being more in procedure
>>> than possibility) make fixes and enhancements swifter.
>>
>>
>> Absolutely
>>
>>> My questions at the root of this are:
>>> ~  1. Assuming the whole of Geronimo passes the TCK, what can be
>>> said of
>>> a 'minimal' Geronimo? Is it able to claim anything with regard to
>>> the TCK?
>>
>>
>> It depends on the specifications the subproject is implementing and
>> if Sun has a stand-alone tck for the specifications.  For example, if
>> it were the Geronimo 'just a webserver edition' we could certify it
>> for servlets and jsp because they have standalone tcks, but if it
>> were tx and jca we could not certify it since there are no standalone
>> tcks for those specs.
>>
>> On the other hand, I'm sure if enough people are interested,
>> sufficient pressure could be applied to Sun to carve a stand-alone
>> tck out of the j2ee monolith.
>>
>>> ~  2. In stating "there is a demonstrated desire", what roadblocks or
>>> opposition is there to having each of the current modules (short of the
>>> kernel, common, core and presumably deployment - and anything else
>>> needed for the server to start-up and do nothing) each be
>>> 'self-contained'? Obviously the 'base' server would have to know what
>>> it's really capable of (unless you go off the deep end with discovery),
>>> but over and above that base it seems that a WebConnector - be it Jetty
>>> for user 1 or Tomcat for user 2 may be used with or without Naming,
>>> with
>>> or without Spring and/or Transactions, etc. Why would there be a
>>> need to
>>> limit modules just to what there is a "demonstrated desire" to have?
>>
>>
>> Each subproject has an inherent amount of overhead.  For example,
>> each subproject needs a separate project management committee, each
>> one will need to produce releases (not an easy task) and so on.  I
>> would sat that "there is a demonstrated desire" when we have enough
>> people showing up to handle the overhead and work on the code.  I
>> personally would say one person is not enough, and seven is more then
>> enough.
>>
>>> Making everything as small and self-contained (even if they don't 'run'
>>> on their own) seems to be a smart move in allowing a bug in one module
>>> to be fixed and made available without waiting on anything else (how
>>> many times have we wanted a typo fixed that had to wait for a
>>> completely
>>> new feature to be implemented?).
>>
>>
>> I think there are technical and realistic limits to this.  Some
>> modules are simply to small to be full projects.  For example the rmi
>> classloadder is like 5 classes.  Also some modules naturally fit
>> together and have a high degree of coupling.  For example the Tx
>> manager and the j2ca implementation naturally fit together.  Now you
>> can use the Tx manager standalone, but you can't really use j2ca
>> without a Tx manager. Because of that linking the modules normally
>> move together.  I would say we put both in one sub project and have
>> them release two jars.
>>
>> -dain
>>

Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Bruce Snyder
In reply to this post by Dain Sundstrom
On 5/28/05, Dain Sundstrom <[hidden email]> wrote:

> Each subproject has an inherent amount of overhead.  For example,
> each subproject needs a separate project management committee, each
> one will need to produce releases (not an easy task) and so on.  I
> would sat that "there is a demonstrated desire" when we have enough
> people showing up to handle the overhead and work on the code.  I
> personally would say one person is not enough, and seven is more then
> enough.

I don't think that every subproject needs it's own PMC unless it's a
subproject wholly separate from the existing Geronimo modules. For
example, if the Spring kernel were brought in as a subproject, it
would need its own PMC, but I don't think splitting up the existing
modules and forming individual PMCs is necessary.

Bruce
--
perl -e 'print unpack("u30","D0G)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: Geronimo subprojects?

Bruce Snyder
In reply to this post by Alan Cabrera
On 5/28/05, Alan D. Cabrera <[hidden email]> wrote:

> I think that people would like to see components broken down so that
> they can mix-n-match the pieces that they want, rather than having to
> always swallow the whole enchilada.
>
> The question then is, how do you break up these pieces so that we can
> support this.

Very well said, Alan.

As a group excercise, and just to make sure everyone involved
understands this discussion, I think that all involved should come to
Colorado to experience Big Head Todd and the Montsters on June 4 at
Red Rocks Amphitheatre. We can commense a meeting that afternnoon. ;-)

Bruce
--
perl -e 'print unpack("u30","D0G)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: Geronimo subprojects?

Alan Cabrera
In reply to this post by Bruce Snyder


Bruce Snyder wrote, On 5/29/2005 2:08 AM:
On 5/28/05, Dain Sundstrom [hidden email] wrote:

  
Each subproject has an inherent amount of overhead.  For example,
each subproject needs a separate project management committee, each
one will need to produce releases (not an easy task) and so on.  I
would sat that "there is a demonstrated desire" when we have enough
people showing up to handle the overhead and work on the code.  I
personally would say one person is not enough, and seven is more then
enough.
    

I don't think that every subproject needs it's own PMC unless it's a
subproject wholly separate from the existing Geronimo modules. For
example, if the Spring kernel were brought in as a subproject, it
would need its own PMC, but I don't think splitting up the existing
modules and forming individual PMCs is necessary.
  
I agree.  IMHO, those projects that could qualify as being subprojects worthy of having a PMC seem to already be at codehaus.


Regards,
Alan


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Geir Magnusson Jr.
In reply to this post by Dain Sundstrom

On May 28, 2005, at 12:38 PM, Dain Sundstrom wrote:

> I just read through the long "Module restructure" thread, and it to  
> me is seems like many people are talking about how we break  
> Geronimo into subprojects without using the word subproject.

That may be where it went to out of confusion, but I think the  
original point was how to get organized so we can have a stable tree  
that is what those of us interested in a sable certified release work  
in while other work can continue.

> The goals of the "Module restructure" thread seem to be:
>
> 1) allow modules to branch to unstable without requiring the  
> geronimo trunk to take unstable code

I would have gone the other way - branch out the stable and let work  
continue in trunk, and loony things go off to a sandbox.

> 2) allow modules to have independent release cycles so they don't  
> have to wait for geronimo trunk
>
> Regardless what we call it, that is a sub project.  I think we  
> should bite the bullet and talk about what sets of functionality  
> make sense as a subproject.  For example, I think there is a  
> demonstrated desire to have a TX/JCA subproject in Geronimo.
>

The problem with trying to force the language to be "subproject"  
rather than "module" is that "subproject" is a loaded word at apache  
with different meaning - in that it has historically, from jakarta,  
tended to mean separate, autonomous projects that live under a  
project umbrella.  I don't think anyone here is advocating that, and  
I'd prefer we not have to explain what we mean over and over to the  
rest of the Apache community....

geir


> -dain
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Geir Magnusson Jr.
In reply to this post by Brian K. Wallace

On May 28, 2005, at 1:20 PM, Brian K. Wallace wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dain Sundstrom wrote:
> | I just read through the long "Module restructure" thread, and it  
> to  me
> | is seems like many people are talking about how we break  
> Geronimo  into
> | subprojects without using the word subproject.  The goals of the
> | "Module restructure" thread seem to be:
> |
> | 1) allow modules to branch to unstable without requiring the  
> geronimo
> | trunk to take unstable code
> | 2) allow modules to have independent release cycles so they  
> don't  have
> | to wait for geronimo trunk
> |
> | Regardless what we call it, that is a sub project.  I think we  
> should
> | bite the bullet and talk about what sets of functionality make  
> sense  as
> | a subproject.  For example, I think there is a demonstrated  
> desire  to
> | have a TX/JCA subproject in Geronimo.
> |
> | -dain
> |
> |
> Agreed. And this, if properly combined with 'common deployments',  
> could
> be a major step toward getting new users more interested.  
> Undoubtedly it
> will require a shift in developer processes, but in the long run it
> would (in theory - application of that theory being more in procedure
> than possibility) make fixes and enhancements swifter.
>
> My questions at the root of this are:
> ~  1. Assuming the whole of Geronimo passes the TCK, what can be  
> said of
> a 'minimal' Geronimo? Is it able to claim anything with regard to  
> the TCK?

No.  Nothing.  The binary that passes the TCK is the only thing about  
which claims can be made.

> ~  2. In stating "there is a demonstrated desire", what roadblocks or
> opposition is there to having each of the current modules (short of  
> the
> kernel, common, core and presumably deployment - and anything else
> needed for the server to start-up and do nothing) each be
> 'self-contained'? Obviously the 'base' server would have to know what
> it's really capable of (unless you go off the deep end with  
> discovery),
> but over and above that base it seems that a WebConnector - be it  
> Jetty
> for user 1 or Tomcat for user 2 may be used with or without Naming,  
> with
> or without Spring and/or Transactions, etc. Why would there be a  
> need to
> limit modules just to what there is a "demonstrated desire" to have?
> Making everything as small and self-contained (even if they don't  
> 'run'
> on their own) seems to be a smart move in allowing a bug in one module
> to be fixed and made available without waiting on anything else (how
> many times have we wanted a typo fixed that had to wait for a  
> completely
> new feature to be implemented?).

I think that the most logical partitioning, which we've talked about  
for a loooong long time, is having the server framework separate,  
done in a way that's easily reusable by others, free of J2EE cruft,  
etc.  Then the other parts that are J2EE - in entirety, like the J2EE  
assembly - or in parts, like TX, could be separate.

geir

>
> My thoughts...
>
> Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo
> nG3rKqN5K3CNVFIEWPDSKjg=
> =BFcE
> -----END PGP SIGNATURE-----
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Geir Magnusson Jr.
In reply to this post by Jeff Genender

On May 28, 2005, at 1:41 PM, Jeff Genender wrote:

> I think I wrote something a little confusing...let me clarify...
>
> What we do to a subset of Geronimo has impact on the whether it  
> passes.  However if Geronimo passes the TCK, then a subset would  
> include the features that passed.

Technically speaking, you couldn't make that claim.

> However, as it stands, passing is an all-or-nothing propsition.

Yes.

We do have licenses for stand-alone TCKs for projects that we have.  
I'd be hard-pressed to argue that we should be able to get TCks for  
things we don't have, like JMS.

geir

>
> I hope that was less confuusing.
>
> Jeff Genender wrote:
>
>> Brian K. Wallace wrote:
>>
>>> ~  1. Assuming the whole of Geronimo passes the TCK, what can be  
>>> said of
>>> a 'minimal' Geronimo? Is it able to claim anything with regard to  
>>> the TCK?
>>>
>> TCK is all or nothing.  You pass all tests or you don't pass  
>> certification.  A minimal Geronimo would clearly be a subset of  
>> the "whole tomato", so TCK has no bearing on this, nor should  
>> there be concern.  A minimal Geronimo is just disconnecting the  
>> features you don't want from the configuration.  TCK and minimal  
>> Geronimo are mutually exclusive and do not impact each other in  
>> any way.
>>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Geir Magnusson Jr.
In reply to this post by Brian K. Wallace

On May 28, 2005, at 2:02 PM, Brian K. Wallace wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dain Sundstrom wrote:
> |
> |> My questions at the root of this are:
> |> ~  1. Assuming the whole of Geronimo passes the TCK, what can  
> be  said of
> |> a 'minimal' Geronimo? Is it able to claim anything with regard  
> to  the
> |> TCK?
> |
> |
> | It depends on the specifications the subproject is implementing  
> and  if
> | Sun has a stand-alone tck for the specifications.  For example,  
> if  it
> | were the Geronimo 'just a webserver edition' we could certify it  
> for
> | servlets and jsp because they have standalone tcks, but if it  
> were tx
> | and jca we could not certify it since there are no standalone  
> tcks for
> | those specs.
> Understood. My main question was if there was some sort of  
> 'prohibition'
> on the use of 'full system' pass/fail statistics for those pieces that
> do, in fact, have their own tcks. [I don't view this as a roadblock to
> anything, but a definite plus if each individual piece that was able
> (due to having and passing their own tcks) could state it passes.]

Yes.  If you want to know if the servlet part works on it's own, you  
need to test it on it's own

geir

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


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Geir Magnusson Jr.
In reply to this post by Bruce Snyder

On May 29, 2005, at 2:08 AM, Bruce Snyder wrote:

> On 5/28/05, Dain Sundstrom <[hidden email]> wrote:
>
>
>> Each subproject has an inherent amount of overhead.  For example,
>> each subproject needs a separate project management committee, each
>> one will need to produce releases (not an easy task) and so on.  I
>> would sat that "there is a demonstrated desire" when we have enough
>> people showing up to handle the overhead and work on the code.  I
>> personally would say one person is not enough, and seven is more then
>> enough.
>>
>
> I don't think that every subproject needs it's own PMC unless it's a
> subproject wholly separate from the existing Geronimo modules. For
> example, if the Spring kernel were brought in as a subproject, it
> would need its own PMC, but I don't think splitting up the existing
> modules and forming individual PMCs is necessary.

Right.  I don't think we need sub-projects or want sub-projects.  I  
think we just need to modularize better and be able to have a stable  
J2EE assembly tree to help the push towards a certified 1.0 Geronimo  
release.

geir

>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)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/
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Jeff Genender
In reply to this post by Geir Magnusson Jr.


Geir Magnusson Jr. wrote:

>
> On May 28, 2005, at 1:41 PM, Jeff Genender wrote:
>
>> I think I wrote something a little confusing...let me clarify...
>>
>> What we do to a subset of Geronimo has impact on the whether it  
>> passes.  However if Geronimo passes the TCK, then a subset would  
>> include the features that passed.
>
>
> Technically speaking, you couldn't make that claim.

Does the law of transitivity not apply here?  If Jetty passes the TCK,
would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not
mean that we are using the passed component for web?

My point was:

Full G Change (where it passes) ---> G Lite contains passed code.

but

G Lite is changed -----> May impact full G's passing of TCK.

Please clarify how this claim may not be valid.

Jeff
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Jeremy Boynes
Jeff Genender wrote:

>
>
> Geir Magnusson Jr. wrote:
>
>>
>> On May 28, 2005, at 1:41 PM, Jeff Genender wrote:
>>
>>> I think I wrote something a little confusing...let me clarify...
>>>
>>> What we do to a subset of Geronimo has impact on the whether it  
>>> passes.  However if Geronimo passes the TCK, then a subset would  
>>> include the features that passed.
>>
>>
>>
>> Technically speaking, you couldn't make that claim.
>
>
> Does the law of transitivity not apply here?  If Jetty passes the TCK,
> would its use on its own in a Geronimo Lite (i.e. G + Jetty only) not
> mean that we are using the passed component for web?
>
> My point was:
>
> Full G Change (where it passes) ---> G Lite contains passed code.
>
> but
>
> G Lite is changed -----> May impact full G's passing of TCK.
>
> Please clarify how this claim may not be valid.
>

I believe natural laws do not apply here given lawyers are involved :-)

Certification applies only to specific binary distributions, so if Jetty
released a binary and certified it then they could claim compatibility
for that version (and even then only on a specific set of platforms).
Any other binary, including Geronimo, that incorporated Jetty would not
be able to claim compatibility unless the combined work was tested.
Similarly if Geronimo incorporates Jetty and certifies then it does not
mean that Jetty standalone can claim compatibility.

What makes matters worse is that some specifications (for example EJB,
J2CA) currently cannot be licensed separately from J2EE making it
impossible to claim compatibility with them standalone.

--
Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Geronimo subprojects?

Dain Sundstrom
In reply to this post by Geir Magnusson Jr.
On May 30, 2005, at 11:22 AM, Geir Magnusson Jr. wrote:

> On May 28, 2005, at 12:38 PM, Dain Sundstrom wrote:
>
>> I just read through the long "Module restructure" thread, and it  
>> to me is seems like many people are talking about how we break  
>> Geronimo into subprojects without using the word subproject.
>>
>
> That may be where it went to out of confusion, but I think the  
> original point was how to get organized so we can have a stable  
> tree that is what those of us interested in a sable certified  
> release work in while other work can continue.

Nice. I'm interested in a stable tree for certification.  I just want  
to avoid unnecessary complexity and all of the module restructuring  
plans so far seem like a svn merge nightmare

>> The goals of the "Module restructure" thread seem to be:
>>
>> 1) allow modules to branch to unstable without requiring the  
>> geronimo trunk to take unstable code
>>
>
> I would have gone the other way - branch out the stable and let  
> work continue in trunk, and loony things go off to a sandbox.

Agreed.  That was a typo, but you got the meaning.

>> 2) allow modules to have independent release cycles so they don't  
>> have to wait for geronimo trunk
>>
>> Regardless what we call it, that is a sub project.  I think we  
>> should bite the bullet and talk about what sets of functionality  
>> make sense as a subproject.  For example, I think there is a  
>> demonstrated desire to have a TX/JCA subproject in Geronimo.
>>
>>
>
> The problem with trying to force the language to be "subproject"  
> rather than "module" is that "subproject" is a loaded word at  
> apache with different meaning - in that it has historically, from  
> jakarta, tended to mean separate, autonomous projects that live  
> under a project umbrella.  I don't think anyone here is advocating  
> that, and I'd prefer we not have to explain what we mean over and  
> over to the rest of the Apache community....

I am advocating that we take stuff like the tx an j2ca implementation  
and make it a "separate, autonomous projects that live under a  
project umbrella".  That way, those that are interested and  
understand those technologies can choose how to develop the code.  
They can choose when to branch, when to do releases, how to structure  
their modules, and so on.  There seems to be an interest in this from  
the community.

-dain


12