geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Restructuring build for flexible server
Date Mon, 29 Oct 2007 16:14:00 GMT
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 -
> post=12460948&framed=y&skin=134
> 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 
> restructure
> 4) mvn -o -Dstage=bootstrap
> 5) mvn -o -Dstage=assembly  <---- You should fail here

david jencks

> Cheers
> Prasad

View raw message