[jira] [Created] (MDEPLOY-287) if no pom specified for deploy-file and file contains a pom, use it
mike duigou created MDEPLOY-287: --- Summary: if no pom specified for deploy-file and file contains a pom, use it Key: MDEPLOY-287 URL: https://issues.apache.org/jira/browse/MDEPLOY-287 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy-file Affects Versions: 3.0.0-M1 Reporter: mike duigou Deploying a file containing a pom requires you either extract the pom to use the -DpomFile option or repeat the artifact coordinates. Why not use the embedded pom file if the artifact has one? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-442) Add "showLint" option
[
https://issues.apache.org/jira/browse/MCOMPILER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike duigou updated MCOMPILER-442:
--
Description:
Add a showLint configuration option to eliminate the need to use
{code:java}
true
-Xlint:all
...
{code}
to configure the display of compiler lint messages. The advantage to a showLint
configuration would be that it is more ammenable to inclusion in a parent or
reactor project for inheritance in to sub-modules.
The element, if present would add the "-Xlint" option to the
compiler command line and the contents of the element as the parameter. ie.
{code:java}
all,-options,-path
{code}
would add:
{code:java}
-Xlint:all,-options,-path
{code}
to the compiler command line.
was:
Add a showLint configuration option to eliminate the need to use
{code:java}
true
-Xlint:all
...
{code}
to configure the display of compiler lint messages. The advantage to a showLint
configuration would be that it is more ammenable to inclusion in a parent or
reactor project for inheritance in to sub-modules.
The element, if present would add the "-Xlint" option to the
compiler command line and the contents of the element as the parameter. ie.
{code:java}
all,-options,-path
{code}
would add:
{code:java}
-Xlint:all,-options,-path
{code}
to the compiler command line.
> Add "showLint" option
> -
>
> Key: MCOMPILER-442
> URL: https://issues.apache.org/jira/browse/MCOMPILER-442
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: mike duigou
>Priority: Minor
>
> Add a showLint configuration option to eliminate the need to use
>
> {code:java}
>
> true
>
> -Xlint:all
>
> ...
> {code}
> to configure the display of compiler lint messages. The advantage to a
> showLint configuration would be that it is more ammenable to inclusion in a
> parent or reactor project for inheritance in to sub-modules.
> The element, if present would add the "-Xlint" option to the
> compiler command line and the contents of the element as the parameter. ie.
> {code:java}
> all,-options,-path
> {code}
> would add:
> {code:java}
> -Xlint:all,-options,-path
> {code}
> to the compiler command line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCOMPILER-442) Add "showLint" option
mike duigou created MCOMPILER-442:
-
Summary: Add "showLint" option
Key: MCOMPILER-442
URL: https://issues.apache.org/jira/browse/MCOMPILER-442
Project: Maven Compiler Plugin
Issue Type: New Feature
Affects Versions: 3.8.1
Reporter: mike duigou
Add a showLint configuration option to eliminate the need to use
{code:java}
true
-Xlint:all
...
{code}
to configure the display of compiler lint messages. The advantage to a showLint
configuration would be that it is more ammenable to inclusion in a parent or
reactor project for inheritance in to sub-modules.
The element, if present would add the "-Xlint" option to the
compiler command line and the contents of the element as the parameter. ie.
{code:java}
all,-options,-path
{code}
would add:
{code:java}
-Xlint:all,-options,-path
{code}
to the compiler command line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212742#comment-17212742
]
mike duigou commented on MNG-6135:
--
Why was this never cherry picked back in to maven master from the abandoned
3.4.0 branch?
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.7.x-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212700#comment-17212700 ] mike duigou commented on MNG-6995: -- Perhaps [~ifedorenko] can provide some context or history as to why core extensions were supported by only top-level projects in MNG-5771 and some guidance for providing the same capability for modules. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5897) Make extensions configurable in a more convenient way.
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212698#comment-17212698
]
mike duigou commented on MNG-5897:
--
This would be a useful enhancement!
Be aware that more generality of the core extensions mechanism is also needed
to support multi-module and aggregator projects. (See MNG-6995)
> Make extensions configurable in a more convenient way.
> --
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17211220#comment-17211220 ] mike duigou commented on MNG-6995: -- I've updated the type, title and description per your request. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mike duigou updated MNG-6995: - Description: If you have defined core extensions using the MNG-5771 .mvn/extensions.xml mechanism and then include the module in an aggregator pom the extensions will currently be ignored. Only extensions defined in same directory as the aggregator pom will be used and those extensions will not be invoked for the modules, only for the aggregator itself. Ideally modules should build with whatever core extensions they have defined. Building a module as part of an aggregator should behave not differently than building the module standalone. was: If you have defined core extensions using the MNG-5771 .mvn/extensions.xml mechanism and then include the module in an aggregator pom the extensions will be ignored. Only extensions defined in same directory as the aggregator pom will be used and those extensions will not be invoked for the modules, only for the aggregator itself. Ideally modules would have whatever extensions they defined. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: Wish > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > Fix For: wontfix-candidate > > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mike duigou updated MNG-6995: - Summary: Support core extensions in modules of aggregator projects (was: Core extensions ignored in modules of aggregator) > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: Wish > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > Fix For: wontfix-candidate > > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will be ignored. Only extensions defined in same directory as the aggregator > pom will be used and those extensions will not be invoked for the modules, > only for the aggregator itself. > Ideally modules would have whatever extensions they defined. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6995) Core extensions ignored in modules of aggregator
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mike duigou updated MNG-6995: - Issue Type: Wish (was: Bug) > Core extensions ignored in modules of aggregator > > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: Wish > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > Fix For: wontfix-candidate > > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will be ignored. Only extensions defined in same directory as the aggregator > pom will be used and those extensions will not be invoked for the modules, > only for the aggregator itself. > Ideally modules would have whatever extensions they defined. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6995) Core extensions ignored in modules of aggregator
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209730#comment-17209730 ] mike duigou commented on MNG-6995: -- There doesn't seem to be any justification or documentation of the current behaviour. That the core extension mechanism didn't work for aggregator modules was surprising and greatly reduces the value of the core extension mechanism. If I build a module independently I get extensions; if I build the same module as part of an aggregator then I don't. So instead of being able to use an aggregator I end up with a bash script to build each of the modules independently and have to manually manage dependencies (yuck!). > Core extensions ignored in modules of aggregator > > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > Fix For: wontfix-candidate > > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will be ignored. Only extensions defined in same directory as the aggregator > pom will be used and those extensions will not be invoked for the modules, > only for the aggregator itself. > Ideally modules would have whatever extensions they defined. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6995) Core extensions ignored in modules of aggregator
mike duigou created MNG-6995: Summary: Core extensions ignored in modules of aggregator Key: MNG-6995 URL: https://issues.apache.org/jira/browse/MNG-6995 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.6.3 Reporter: mike duigou If you have defined core extensions using the MNG-5771 .mvn/extensions.xml mechanism and then include the module in an aggregator pom the extensions will be ignored. Only extensions defined in same directory as the aggregator pom will be used and those extensions will not be invoked for the modules, only for the aggregator itself. Ideally modules would have whatever extensions they defined. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MWAR-422) specification of a classifier conflicts with primaryArtifact config
[ https://issues.apache.org/jira/browse/MWAR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835990#comment-16835990 ] mike duigou commented on MWAR-422: -- Only war files (and source, javadoc) are being produced. The problem is that if you specify a classifier then there is no main artifact produced by the war plugin. An artifact with the specified classifier is created but it is treated as an attachment rather than as the main artifact. Since this artifact is not the main artifact it cannot be deployed as recent versions of the deploy plugin will deploy only the main artifact. > specification of a classifier conflicts with primaryArtifact config > --- > > Key: MWAR-422 > URL: https://issues.apache.org/jira/browse/MWAR-422 > Project: Maven WAR Plugin > Issue Type: Bug >Reporter: mike duigou >Priority: Major > Labels: has-patch > Time Spent: 10m > Remaining Estimate: 0h > > The documentation for the classifier configuration states "If given, the > artifact will be an attachment instead." which ignores the configuration > specified by the primaryArtifact config. > IMO, specification of a classifier should no cause a change in behaviour from > attaching main artifact vs attaching supplemental artifact. This behaviour > makes it impossible to use the deploy goal with a classifier specified > because there is no main artifact. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MWAR-422) specification of a classifier conflicts with primaryArtifact config
[ https://issues.apache.org/jira/browse/MWAR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mike duigou updated MWAR-422: - Labels: has-patch (was: ) > specification of a classifier conflicts with primaryArtifact config > --- > > Key: MWAR-422 > URL: https://issues.apache.org/jira/browse/MWAR-422 > Project: Maven WAR Plugin > Issue Type: Bug >Reporter: mike duigou >Priority: Major > Labels: has-patch > Time Spent: 10m > Remaining Estimate: 0h > > The documentation for the classifier configuration states "If given, the > artifact will be an attachment instead." which ignores the configuration > specified by the primaryArtifact config. > IMO, specification of a classifier should no cause a change in behaviour from > attaching main artifact vs attaching supplemental artifact. This behaviour > makes it impossible to use the deploy goal with a classifier specified > because there is no main artifact. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MWAR-422) specification of a classifier conflicts with primaryArtifact config
mike duigou created MWAR-422: Summary: specification of a classifier conflicts with primaryArtifact config Key: MWAR-422 URL: https://issues.apache.org/jira/browse/MWAR-422 Project: Maven WAR Plugin Issue Type: Bug Reporter: mike duigou The documentation for the classifier configuration states "If given, the artifact will be an attachment instead." which ignores the configuration specified by the primaryArtifact config. IMO, specification of a classifier should no cause a change in behaviour from attaching main artifact vs attaching supplemental artifact. This behaviour makes it impossible to use the deploy goal with a classifier specified because there is no main artifact. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEP-638) unpack-dependencies excludeGroupIds still includes transitive dependencies of excluded
mike duigou created MDEP-638: Summary: unpack-dependencies excludeGroupIds still includes transitive dependencies of excluded Key: MDEP-638 URL: https://issues.apache.org/jira/browse/MDEP-638 Project: Maven Dependency Plugin Issue Type: Bug Components: unpack-dependencies Reporter: mike duigou If I exclude group IDs with excludeGroupIds I would expect that the transitive dependencies only reachable through the excluded dependencies would not be included -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike duigou updated MNG-6507:
-
Description:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ App Reactor}}
{{ App Reactor Project}}
{{ ${revision}${changelist}}}
{{ pom }}
{{ 3.2.0}}
{{ -SNAPSHOT}}
{{ ${revision}${changelist}}}
{{ }}
{{ }}
{{ core}}
{{ configuration}}
{{ }}{{ }}
{{ }}{{ }}
\{{ }}
The configuration project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ App Configuration}}
{{ jar}}
{{ .}}{{ }}
{{ }}
The core project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Core}}
{{ App Core}}
{{ jar}}
{{ }}
{{ }}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ ${revision}${changelist}}}
{{ test}}
{{ }}
{{ .}}
{{ }}
{{ .}}
{{ }}
When building the reactor everything works as expected but building the core
project independently results in maven attempting to resolve a version
${revision}${changelist} from the repos:
{{[ERROR] Failed to execute goal on project Core: Could not resolve
dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect
dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failed to
read artifact descriptor for com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced -> [Help 1]}}
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project Core: Could not resolve dependencies for project
com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed
to read artifact descriptor for
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to
find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
It appears there are some places that should be doing the property substitution
that are not, specifically in this case when including a pom as a dependency.
was:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike duigou updated MNG-6507:
-
Description:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ App Reactor}}
{{ App Reactor Project}}
{{ ${revision}${changelist}}}
{{ pom }}
{{ 3.2.0}}
{{ -SNAPSHOT}}
{{ ${revision}${changelist}}}
{{ }}
{{ }}
{{ core}}
{{ configuration}}
{{ }}{{ }}
{{ }}{{ }}
\{{ }}
The configuration project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ App Configuration}}
{{ jar}}
{{ .}}{{ }}
{{ }}
The core project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Core}}
{{ App Core}}
{{ jar}}
{{ }}
{{ }}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ ${revision}${changelist}}}
{{ test}}
{{ }}
{{ .}}
{{ }}
{{ .}}
{{ }}
When building the reactor everything works as expected but building the core
project independently results in maven attempting to resolve a version
${revision}${changelist} from the repos:
{{[ERROR] Failed to execute goal on project Core: Could not resolve
dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect
dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failed to
read artifact descriptor for com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced -> [Help 1]}}
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project Core: Could not resolve dependencies for project
com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed
to read artifact descriptor for
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to
find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
It appears there are some places that should be doing the property substitution
that are not.
was:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
[jira] [Updated] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
[
https://issues.apache.org/jira/browse/MNG-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mike duigou updated MNG-6507:
-
Description:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ App Reactor}}
{{ App Reactor Project}}
{{ ${revision}${changelist}}}
{{ pom }}
{{ 3.2.0}}
{{ -SNAPSHOT}}
{{ ${revision}${changelist}}}
{{ }}
{{ }}
{{ core}}
{{ configuration}}
{{ }}{{ }}
{{ }}{{ }}
{{ }}
The configuration project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ App Configuration}}
{{ jar}}
{{ .}}{{ }}
{{ }}
The core project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Core}}
{{ App Core}}
{{ jar}}
{{ }}
{{ }}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ ${revision}${changelist}}}
{{ test}}
{{ }}
{{ .}}
{{ }}
{{ .}}
{{ }}
When building the reactor everything works as expected but building the core
project independently results in maven attempting to resolve a version
${revision}${changelist} from the repos:
{{[ERROR] Failed to execute goal on project Regulus: Could not resolve
dependencies for project com.example:Regulus:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
Failed to read artifact descriptor for
com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced -> [Help 1]}}
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project Regulus: Could not resolve dependencies for project
com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.collection.DependencyCollectionException:
Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed
to read artifact descriptor for
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.apache.maven.model.resolution.UnresolvableModelException:
Failure to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}{{ }}
{{Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Failure
to find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
{{Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to
find com.example.app:Reactor:pom:${revision}${changelist} in
[http://artifactory.example.com:8081/artifactory/libs-release] was cached in
the local repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced}}
{{... stack omitted ...}}
It appears there are some places that should be doing the property substitution
that are not.
was:
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ App
[jira] [Created] (MNG-6507) CI-friendly versioning doesn't work when included as dependency
mike duigou created MNG-6507:
Summary: CI-friendly versioning doesn't work when included as
dependency
Key: MNG-6507
URL: https://issues.apache.org/jira/browse/MNG-6507
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.6.0
Reporter: mike duigou
I saw in the 3.6.0 release notes that several issues for CI friendly versions
had been fixed so decided to try the feature.
One of our reactor projects is (simplified):
Reactor pom.xml:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Infrastructure}}
{{ 7}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ App Reactor}}
{{ App Reactor Project}}
{{ ${revision}${changelist}}}
{{ pom }}
{{ 3.2.0}}
{{ -SNAPSHOT}}
{{ ${revision}${changelist}}}
{{ }}
{{ }}
{{ core}}
{{ configuration}}
{{ }}{{ }}{{ }}
The configuration project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ App Configuration}}
{{ jar}}
{{ .}}{{ }}
The core project pom.xml uses CI-friendly versioning:
{{}}
{{ 4.0.0}}
{{ }}
{{ com.example.app}}
{{ Reactor}}
{{ ${revision}${changelist}}}
{{ }}
{{ com.example.app}}
{{ Core}}
{{ App Core}}
{{ jar}}
{{ }}
{{ }}
{{ }}
{{ com.example.app}}
{{ Configuration}}
{{ ${revision}${changelist}}}
{{ test}}
{{ }}
{{ .}}
{{ }}
{{ .}}
{{ }}
When building the reactor everything works as expected but building the core
project independently results in maven attempting to resolve a version
${revision}${changelist} from the repos:
{{[ERROR] Failed to execute goal on project Regulus: Could not resolve
dependencies for project com.example:Regulus:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT:
Failed to read artifact descriptor for
com.example.app:Configuration:jar:3.6.0-SNAPSHOT: Failure to find
com.example.app:Reactor:pom:${revision}${changelist} in
http://artifactory.example.com:8081/artifactory/libs-release was cached in the
local repository, resolution will not be reattempted until the update interval
of central has elapsed or updates are forced -> [Help 1]}}
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project Regulus: Could not resolve dependencies for project
com.example:Core:jar:3.6.0-SNAPSHOT: Failed to collect dependencies at
com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}
{{Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.example:Core:jar:3.6.0-SNAPSHOT: Failed to
collect dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}{{...
stack omitted ...}}{{Caused by:
org.eclipse.aether.collection.DependencyCollectionException: Failed to collect
dependencies at com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ Caused by:
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read
artifact descriptor for com.example.app:Configuration:jar:3.6.0-SNAPSHOT}}
{{... stack omitted ...}}{{ Caused by:
org.apache.maven.model.resolution.UnresolvableModelException: Failure to find
com.example.app:Reactor:pom:${revision}${changelist} in
http://artifactory.example.com:8081/artifactory/libs-release was cached in the
local repository, resolution will not be reattempted until the update interval
of central has elapsed or updates are forced}}{{... stack omitted ...}}{{
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Failure
to find com.example.app:Reactor:pom:${revision}${changelist} in
http://artifactory.example.com:8081/artifactory/libs-release was cached in the
local repository, resolution will not be reattempted until the update interval
of central has elapsed or updates are forced}}{{... stack omitted ...}}{{
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to
find com.example.app:Reactor:pom:${revision}${changelist} in
http://artifactory.example.com:8081/artifactory/libs-release was cached in the
local repository, resolution will not be reattempted until the update interval
of central has elapsed or updates are forced}}{{... stack omitted ...}}
It appears there are some places that should be doing the property substitution
that are not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCOMPILER-331) Defining maven.compiler.release prevents compilation with Java 8
mike duigou created MCOMPILER-331:
-
Summary: Defining maven.compiler.release prevents compilation with
Java 8
Key: MCOMPILER-331
URL: https://issues.apache.org/jira/browse/MCOMPILER-331
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.7.0
Reporter: mike duigou
I am in the process of transitioning projects to be compatible with building on
Java 9 and later. One of the steps is to supplement and eventually replace the
properties we are using for source and target:
{{8}}
{{8}}
with:
{{8}}
However, adding the additional property prevents compilation on Java 8 as it
does not accept the --release option
If the javac being used is Java 8 or older then the maven.compiler.release
property should be ignored or translated in to -source 8 -target 8. This will
make the transition from source/target to release easier.--
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEP-588) Allow exclusion of optional dependencies
mike duigou created MDEP-588: Summary: Allow exclusion of optional dependencies Key: MDEP-588 URL: https://issues.apache.org/jira/browse/MDEP-588 Project: Maven Dependency Plugin Issue Type: Improvement Components: copy-dependencies, unpack-dependencies Affects Versions: 3.0.2 Reporter: mike duigou Priority: Minor Optional dependencies can be manually excluded but it would be useful to be able to omit them without having to specifically reference the artifacts by name. An "omitOptional" defaulting to "false" would suffice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1210) Load test-classes and test dependencies into isolated loader
mike duigou created SUREFIRE-1210: - Summary: Load test-classes and test dependencies into isolated loader Key: SUREFIRE-1210 URL: https://issues.apache.org/jira/browse/SUREFIRE-1210 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.18.1 Reporter: mike duigou Currently both the artifact and it's tests are loaded in to the same classloader. The test-classes and test dependencies are also placed ahead of the artifact classes in the search path. This can cause problems if the test classes contains mocks classes with the same name as artifact classes that aren't intended for use by all tests. The test classes and test dependencies should be placed in their own classloader, a child of whichever classloader is being used for the artifact and run dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-759) tar outputs missing entries for target directory.
[
https://issues.apache.org/jira/browse/MASSEMBLY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596647#comment-14596647
]
mike duigou commented on MASSEMBLY-759:
---
I'm all for encouraging patches from outside contributors but since, as you
suggest, it's not a simple bug and involves layers of maven abstraction it
might not be the best choice for a newbie contributor.
tar outputs missing entries for target directory.
-
Key: MASSEMBLY-759
URL: https://issues.apache.org/jira/browse/MASSEMBLY-759
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.3
Reporter: mike duigou
{quote}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idtarball/id
formats
formattar/format
formattbz2/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory./lib/outputDirectory
directoryMode0755/directoryMode
useProjectArtifacttrue/useProjectArtifact
unpackfalse/unpack
scoperuntime/scope
excludes
exclude*:javaee-web-api/exclude
/excludes
/dependencySet
/dependencySets
/assembly
{quote}
Does not output a tar record for the created libdirectory, just for the
entries under it:
{quote}
-rw-r--r-- 0 mike staff 60686 29 Dec 13:19 lib/commons-logging-1.1.1.jar
{quote}
The only alternative seems to be to create a lib directory somewhere and use
a fileset to copy it over before the dependencySet
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-759) tar outputs missing entries for target directory.
[
https://issues.apache.org/jira/browse/MASSEMBLY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14590679#comment-14590679
]
mike duigou commented on MASSEMBLY-759:
---
Any chance this will get attention?
tar outputs missing entries for target directory.
-
Key: MASSEMBLY-759
URL: https://issues.apache.org/jira/browse/MASSEMBLY-759
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.3
Reporter: mike duigou
{quote}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idtarball/id
formats
formattar/format
formattbz2/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory./lib/outputDirectory
directoryMode0755/directoryMode
useProjectArtifacttrue/useProjectArtifact
unpackfalse/unpack
scoperuntime/scope
excludes
exclude*:javaee-web-api/exclude
/excludes
/dependencySet
/dependencySets
/assembly
{quote}
Does not output a tar record for the created libdirectory, just for the
entries under it:
{quote}
-rw-r--r-- 0 mike staff 60686 29 Dec 13:19 lib/commons-logging-1.1.1.jar
{quote}
The only alternative seems to be to create a lib directory somewhere and use
a fileset to copy it over before the dependencySet
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MASSEMBLY-758) Allow omission of classifier in archive file name
Mike Duigou created MASSEMBLY-758: - Summary: Allow omission of classifier in archive file name Key: MASSEMBLY-758 URL: https://jira.codehaus.org/browse/MASSEMBLY-758 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.5.3 Reporter: Mike Duigou I don't need my tarballs to end in -1.0-SNAPSHOT-tarball.tgz simply because my assembly descriptor id is tarball. For a feature that oriented towards exporting src/bin/doc archives the mandatory inclusion of the classifier is a severe annoyance. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-759) tar outputs missing entries for target directory.
Mike Duigou created MASSEMBLY-759:
-
Summary: tar outputs missing entries for target directory.
Key: MASSEMBLY-759
URL: https://jira.codehaus.org/browse/MASSEMBLY-759
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.3
Reporter: Mike Duigou
{quote}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idtarball/id
formats
formattar/format
formattbz2/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory./lib/outputDirectory
directoryMode0755/directoryMode
useProjectArtifacttrue/useProjectArtifact
unpackfalse/unpack
scoperuntime/scope
excludes
exclude*:javaee-web-api/exclude
/excludes
/dependencySet
/dependencySets
/assembly
{quote}
Does not output a tar record for the created libdirectory, just for the
entries under it:
{quote}
-rw-r--r-- 0 mike staff 60686 29 Dec 13:19 lib/commons-logging-1.1.1.jar
{quote}
The only alternative seems to be to create a lib directory somewhere and use a
fileset to copy it over before the dependencySet
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-347) javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and there is an error
[
https://jira.codehaus.org/browse/MJAVADOC-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365440#comment-365440
]
Mike Duigou commented on MJAVADOC-347:
--
Yes, please create the jar anyway if failOnError=false.
javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and
there is an error
---
Key: MJAVADOC-347
URL: https://jira.codehaus.org/browse/MJAVADOC-347
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Luis Miranda
Fix For: 2.10.3
Attachments:
0001-MJAVADOC-347-added-JavadocJarTest.testContinueIfFail.patch,
0002-MJAVADOC-347-continue-with-archive-creation-if-failO.patch
We are generating Javadocs for a large multi-module build, so there are bound
to be some errors (for example, in 3rd party dependencies).
Currently we set failOnError=false, but we found that the {{aggregate-jar}}
MOJO does not produce a JAR if there are errors. The problem comes down to
this code in JavadocJar:
{code}
try
{
executeReport( Locale.getDefault() );
if ( innerDestDir.exists() )
{
File outputFile = generateArchive( innerDestDir, finalName +
- + getClassifier() + .jar );
if ( !attach )
{
getLog().info( NOT adding javadoc to attached artifacts
list. );
}
else
{
// TODO: these introduced dependencies on the project are
going to become problematic - can we expor
// through metadata instead?
projectHelper.attachArtifact( project, javadoc,
getClassifier(), outputFile );
}
}
}
catch ( ArchiverException e )
{
failOnError( ArchiverException: Error while creating archive, e
);
}
catch ( IOException e )
{
failOnError( IOException: Error while creating archive, e );
}
catch ( MavenReportException e )
{
failOnError( MavenReportException: Error while creating
archive, e );
}
catch ( RuntimeException e )
{
failOnError( RuntimeException: Error while creating archive, e
);
}
{code}
If there is an error in {{executeReport( Locale.getDefault() )}} then the
MOJO will just give up and not try to create the archive. I think that if
failOnError is set, then we should try to create the archive anyway.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-603) ${maven.build.timestamp} placeholder is not filtered
[
https://jira.codehaus.org/browse/MASSEMBLY-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=362903#comment-362903
]
Mike Duigou commented on MASSEMBLY-603:
---
The workaround produces ${maven.build.timestamp} in the output for me and in
some contexts (NetBeans) the following error message:
[ERROR] Resolving expression: '${maven.build.timestamp}': Detected the
following recursive expression cycle in 'maven.build.timestamp':
[maven.build.timestamp]
This and http://jira.codehaus.org/browse/MRESOURCES-99 both deserve to be fixed.
${maven.build.timestamp} placeholder is not filtered
Key: MASSEMBLY-603
URL: https://jira.codehaus.org/browse/MASSEMBLY-603
Project: Maven Assembly Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.3, 2.4
Reporter: Igor Bljahhin
Priority: Minor
Attachments: assembly-issue.zip
When filtering files in assembly plugin most of placeholders are replaced
with values,
but Maven's property maven.build.timestamp (described here
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html in
Special Variables section) is not substituted with value.
Run mvn clean package in the test project and you will get
target/assembly-issue-0.0.1-SNAPSHOT-dist.zip archive. Open index.html from
archive and you will see that property project.version was replaced during
assembly, but maven.build.timestamp was left untouched.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
