You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Prasad Kashyap <go...@gmail.com> on 2007/10/29 15:48:48 UTC
Restructuring build for flexible server
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.
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.
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
Cheers
Prasad
Re: Restructuring build for flexible server
Posted by David Jencks <da...@yahoo.com>.
This looks great!
I had a couple of suggestions I mentioned to Prasad on IRC:
- move client-transaction to the plugins/connector
- move the jetty specific clustering stuff from plugins/clustering to
plugins/jetty
Unfortunately the sandbox doesn't seem to have svn history. I think
its essential to preserve svn history. I think we can get this into
trunk, preserve svn history, and hopefully preserve Prasad's sanity by:
1. create the new directories in trunk (e.g. framework, plugins/
connector, plugins/* etc)
2. svn cp the existing modules and configs to their new locations.
This is probably the hard part.... I guess I'd start with the output
of ls modules configs and write a script.
3. copy the new and modified poms (and other files) from restructure
to trunk. If we copy rather than svn cp modified files we wont break
history. Also, as long as we don't modify the root pom, all work up
to here can be committed without affecting the existing build.
4. after committing the modified root pom, remove modules and configs.
I'm in favor of asking Prasad to do steps 1-3 immediately in trunk.
I'm fine with (4) too but perhaps we should have a vote on (4) since
this is a pretty large change?
thanks
david jencks
On Oct 29, 2007, at 8:51 PM, Prasad Kashyap wrote:
> I ran the tck smoketest (both Jetty & Tomcat) on the restructured
> build and the results were consistent with the ones from the current
> trunk build.
>
> What are the next steps ? If we plan to use this tree for 2.1 trunk,
> then we should merge ASAP before the trees get too much out of synch.
>
> I'd appreciate if folks checked out the restructure dir from sandbox
> and built the new tree.
>
> The steps are listed here again
>
> 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
>
> P.S: If jee-specs and myfaces modules fail to build due to missing
> o.a.myfaces.core/myfaces-* dependencies, just build those in the
> online mode.
>
> Cheers
> Prasad
>
> On 10/29/07, Joe Bohn <jo...@earthlink.net> wrote:
>>
>>
>> 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
>> space.
>>
>> Joe
>>
>>>
>>> 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 -
>>>>> 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
>>>>
>>>>
>>
Re: Restructuring build for flexible server
Posted by Prasad Kashyap <go...@gmail.com>.
I ran the tck smoketest (both Jetty & Tomcat) on the restructured
build and the results were consistent with the ones from the current
trunk build.
What are the next steps ? If we plan to use this tree for 2.1 trunk,
then we should merge ASAP before the trees get too much out of synch.
I'd appreciate if folks checked out the restructure dir from sandbox
and built the new tree.
The steps are listed here again
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
P.S: If jee-specs and myfaces modules fail to build due to missing
o.a.myfaces.core/myfaces-* dependencies, just build those in the
online mode.
Cheers
Prasad
On 10/29/07, Joe Bohn <jo...@earthlink.net> wrote:
>
>
> 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
> space.
>
> Joe
>
> >
> > 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 -
> >>> 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
> >>
> >>
>
Re: Restructuring build for flexible server
Posted by Prasad Kashyap <go...@gmail.com>.
Interesting points. However, I think we should tackle this and other
further restructuring in our next rev. For now, just baby steps.
To dos:
-----------
1. Consider breaking specs after a risk-benefit analysis.
2. Change groupIds and artifactIds. While most cars(plugins) are under
o.a.g.configs, there are some plugins (present plugins dir) under
o.a.g.plugins. But at the end of the day, they are all plugins now.
3. Break the tree into 4-5 smaller trees.
Cheers
Prasad
On 10/29/07, Joe Bohn <jo...@earthlink.net> wrote:
>
>
> 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
> space.
>
> Joe
>
> >
> > 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 -
> >>> 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
> >>
> >>
>
Re: Restructuring build for flexible server
Posted by Joe Bohn <jo...@earthlink.net>.
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
space.
Joe
>
> 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 -
>>> 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
>>
>>
Re: Restructuring build for flexible server
Posted by Donald Woods <dw...@apache.org>.
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.
-Donald
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 -
>> 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
>
>
Re: Restructuring build for flexible server
Posted by Prasad Kashyap <go...@gmail.com>.
OK. This is how I restructured it.
But first, the aim was to keep the groupdId and artifactId of all
artifacts as is so that our assemblies and final server is not
affected. So the gIds and aIds of the modules and configs pieces were
left unchanged for now.
| geronimo
|--- framework
|--- modules
|--- configs
|--- components
|--- plugins
The framework dir contains only those modules and deployers that are
needed by the framework assembly. Only geronimo-j2ee module in
included here because it is needed to build the car-maven-plugin.
The bootstrap profile now builds framework/modules and then builds
mavenplugins (including c-m-p).
All other modules, builders and their corresponding configs (cars) are
moved to their respective dirs under plugins. So plugins/myfaces
contain only myfaces modules and configs.
I put artifacts like spring, transformer-agent and upgrade under
components dir. Maybe they don't belong there. Maybe they can go
elsewhere.
The config pieces for the applications also moved to reside along with
the application wars in the application dirs.
Cheers
Prasad
On 10/30/07, Paul McMahan <pa...@gmail.com> wrote:
> On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote:
>
> > 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.
>
> I noticed that the groupIds in the poms don't always match their
> placement in the svn directory structure. Is the intention to keep
> things this way? For example:
> https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/
> plugins/cxf/cxf/pom.xml
>
> Also I'm curious what qualifies a subproject as belonging under
> plugins, applications, components, configs, or modules . Currently
> it's arranged as:
>
> applications:
> # ca-helper/
> # geronimo-uddi-db/
> # mejb/
> # remote-deploy/
> # sharedlib/
> # uddi-server/
> # welcome/
>
> components:
> # spring/
> # transformer-agent/
> # upgrade/
>
> framework/configs:
> # client-system/
> # geronimo-gbean-deployer/
> # geronimo-gbean-deployer-bootstrap/
> # j2ee-security/
> # j2ee-system/
> # jee-specs/
> # jsr88-cli/
> # jsr88-deploymentfactory/
> # offline-deployer/
> # online-deployer/
> # rmi-naming/
> # server-security-config/
> # shutdown/
> # upgrade-cli/
> # xmlbeans/
>
> framework/modules:
> # geronimo-cli/
> # geronimo-commands/
> # geronimo-common/
> # geronimo-core/
> # geronimo-deploy-config/
> # geronimo-deploy-jsr88/
> # geronimo-deploy-jsr88-bootstrapper/
> # geronimo-deploy-tool/
> # geronimo-deployment/
> # geronimo-interceptor/
> # geronimo-j2ee/
> # geronimo-jdbc/
> # geronimo-jmx-remoting/
> # geronimo-kernel/
> # geronimo-management/
> # geronimo-naming/
> # geronimo-security/
> # geronimo-service-builder/
> # geronimo-system/
> # geronimo-transformer/
> # geronimo-upgrade/
> # geronimo-util/
>
> plugins:
> # activemq/
> # axis/
> # axis2/
> # client/
> # clustering/
> # connector/
> # console/
> # corba/
> # cxf/
> # debugviews/
> # dojo/
> # hotdeploy/
> # j2ee/
> # jasper/
> # javamail/
> # jaxws/
> # jetty/
> # myfaces/
> # openejb/
> # openjpa/
> # plancreator/
> # pluto/
> # system-database/
> # tomcat/
> # webservices/
>
>
>
> Best wishes,
> Paul
>
Re: Restructuring build for flexible server
Posted by Paul McMahan <pa...@gmail.com>.
On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote:
> 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.
I noticed that the groupIds in the poms don't always match their
placement in the svn directory structure. Is the intention to keep
things this way? For example:
https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/
plugins/cxf/cxf/pom.xml
Also I'm curious what qualifies a subproject as belonging under
plugins, applications, components, configs, or modules . Currently
it's arranged as:
applications:
# ca-helper/
# geronimo-uddi-db/
# mejb/
# remote-deploy/
# sharedlib/
# uddi-server/
# welcome/
components:
# spring/
# transformer-agent/
# upgrade/
framework/configs:
# client-system/
# geronimo-gbean-deployer/
# geronimo-gbean-deployer-bootstrap/
# j2ee-security/
# j2ee-system/
# jee-specs/
# jsr88-cli/
# jsr88-deploymentfactory/
# offline-deployer/
# online-deployer/
# rmi-naming/
# server-security-config/
# shutdown/
# upgrade-cli/
# xmlbeans/
framework/modules:
# geronimo-cli/
# geronimo-commands/
# geronimo-common/
# geronimo-core/
# geronimo-deploy-config/
# geronimo-deploy-jsr88/
# geronimo-deploy-jsr88-bootstrapper/
# geronimo-deploy-tool/
# geronimo-deployment/
# geronimo-interceptor/
# geronimo-j2ee/
# geronimo-jdbc/
# geronimo-jmx-remoting/
# geronimo-kernel/
# geronimo-management/
# geronimo-naming/
# geronimo-security/
# geronimo-service-builder/
# geronimo-system/
# geronimo-transformer/
# geronimo-upgrade/
# geronimo-util/
plugins:
# activemq/
# axis/
# axis2/
# client/
# clustering/
# connector/
# console/
# corba/
# cxf/
# debugviews/
# dojo/
# hotdeploy/
# j2ee/
# jasper/
# javamail/
# jaxws/
# jetty/
# myfaces/
# openejb/
# openjpa/
# plancreator/
# pluto/
# system-database/
# tomcat/
# webservices/
Best wishes,
Paul
Re: Restructuring build for flexible server
Posted by Prasad Kashyap <go...@gmail.com>.
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 <da...@yahoo.com> 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
>
>
Re: Restructuring build for flexible server
Posted by David Jencks <da...@yahoo.com>.
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