David Jencks wrote:
I think the debate over what to do about jee 5 is hurrying down a path
that only compounds and exacerbates many of the problems we have now.
I really hope we can step back a little bit and find a way to solve
more problems than we create and perpetuate.
IIRC the main activities actually postponed until 1.2 are out the door
are:
- reorganize the build/svn tree so it has a core server bit and a bunch
of optional bits (I think this is jdillons description)
Is this the discussion about organization by function rather than type
(so instead of Jetty pieces in modules and configs we would put all of
the jetty pieces into a jetty plugin location)? If so, then I'm all for
it but I'm not sure if it affects this discussion.
- reorganize the build to build by plugin (my description of the same
thing)
- make maven dependencies and geronimo dependencies match (a
consequence of the preceding reorganization)
- make the console plugin based so each plugin includes a console bit
to administer it.
- make the users view of the server plugin based.
IMO not solving these problems keeps our build and architecture very
unpleasant to deal with, and solving most of them should not be very hard.
IMO we should introduce the jee5 features according to this model.
Doing so will entirely avoid the need to branch or keep 2 copies of any
code.
I agree with the ideas presented earlier. However, this last point is
where I no longer follow. Doesn't organizing around plugins *and*
supporting both j2ee 1.4 and javaee5 in the same Geronimo branch/release
ensure that there *will be* duplicate code? Right now we have code to
integrate Jetty 5.x in trunk. IIUC correctly that code has been
duplicated and modified for Jetty 6 in the javaee5 sandbox you created.
With the plugin organization approach and supporting both version of
j2ee we would end up with two Jetty plugins for the same Geronimo
release. Is this correct?
Actually, it seems that the way we distinguish the j2ee1.4 vs. javaee5
jetty plugins is potentially problematic at the moment. A portion of
the jetty version is actually included in the artifact name
(geronimo-jetty6) for javaee5. This seems like it could cause problems
in the future. What happens when Jetty 7 is released? We are no longer
endorsing a single version of Jetty for a release of Geronimo - rather
we are attempting to support multiple Jetty releases and I have to
wonder what the value of this is.
If we were to branch and only support javaee5 within that branch then we
could just upgrade the existing jetty components as necessary with a
specific version of jetty.
In addition, I think several people have expressed the opinion that
supporting j2ee 1.4 and jee5 code simultaneously is going to introduce
some kind of code complexity or difficulty. I think I've been the only
person to address this (correct me if I'm wrong)
Not only are you the only person to address this but I think you are
also the only person who has been able to this to build using trunk and
the sparse tree. (at least I have yet to be able to get a successful
build) ;-)
and so far the changes
I've made for this have been IMO unequivocal architectural improvements
that have simplified and clarified the code base and made it easier to
extend and maintain. They also haven't been that difficult. The main
place this is a problem is deployment code: it's still a big mess, but
its better than it was. I think that at this point most of the
flexibility we'd need to support mixed j2ee 1.4/ jee5 deployments is
probably in place, but I hope that as we work on more jee5 features we
can considerably simplify the structure of the deployment components.
To reiterate over and over again, IMO
-- branching is a bad solution to the wrong problem and we should work
very hard to avoid it
-- supporting various j2ee 1.4- jee5 feature mixes is not hard and
leads to improved architecture and simpler code.
I still see complexity here for both Geronimo developers and more
importantly our users. Even if it is easier then I think it will be ...
what value is there in mixing j2ee1.4 and jee5 features? A javaee5
server should still be able to run applications built for j2ee1.4, right
(downward capability and all that)? Why would a user have a need for a
j2ee1.4 image of Geronimo 2.0?
Thanks,
Joe
