You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/12/14 19:51:41 UTC
Car plugin is fighting with maven too much
Ever since we got close to having an m2 build we've been having
problems with the car plugin overloading the maven scopes to mean
something in geronimo. This has caused endless problems, the latest
of which is that in order to be able to use the car plugin outside
geronimo, you have to have built geronimo on that machine so all the
geronimo bits you need are sure to be there. In more detail this is
caused by the use of the provided scope to mean "don't stick this
dependency in the environment". So, if you mark a builder car as
provided so it won't get stuck in the environment, maven won't
download all the bits it needs to run.
This is all caused by our attempt to build the environment plan
element from the pom. The main reason I wanted to do that was to be
sure that if you mentioned something in the environment, maven would
make sure it was available. So, maybe it's time to take a more
direct approach:
How about changing the plugin so it doesn't generate the environment
element, but instead verifies that all the environment dependencies
are mentioned in the pom? Among other things this will give easier
control over which versions are included in the environment element.
The other possible solutions to this problem I have thought of are:
-- get maven to have an extensible scope system or allow dependency
annotations like you could do in maven 1. I think there's no chance
of this happening before geronimo 3, but I could be wrong.
-- copy the environment dependencies into the car plugin
configuration. I think this would end up being harder to deal with
than validating the environment against the pom.
-- write a maven project that just has dependencies on all geronimo
artifacts included in any geronimo assembly, so you can build it and
all the bits will be around for the car plugin to use.
Thanks to gnodet for pointing out this problem and discussing
possible solutions.
Any thoughts?
thanks
david jencks
Re: Car plugin is fighting with maven too much
Posted by David Jencks <da...@yahoo.com>.
On Dec 14, 2006, at 2:02 PM, Aaron Mulder wrote:
> I just want to add that for Geronimo plugins, it's not very useful to
> have the car-maven-plugin write the environment into the deployment
> plan. More often that not, you want the source tree to contain a
> fully valid and correct deployment plan, so you can easily redeploy
> the module (e.g. on the command line or hot deploy directory) without
> going through the plugin mechanics. (This is, while you're actively
> developing and testing the new G plugin.) That means that it's not
> acceptable for the source tree to contain a plan with an empty
> environment and rely on the car-maven-plugin to generate an output
> plan with a valid environment. I'd be happy if there was a flag
> saying "don't write environment", and that would eliminate the need
> for a G plugin build to use the "scope=provided" in the plugin build
> POM (currently all the artifacts in the environment are listed with
> scope=provided so the build is aware of them but they are not written
> into the environment).
After spending a long time thinking the "generate the environment"
idea was the best, I now agree with you that it's unsatisfactory. I
wonder if some kind of filtering might still be appropriate and
whether we might want to add something like that to the online/
offline/console deployers.
>
> Anyway, I'm going to restate the problem I think you're describing
> just to make sure we're talking about the same thing. I think the
> main problem with the car-maven-plugin is that is starts a
> mini-Geronimo server to do the deployment.
umm, that's not the problem :-)
> Therefore, it needs all
> the core Geronimo CARs in your local repository so it can use them to
> start the server. Those are the ones that Maven does not download on
> your behalf (therefore the comment that it only works if you've built
> G on that machine before).
> It seems like you ought to be able to list
> the deployers you care about as well as the dependency CARs/JARs, and
> Maven should download those and anything they depend on transitively,
> so it has everything it needs in order to run the server.
exactly. This is currently not working because of the need to use
scope "provided" in order to avoid messing up the generated
environment element.
> Normally
> I'd say the car-maven-plugin should just list all that stuff as
> dependencies, but a single version of the car-maven-plugin can
> potentially work across several Geronimo versions, so I guess all the
> Geronimo CARs need to be resolved dynamically. The main problem is,
> if we're on Geronimo 2.0 and you configure the car-maven-plugin for
> the Geronimo 1.2 GBean deployer, and that depends on
> */j2ee-system/*/car then it's likely to incorrectly resolve that to
> the 2.0 j2ee-system CAR, so we need some way to tell the
> car-maven-plugin to resolve all Geronimo libs to version X (and all
> OpenEJB libs to version Y, and all TranQL libs to version Z, and
> etc.). Is that the same issue you're describing?
That's another issue. I'm not sure how likely it will be that we can
maintain car-maven-plugin compatibility across geronimo releases, but
it would be nice. One thing is we'll have to be careful to leave out
all versions from the default environment attributes in the builders,
and from the dependencies in the varlous builder plugins. In any
case this would be great but is not the current problem.
>
> FWIW, several of the SF plugins have a POM that lists all the stuff
> needed to build a plugin on G 1.1.1, and I'll probably be coming up
> with a 1.2 version in the relatively near future. If you include that
> as a module in your build it will produce an empty JAR, but it will
> cause all the needed JARs and CARs to be downloaded into your local M2
> repo so the car-maven-plugin works as expected.
This sounds similar to my proposal to have a pom with all geronimo
artifacts listed in it.
Anyway I think we're on the same page here.
thanks
david jencks
>
> Thanks,
> Aaron
>
> On 12/14/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> I'm not completely aware of what the car plugin do, but I think
>> this is
>> pretty close to what we have done for servicemix.
>> I think we should be able to get back transitive dependencies on
>> jars,
>> by rebuilding the full dependency graph, and excluding artifacts that
>> are already included by referenced cars. Let me explain:
>>
>> If the following is the dependency graph (we are trying to build
>> carA)
>> - carA
>> - jarB
>> -jarC
>> - jarD
>> - carE
>> - jarC
>> it is possible to load this full graph and prune it to obtain a
>> list of *real*
>> dependencies: jarB, jarD, carE. jarC would be removed, because it
>> already
>> contains jarC. To do this, we rely only on the poms of the
>> dependencies.
>> We have already done that in servicemix maven plugin, so there's
>> no reason
>> it could not be done for Geronimo ;)
>>
>> I'm not sure about the provided scope. Actually, the servicemix
>> plugin handle
>> this scope the same way as the car plugin, but the main difference is
>> that we don't
>> have the need of deployers, so things are easier.
>>
>> On 12/14/06, David Jencks <da...@yahoo.com> wrote:
>> > Ever since we got close to having an m2 build we've been having
>> > problems with the car plugin overloading the maven scopes to mean
>> > something in geronimo. This has caused endless problems, the
>> latest
>> > of which is that in order to be able to use the car plugin outside
>> > geronimo, you have to have built geronimo on that machine so all
>> the
>> > geronimo bits you need are sure to be there. In more detail
>> this is
>> > caused by the use of the provided scope to mean "don't stick this
>> > dependency in the environment". So, if you mark a builder car as
>> > provided so it won't get stuck in the environment, maven won't
>> > download all the bits it needs to run.
>> >
>> > This is all caused by our attempt to build the environment plan
>> > element from the pom. The main reason I wanted to do that was
>> to be
>> > sure that if you mentioned something in the environment, maven
>> would
>> > make sure it was available. So, maybe it's time to take a more
>> > direct approach:
>> >
>> > How about changing the plugin so it doesn't generate the
>> environment
>> > element, but instead verifies that all the environment dependencies
>> > are mentioned in the pom? Among other things this will give easier
>> > control over which versions are included in the environment
>> element.
>> >
>> > The other possible solutions to this problem I have thought of are:
>> >
>> > -- get maven to have an extensible scope system or allow dependency
>> > annotations like you could do in maven 1. I think there's no
>> chance
>> > of this happening before geronimo 3, but I could be wrong.
>> >
>> > -- copy the environment dependencies into the car plugin
>> > configuration. I think this would end up being harder to deal with
>> > than validating the environment against the pom.
>> >
>> > -- write a maven project that just has dependencies on all geronimo
>> > artifacts included in any geronimo assembly, so you can build it
>> and
>> > all the bits will be around for the car plugin to use.
>> >
>> >
>> > Thanks to gnodet for pointing out this problem and discussing
>> > possible solutions.
>> >
>> > Any thoughts?
>> >
>> > thanks
>> > david jencks
>> >
>> >
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>>
>>
Re: Car plugin is fighting with maven too much
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I just want to add that for Geronimo plugins, it's not very useful to
have the car-maven-plugin write the environment into the deployment
plan. More often that not, you want the source tree to contain a
fully valid and correct deployment plan, so you can easily redeploy
the module (e.g. on the command line or hot deploy directory) without
going through the plugin mechanics. (This is, while you're actively
developing and testing the new G plugin.) That means that it's not
acceptable for the source tree to contain a plan with an empty
environment and rely on the car-maven-plugin to generate an output
plan with a valid environment. I'd be happy if there was a flag
saying "don't write environment", and that would eliminate the need
for a G plugin build to use the "scope=provided" in the plugin build
POM (currently all the artifacts in the environment are listed with
scope=provided so the build is aware of them but they are not written
into the environment).
Anyway, I'm going to restate the problem I think you're describing
just to make sure we're talking about the same thing. I think the
main problem with the car-maven-plugin is that is starts a
mini-Geronimo server to do the deployment. Therefore, it needs all
the core Geronimo CARs in your local repository so it can use them to
start the server. Those are the ones that Maven does not download on
your behalf (therefore the comment that it only works if you've built
G on that machine before). It seems like you ought to be able to list
the deployers you care about as well as the dependency CARs/JARs, and
Maven should download those and anything they depend on transitively,
so it has everything it needs in order to run the server. Normally
I'd say the car-maven-plugin should just list all that stuff as
dependencies, but a single version of the car-maven-plugin can
potentially work across several Geronimo versions, so I guess all the
Geronimo CARs need to be resolved dynamically. The main problem is,
if we're on Geronimo 2.0 and you configure the car-maven-plugin for
the Geronimo 1.2 GBean deployer, and that depends on
*/j2ee-system/*/car then it's likely to incorrectly resolve that to
the 2.0 j2ee-system CAR, so we need some way to tell the
car-maven-plugin to resolve all Geronimo libs to version X (and all
OpenEJB libs to version Y, and all TranQL libs to version Z, and
etc.). Is that the same issue you're describing?
FWIW, several of the SF plugins have a POM that lists all the stuff
needed to build a plugin on G 1.1.1, and I'll probably be coming up
with a 1.2 version in the relatively near future. If you include that
as a module in your build it will produce an empty JAR, but it will
cause all the needed JARs and CARs to be downloaded into your local M2
repo so the car-maven-plugin works as expected.
Thanks,
Aaron
On 12/14/06, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm not completely aware of what the car plugin do, but I think this is
> pretty close to what we have done for servicemix.
> I think we should be able to get back transitive dependencies on jars,
> by rebuilding the full dependency graph, and excluding artifacts that
> are already included by referenced cars. Let me explain:
>
> If the following is the dependency graph (we are trying to build carA)
> - carA
> - jarB
> -jarC
> - jarD
> - carE
> - jarC
> it is possible to load this full graph and prune it to obtain a list of *real*
> dependencies: jarB, jarD, carE. jarC would be removed, because it already
> contains jarC. To do this, we rely only on the poms of the dependencies.
> We have already done that in servicemix maven plugin, so there's no reason
> it could not be done for Geronimo ;)
>
> I'm not sure about the provided scope. Actually, the servicemix plugin handle
> this scope the same way as the car plugin, but the main difference is
> that we don't
> have the need of deployers, so things are easier.
>
> On 12/14/06, David Jencks <da...@yahoo.com> wrote:
> > Ever since we got close to having an m2 build we've been having
> > problems with the car plugin overloading the maven scopes to mean
> > something in geronimo. This has caused endless problems, the latest
> > of which is that in order to be able to use the car plugin outside
> > geronimo, you have to have built geronimo on that machine so all the
> > geronimo bits you need are sure to be there. In more detail this is
> > caused by the use of the provided scope to mean "don't stick this
> > dependency in the environment". So, if you mark a builder car as
> > provided so it won't get stuck in the environment, maven won't
> > download all the bits it needs to run.
> >
> > This is all caused by our attempt to build the environment plan
> > element from the pom. The main reason I wanted to do that was to be
> > sure that if you mentioned something in the environment, maven would
> > make sure it was available. So, maybe it's time to take a more
> > direct approach:
> >
> > How about changing the plugin so it doesn't generate the environment
> > element, but instead verifies that all the environment dependencies
> > are mentioned in the pom? Among other things this will give easier
> > control over which versions are included in the environment element.
> >
> > The other possible solutions to this problem I have thought of are:
> >
> > -- get maven to have an extensible scope system or allow dependency
> > annotations like you could do in maven 1. I think there's no chance
> > of this happening before geronimo 3, but I could be wrong.
> >
> > -- copy the environment dependencies into the car plugin
> > configuration. I think this would end up being harder to deal with
> > than validating the environment against the pom.
> >
> > -- write a maven project that just has dependencies on all geronimo
> > artifacts included in any geronimo assembly, so you can build it and
> > all the bits will be around for the car plugin to use.
> >
> >
> > Thanks to gnodet for pointing out this problem and discussing
> > possible solutions.
> >
> > Any thoughts?
> >
> > thanks
> > david jencks
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
Re: Car plugin is fighting with maven too much
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 12/14/06, Guillaume Nodet <gn...@gmail.com> wrote:
> Just a side note. It took me some time to understand that you *have* to
> build Geronimo if you want to build a plugin against a SNAPSHOT version.
> The reason is that the plugin loads cars that depend on snapshot jars (it works
> against the new 1.2beta).
> But if you download snapshots using maven, they end up in the local
> repo with a timestamp, and my guess is that they are not found.
> Unfortunately, the exception thrown just says that the configuration
> could not be loaded, which is not very helpful.
That sounds like a different problem, which is that our "Maven 2
Repository" implementation doesn't actually use the same rules that
Maven 2 does for locating artifacts in the repository (at least, for
SNAPSHOTs). We either need to enhance our code or find a way to just
reuse the Maven code. IIRC Dain said the current implementation was
just supposed to be a placeholder, but no one's gotten around to
replacing it yet. :)
Thanks,
Aaron
> On 12/14/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > I'm not completely aware of what the car plugin do, but I think this is
> > pretty close to what we have done for servicemix.
> > I think we should be able to get back transitive dependencies on jars,
> > by rebuilding the full dependency graph, and excluding artifacts that
> > are already included by referenced cars. Let me explain:
> >
> > If the following is the dependency graph (we are trying to build carA)
> > - carA
> > - jarB
> > -jarC
> > - jarD
> > - carE
> > - jarC
> > it is possible to load this full graph and prune it to obtain a list of *real*
> > dependencies: jarB, jarD, carE. jarC would be removed, because it already
> > contains jarC. To do this, we rely only on the poms of the dependencies.
> > We have already done that in servicemix maven plugin, so there's no reason
> > it could not be done for Geronimo ;)
> >
> > I'm not sure about the provided scope. Actually, the servicemix plugin handle
> > this scope the same way as the car plugin, but the main difference is
> > that we don't
> > have the need of deployers, so things are easier.
> >
> > On 12/14/06, David Jencks <da...@yahoo.com> wrote:
> > > Ever since we got close to having an m2 build we've been having
> > > problems with the car plugin overloading the maven scopes to mean
> > > something in geronimo. This has caused endless problems, the latest
> > > of which is that in order to be able to use the car plugin outside
> > > geronimo, you have to have built geronimo on that machine so all the
> > > geronimo bits you need are sure to be there. In more detail this is
> > > caused by the use of the provided scope to mean "don't stick this
> > > dependency in the environment". So, if you mark a builder car as
> > > provided so it won't get stuck in the environment, maven won't
> > > download all the bits it needs to run.
> > >
> > > This is all caused by our attempt to build the environment plan
> > > element from the pom. The main reason I wanted to do that was to be
> > > sure that if you mentioned something in the environment, maven would
> > > make sure it was available. So, maybe it's time to take a more
> > > direct approach:
> > >
> > > How about changing the plugin so it doesn't generate the environment
> > > element, but instead verifies that all the environment dependencies
> > > are mentioned in the pom? Among other things this will give easier
> > > control over which versions are included in the environment element.
> > >
> > > The other possible solutions to this problem I have thought of are:
> > >
> > > -- get maven to have an extensible scope system or allow dependency
> > > annotations like you could do in maven 1. I think there's no chance
> > > of this happening before geronimo 3, but I could be wrong.
> > >
> > > -- copy the environment dependencies into the car plugin
> > > configuration. I think this would end up being harder to deal with
> > > than validating the environment against the pom.
> > >
> > > -- write a maven project that just has dependencies on all geronimo
> > > artifacts included in any geronimo assembly, so you can build it and
> > > all the bits will be around for the car plugin to use.
> > >
> > >
> > > Thanks to gnodet for pointing out this problem and discussing
> > > possible solutions.
> > >
> > > Any thoughts?
> > >
> > > thanks
> > > david jencks
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
Re: Car plugin is fighting with maven too much
Posted by Guillaume Nodet <gn...@gmail.com>.
Just a side note. It took me some time to understand that you *have* to
build Geronimo if you want to build a plugin against a SNAPSHOT version.
The reason is that the plugin loads cars that depend on snapshot jars (it works
against the new 1.2beta).
But if you download snapshots using maven, they end up in the local
repo with a timestamp, and my guess is that they are not found.
Unfortunately, the exception thrown just says that the configuration
could not be loaded, which is not very helpful.
On 12/14/06, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm not completely aware of what the car plugin do, but I think this is
> pretty close to what we have done for servicemix.
> I think we should be able to get back transitive dependencies on jars,
> by rebuilding the full dependency graph, and excluding artifacts that
> are already included by referenced cars. Let me explain:
>
> If the following is the dependency graph (we are trying to build carA)
> - carA
> - jarB
> -jarC
> - jarD
> - carE
> - jarC
> it is possible to load this full graph and prune it to obtain a list of *real*
> dependencies: jarB, jarD, carE. jarC would be removed, because it already
> contains jarC. To do this, we rely only on the poms of the dependencies.
> We have already done that in servicemix maven plugin, so there's no reason
> it could not be done for Geronimo ;)
>
> I'm not sure about the provided scope. Actually, the servicemix plugin handle
> this scope the same way as the car plugin, but the main difference is
> that we don't
> have the need of deployers, so things are easier.
>
> On 12/14/06, David Jencks <da...@yahoo.com> wrote:
> > Ever since we got close to having an m2 build we've been having
> > problems with the car plugin overloading the maven scopes to mean
> > something in geronimo. This has caused endless problems, the latest
> > of which is that in order to be able to use the car plugin outside
> > geronimo, you have to have built geronimo on that machine so all the
> > geronimo bits you need are sure to be there. In more detail this is
> > caused by the use of the provided scope to mean "don't stick this
> > dependency in the environment". So, if you mark a builder car as
> > provided so it won't get stuck in the environment, maven won't
> > download all the bits it needs to run.
> >
> > This is all caused by our attempt to build the environment plan
> > element from the pom. The main reason I wanted to do that was to be
> > sure that if you mentioned something in the environment, maven would
> > make sure it was available. So, maybe it's time to take a more
> > direct approach:
> >
> > How about changing the plugin so it doesn't generate the environment
> > element, but instead verifies that all the environment dependencies
> > are mentioned in the pom? Among other things this will give easier
> > control over which versions are included in the environment element.
> >
> > The other possible solutions to this problem I have thought of are:
> >
> > -- get maven to have an extensible scope system or allow dependency
> > annotations like you could do in maven 1. I think there's no chance
> > of this happening before geronimo 3, but I could be wrong.
> >
> > -- copy the environment dependencies into the car plugin
> > configuration. I think this would end up being harder to deal with
> > than validating the environment against the pom.
> >
> > -- write a maven project that just has dependencies on all geronimo
> > artifacts included in any geronimo assembly, so you can build it and
> > all the bits will be around for the car plugin to use.
> >
> >
> > Thanks to gnodet for pointing out this problem and discussing
> > possible solutions.
> >
> > Any thoughts?
> >
> > thanks
> > david jencks
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: Car plugin is fighting with maven too much
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm not completely aware of what the car plugin do, but I think this is
pretty close to what we have done for servicemix.
I think we should be able to get back transitive dependencies on jars,
by rebuilding the full dependency graph, and excluding artifacts that
are already included by referenced cars. Let me explain:
If the following is the dependency graph (we are trying to build carA)
- carA
- jarB
-jarC
- jarD
- carE
- jarC
it is possible to load this full graph and prune it to obtain a list of *real*
dependencies: jarB, jarD, carE. jarC would be removed, because it already
contains jarC. To do this, we rely only on the poms of the dependencies.
We have already done that in servicemix maven plugin, so there's no reason
it could not be done for Geronimo ;)
I'm not sure about the provided scope. Actually, the servicemix plugin handle
this scope the same way as the car plugin, but the main difference is
that we don't
have the need of deployers, so things are easier.
On 12/14/06, David Jencks <da...@yahoo.com> wrote:
> Ever since we got close to having an m2 build we've been having
> problems with the car plugin overloading the maven scopes to mean
> something in geronimo. This has caused endless problems, the latest
> of which is that in order to be able to use the car plugin outside
> geronimo, you have to have built geronimo on that machine so all the
> geronimo bits you need are sure to be there. In more detail this is
> caused by the use of the provided scope to mean "don't stick this
> dependency in the environment". So, if you mark a builder car as
> provided so it won't get stuck in the environment, maven won't
> download all the bits it needs to run.
>
> This is all caused by our attempt to build the environment plan
> element from the pom. The main reason I wanted to do that was to be
> sure that if you mentioned something in the environment, maven would
> make sure it was available. So, maybe it's time to take a more
> direct approach:
>
> How about changing the plugin so it doesn't generate the environment
> element, but instead verifies that all the environment dependencies
> are mentioned in the pom? Among other things this will give easier
> control over which versions are included in the environment element.
>
> The other possible solutions to this problem I have thought of are:
>
> -- get maven to have an extensible scope system or allow dependency
> annotations like you could do in maven 1. I think there's no chance
> of this happening before geronimo 3, but I could be wrong.
>
> -- copy the environment dependencies into the car plugin
> configuration. I think this would end up being harder to deal with
> than validating the environment against the pom.
>
> -- write a maven project that just has dependencies on all geronimo
> artifacts included in any geronimo assembly, so you can build it and
> all the bits will be around for the car plugin to use.
>
>
> Thanks to gnodet for pointing out this problem and discussing
> possible solutions.
>
> Any thoughts?
>
> thanks
> david jencks
>
>
--
Cheers,
Guillaume Nodet
Re: Car plugin is fighting with maven too much
Posted by Donald Woods <dr...@yahoo.com>.
Now that sounds promising.... using the existing geronimo-plugin.xml and
deployer to install new apps without having to build a car wrapper for
them. That would make it tons easier to create "remote install
descriptors" for apps like Liferay, Roller, ....
Would we just extend the application deployment plans to allow for a new
moduleType=plugin?
-Donald
jason.dillon@gmail.com wrote:
> Or how about getting rid of car files, use a simple xml file and handle all of this muck in the server at runtime.... Optionally running a validate on the xml durring the build.
>
> --jason
>
>
> -----Original Message-----
> From: David Jencks <da...@yahoo.com>
> Date: Thu, 14 Dec 2006 10:51:41
> To:"Geronimo Dev List (JIRA)" <de...@geronimo.apache.org>
> Subject: Car plugin is fighting with maven too much
>
> Ever since we got close to having an m2 build we've been having
> problems with the car plugin overloading the maven scopes to mean
> something in geronimo. This has caused endless problems, the latest
> of which is that in order to be able to use the car plugin outside
> geronimo, you have to have built geronimo on that machine so all the
> geronimo bits you need are sure to be there. In more detail this is
> caused by the use of the provided scope to mean "don't stick this
> dependency in the environment". So, if you mark a builder car as
> provided so it won't get stuck in the environment, maven won't
> download all the bits it needs to run.
>
> This is all caused by our attempt to build the environment plan
> element from the pom. The main reason I wanted to do that was to be
> sure that if you mentioned something in the environment, maven would
> make sure it was available. So, maybe it's time to take a more
> direct approach:
>
> How about changing the plugin so it doesn't generate the environment
> element, but instead verifies that all the environment dependencies
> are mentioned in the pom? Among other things this will give easier
> control over which versions are included in the environment element.
>
> The other possible solutions to this problem I have thought of are:
>
> -- get maven to have an extensible scope system or allow dependency
> annotations like you could do in maven 1. I think there's no chance
> of this happening before geronimo 3, but I could be wrong.
>
> -- copy the environment dependencies into the car plugin
> configuration. I think this would end up being harder to deal with
> than validating the environment against the pom.
>
> -- write a maven project that just has dependencies on all geronimo
> artifacts included in any geronimo assembly, so you can build it and
> all the bits will be around for the car plugin to use.
>
>
> Thanks to gnodet for pointing out this problem and discussing
> possible solutions.
>
> Any thoughts?
>
> thanks
> david jencks
>
Re: Car plugin is fighting with maven too much
Posted by ja...@gmail.com.
Or how about getting rid of car files, use a simple xml file and handle all of this muck in the server at runtime.... Optionally running a validate on the xml durring the build.
--jason
-----Original Message-----
From: David Jencks <da...@yahoo.com>
Date: Thu, 14 Dec 2006 10:51:41
To:"Geronimo Dev List (JIRA)" <de...@geronimo.apache.org>
Subject: Car plugin is fighting with maven too much
Ever since we got close to having an m2 build we've been having
problems with the car plugin overloading the maven scopes to mean
something in geronimo. This has caused endless problems, the latest
of which is that in order to be able to use the car plugin outside
geronimo, you have to have built geronimo on that machine so all the
geronimo bits you need are sure to be there. In more detail this is
caused by the use of the provided scope to mean "don't stick this
dependency in the environment". So, if you mark a builder car as
provided so it won't get stuck in the environment, maven won't
download all the bits it needs to run.
This is all caused by our attempt to build the environment plan
element from the pom. The main reason I wanted to do that was to be
sure that if you mentioned something in the environment, maven would
make sure it was available. So, maybe it's time to take a more
direct approach:
How about changing the plugin so it doesn't generate the environment
element, but instead verifies that all the environment dependencies
are mentioned in the pom? Among other things this will give easier
control over which versions are included in the environment element.
The other possible solutions to this problem I have thought of are:
-- get maven to have an extensible scope system or allow dependency
annotations like you could do in maven 1. I think there's no chance
of this happening before geronimo 3, but I could be wrong.
-- copy the environment dependencies into the car plugin
configuration. I think this would end up being harder to deal with
than validating the environment against the pom.
-- write a maven project that just has dependencies on all geronimo
artifacts included in any geronimo assembly, so you can build it and
all the bits will be around for the car plugin to use.
Thanks to gnodet for pointing out this problem and discussing
possible solutions.
Any thoughts?
thanks
david jencks