You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2008/05/12 13:20:44 UTC
Need some advice on how to include repository/* bits in the boilerplate
I'm trying to remove the use of the gshell-embeddable artifact, which
includes some duplicates (like jline, xstream, slf4j, etc)... but I
can't figure out how the new assembly bits are used to get stuff into
the repository/*.
I can hack something up (with the assembly + antrun plugins) but I'm
wondering if there is a better way. I'd like to not have a ton of pom
config to list all of the gshell required dependencies, just use mvn's
transitive deps to populate the repository/* with the bits that gshell
needs.
Anyone have any suggestions?
--jason
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Donald Woods <dw...@apache.org>.
BTW - I opened GERONIMO-4012 so we can track the changes for this effort...
-Donald
Jason Dillon wrote:
> I'm trying to remove the use of the gshell-embeddable artifact, which
> includes some duplicates (like jline, xstream, slf4j, etc)... but I
> can't figure out how the new assembly bits are used to get stuff into
> the repository/*.
>
> I can hack something up (with the assembly + antrun plugins) but I'm
> wondering if there is a better way. I'd like to not have a ton of pom
> config to list all of the gshell required dependencies, just use mvn's
> transitive deps to populate the repository/* with the bits that gshell
> needs.
>
> Anyone have any suggestions?
>
> --jason
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Jason Dillon <ja...@planet57.com>.
On May 14, 2008, at 3:23 AM, Donald Woods wrote:
> Well, changes were already checked into trunk about 20 miins. before
> your email....
> The changes need to also go into branches/2.1, because right now we
> have different/duplicate versions of some depends included in
> Geronimo 2.1.x and 2.2, due to the gshell-embeddable jarfile, which
> was created using the shade-maven-plugin and no one noticed the
> mismatched depends and the fact that Geronimo is actually including
> additional plexus and gshell jars that are not visible in our
> repository, due to shade extracting them and repackaging them into
> this uber gshell-embeddable jar.....
I'm not sure why this matters at all, since those dependencies are
really *only* used by gshell anyways.
> I'm for fixing the transitive depend mechanism in car-maven-plugin,
> as long as it correctly handles different versions between the
> server and other projects, with the server/pom.xml specified
> versions always winning.
>
> I'm against the continued usage of the gshell-embeddable jar, as it
> hides the fact that we are including other depends in our server
> assemblies and will just likely cause more version conflicts and
> duplicate depends in the future. Maybe if you get the car-maven-
> plugin updated for transitive depends and mismatched versions, then
> we can just create a new gshell-framework pom that lets gshell tell
> us and the car-maven-plugin which depends to pull in....
Well, gshell-embeddable is going to be going away... BUT, I still
think that there is no issue with any mismatched anything, and that
this is a made up problem.
--jason
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Jason Dillon <ja...@planet57.com>.
On May 14, 2008, at 3:23 AM, Donald Woods wrote:
> I'm against the continued usage of the gshell-embeddable jar, as it
> hides the fact that we are including other depends in our server
> assemblies and will just likely cause more version conflicts and
> duplicate depends in the future. Maybe if you get the car-maven-
> plugin updated for transitive depends and mismatched versions, then
> we can just create a new gshell-framework pom that lets gshell tell
> us and the car-maven-plugin which depends to pull in....
And it just occurred to me that not using gshell-embedabble, at least
to pick up the plexus support classes which gshell requires may in
fact break other things, since gshell uses a much newer version of
plexus than maven does, meaning that inclusion of the newer stuff
could break some code depending on the other version.
But we'll have to see...
--jason
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Donald Woods <dw...@apache.org>.
Well, changes were already checked into trunk about 20 miins. before
your email....
The changes need to also go into branches/2.1, because right now we have
different/duplicate versions of some depends included in Geronimo 2.1.x
and 2.2, due to the gshell-embeddable jarfile, which was created using
the shade-maven-plugin and no one noticed the mismatched depends and the
fact that Geronimo is actually including additional plexus and gshell
jars that are not visible in our repository, due to shade extracting
them and repackaging them into this uber gshell-embeddable jar.....
I'm for fixing the transitive depend mechanism in car-maven-plugin, as
long as it correctly handles different versions between the server and
other projects, with the server/pom.xml specified versions always winning.
I'm against the continued usage of the gshell-embeddable jar, as it
hides the fact that we are including other depends in our server
assemblies and will just likely cause more version conflicts and
duplicate depends in the future. Maybe if you get the car-maven-plugin
updated for transitive depends and mismatched versions, then we can just
create a new gshell-framework pom that lets gshell tell us and the
car-maven-plugin which depends to pull in....
-Donald
David Jencks wrote:
> I talked with jason a bit on irc and we're doing an experiment with
> optionally including transitive dependencies using the
> car-maven-plugin. Hopefully this will work and avoid the duplication
> jason is leery of. Please don't commit duplication until we find out if
> this works or not.
>
> AFAICT this isn't a bug fix but rather new development so I'm unclear
> about why you are thinking of including this in 2.1.2?
>
> thanks
> david jencks
>
> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>
>> I started with your new framework/configs/gshell-* code, updated
>> gshell-framework to include all the individual depends so we don't
>> need gshell-embeddable, updated server/pom.xml with the new depends
>> and updated boilerplate with the new gshell-geronimo car depend and it
>> looks promising. I'm still exercising some of the gsh commands, but
>> so far help, geronimo/start-server, deploy/connect and
>> geronimo/stop-server are working....
>>
>> If all looks well after a few more tests, I'll commit the changes into
>> trunk for everyone to review before we spend the time pulling it into
>> 2.1.2.
>>
>>
>> -Donald
>>
>>
>> Jason Dillon wrote:
>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>> So including the dependencies you need for gshell in the
>>>> boilerplate's pom would get them into the geronimo repo. As I said
>>>> transitive dependencies don't result in inclusion at the moment for
>>>> rather good reasons. I don't know what the <include> tag would do
>>>> but it's probably worth investigating.
>>> What <include> tag are you talking about?
>>> I guess I'm gonna try to make plugins for the gshell dependencies,
>>> these 3:
>>> gshell-framework - just the core bits required to make gshell work
>>> gshell-geronimo - our additional commands to work with the server
>>> + their deps
>>> gshell-remote - the remote/whisper commands
>>> I must say I'm really quite frustrated at the lack of transitive
>>> dependency support here. As this means that alot of the
>>> dependencyManagement configuration which is already in the GShell
>>> poms need to be duplicated into the Geronimo poms, making version
>>> management even more of a nightmare.
>>> :-(
>>> Well, I started to add these cars to framework/configs, but I must
>>> admit I really am clueless for how this stuff works now.
>>> :-(
>>> --jason
>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 15, 2008, at 8:36 PM, Jason Dillon wrote:
> Hey, so now the plugins are doing the trick... yay... thanks David!
BTW, following a comment you made on IRC, I've been reworking the
mojos to not use codehaus mojo-support but go directly to the maven
dependency code stuff. It's taken a little while to get working but I
think I'm close now. I'll be offline most of tomorrow but can
probably commit monday.
>
>
> But, now I'm wondering, when the server loads, it shows those
> plugins loading, which is fine I guess... but I'm wondering if they
> are eating up memory or building classpath muck that is never going
> to be used by the server (or well, not until we get support for
> running an rshd instance in the server).
>
I want to look at what is happening here again.... probably nothing
bad but I'd like to check.
thanks
david jencks
> --jason
>
>
> On May 14, 2008, at 2:38 PM, David Jencks wrote:
>
>>
>> On May 13, 2008, at 6:02 PM, Donald Woods wrote:
>>
>>> Attached patch includes other changes, like moving to jaxb 2.1,
>>> some security changes, ....
>>
>> I thought I left out the security changes, sorry. Comes from
>> trying to do too many things at once :-(
>>>
>>>
>>> Other comments attached to GERONIMO-4013.
>>
>> I may have been unclear. I wasn't suggesting my initial
>> GERONIMO-4013 patch was suitable to be committed, but that it might
>> let us figure out some of the problems with the idea of the car-
>> maven-plugin including maven transitive dependencies before we
>> broke everything at once. In particular it looks to me as if the
>> dependencies for the gshell-* plugins are too all-inclusive and was
>> wondering what to do about this.
>>
>> For instance, I have no problem with removing gshell-embeddable,
>> but would prefer to get the car-maven-plugin working better before
>> attacking that problem.
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> David Jencks wrote:
>>>> I've attached a patch to GERONIMO-4013 that reverses the changes
>>>> from 4012 and change the car-maven-plugin to optionally follow
>>>> transitive dependencies. I think if you apply my patch you won't
>>>> be using the gshell-* plugins. I had to make a couple other
>>>> minor build changes to get the build to complete. The server
>>>> builds and shows signs of starting -- on my copy it runs into
>>>> some problems with unrelated changes to the security system I'm
>>>> working on.
>>>> Jason, can you check the generated dependencies in the gshell-*
>>>> plugins to see if they look remotely plausible or can be nudged
>>>> closer to plausible?
>>>> thanks
>>>> david jencks
>>>> On May 13, 2008, at 11:55 AM, David Jencks wrote:
>>>>> I talked with jason a bit on irc and we're doing an experiment
>>>>> with optionally including transitive dependencies using the car-
>>>>> maven-plugin. Hopefully this will work and avoid the
>>>>> duplication jason is leery of. Please don't commit duplication
>>>>> until we find out if this works or not.
>>>>>
>>>>> AFAICT this isn't a bug fix but rather new development so I'm
>>>>> unclear about why you are thinking of including this in 2.1.2?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>>>>>
>>>>>> I started with your new framework/configs/gshell-* code,
>>>>>> updated gshell-framework to include all the individual depends
>>>>>> so we don't need gshell-embeddable, updated server/pom.xml with
>>>>>> the new depends and updated boilerplate with the new gshell-
>>>>>> geronimo car depend and it looks promising. I'm still
>>>>>> exercising some of the gsh commands, but so far help, geronimo/
>>>>>> start-server, deploy/connect and geronimo/stop-server are
>>>>>> working....
>>>>>>
>>>>>> If all looks well after a few more tests, I'll commit the
>>>>>> changes into trunk for everyone to review before we spend the
>>>>>> time pulling it into 2.1.2.
>>>>>>
>>>>>>
>>>>>> -Donald
>>>>>>
>>>>>>
>>>>>> Jason Dillon wrote:
>>>>>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>>>>>> So including the dependencies you need for gshell in the
>>>>>>>> boilerplate's pom would get them into the geronimo repo. As
>>>>>>>> I said transitive dependencies don't result in inclusion at
>>>>>>>> the moment for rather good reasons. I don't know what the
>>>>>>>> <include> tag would do but it's probably worth investigating.
>>>>>>> What <include> tag are you talking about?
>>>>>>> I guess I'm gonna try to make plugins for the gshell
>>>>>>> dependencies, these 3:
>>>>>>> gshell-framework - just the core bits required to make gshell
>>>>>>> work
>>>>>>> gshell-geronimo - our additional commands to work with the
>>>>>>> server + their deps
>>>>>>> gshell-remote - the remote/whisper commands
>>>>>>> I must say I'm really quite frustrated at the lack of
>>>>>>> transitive dependency support here. As this means that alot
>>>>>>> of the dependencyManagement configuration which is already in
>>>>>>> the GShell poms need to be duplicated into the Geronimo poms,
>>>>>>> making version management even more of a nightmare.
>>>>>>> :-(
>>>>>>> Well, I started to add these cars to framework/configs, but I
>>>>>>> must admit I really am clueless for how this stuff works now.
>>>>>>> :-(
>>>>>>> --jason
>>>>>
>>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 15, 2008, at 5:36 PM, Jason Dillon wrote:
> Hey, so now the plugins are doing the trick... yay... thanks David!
>
> But, now I'm wondering, when the server loads, it shows those
> plugins loading, which is fine I guess... but I'm wondering if they
> are eating up memory or building classpath muck that is never going
> to be used by the server (or well, not until we get support for
> running an rshd instance in the server).
Hmm, how are they added to the config? If they are ancestors of j2ee-
system then they get into the base geronimo classloader. Most likely
they are getting started but the resulting classloader is not a parent
of anything.
We can prevent them from even starting by having another "server"
configuration that they are specified for in the plugin goo, similar
to how the client-* plugins work.
thanks
david jencks
>
>
>
> --jason
>
>
> On May 14, 2008, at 2:38 PM, David Jencks wrote:
>
>>
>> On May 13, 2008, at 6:02 PM, Donald Woods wrote:
>>
>>> Attached patch includes other changes, like moving to jaxb 2.1,
>>> some security changes, ....
>>
>> I thought I left out the security changes, sorry. Comes from
>> trying to do too many things at once :-(
>>>
>>>
>>> Other comments attached to GERONIMO-4013.
>>
>> I may have been unclear. I wasn't suggesting my initial
>> GERONIMO-4013 patch was suitable to be committed, but that it might
>> let us figure out some of the problems with the idea of the car-
>> maven-plugin including maven transitive dependencies before we
>> broke everything at once. In particular it looks to me as if the
>> dependencies for the gshell-* plugins are too all-inclusive and was
>> wondering what to do about this.
>>
>> For instance, I have no problem with removing gshell-embeddable,
>> but would prefer to get the car-maven-plugin working better before
>> attacking that problem.
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> David Jencks wrote:
>>>> I've attached a patch to GERONIMO-4013 that reverses the changes
>>>> from 4012 and change the car-maven-plugin to optionally follow
>>>> transitive dependencies. I think if you apply my patch you won't
>>>> be using the gshell-* plugins. I had to make a couple other
>>>> minor build changes to get the build to complete. The server
>>>> builds and shows signs of starting -- on my copy it runs into
>>>> some problems with unrelated changes to the security system I'm
>>>> working on.
>>>> Jason, can you check the generated dependencies in the gshell-*
>>>> plugins to see if they look remotely plausible or can be nudged
>>>> closer to plausible?
>>>> thanks
>>>> david jencks
>>>> On May 13, 2008, at 11:55 AM, David Jencks wrote:
>>>>> I talked with jason a bit on irc and we're doing an experiment
>>>>> with optionally including transitive dependencies using the car-
>>>>> maven-plugin. Hopefully this will work and avoid the
>>>>> duplication jason is leery of. Please don't commit duplication
>>>>> until we find out if this works or not.
>>>>>
>>>>> AFAICT this isn't a bug fix but rather new development so I'm
>>>>> unclear about why you are thinking of including this in 2.1.2?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>>>>>
>>>>>> I started with your new framework/configs/gshell-* code,
>>>>>> updated gshell-framework to include all the individual depends
>>>>>> so we don't need gshell-embeddable, updated server/pom.xml with
>>>>>> the new depends and updated boilerplate with the new gshell-
>>>>>> geronimo car depend and it looks promising. I'm still
>>>>>> exercising some of the gsh commands, but so far help, geronimo/
>>>>>> start-server, deploy/connect and geronimo/stop-server are
>>>>>> working....
>>>>>>
>>>>>> If all looks well after a few more tests, I'll commit the
>>>>>> changes into trunk for everyone to review before we spend the
>>>>>> time pulling it into 2.1.2.
>>>>>>
>>>>>>
>>>>>> -Donald
>>>>>>
>>>>>>
>>>>>> Jason Dillon wrote:
>>>>>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>>>>>> So including the dependencies you need for gshell in the
>>>>>>>> boilerplate's pom would get them into the geronimo repo. As
>>>>>>>> I said transitive dependencies don't result in inclusion at
>>>>>>>> the moment for rather good reasons. I don't know what the
>>>>>>>> <include> tag would do but it's probably worth investigating.
>>>>>>> What <include> tag are you talking about?
>>>>>>> I guess I'm gonna try to make plugins for the gshell
>>>>>>> dependencies, these 3:
>>>>>>> gshell-framework - just the core bits required to make gshell
>>>>>>> work
>>>>>>> gshell-geronimo - our additional commands to work with the
>>>>>>> server + their deps
>>>>>>> gshell-remote - the remote/whisper commands
>>>>>>> I must say I'm really quite frustrated at the lack of
>>>>>>> transitive dependency support here. As this means that alot
>>>>>>> of the dependencyManagement configuration which is already in
>>>>>>> the GShell poms need to be duplicated into the Geronimo poms,
>>>>>>> making version management even more of a nightmare.
>>>>>>> :-(
>>>>>>> Well, I started to add these cars to framework/configs, but I
>>>>>>> must admit I really am clueless for how this stuff works now.
>>>>>>> :-(
>>>>>>> --jason
>>>>>
>>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Jason Dillon <ja...@planet57.com>.
Hey, so now the plugins are doing the trick... yay... thanks David!
But, now I'm wondering, when the server loads, it shows those plugins
loading, which is fine I guess... but I'm wondering if they are eating
up memory or building classpath muck that is never going to be used by
the server (or well, not until we get support for running an rshd
instance in the server).
--jason
On May 14, 2008, at 2:38 PM, David Jencks wrote:
>
> On May 13, 2008, at 6:02 PM, Donald Woods wrote:
>
>> Attached patch includes other changes, like moving to jaxb 2.1,
>> some security changes, ....
>
> I thought I left out the security changes, sorry. Comes from trying
> to do too many things at once :-(
>>
>>
>> Other comments attached to GERONIMO-4013.
>
> I may have been unclear. I wasn't suggesting my initial
> GERONIMO-4013 patch was suitable to be committed, but that it might
> let us figure out some of the problems with the idea of the car-
> maven-plugin including maven transitive dependencies before we broke
> everything at once. In particular it looks to me as if the
> dependencies for the gshell-* plugins are too all-inclusive and was
> wondering what to do about this.
>
> For instance, I have no problem with removing gshell-embeddable, but
> would prefer to get the car-maven-plugin working better before
> attacking that problem.
>
> thanks
> david jencks
>
>>
>>
>>
>> -Donald
>>
>>
>> David Jencks wrote:
>>> I've attached a patch to GERONIMO-4013 that reverses the changes
>>> from 4012 and change the car-maven-plugin to optionally follow
>>> transitive dependencies. I think if you apply my patch you won't
>>> be using the gshell-* plugins. I had to make a couple other minor
>>> build changes to get the build to complete. The server builds and
>>> shows signs of starting -- on my copy it runs into some problems
>>> with unrelated changes to the security system I'm working on.
>>> Jason, can you check the generated dependencies in the gshell-*
>>> plugins to see if they look remotely plausible or can be nudged
>>> closer to plausible?
>>> thanks
>>> david jencks
>>> On May 13, 2008, at 11:55 AM, David Jencks wrote:
>>>> I talked with jason a bit on irc and we're doing an experiment
>>>> with optionally including transitive dependencies using the car-
>>>> maven-plugin. Hopefully this will work and avoid the duplication
>>>> jason is leery of. Please don't commit duplication until we find
>>>> out if this works or not.
>>>>
>>>> AFAICT this isn't a bug fix but rather new development so I'm
>>>> unclear about why you are thinking of including this in 2.1.2?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>>>>
>>>>> I started with your new framework/configs/gshell-* code, updated
>>>>> gshell-framework to include all the individual depends so we
>>>>> don't need gshell-embeddable, updated server/pom.xml with the
>>>>> new depends and updated boilerplate with the new gshell-geronimo
>>>>> car depend and it looks promising. I'm still exercising some of
>>>>> the gsh commands, but so far help, geronimo/start-server, deploy/
>>>>> connect and geronimo/stop-server are working....
>>>>>
>>>>> If all looks well after a few more tests, I'll commit the
>>>>> changes into trunk for everyone to review before we spend the
>>>>> time pulling it into 2.1.2.
>>>>>
>>>>>
>>>>> -Donald
>>>>>
>>>>>
>>>>> Jason Dillon wrote:
>>>>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>>>>> So including the dependencies you need for gshell in the
>>>>>>> boilerplate's pom would get them into the geronimo repo. As I
>>>>>>> said transitive dependencies don't result in inclusion at the
>>>>>>> moment for rather good reasons. I don't know what the
>>>>>>> <include> tag would do but it's probably worth investigating.
>>>>>> What <include> tag are you talking about?
>>>>>> I guess I'm gonna try to make plugins for the gshell
>>>>>> dependencies, these 3:
>>>>>> gshell-framework - just the core bits required to make gshell
>>>>>> work
>>>>>> gshell-geronimo - our additional commands to work with the
>>>>>> server + their deps
>>>>>> gshell-remote - the remote/whisper commands
>>>>>> I must say I'm really quite frustrated at the lack of
>>>>>> transitive dependency support here. As this means that alot of
>>>>>> the dependencyManagement configuration which is already in the
>>>>>> GShell poms need to be duplicated into the Geronimo poms,
>>>>>> making version management even more of a nightmare.
>>>>>> :-(
>>>>>> Well, I started to add these cars to framework/configs, but I
>>>>>> must admit I really am clueless for how this stuff works now.
>>>>>> :-(
>>>>>> --jason
>>>>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 13, 2008, at 6:02 PM, Donald Woods wrote:
> Attached patch includes other changes, like moving to jaxb 2.1, some
> security changes, ....
I thought I left out the security changes, sorry. Comes from trying
to do too many things at once :-(
>
>
> Other comments attached to GERONIMO-4013.
I may have been unclear. I wasn't suggesting my initial GERONIMO-4013
patch was suitable to be committed, but that it might let us figure
out some of the problems with the idea of the car-maven-plugin
including maven transitive dependencies before we broke everything at
once. In particular it looks to me as if the dependencies for the
gshell-* plugins are too all-inclusive and was wondering what to do
about this.
For instance, I have no problem with removing gshell-embeddable, but
would prefer to get the car-maven-plugin working better before
attacking that problem.
thanks
david jencks
>
>
>
> -Donald
>
>
> David Jencks wrote:
>> I've attached a patch to GERONIMO-4013 that reverses the changes
>> from 4012 and change the car-maven-plugin to optionally follow
>> transitive dependencies. I think if you apply my patch you won't
>> be using the gshell-* plugins. I had to make a couple other minor
>> build changes to get the build to complete. The server builds and
>> shows signs of starting -- on my copy it runs into some problems
>> with unrelated changes to the security system I'm working on.
>> Jason, can you check the generated dependencies in the gshell-*
>> plugins to see if they look remotely plausible or can be nudged
>> closer to plausible?
>> thanks
>> david jencks
>> On May 13, 2008, at 11:55 AM, David Jencks wrote:
>>> I talked with jason a bit on irc and we're doing an experiment
>>> with optionally including transitive dependencies using the car-
>>> maven-plugin. Hopefully this will work and avoid the duplication
>>> jason is leery of. Please don't commit duplication until we find
>>> out if this works or not.
>>>
>>> AFAICT this isn't a bug fix but rather new development so I'm
>>> unclear about why you are thinking of including this in 2.1.2?
>>>
>>> thanks
>>> david jencks
>>>
>>> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>>>
>>>> I started with your new framework/configs/gshell-* code, updated
>>>> gshell-framework to include all the individual depends so we
>>>> don't need gshell-embeddable, updated server/pom.xml with the new
>>>> depends and updated boilerplate with the new gshell-geronimo car
>>>> depend and it looks promising. I'm still exercising some of the
>>>> gsh commands, but so far help, geronimo/start-server, deploy/
>>>> connect and geronimo/stop-server are working....
>>>>
>>>> If all looks well after a few more tests, I'll commit the changes
>>>> into trunk for everyone to review before we spend the time
>>>> pulling it into 2.1.2.
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> Jason Dillon wrote:
>>>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>>>> So including the dependencies you need for gshell in the
>>>>>> boilerplate's pom would get them into the geronimo repo. As I
>>>>>> said transitive dependencies don't result in inclusion at the
>>>>>> moment for rather good reasons. I don't know what the
>>>>>> <include> tag would do but it's probably worth investigating.
>>>>> What <include> tag are you talking about?
>>>>> I guess I'm gonna try to make plugins for the gshell
>>>>> dependencies, these 3:
>>>>> gshell-framework - just the core bits required to make gshell
>>>>> work
>>>>> gshell-geronimo - our additional commands to work with the
>>>>> server + their deps
>>>>> gshell-remote - the remote/whisper commands
>>>>> I must say I'm really quite frustrated at the lack of transitive
>>>>> dependency support here. As this means that alot of the
>>>>> dependencyManagement configuration which is already in the
>>>>> GShell poms need to be duplicated into the Geronimo poms, making
>>>>> version management even more of a nightmare.
>>>>> :-(
>>>>> Well, I started to add these cars to framework/configs, but I
>>>>> must admit I really am clueless for how this stuff works now.
>>>>> :-(
>>>>> --jason
>>>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Donald Woods <dw...@apache.org>.
Attached patch includes other changes, like moving to jaxb 2.1, some
security changes, ....
Other comments attached to GERONIMO-4013.
-Donald
David Jencks wrote:
> I've attached a patch to GERONIMO-4013 that reverses the changes from
> 4012 and change the car-maven-plugin to optionally follow transitive
> dependencies. I think if you apply my patch you won't be using the
> gshell-* plugins. I had to make a couple other minor build changes to
> get the build to complete. The server builds and shows signs of
> starting -- on my copy it runs into some problems with unrelated changes
> to the security system I'm working on.
>
> Jason, can you check the generated dependencies in the gshell-* plugins
> to see if they look remotely plausible or can be nudged closer to
> plausible?
>
> thanks
> david jencks
>
> On May 13, 2008, at 11:55 AM, David Jencks wrote:
>
>> I talked with jason a bit on irc and we're doing an experiment with
>> optionally including transitive dependencies using the
>> car-maven-plugin. Hopefully this will work and avoid the duplication
>> jason is leery of. Please don't commit duplication until we find out
>> if this works or not.
>>
>> AFAICT this isn't a bug fix but rather new development so I'm unclear
>> about why you are thinking of including this in 2.1.2?
>>
>> thanks
>> david jencks
>>
>> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>>
>>> I started with your new framework/configs/gshell-* code, updated
>>> gshell-framework to include all the individual depends so we don't
>>> need gshell-embeddable, updated server/pom.xml with the new depends
>>> and updated boilerplate with the new gshell-geronimo car depend and
>>> it looks promising. I'm still exercising some of the gsh commands,
>>> but so far help, geronimo/start-server, deploy/connect and
>>> geronimo/stop-server are working....
>>>
>>> If all looks well after a few more tests, I'll commit the changes
>>> into trunk for everyone to review before we spend the time pulling it
>>> into 2.1.2.
>>>
>>>
>>> -Donald
>>>
>>>
>>> Jason Dillon wrote:
>>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>>> So including the dependencies you need for gshell in the
>>>>> boilerplate's pom would get them into the geronimo repo. As I said
>>>>> transitive dependencies don't result in inclusion at the moment for
>>>>> rather good reasons. I don't know what the <include> tag would do
>>>>> but it's probably worth investigating.
>>>> What <include> tag are you talking about?
>>>> I guess I'm gonna try to make plugins for the gshell dependencies,
>>>> these 3:
>>>> gshell-framework - just the core bits required to make gshell work
>>>> gshell-geronimo - our additional commands to work with the server
>>>> + their deps
>>>> gshell-remote - the remote/whisper commands
>>>> I must say I'm really quite frustrated at the lack of transitive
>>>> dependency support here. As this means that alot of the
>>>> dependencyManagement configuration which is already in the GShell
>>>> poms need to be duplicated into the Geronimo poms, making version
>>>> management even more of a nightmare.
>>>> :-(
>>>> Well, I started to add these cars to framework/configs, but I must
>>>> admit I really am clueless for how this stuff works now.
>>>> :-(
>>>> --jason
>>
>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
I've attached a patch to GERONIMO-4013 that reverses the changes from
4012 and change the car-maven-plugin to optionally follow transitive
dependencies. I think if you apply my patch you won't be using the
gshell-* plugins. I had to make a couple other minor build changes to
get the build to complete. The server builds and shows signs of
starting -- on my copy it runs into some problems with unrelated
changes to the security system I'm working on.
Jason, can you check the generated dependencies in the gshell-*
plugins to see if they look remotely plausible or can be nudged closer
to plausible?
thanks
david jencks
On May 13, 2008, at 11:55 AM, David Jencks wrote:
> I talked with jason a bit on irc and we're doing an experiment with
> optionally including transitive dependencies using the car-maven-
> plugin. Hopefully this will work and avoid the duplication jason is
> leery of. Please don't commit duplication until we find out if this
> works or not.
>
> AFAICT this isn't a bug fix but rather new development so I'm
> unclear about why you are thinking of including this in 2.1.2?
>
> thanks
> david jencks
>
> On May 13, 2008, at 11:32 AM, Donald Woods wrote:
>
>> I started with your new framework/configs/gshell-* code, updated
>> gshell-framework to include all the individual depends so we don't
>> need gshell-embeddable, updated server/pom.xml with the new depends
>> and updated boilerplate with the new gshell-geronimo car depend and
>> it looks promising. I'm still exercising some of the gsh commands,
>> but so far help, geronimo/start-server, deploy/connect and geronimo/
>> stop-server are working....
>>
>> If all looks well after a few more tests, I'll commit the changes
>> into trunk for everyone to review before we spend the time pulling
>> it into 2.1.2.
>>
>>
>> -Donald
>>
>>
>> Jason Dillon wrote:
>>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>>> So including the dependencies you need for gshell in the
>>>> boilerplate's pom would get them into the geronimo repo. As I
>>>> said transitive dependencies don't result in inclusion at the
>>>> moment for rather good reasons. I don't know what the <include>
>>>> tag would do but it's probably worth investigating.
>>> What <include> tag are you talking about?
>>> I guess I'm gonna try to make plugins for the gshell dependencies,
>>> these 3:
>>> gshell-framework - just the core bits required to make gshell work
>>> gshell-geronimo - our additional commands to work with the
>>> server + their deps
>>> gshell-remote - the remote/whisper commands
>>> I must say I'm really quite frustrated at the lack of transitive
>>> dependency support here. As this means that alot of the
>>> dependencyManagement configuration which is already in the GShell
>>> poms need to be duplicated into the Geronimo poms, making version
>>> management even more of a nightmare.
>>> :-(
>>> Well, I started to add these cars to framework/configs, but I must
>>> admit I really am clueless for how this stuff works now.
>>> :-(
>>> --jason
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
I talked with jason a bit on irc and we're doing an experiment with
optionally including transitive dependencies using the car-maven-
plugin. Hopefully this will work and avoid the duplication jason is
leery of. Please don't commit duplication until we find out if this
works or not.
AFAICT this isn't a bug fix but rather new development so I'm unclear
about why you are thinking of including this in 2.1.2?
thanks
david jencks
On May 13, 2008, at 11:32 AM, Donald Woods wrote:
> I started with your new framework/configs/gshell-* code, updated
> gshell-framework to include all the individual depends so we don't
> need gshell-embeddable, updated server/pom.xml with the new depends
> and updated boilerplate with the new gshell-geronimo car depend and
> it looks promising. I'm still exercising some of the gsh commands,
> but so far help, geronimo/start-server, deploy/connect and geronimo/
> stop-server are working....
>
> If all looks well after a few more tests, I'll commit the changes
> into trunk for everyone to review before we spend the time pulling
> it into 2.1.2.
>
>
> -Donald
>
>
> Jason Dillon wrote:
>> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>>> So including the dependencies you need for gshell in the
>>> boilerplate's pom would get them into the geronimo repo. As I
>>> said transitive dependencies don't result in inclusion at the
>>> moment for rather good reasons. I don't know what the <include>
>>> tag would do but it's probably worth investigating.
>> What <include> tag are you talking about?
>> I guess I'm gonna try to make plugins for the gshell dependencies,
>> these 3:
>> gshell-framework - just the core bits required to make gshell work
>> gshell-geronimo - our additional commands to work with the
>> server + their deps
>> gshell-remote - the remote/whisper commands
>> I must say I'm really quite frustrated at the lack of transitive
>> dependency support here. As this means that alot of the
>> dependencyManagement configuration which is already in the GShell
>> poms need to be duplicated into the Geronimo poms, making version
>> management even more of a nightmare.
>> :-(
>> Well, I started to add these cars to framework/configs, but I must
>> admit I really am clueless for how this stuff works now.
>> :-(
>> --jason
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Donald Woods <dw...@apache.org>.
I started with your new framework/configs/gshell-* code, updated
gshell-framework to include all the individual depends so we don't need
gshell-embeddable, updated server/pom.xml with the new depends and
updated boilerplate with the new gshell-geronimo car depend and it looks
promising. I'm still exercising some of the gsh commands, but so far
help, geronimo/start-server, deploy/connect and geronimo/stop-server are
working....
If all looks well after a few more tests, I'll commit the changes into
trunk for everyone to review before we spend the time pulling it into 2.1.2.
-Donald
Jason Dillon wrote:
> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>> So including the dependencies you need for gshell in the boilerplate's
>> pom would get them into the geronimo repo. As I said transitive
>> dependencies don't result in inclusion at the moment for rather good
>> reasons. I don't know what the <include> tag would do but it's
>> probably worth investigating.
>
> What <include> tag are you talking about?
>
> I guess I'm gonna try to make plugins for the gshell dependencies, these 3:
>
> gshell-framework - just the core bits required to make gshell work
> gshell-geronimo - our additional commands to work with the server +
> their deps
> gshell-remote - the remote/whisper commands
>
> I must say I'm really quite frustrated at the lack of transitive
> dependency support here. As this means that alot of the
> dependencyManagement configuration which is already in the GShell poms
> need to be duplicated into the Geronimo poms, making version management
> even more of a nightmare.
>
> :-(
>
> Well, I started to add these cars to framework/configs, but I must admit
> I really am clueless for how this stuff works now.
>
> :-(
>
> --jason
>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 12, 2008, at 11:26 PM, Jason Dillon wrote:
> On May 13, 2008, at 1:14 AM, David Jencks wrote:
>> So including the dependencies you need for gshell in the
>> boilerplate's pom would get them into the geronimo repo. As I said
>> transitive dependencies don't result in inclusion at the moment for
>> rather good reasons. I don't know what the <include> tag would do
>> but it's probably worth investigating.
>
> What <include> tag are you talking about?
As usual I get include and import confused. See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
under import dependencies. I find the docs pretty unclear about
whether actual dependencies (rather than dependency management
sections) get imported into the using pom's dependencies or are
ignored or something else.
I'll see if I can do an experiment to see if/how this works.
It does require maven 2.0.9
thanks
david jencks
>
>
> I guess I'm gonna try to make plugins for the gshell dependencies,
> these 3:
>
> gshell-framework - just the core bits required to make gshell work
> gshell-geronimo - our additional commands to work with the server
> + their deps
> gshell-remote - the remote/whisper commands
>
> I must say I'm really quite frustrated at the lack of transitive
> dependency support here. As this means that alot of the
> dependencyManagement configuration which is already in the GShell
> poms need to be duplicated into the Geronimo poms, making version
> management even more of a nightmare.
>
> :-(
>
> Well, I started to add these cars to framework/configs, but I must
> admit I really am clueless for how this stuff works now.
>
> :-(
>
> --jason
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Jason Dillon <ja...@planet57.com>.
On May 13, 2008, at 1:14 AM, David Jencks wrote:
> So including the dependencies you need for gshell in the
> boilerplate's pom would get them into the geronimo repo. As I said
> transitive dependencies don't result in inclusion at the moment for
> rather good reasons. I don't know what the <include> tag would do
> but it's probably worth investigating.
What <include> tag are you talking about?
I guess I'm gonna try to make plugins for the gshell dependencies,
these 3:
gshell-framework - just the core bits required to make gshell work
gshell-geronimo - our additional commands to work with the server
+ their deps
gshell-remote - the remote/whisper commands
I must say I'm really quite frustrated at the lack of transitive
dependency support here. As this means that alot of the
dependencyManagement configuration which is already in the GShell poms
need to be duplicated into the Geronimo poms, making version
management even more of a nightmare.
:-(
Well, I started to add these cars to framework/configs, but I must
admit I really am clueless for how this stuff works now.
:-(
--jason
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 12, 2008, at 11:03 AM, Jason Dillon wrote:
> Um, the boilerplate does not put anything into the repository/* so
> how do they get in there? Or is that figured out when the
> boilerplate is applied to an assembly or something?
boilerplate is a geronimo plugin, and the car-maven-plugin generates a
geronimo-plugin.xml for it.
Therefore when it is installed into an assembly (usually the first
plugin :-) all the dependencies listed in geronimo-plugin.xml get
installed in the geronimo repo.
So including the dependencies you need for gshell in the boilerplate's
pom would get them into the geronimo repo. As I said transitive
dependencies don't result in inclusion at the moment for rather good
reasons. I don't know what the <include> tag would do but it's
probably worth investigating.
thanks
david jencks
>
>
> --jason
>
>
> On May 13, 2008, at 12:26 AM, David Jencks wrote:
>
>>
>> On May 12, 2008, at 4:20 AM, Jason Dillon wrote:
>>
>>> I'm trying to remove the use of the gshell-embeddable artifact,
>>> which includes some duplicates (like jline, xstream, slf4j,
>>> etc)... but I can't figure out how the new assembly bits are used
>>> to get stuff into the repository/*.
>>>
>>> I can hack something up (with the assembly + antrun plugins) but
>>> I'm wondering if there is a better way. I'd like to not have a
>>> ton of pom config to list all of the gshell required dependencies,
>>> just use mvn's transitive deps to populate the repository/* with
>>> the bits that gshell needs.
>>>
>>> Anyone have any suggestions?
>>
>> Right now our transitive dependencies are sufficiently confused so
>> that the car-maven-plugin ignores them when figuring out the
>> geronimo dependencies for a plugin. So, the boilerplate plugin pom
>> explicitly lists the jars it wants to get into the geronimo repo.
>> I'm afraid including transitive dependencies may not be consistent
>> with our classloader graph approach compared to plexus's one giant
>> classloader approach. I havent' thought about it in detail.
>>
>> Maybe we can use the mvn 2.0.9 include pom element to allow for
>> cribbing depenendencies from one maven project into another?
>>
>> thanks
>> david jencks
>>>
>>>
>>> --jason
>>
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by Jason Dillon <ja...@planet57.com>.
Um, the boilerplate does not put anything into the repository/* so
how do they get in there? Or is that figured out when the boilerplate
is applied to an assembly or something?
--jason
On May 13, 2008, at 12:26 AM, David Jencks wrote:
>
> On May 12, 2008, at 4:20 AM, Jason Dillon wrote:
>
>> I'm trying to remove the use of the gshell-embeddable artifact,
>> which includes some duplicates (like jline, xstream, slf4j, etc)...
>> but I can't figure out how the new assembly bits are used to get
>> stuff into the repository/*.
>>
>> I can hack something up (with the assembly + antrun plugins) but
>> I'm wondering if there is a better way. I'd like to not have a ton
>> of pom config to list all of the gshell required dependencies, just
>> use mvn's transitive deps to populate the repository/* with the
>> bits that gshell needs.
>>
>> Anyone have any suggestions?
>
> Right now our transitive dependencies are sufficiently confused so
> that the car-maven-plugin ignores them when figuring out the
> geronimo dependencies for a plugin. So, the boilerplate plugin pom
> explicitly lists the jars it wants to get into the geronimo repo.
> I'm afraid including transitive dependencies may not be consistent
> with our classloader graph approach compared to plexus's one giant
> classloader approach. I havent' thought about it in detail.
>
> Maybe we can use the mvn 2.0.9 include pom element to allow for
> cribbing depenendencies from one maven project into another?
>
> thanks
> david jencks
>>
>>
>> --jason
>
Re: Need some advice on how to include repository/* bits in the boilerplate
Posted by David Jencks <da...@yahoo.com>.
On May 12, 2008, at 4:20 AM, Jason Dillon wrote:
> I'm trying to remove the use of the gshell-embeddable artifact,
> which includes some duplicates (like jline, xstream, slf4j, etc)...
> but I can't figure out how the new assembly bits are used to get
> stuff into the repository/*.
>
> I can hack something up (with the assembly + antrun plugins) but I'm
> wondering if there is a better way. I'd like to not have a ton of
> pom config to list all of the gshell required dependencies, just use
> mvn's transitive deps to populate the repository/* with the bits
> that gshell needs.
>
> Anyone have any suggestions?
Right now our transitive dependencies are sufficiently confused so
that the car-maven-plugin ignores them when figuring out the geronimo
dependencies for a plugin. So, the boilerplate plugin pom explicitly
lists the jars it wants to get into the geronimo repo. I'm afraid
including transitive dependencies may not be consistent with our
classloader graph approach compared to plexus's one giant classloader
approach. I havent' thought about it in detail.
Maybe we can use the mvn 2.0.9 include pom element to allow for
cribbing depenendencies from one maven project into another?
thanks
david jencks
>
>
> --jason