On 12/14/06, Guillaume Nodet <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
