geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Java EE 5.0
Date Wed, 08 Nov 2006 21:01:36 GMT

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?


View raw message