Thanx David. With the latest commit to sandbox, I have all the artifacts building successfully. We have good assemblies too. Tthe groupId and artifactId of all the artifacts have essentially remained the same.
The final server should now pass TCK smoketests and our testsuite. More comments inline - On 10/29/07, David Jencks <[EMAIL PROTECTED]> 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 - > > 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. I'm sorry. I had misrepresented the problem. The j2ee-specs and it's dependencies are fine. The problem is with myfaces artifacts showing up as missing even though they are in very much present in the local repo. I learnt that this is a problem even with the current build. It seemed to be caused by an incorrect publish of the myfaces artifacts. We are fine here as long as we do a online build. > > > > 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? The CredentialStore gbean in security-deployer config needed the j2eeDeployer during c-m-p. The gbean was all but commented out as it is. So I reduced it to a standard empty gbean and removed the j2eeDeployer in the deploymentConfig of the c-m-p. This has solved the problem. > > > > 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=assemble <---- You should fail here I have had to add deps in the console-tomcat and console-jetty poms on a few deployers to impose build order. But for that, we now have a restructured tree. > > Thanks! > david jencks > > > > > Cheers > > Prasad > >
