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
Attachment:
signature.asc
Description: This is a digitally signed message part