geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Restructuring build for flexible server
Date Tue, 30 Oct 2007 01:26:20 GMT

Donald Woods wrote:
> I think we really need to find some way to break the specs into smaller
> pieces.  Having to install all of the JEE specs just for the simple
> minimal web container assembly is ugly and wastes disk space.

Well, we could have a config per spec ... but that might be a bit too 
much.  I'm not sure what smaller organizations would look like.

We thought about breaking jee-specs up when we created the minimal 
assemblies but at the time it didn't seem worthy of the effort.  Now 
that we are getting closer to making the flexible server a reality 
perhaps it is time.  But I'm still not convinced that it would be worth 
the complexities it would bring and it doesn't consume a huge amount of 


> David Jencks wrote:
>> Good work!!  A couple comments inline.
>> On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote:
>>> I spend most of the weekend trying to restructure trunk to reflect the
>>> new flexible server and I should tell you, it has been one shitty job
>>> much akin to untangling the knots of Medusa's hair.
>>> To begin with I wanted to build just the modules and configs (along
>>> with the necessary buildsupport and  maven-plugins artifacts) that go
>>> into a framework assembly.I believe that if we effectively want to
>>> restructure the build tree to reflect the flexible server, then we
>>> should be able to build just the framework artifacts ONLY. The
>>> framework artifacts should not have a dependency on plugins artifacts
>>> because they are optionally choosen to build an assembly of choice.
>>> Also, if our strategic vision is to break down the tree into smaller
>>> projects for framework, plugins etc, this we should break this
>>> cyclical dependency too. See Jason's response here -
>>> First hitch - Our framework assembly contains jee-specs car. This car
>>> has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is
>>> in a incorrect dependency which we don't need at this point or it
>>> might be truly needed here so that it gets in the classpath for later
>>> use. I commented this dependency out and proceeded to build jee-specs
>>> car. I strongly tend to believe that this myfaces dep is wrongly
>>> placed here. If it is really req'd then we have a bigger problem of
>>> fixing our classloader scheme.
>> I don't understand the problem here and what you want to do.  We have 
>> several other specs (from axis and jstl) that we don't build that are 
>> included in jee-specs.  Is the jsf api different from these in some 
>> way?  Do you want to remove the jsf spec from jee-specs or the 
>> jee-specs from the framework assembly?  I remember having a lot of 
>> classloader problems trying to get stuff to run and pass the tck 
>> before we came up with the jee-specs module, but it might be possible 
>> to split it up and put the jars with the implementations that use 
>> them.  I think this will be difficult so I'd like to postpone that.
>>> Second hitch - Trying to build framework assembly's
>>> server-security-config car requires you to build j2ee-deployer. If you
>>> wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars
>>> which in turn has a dependency on webservices. Slowly we are building
>>> more and more plugins which are optional artifacts.
>> This is definitely a problem.  I think we can solve it with a 
>> security-deployer config that has the security related gbeans from 
>> j2ee-deployer in it.  What do you think?
>>> If we really have to build a lot of plugins just to build the
>>> framework artifacts, then there is little point in restructuring the
>>> build tree now or breaking the tree later.
>>> I have checked in the restructured code under sandbox/restructure. I
>>> have been able to do a bootstrap build thus far.
>>> To build this on your machine, take the following steps
>>> 1) begin with a good local repository for your trunk build
>>> 2) delete applications, assemblies, modules, geronimo, configs,
>>> plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
>>> local repo.
>>> 3) svn co
>>> 4) mvn -o -Dstage=bootstrap
>>> 5) mvn -o -Dstage=assembly  <---- You should fail here
>> Thanks!
>> david jencks
>>> Cheers
>>> Prasad

View raw message