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 -
http://www.nabble.com/forum/ViewPost.jtp?
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 https://svn.apache.org/repos/asf/geronimo/sandbox/
restructure
4) mvn -o -Dstage=bootstrap
5) mvn -o -Dstage=assembly <---- You should fail here
Thanks!
david jencks
Cheers
Prasad
