geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Car plugin is fighting with maven too much
Date Thu, 14 Dec 2006 22:16:14 GMT
On 12/14/06, Guillaume Nodet <gnodet@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 <gnodet@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 <david_jencks@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
>
>

Mime
View raw message