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
[EMAIL PROTECTED]
