Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #8629

Re: maven-debian-helper=2.0~exp2 rebuild

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Wed, 2015-12-02 at 09:58 +0100, Emmanuel Bourg wrote:
> > I think this comes back to our conversation about Maven 3 searching
> > for
> > that metadata file unless a version is explicit specified.
> 
> So if I understand well:
> 
> 1. the plugin defines the sequence of goals executed for each phase.
> The
> goals are specified with groupId:artifactId:goal(:version)?

Almost. It's the same format that is used on the command-line, although
I'm not sure if the shorthand works (i.e. dependency:copy):
groupId:artifactId[:version]:goal. See [1] for the defaults.

> 
> 2. if the version of a goal is specified, Maven doesn't check if the
> plugin is installed until the actual execution of the phase.
> 
> 3. if the version of a goal isn't specified, Maven attempts to
> resolve
> the version by reading the metadata file in the local repository.
> This
> happens during the initialization of the plugin, even if the phase
> isn't
> executed. Failing to resolve the version triggers an error.
> 
> Is this correct?

Yup. That's my understanding as well. A more thorough breakdown below:

Maven first builds a model to in order to create an execution plan. At
this point only plugin versions in the pom are resolved (see plugins in
the effective-pom). As it creates this execution plan, plugins from the
lifecycle mapping [1] are injected into the model and versions are
resolved again before finally running the execution plan. Physical
plugin jars appear to be resolved just before executing a goal.

Anytime you see resolve versions above, either (1) there is an explicit
version specified, (2) it is resolved from a parent or the superpom
through plugin/plugin management, or (3) resolved first from maven
-metadata.xml in the local repo (ignoring whether a jar file is present
or not), or through any other online repositories defined (these aren't
applicable since we build in offline mode). If a version cannot be
found, it dies as you have found.

Notice that when resolving versions, you don't need the metadata if you
specify a version explicitly (as the default jar packaging does) and
therefore don't need the plugin in the local repo at all (unless you
actually want to run that plugins goal).

> 
> In this case generating the metadata automatically doesn't help,
> because
> for now it covers only the plugins already installed. We would need
> metadata for plugins not installed to work around this issue.
> 
> 
> > Looking at maven-bundle-plugin:2.4.0, none of the goals specify a
> > version (the default ones defined in maven-core do). Curious that
> > the
> > install plugin is the only one complaining...
> 
> Actually I noticed similar errors with the deploy plugin, I guess it
> came from the bundle plugin as well since it declares:
> 
>   <deploy>
>     org.apache.maven.plugins:maven-deploy-plugin:deploy,
>     org.apache.felix:maven-bundle-plugin:deploy
>   </deploy>
> 
> I added a dependency on maven-deploy-plugin to work around this
> issue.

Yup. The bundle plugin lifecycle mapping overwrites the default one.
Since the clean/site mappings aren't touched, they are inherited from
jar.

> 
> 
> > If we can get away with just installing the plugin rather than
> > generating metadata, so much the better. Just keep this in mind as
> > you
> > may run into it again for another project type.
> 
> At this point I'm wondering if I should move the dependency on the
> install plugin from maven-debian-helper to the bundle plugin. That
> would
> be a more accurate dependency chain, but on the other hand the
> install
> plugin is often used, so having it by default with maven-debian
> -helper
> is maybe a good thing.
> 

I don't know if adding a dependency will actually fix this based on the
resolution logic above. At least, not without metadata. But defining a
dependency on the maven-bundle-plugin makes more sense to me.

Two other options, although not as clean as the metadata approach:

1) Modify maven-core with a custom super pom with defining the install
-plugin version that we use. Unfortunately, this can be overridden...

2) Modify the bundle plugin to explicitly specify a version in the
lifecycle mappings.

Andrew

Back to linux.debian.maint.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

maven-debian-helper=2.0~exp2 rebuild Chris West <solo-debian-java@goeswhere.com> - 2015-11-25 23:20 +0100
  Re: maven-debian-helper=2.0~exp2 rebuild Emmanuel Bourg <ebourg@apache.org> - 2015-11-27 11:00 +0100
    Re: maven-debian-helper=2.0~exp2 rebuild Andrew Schurman <arcticwaters@gmail.com> - 2015-12-02 09:30 +0100
      Re: maven-debian-helper=2.0~exp2 rebuild Emmanuel Bourg <ebourg@apache.org> - 2015-12-02 10:00 +0100
        Re: maven-debian-helper=2.0~exp2 rebuild Andrew Schurman <arcticwaters@gmail.com> - 2015-12-02 23:00 +0100
          Re: maven-debian-helper=2.0~exp2 rebuild Emmanuel Bourg <ebourg@apache.org> - 2015-12-09 09:40 +0100

csiph-web