[jira] [Commented] (MENFORCER-420) Reuse getDependenciesToCheck results across rules
[
https://issues.apache.org/jira/browse/MENFORCER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543638#comment-17543638
]
Joseph Walton commented on MENFORCER-420:
-
That makes sense; adding it to the Helper is a nice way to get an
execution-scoped cache without having to thread a new object through all the
calls. I've updated the PR.
One downside is that it will not longer be shared _across_ executions. Our
current configuration uses several distinct executions with their own
{{{}{}}}. However, I think adapting our build is
reasonable, and the isolation from other state is worth it.
> Reuse getDependenciesToCheck results across rules
> -
>
> Key: MENFORCER-420
> URL: https://issues.apache.org/jira/browse/MENFORCER-420
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Reporter: Joseph Walton
>Priority: Minor
>
> We have a build with a significant number of dependencies, and also a large
> number of {{}} rules. Together, they lead to a build
> where Enforcer takes tens of minutes.
> Looking into bottlenecks, we found that
> {{AbstractBanDependencies#getDependenciesToCheck}} was taking a significant
> proportion of the build time (tens of percent). This method is called once
> per rule, so it's recalculating the dependencies for every rule across every
> execution.
> Introducing a cache, to reuse the dependencies one they'd been calculated for
> a module, dropped the time spent in banned dependency enforcement by about
> 75%, which was reflected as a 60% improvement in the time of that build.
> Our local implementation used the {{org.codehaus.plexus.context.Context}} to
> store the dependencies keyed by the concatenation of {{MavenProject#getId}}
> and {{searchTransitive}}; there may be a more appropriate scope to avoid edge
> cases with complex configurations.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MENFORCER-420) Reuse getDependenciesToCheck results across rules
Joseph Walton created MENFORCER-420:
---
Summary: Reuse getDependenciesToCheck results across rules
Key: MENFORCER-420
URL: https://issues.apache.org/jira/browse/MENFORCER-420
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: Standard Rules
Reporter: Joseph Walton
We have a build with a significant number of dependencies, and also a large
number of {{}} rules. Together, they lead to a build where
Enforcer takes tens of minutes.
Looking into bottlenecks, we found that
{{AbstractBanDependencies#getDependenciesToCheck}} was taking a significant
proportion of the build time (tens of percent). This method is called once per
rule, so it's recalculating the dependencies for every rule across every
execution.
Introducing a cache, to reuse the dependencies one they'd been calculated for a
module, dropped the time spent in banned dependency enforcement by about 75%,
which was reflected as a 60% improvement in the time of that build.
Our local implementation used the {{org.codehaus.plexus.context.Context}} to
store the dependencies keyed by the concatenation of {{MavenProject#getId}} and
{{searchTransitive}}; there may be a more appropriate scope to avoid edge cases
with complex configurations.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MDEP-779) dependency:analyze should list the classes that cause a used undeclared dependency
[
https://issues.apache.org/jira/browse/MDEP-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MDEP-779:
---
Description:
When {{dependency:analyze}} shows that a module has used classes from an
undeclared dependency, it may not be clear which classes are involved. In
particular, on large projects where modules and packages don't have a clear 1:1
relationship.
It would be useful if there was (opt-in?) display of the classes involved. This
could make it significantly quicker to identify the specific issue without
switching to another tool.
For example:
{noformat}
[WARNING] Used undeclared dependencies found:
[WARNING]xml-apis:xml-apis:jar:1.0.b2:compile
[WARNING]class org.apache.xmlcommons.Version
{noformat}
was:
When {{dependency:analyze}} shows that a module has used classes from an
undeclared dependency, it may not be clear which classes are involved. In
particular, on large projects where modules and packages don't have a clear 1:1
relationship.
It would be useful if there was (opt-in?) display of the classes involved. This
could make it significantly quicker to identify the specific issue without
switching to another tool.
For example:
{noformat}
[WARNING] Used undeclared dependencies found:
[WARNING]xml-apis:xml-apis:jar:1.0.b2:compile
{WARNING]class org.apache.xmlcommons.Version
{noformat}
> dependency:analyze should list the classes that cause a used undeclared
> dependency
> --
>
> Key: MDEP-779
> URL: https://issues.apache.org/jira/browse/MDEP-779
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: analyze-dep-mgt
>Reporter: Joseph Walton
>Priority: Major
>
> When {{dependency:analyze}} shows that a module has used classes from an
> undeclared dependency, it may not be clear which classes are involved. In
> particular, on large projects where modules and packages don't have a clear
> 1:1 relationship.
> It would be useful if there was (opt-in?) display of the classes involved.
> This could make it significantly quicker to identify the specific issue
> without switching to another tool.
> For example:
> {noformat}
> [WARNING] Used undeclared dependencies found:
> [WARNING]xml-apis:xml-apis:jar:1.0.b2:compile
> [WARNING]class org.apache.xmlcommons.Version
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MDEP-779) dependency:analyze should list the classes that cause a used undeclared dependency
Joseph Walton created MDEP-779:
--
Summary: dependency:analyze should list the classes that cause a
used undeclared dependency
Key: MDEP-779
URL: https://issues.apache.org/jira/browse/MDEP-779
Project: Maven Dependency Plugin
Issue Type: Improvement
Components: analyze-dep-mgt
Reporter: Joseph Walton
When {{dependency:analyze}} shows that a module has used classes from an
undeclared dependency, it may not be clear which classes are involved. In
particular, on large projects where modules and packages don't have a clear 1:1
relationship.
It would be useful if there was (opt-in?) display of the classes involved. This
could make it significantly quicker to identify the specific issue without
switching to another tool.
For example:
{noformat}
[WARNING] Used undeclared dependencies found:
[WARNING]xml-apis:xml-apis:jar:1.0.b2:compile
{WARNING]class org.apache.xmlcommons.Version
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6898) Convert DefaultLifecyclePluginAnalyzer to JSR 330
[
https://issues.apache.org/jira/browse/MNG-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423545#comment-17423545
]
Joseph Walton commented on MNG-6898:
Thanks for fixing this, [~cstamas]; having one file left unconverted to JSR 330
was annoying.
> Convert DefaultLifecyclePluginAnalyzer to JSR 330
> -
>
> Key: MNG-6898
> URL: https://issues.apache.org/jira/browse/MNG-6898
> Project: Maven
> Issue Type: Sub-task
> Components: Core
>Affects Versions: 3.6.3
>Reporter: Joseph Walton
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0-alpha-1
>
>
> Convert {{DefaultLifecyclePluginAnalyzer}} in {{maven-core}} to JSR 330
> annotations. This follows on from MNG-5577, which converted the other classes.
> The complication here is that, with the annotations changed, the
> {{lifecycleMappings}} {{Map}} is no longer getting filtered by sisu.plexus's
> {{RealmFilteredBeans}}. That means extensions added in one module will appear
> in all of them, which makes
> [{{MavenITmng4385LifecycleMappingFromExtensionInReactorTest}}|https://github.com/apache/maven-integration-testing/blob/6e480ac3a436bf4f3624f36935578966430c654c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4385LifecycleMappingFromExtensionInReactorTest.java]
> fail.
> From what I can see, the only place a {{RealmFilteredBeans}} is used during
> injection is when the resource is located through
> {{DefaultPlexusBeanLocator}}. However, that's not the case after that field
> switches from {{@Requirement}} to {{@Inject}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092676#comment-17092676 ] Joseph Walton commented on MNG-5577: Split the remaining class out as MNG-6898, and carried over the relevant details. > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. > *NOTE:* The descriptor must still be generated, since Maven doesn't do > annotation scanning for performance reason. It simply reads the descriptor > file(s). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6898) Convert DefaultLifecyclePluginAnalyzer to JSR 330
Joseph Walton created MNG-6898:
--
Summary: Convert DefaultLifecyclePluginAnalyzer to JSR 330
Key: MNG-6898
URL: https://issues.apache.org/jira/browse/MNG-6898
Project: Maven
Issue Type: Improvement
Components: core
Reporter: Joseph Walton
Convert {{DefaultLifecyclePluginAnalyzer}} in {{maven-core}} to JSR 330
annotations. This follows on from MNG-5577, which converted the other classes.
The complication here is that, with the annotations changed, the
{{lifecycleMappings}} {{Map}} is no longer getting filtered by sisu.plexus's
{{RealmFilteredBeans}}. That means extensions added in one module will appear
in all of them, which makes
[{{MavenITmng4385LifecycleMappingFromExtensionInReactorTest}}|https://github.com/apache/maven-integration-testing/blob/6e480ac3a436bf4f3624f36935578966430c654c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4385LifecycleMappingFromExtensionInReactorTest.java]
fail.
>From what I can see, the only place a {{RealmFilteredBeans}} is used during
>injection is when the resource is located through
>{{DefaultPlexusBeanLocator}}. However, that's not the case after that field
>switches from {{@Requirement}} to {{@Inject}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[
https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092233#comment-17092233
]
Joseph Walton commented on MNG-5577:
There's a single class still to do here; see earlier comments:
{quote}The blocker is {{DefaultLifecyclePluginAnalyzer}}.
{quote}
{{sisu.plexus}} wires it up with a {{RealmFilteredBeans}}; it's not clear how
to retain that with {{@Inject}}.
> Convert the core to use JSR 330 and remove the use of Plexus
>
>
> Key: MNG-5577
> URL: https://issues.apache.org/jira/browse/MNG-5577
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Jason van Zyl
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Remove the use of Plexus annotations and use JSR330 annotations throughout
> the core.
> *NOTE:* The descriptor must still be generated, since Maven doesn't do
> annotation scanning for performance reason. It simply reads the descriptor
> file(s).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6687) Convert Maven Compat to JSR 330
[
https://issues.apache.org/jira/browse/MNG-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092231#comment-17092231
]
Joseph Walton commented on MNG-6687:
As the reporter, I'm totally fine with wontfix here. Considering compatibility:
should there be a ticket to delete {{maven-compat}}?
> Convert Maven Compat to JSR 330
> ---
>
> Key: MNG-6687
> URL: https://issues.apache.org/jira/browse/MNG-6687
> Project: Maven
> Issue Type: Sub-task
>Reporter: Joseph Walton
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Convert all Plexus {{@Component}} classes in {{maven-compat}} to JSR 330
> annotations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6858) Need a way to skip empty-string arguments
[
https://issues.apache.org/jira/browse/MNG-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074632#comment-17074632
]
Joseph Walton commented on MNG-6858:
If you know that have a Bash script, you can use the technique in [this Unix
Stack Exchange answer|https://unix.stackexchange.com/a/446848]. To paraphrase:
{code:java}
params=()
if [ "${ANDROID}" = "true" ]; then
params+=(-Pandroid)
fi
...
mvn "${params[@]}" ...
{code}
This could be less surprising than Maven silently ignore empty strings (always?
Only when they'd otherwise be goals?).
> Need a way to skip empty-string arguments
> -
>
> Key: MNG-6858
> URL: https://issues.apache.org/jira/browse/MNG-6858
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.1
> Environment: Ubuntu 19.10
>Reporter: Chris Hennick
>Priority: Major
>
> I have a bash script that sets a sometimes-empty variable as follows:
>
> {code:java}
> if [ "${ANDROID}" = "true" ]; then
> MAYBE_ANDROID_FLAG=-Pandroid
> else
> MAYBE_ANDROID_FLAG=
> fi{code}
>
> It's used like so:
>
> {code:java}
> mvn ${MAYBE_ANDROID_FLAG} clean compile jacoco:instrument
> jacoco:prepare-agent test jacoco:restore-instrumented-classes jacoco:report
> -e -B}}{code}
>
> Shell-scripting best practices dictate that ${MAYBE_ANDROID_FLAG} above
> should be in double quotes, but when I do that, I get 'Unknown lifecycle
> phase ""'. For it to be possible to follow best practices, then, we need a
> way to make Maven skip over command-line arguments that are empty strings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6873) Inconsistent library versions notice.
[
https://issues.apache.org/jira/browse/MNG-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074627#comment-17074627
]
Joseph Walton commented on MNG-6873:
In general, this is a good problem to fix, but this looks like it could be a
false positive.
For JUnit, this report is comparing the version used in different tests;
everything reported is in {{src/test/resources}}. I don't see any reason for
those versions to align, and I'm assuming that in some cases they're
intentionally divergent as part of the test.
> Inconsistent library versions notice.
> -
>
> Key: MNG-6873
> URL: https://issues.apache.org/jira/browse/MNG-6873
> Project: Maven
> Issue Type: Improvement
>Reporter: Kaifeng Huang
>Priority: Major
> Attachments: apache maven.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> Hi. I have implemented a tool to detect library version inconsistencies. Your
> project have 1 inconsistent library and 12 false consistent libraries.
>
> Take junit:junit for example, this library is declared as version 3.8.1 in
> maven-core/src/test/resources-project-builder/dependency-inheritance, 4.4 in
> maven-core/src/test/resources-project-builder/dependency-inheritance/sub and
> etc... Such version inconsistencies may cause unnecessary maintenance effort
> in the long run. For example, if two modules become inter-dependent, library
> version conflict may happen. It has already become a common issue and hinders
> development progress. Thus a version harmonization is necessary.
>
> Provided we applied a version harmonization, I calculated the cost it may
> have to harmonize to all upper versions including an up-to-date one. The cost
> refers to POM config changes and API invocation changes. Take junit:junit for
> example, if we harmonize all the library versions into 4.4. The concern is,
> how much should the project code adapt to the newer library version. We list
> an effort table to quantify the harmonization cost.
>
> The effort table shows the overall harmonization cost on APIs. It seems your
> project have no API invokes on this library, which could be safely upgrade to
> 4.4
> ||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)||
> |1|maven-core/src/test/resources-project-builder/dependency-inheritance|0(0)|0(0)|0(0)|
> |2|maven-core/src/test/resources-project-builder/dependency-inheritance/sub|0(0)|0(0)|0(0)|
>
> Also we provided another table to show the potential files that may be
> affected due to library API change, which could help to spot the concerned
> API usage and rerun the test cases.
> As for false consistency, take junit junit jar for example. The library is
> declared in version 4.13 in all modules. However they are declared
> differently. As components are developed in parallel, if one single library
> version is updated, which could become inconsistent as mentioned above, may
> cause above-mentioned inconsistency issues
> If you are interested, you can have a more complete and detailed report in
> the attached PDF file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6875) mvn test keeps failing after changes removed
[
https://issues.apache.org/jira/browse/MNG-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074625#comment-17074625
]
Joseph Walton commented on MNG-6875:
The reported error is from [https://github.com/revelc/formatter-maven-plugin].
It [uses a
cache|https://github.com/revelc/formatter-maven-plugin/blob/c24af2ed4ce71367fce92d2938cbf56ded1e9fe1/src/main/java/net/revelc/code/formatter/FormatterMojo.java#L82]
stored in the filesystem; it may be worth reporting a bug against that mojo.
> mvn test keeps failing after changes removed
>
>
> Key: MNG-6875
> URL: https://issues.apache.org/jira/browse/MNG-6875
> Project: Maven
> Issue Type: Bug
>Reporter: Grigoriy Mikhalkin
>Priority: Major
>
> Maven version: 3.6.0
> Problem:
> After i created new branch and did few changes to code, i ran `mvn test` and
> got formatting error:
>
> {code:java}
> somefile has not been previously formatted. Please format file and commit
> before running validation!{code}
>
>
> I stashed changes, so `git status` didn't displayed any changes between
> master and branch, and ran `mvn test` again - still got same error.
>
> Then i switched to master and ran `mvn test` - no errors. Switched to new
> branch again - still having errors. Just in case, i tried to close my IDE and
> log out/in - nothing helps.
>
> From what i understand, even if there some changes in files, that git is not
> tracking, `mvn test` should return identical results in both cases(as code in
> master and branch are same). But in reality it's not the case. Probably,
> maven stores some metadata about git branches, that can cause such behavior?
>
> Btw, not sure if this is really problem with maven. Maybe someone can point
> to right places to look at.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[
https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074618#comment-17074618
]
Joseph Walton commented on MNG-5818:
The {{@Deprecated}} annotation is added but (e.g.) {{cobertura-maven-plugin}}
2.7, [still calls
{{setDependencyArtifacts}}|https://github.com/mojohaus/cobertura-maven-plugin/blob/4dbda2c19ebad2c5fe7610421254f86faf9642a6/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java#L247]:
{code:java}
Set set = new LinkedHashSet(
this.getProject().getDependencyArtifacts() );
set.add( coberturaArtifact );
this.getProject().setDependencyArtifacts( set );
{code}
The comment for
[4567c83|https://github.com/apache/maven/commit/4567c8319e95d58e258e9a8c2067ed9bbe01b58e]
says:
{quote}I'm going to try and create a call-graph for all of Maven Central with my
first test to see if I can accurately detect all usages of
MavenProject.setDependencyArtifacts
of artifact in Maven Central.
{quote}
Either that needs to happen, or this method could be deleted first and mojos
can be fixed when breakage is noticed.
> Disallow plugins from programmatically adding dependencies to projects
> --
>
> Key: MNG-5818
> URL: https://issues.apache.org/jira/browse/MNG-5818
> Project: Maven
> Issue Type: Task
>Reporter: Jason van Zyl
>Priority: Major
>
> MavenProject.setDependencyArtifacts(deps) is publicly available to plugins
> that can alter the classpath non-declaratively. For compatibility reasons in
> MNG-4363 we restored this capability for the cobertura-maven-plugin but it
> needs to be removed. It causes some nasty logic in the core, but it being
> non-delclarative and magical is the real problem.
> We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace
> the logic for constructing the artifacts in a better. Preferably passing in
> the artifacts in the constructor of MavenProject.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074601#comment-17074601
]
Joseph Walton edited comment on MNG-6613 at 4/3/20, 2:01 PM:
-
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test; [PR
opened|https://github.com/apache/maven-integration-testing/pull/57].
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
was (Author: j...@kafsemo.org):
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test.
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074601#comment-17074601
]
Joseph Walton commented on MNG-6613:
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test.
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[
https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072775#comment-17072775
]
Joseph Walton commented on MNG-5577:
>From what I can see, the only place a {{RealmFilteredBeans}} is used during
>injection is when the resource is located through
>{{DefaultPlexusBeanLocator}}. However, that's not the case after that field
>switches from {{@Requirement}} to {{@Inject}}.
It's not clear what the correct way is to retain the old behaviour; MNG-4385
established that it was intentional.
> Convert the core to use JSR 330 and remove the use of Plexus
>
>
> Key: MNG-5577
> URL: https://issues.apache.org/jira/browse/MNG-5577
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Jason van Zyl
>Priority: Major
> Fix For: 3.7.x-candidate
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Remove the use of Plexus annotations and use JSR330 annotations throughout
> the core.
> *NOTE:* The descriptor must still be generated, since Maven doesn't do
> annotation scanning for performance reason. It simply reads the descriptor
> file(s).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6703) DefaultUrlNormalizer doesn't normalize all relative URIs
Joseph Walton created MNG-6703:
--
Summary: DefaultUrlNormalizer doesn't normalize all relative URIs
Key: MNG-6703
URL: https://issues.apache.org/jira/browse/MNG-6703
Project: Maven
Issue Type: Bug
Reporter: Joseph Walton
{{DefaultUrlNormalizer}}'s tests only cover absolute URLs. Extending the tests
to relative URI references (as suggested by MNG-6535) suggests an edge case of
{{"a/../"}} that should be normalized to the empty string, but which is left
unchanged.
This input should either be rejected, or the behaviour documented or fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6687) Convert Maven Compat to JSR 330
[
https://issues.apache.org/jira/browse/MNG-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MNG-6687:
---
Summary: Convert Maven Compat to JSR 330 (was: Convert Maven Model Builder
to JSR 330)
> Convert Maven Compat to JSR 330
> ---
>
> Key: MNG-6687
> URL: https://issues.apache.org/jira/browse/MNG-6687
> Project: Maven
> Issue Type: Sub-task
>Reporter: Joseph Walton
>Assignee: Michael Osipov
>Priority: Major
>
> Convert all Plexus {{@Component}} classes in {{maven-compat}} to JSR 330
> annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6687) Convert Maven Model Builder to JSR 330
Joseph Walton created MNG-6687:
--
Summary: Convert Maven Model Builder to JSR 330
Key: MNG-6687
URL: https://issues.apache.org/jira/browse/MNG-6687
Project: Maven
Issue Type: Sub-task
Reporter: Joseph Walton
Convert all Plexus {{@Component}} classes in {{maven-compat}} to JSR 330
annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6686) Convert Maven Embedder to JSR 330
Joseph Walton created MNG-6686:
--
Summary: Convert Maven Embedder to JSR 330
Key: MNG-6686
URL: https://issues.apache.org/jira/browse/MNG-6686
Project: Maven
Issue Type: Sub-task
Reporter: Joseph Walton
Convert all Plexus {{@Component}} classes in {{maven-embedder}} to JSR 330
annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6685) Convert Maven Model Builder to JSR 330
Joseph Walton created MNG-6685:
--
Summary: Convert Maven Model Builder to JSR 330
Key: MNG-6685
URL: https://issues.apache.org/jira/browse/MNG-6685
Project: Maven
Issue Type: Sub-task
Reporter: Joseph Walton
Convert all Plexus {{@Component}} classes in {{maven-model-builder}} to JSR 330
annotations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6535) Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
[
https://issues.apache.org/jira/browse/MNG-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843919#comment-16843919
]
Joseph Walton commented on MNG-6535:
Although the PR's been declined, one of the tests improves the code coverage of
{{DefaultUrlNormalizer}}. To minimise it, and add a clearer statement of what
it's testing:
{code}
public void testNormalizeInputWithNoParentDirectoriesToAscendTo()
{
assertEquals("a/../", normalize("a/../"));
}
{code}
> Add unit tests for org.apache.maven.model.path.DefaultUrlNormalizer
> ---
>
> Key: MNG-6535
> URL: https://issues.apache.org/jira/browse/MNG-6535
> Project: Maven
> Issue Type: Test
>Reporter: Louis Mills
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These tests were written by Diffblue Cover.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-5811) Display the time of execution for each participant of the build
[
https://issues.apache.org/jira/browse/MNG-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829256#comment-16829256
]
Joseph Walton edited comment on MNG-5811 at 4/29/19 1:18 PM:
-
For access to these results, and control over the summaries, consider
[{{maven-profiler}}|https://github.com/jcgay/maven-profiler] or the (other)
[{{maven-profiler}}|https://github.com/takari/maven-profiler].
was (Author: j...@kafsemo.org):
For access to these results, and control over the summaries, consider
[{{maven-profiler}}|https://github.com/jcgay/maven-profiler] or the (other)
https://github.com/takari/maven-profiler
[{{maven-profiler}}|https://github.com/takari/maven-profiler].
> Display the time of execution for each participant of the build
> ---
>
> Key: MNG-5811
> URL: https://issues.apache.org/jira/browse/MNG-5811
> Project: Maven
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.5, 3.3.1
>Reporter: Rocher Suchard
>Priority: Minor
> Labels: features
>
> Hello,
> When working with projet with a lots of plugins bundled in different phase,
> I'd find rather interesting to have the execution time of such plugin, like
> you have the execution time of each project in a multi module project.
> The major use of such feature is to determine the plugins that takes too much
> time in the build process and possibly to correct them.
> For an example of what I want, compare the two output :
> - default log (on any project, this is not relevant here) :
> {code}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Application ... SUCCESS [ 0.768 s]
> [INFO] apps-common ... SUCCESS [ 3.649 s]
> [INFO] apps-template-plugin .. SUCCESS [ 6.665 s]
> [INFO] apps-general .. SUCCESS [ 12.627 s]
> [INFO] apps-console .. SUCCESS [ 0.384 s]
> [INFO] GUI Tools . SUCCESS [ 1.059 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 25.330 s
> [INFO] Finished at: 2015-04-27T22:46:54+02:00
> [INFO] Final Memory: 47M/613M
> [INFO]
>
> {code}
> - "enhanced" logs :
> {code}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Application
> ... SUCCESS [ 0.768
> s]
> [INFO] apps-common
> ... SUCCESS [ 3.649
> s]
> [INFO] apps-template-plugin
> .. SUCCESS [ 6.665 s]
> [INFO] apps-general
> .. SUCCESS [ 12.627 s]
> [INFO] apps-console
> .. SUCCESS [ 0.384 s]
> [INFO] GUI Tools
> . SUCCESS [
> 1.059 s]
> [INFO] - maven-clean-plugin:2.6.1:clean
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-resources-plugin:2.6:resources (default-resources)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-compiler-plugin:2.0.2:compile (default-compile)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-resources-plugin:2.6:testResources (default-testResources)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-surefire-plugin:2.12.4:test (default-test)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-jar-plugin:2.4:jar (default-jar)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-install-plugin:2.4:install (default-install)
> ... SUCCESS [ 1.000 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 25.330 s
> [INFO] Finished at: 2015-04-27T22:46:54+02:00
> [INFO] Final Memory: 47M/613M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5811) Display the time of execution for each participant of the build
[
https://issues.apache.org/jira/browse/MNG-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829256#comment-16829256
]
Joseph Walton commented on MNG-5811:
For access to these results, and control over the summaries, consider
[{{maven-profiler}}|https://github.com/jcgay/maven-profiler] or the (other)
https://github.com/takari/maven-profiler
[{{maven-profiler}}|https://github.com/takari/maven-profiler].
> Display the time of execution for each participant of the build
> ---
>
> Key: MNG-5811
> URL: https://issues.apache.org/jira/browse/MNG-5811
> Project: Maven
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.5, 3.3.1
>Reporter: Rocher Suchard
>Priority: Minor
> Labels: features
>
> Hello,
> When working with projet with a lots of plugins bundled in different phase,
> I'd find rather interesting to have the execution time of such plugin, like
> you have the execution time of each project in a multi module project.
> The major use of such feature is to determine the plugins that takes too much
> time in the build process and possibly to correct them.
> For an example of what I want, compare the two output :
> - default log (on any project, this is not relevant here) :
> {code}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Application ... SUCCESS [ 0.768 s]
> [INFO] apps-common ... SUCCESS [ 3.649 s]
> [INFO] apps-template-plugin .. SUCCESS [ 6.665 s]
> [INFO] apps-general .. SUCCESS [ 12.627 s]
> [INFO] apps-console .. SUCCESS [ 0.384 s]
> [INFO] GUI Tools . SUCCESS [ 1.059 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 25.330 s
> [INFO] Finished at: 2015-04-27T22:46:54+02:00
> [INFO] Final Memory: 47M/613M
> [INFO]
>
> {code}
> - "enhanced" logs :
> {code}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Application
> ... SUCCESS [ 0.768
> s]
> [INFO] apps-common
> ... SUCCESS [ 3.649
> s]
> [INFO] apps-template-plugin
> .. SUCCESS [ 6.665 s]
> [INFO] apps-general
> .. SUCCESS [ 12.627 s]
> [INFO] apps-console
> .. SUCCESS [ 0.384 s]
> [INFO] GUI Tools
> . SUCCESS [
> 1.059 s]
> [INFO] - maven-clean-plugin:2.6.1:clean
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-resources-plugin:2.6:resources (default-resources)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-compiler-plugin:2.0.2:compile (default-compile)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-resources-plugin:2.6:testResources (default-testResources)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-surefire-plugin:2.12.4:test (default-test)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-jar-plugin:2.4:jar (default-jar)
> ... SUCCESS [ 1.000 s]
> [INFO] - maven-install-plugin:2.4:install (default-install)
> ... SUCCESS [ 1.000 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 25.330 s
> [INFO] Finished at: 2015-04-27T22:46:54+02:00
> [INFO] Final Memory: 47M/613M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6580) Unable to inject annotations from classes compiled for Java 9+
[
https://issues.apache.org/jira/browse/MNG-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829241#comment-16829241
]
Joseph Walton commented on MNG-6580:
Sisu's ASM has [been slightly
upgraded|https://github.com/eclipse/sisu.inject/commit/ae6e9d93785e11447a12b0eab964412bf51eb29e],
but the 0.3.3 release's copy of ASM [still only handles
1.8|https://github.com/eclipse/sisu.inject/blob/6082fa8588c4eca77592e26dc466239d3be8087f/org.eclipse.sisu.inject/src/org/eclipse/sisu/space/asm/ClassReader.java#L169].
Upstream ASM [currently supports Java
13|https://gitlab.ow2.org/asm/asm/blob/7a469bc9/asm/src/main/java/org/objectweb/asm/ClassReader.java#L193]
classfiles.
> Unable to inject annotations from classes compiled for Java 9+
> --
>
> Key: MNG-6580
> URL: https://issues.apache.org/jira/browse/MNG-6580
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Sylwester Lachiewicz
>Priority: Major
>
> While Sisu (0.3.3) is searching for implementation classes to be available
> for injection - it accepts only classes compiled for Java up to 8
> [https://github.com/eclipse/sisu.inject/blob/master/org.eclipse.sisu.inject/src/org/eclipse/sisu/space/asm/ClassReader.java#L168]
> If an implementation is compiled for Java 9+ warning will be logged
> (log.Sisu=trace) and class ignored.
> {code:java}
> [main] [TRACE] Sisu - Problem scanning:
> jar:file:/c:/programs/apache-maven-3.6.1-SNAPSHOT/bin/../lib/maven-core-3.6.1-SNAPSHOT.jar!/org/apache/maven/lifecycle/internal/LifecycleDependencyResolver.class
> java.lang.IllegalArgumentException
> at org.eclipse.sisu.space.asm.ClassReader. (ClassReader.java:170)
> at org.eclipse.sisu.space.asm.ClassReader. (ClassReader.java:153)
> at org.eclipse.sisu.space.asm.ClassReader. (ClassReader.java:424)
> at org.eclipse.sisu.space.SpaceScanner.accept (SpaceScanner.java:102)
> at org.eclipse.sisu.space.SpaceScanner.accept (SpaceScanner.java:78)
> at org.eclipse.sisu.space.SpaceModule.scanForElements (SpaceModule.java:168)
> at org.eclipse.sisu.space.SpaceModule.configure (SpaceModule.java:129)
> at org.eclipse.sisu.plexus.PlexusAnnotatedBeanModule.configure
> (PlexusAnnotatedBeanModule.java:102)
> at org.eclipse.sisu.plexus.PlexusBindingModule.configure
> (PlexusBindingModule.java:63)
> at com.google.inject.spi.Elements$RecordingBinder.install (Elements.java:344)
> at com.google.inject.spi.Elements.getElements (Elements.java:103)
> at com.google.inject.spi.Elements.getElements (Elements.java:96)
> at org.eclipse.sisu.wire.WireModule.configure (WireModule.java:75)
> at com.google.inject.spi.Elements$RecordingBinder.install (Elements.java:344)
> at com.google.inject.spi.Elements.getElements (Elements.java:103)
> at com.google.inject.internal.InjectorShell$Builder.build
> (InjectorShell.java:137)
> at com.google.inject.internal.InternalInjectorCreator.build
> (InternalInjectorCreator.java:103)
> at com.google.inject.Guice.createInjector (Guice.java:87)
> at com.google.inject.Guice.createInjector (Guice.java:69)
> at com.google.inject.Guice.createInjector (Guice.java:59)
> at org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector
> (DefaultPlexusContainer.java:481)
> at org.codehaus.plexus.DefaultPlexusContainer.
> (DefaultPlexusContainer.java:206)
> at org.apache.maven.cli.MavenCli.container (MavenCli.java:635)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:281)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> and a similar error is thrown
> {code:java}
> [WARNING] Error injecting:
> org.apache.maven.project.DefaultProjectBuildingHelper
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) No implementation for org.apache.maven.classrealm.ClassRealmManager was
> bound.
> while locating org.apache.maven.project.DefaultProjectBuildingHelper
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6096) Deprecate DefaultArtifactVersion class
[
https://issues.apache.org/jira/browse/MNG-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822864#comment-16822864
]
Joseph Walton commented on MNG-6096:
This looks like a trivial change to reschedule; what's the long-term story
here? Is the alternative {{ComparableVersion}}?
{{DefaultArtifactVersion}} is still used throughout Maven:
{code}
maven-artifact/src/main/java/org/apache/maven/artifact/DefaultArtifact.java
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java
maven-compat/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java
maven-compat/src/main/java/org/apache/maven/profiles/activation/JdkPrefixProfileActivator.java
maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultGraphConflictResolutionPolicy.java
maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java
maven-core/src/main/java/org/apache/maven/toolchain/RequirementMatcherFactory.java
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
{code}
and, with {{DefaultVersion}} used in API, it doesn't seem like it's possible to
remove it without either breaking API or providing a new concrete
implementation.
> Deprecate DefaultArtifactVersion class
> --
>
> Key: MNG-6096
> URL: https://issues.apache.org/jira/browse/MNG-6096
> Project: Maven
> Issue Type: Task
> Components: core
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> The DefaultArtifactVersion class parses the version of the artifacts but in
> many situations it does not work correctly.
> Furthermore based on the references and hints given here:
> https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-306) [REGRESSION] RequirePluginVersions fails
[
https://issues.apache.org/jira/browse/MENFORCER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691557#comment-16691557
]
Joseph Walton commented on MENFORCER-306:
-
I ran into this issue; a more specific issue title might help others to find
it ("requirePluginsVersions fails to recognise versions specified in parent
poms from outside the reactor"?).
It looks like a [branch for this
issue|https://github.com/apache/maven-enforcer/tree/MENFORCER-306] had a
[potential
fix|https://github.com/apache/maven-enforcer/commit/f503829ff3e0a05df9af8cf29d206693225a21b7]
committed back in June. Was that a viable approach? Is it worth testing,
suggesting feedback or proposing alternatives?
> [REGRESSION] RequirePluginVersions fails
>
>
> Key: MENFORCER-306
> URL: https://issues.apache.org/jira/browse/MENFORCER-306
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: MENFORCER-306.zip, pom.xml
>
>
> I have found that running the {{RequirePluginVersions}} rule on a project
> with version {{3.0.0-M1}} works fine whereas it fails with version
> {{3.0.0-M2}}.
> {code}
> [DEBUG] Executing rule:
> org.apache.maven.plugins.enforcer.RequirePluginVersions
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = clean
> [DEBUG] plugins = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] plugin = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] GAV = [org.apache.maven.plugins, maven-clean-plugin, 2.5, clean]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = install
> [DEBUG] plugins = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] plugin = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] GAV = [org.apache.maven.plugins, maven-install-plugin, 2.4,
> install]
> [DEBUG] lifecycleMapping = deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-deploy-plugin, 2.7, deploy]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = site
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, site]
> [DEBUG] lifecycleMapping = site-deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, deploy]
> [DEBUG] All Plugins in use: [Plugin [org.tinyjee.dim:doxia-include-macro],
> Plugin [org.apache.maven.plugins:maven-clean-plugin], Plugin
> [org.apache.maven.plugins:maven-install-plugin], Plugin
> [org.apache.maven.plugins:maven-site-plugin], Plugin
> [org.apache.maven.plugins:maven-deploy-plugin], Plugin
> [org.jacoco:jacoco-maven-plugin], Plugin
> [org.apache.maven.plugins:maven-enforcer-plugin]]
> [DEBUG] plugin org.tinyjee.dim:doxia-include-macro not found
> [DEBUG] plugin org.apache.maven.plugins:maven-clean-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-install-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-site-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-deploy-plugin not found
> [DEBUG] plugin org.jacoco:jacoco-maven-plugin not found
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Some plugins are
> missing valid versions:(LATEST RELEASE SNAPSHOT are not allowed )
> org.tinyjee.dim:doxia-include-macro. The version currently in use is 1.1
> org.apache.maven.plugins:maven-clean-plugin. The version currently in use is
> 3.0.0
> org.apache.maven.plugins:maven-install-plugin.The version currently
> in use is 2.5.2
> org.apache.maven.plugins:maven-site-plugin. The version currently in use is
> 3.6
> org.apache.maven.plugins:maven-deploy-plugin. The version currently
> in use is 2.8.2
> org.jacoco:jacoco-maven-plugin. The version currently in use is 0.8.0
> Always define plugin versions! Never use LATEST or RELEASE.
> at org.apache.maven.plugins.enforcer.RequirePluginVersions.execute
> (RequirePluginVersions.java:320)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {code}
--
This message was sent by Atlassian
[jira] [Commented] (MNG-6281) ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML
[ https://issues.apache.org/jira/browse/MNG-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480556#comment-16480556 ] Joseph Walton commented on MNG-6281: Duplicate of MNG-6216? > ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML > --- > > Key: MNG-6281 > URL: https://issues.apache.org/jira/browse/MNG-6281 > Project: Maven > Issue Type: Sub-task > Components: POM >Affects Versions: 3.5.0 >Reporter: Robert Scholte >Priority: Major > Fix For: 3.5.x-candidate > > > This is a hard one to recognize and to reproduce, but there are cases where > (for unknown reasons) that the content of the XML is duplicated in the pom > file. > Up until version 3.5.0 this was not an issue, because the XML parser stopped > parsing once hitting the closing project-tag, ignoring any content afterwards. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5835) Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
[
https://issues.apache.org/jira/browse/MNG-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576707#comment-14576707
]
Joseph Walton commented on MNG-5835:
bq. However, I just created a slightly changed hello-maven-plugin
Don't do that ;-)
If you call {{getLog()}} in your constructor then you'll [get an instance of
{{SystemStreamLog}}|https://github.com/apache/maven/blob/40d5087b6b134842e2b61a567dbb4bfbcfab7ae6/maven-plugin-api/src/main/java/org/apache/maven/plugin/AbstractMojo.java#L177]
that unconditionally logs to {{System.out}}. Your mojo will be wired with an
SLF4J-backed logger *after* construction.
Call {{getLog()}} during the {{execute()}} method, and don't cache the value.
If any of this behaviour seems like it could be improved, consider being
specific about your use case and your expectations. Otherwise these sound like
cases where the documentation should be clearer, rather than the behaviour
changed.
Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
-
Key: MNG-5835
URL: https://issues.apache.org/jira/browse/MNG-5835
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.3, 3.3.3
Reporter: S L
Attachments: hello-maven-plugin.zip, hello-maven-plugin2.zip
Hi,
since Maven should supports slf4j-Logging combined with the SLF4J Simple
implementation from Maven 3.1.0 onward
(http://maven.apache.org/maven-logging.html).
I'm kind of wondering why the default getLog() called from a Plugin ignores
the Environment-Variable ``-Dorg.slf4j.simpleLogger.defaultLogLevel=warn``
I'm currently using:
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-3.2.3
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: linux, version: 3.16.0-33-generic, arch: amd64, family: unix
Tested with different Maven-Versions and different maven-plugin-api Versions,
still no success.
Any help is highly appreciated.
Thanks,
PS: Hopefully I can attach my Example-Project which can be executed by using:
mvn clean install mvn clean package -Pdemo
-Dorg.slf4j.simpleLogger.defaultLogLevel=warn
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MANTTASKS-248) artifact:dependencies does not use SSL
[
https://issues.apache.org/jira/browse/MANTTASKS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MANTTASKS-248:
Attachment: MANTTASKS-248-use-https-url-for-central.diff
artifact:dependencies does not use SSL
--
Key: MANTTASKS-248
URL: https://issues.apache.org/jira/browse/MANTTASKS-248
Project: Maven Ant Tasks
Issue Type: Bug
Components: dependencies task
Reporter: Joseph Walton
Attachments: MANTTASKS-248-use-https-url-for-central.diff
The harcoded base URL used by {{artifact:dependencies}} is the old non-SSL
version:
{noformat}
http://repo1.maven.org/maven2
{noformat}
This is used during a bootstrap build of Maven itself, so should be updated to
{noformat}
https://repo.maven.apache.org/maven2
{noformat}
so that all artifacts are fetched over SSL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5835) Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
[
https://issues.apache.org/jira/browse/MNG-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576308#comment-14576308
]
Joseph Walton commented on MNG-5835:
{{MavenCli}} considers the {{-D}} arguments passed to Maven after the SLF4J
logger has already been initialised:
{code:title=MavenCli.java}
logging( cliRequest );
version( cliRequest );
properties( cliRequest );
{code}
To work around this, pass the arguments using {{MAVEN_OPTS}} instead, so
they're applied directly by {{java}} rather than as part of Maven's
initialisation:
{noformat}
MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean package
-Pdemo
{noformat}
Alternatively, use {{mvn --quiet}} which will also set the underlying SLF4J
level to {{ERROR}}.
Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
-
Key: MNG-5835
URL: https://issues.apache.org/jira/browse/MNG-5835
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.3, 3.3.3
Reporter: S L
Attachments: hello-maven-plugin.zip
Hi,
since Maven should supports slf4j-Logging combined with the SLF4J Simple
implementation from Maven 3.1.0 onward
(http://maven.apache.org/maven-logging.html).
I'm kind of wondering why the default getLog() called from a Plugin ignores
the Environment-Variable ``-Dorg.slf4j.simpleLogger.defaultLogLevel=warn``
I'm currently using:
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-3.2.3
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: linux, version: 3.16.0-33-generic, arch: amd64, family: unix
Tested with different Maven-Versions and different maven-plugin-api Versions,
still no success.
Any help is highly appreciated.
Thanks,
PS: Hopefully I can attach my Example-Project which can be executed by using:
mvn clean install mvn clean package -Pdemo
-Dorg.slf4j.simpleLogger.defaultLogLevel=warn
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MANTTASKS-248) artifact:dependencies does not use SSL
Joseph Walton created MANTTASKS-248:
---
Summary: artifact:dependencies does not use SSL
Key: MANTTASKS-248
URL: https://issues.apache.org/jira/browse/MANTTASKS-248
Project: Maven Ant Tasks
Issue Type: Bug
Components: dependencies task
Reporter: Joseph Walton
The harcoded base URL used by {{artifact:dependencies}} is the old non-SSL
version:
{noformat}
http://repo1.maven.org/maven2
{noformat}
This is used during a bootstrap build of Maven itself, so should be updated to
{noformat}
https://repo.maven.apache.org/maven2
{noformat}
so that all artifacts are fetched over SSL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
[
https://issues.apache.org/jira/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576233#comment-14576233
]
Joseph Walton commented on MNG-5680:
It looks like [this
commit|https://github.com/apache/maven/commit/ce6f0bfdb527e20c3afbd76b9c742e07b13d25b2#diff-9037bac1b0c7ac509f2f375f84d60f8d]
in 3.2.4 for MNG-5727 may fix this.
java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
--
Key: MNG-5680
URL: https://issues.apache.org/jira/browse/MNG-5680
Project: Maven
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 3.2.3
Reporter: George Gastaldi
Priority: Critical
Attachments: pom.xml
{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}
When the build method is called, the following exception is thrown:
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}
The code should be reviewed. This is the offending code inside
DefaultProjectBuilder:
{code}
Artifact artifact =
repositorySystem.createDependencyArtifact( d );
if ( artifact == null )
{
map = Collections.emptyMap();
}
map.put( d.getManagementKey(), artifact );
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MECLIPSE-758) Use mojo annotations
[
https://issues.apache.org/jira/browse/MECLIPSE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14492281#comment-14492281
]
Joseph Walton commented on MECLIPSE-758:
Apologies for that. That build result has expired, but it looks like this has
already been fixed by [this
commit|https://github.com/apache/maven-plugins/commit/41fb886525d2b15e24af7d1191dc70aaf189f1de],
which corrects my mistake of relying on MNG-5436 (not present in Maven 2).
Use mojo annotations
Key: MECLIPSE-758
URL: https://issues.apache.org/jira/browse/MECLIPSE-758
Project: Maven Eclipse Plugin
Issue Type: Improvement
Reporter: jwalton
Assignee: Karl Heinz Marbaise
Fix For: 2.10
Attachments: 0002-MECLIPSE-758-Use-annotations-for-mojos.patch
{{maven-eclipse-plugin}} is one of the only core plugins still using Javadoc
to define mojos and parameters. Moving over to annotations would make things
more consistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MECLIPSE-758) Use mojo annotations
Joseph Walton created MECLIPSE-758:
--
Summary: Use mojo annotations
Key: MECLIPSE-758
URL: https://jira.codehaus.org/browse/MECLIPSE-758
Project: Maven Eclipse Plugin
Issue Type: Improvement
Reporter: Joseph Walton
{{maven-eclipse-plugin}} is one of the only core plugins still using Javadoc to
define mojos and parameters. Moving over to annotations would make things more
consistent.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MECLIPSE-697) Delete deprecated code
[ https://jira.codehaus.org/browse/MECLIPSE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton updated MECLIPSE-697: --- Attachment: 0001-MECLIPSE-697-Delete-PDE-support-and-deprecated-class.patch Patch attached to delete all the suggested classes, along with any tests that only test that functionality. This clears out about a thousand lines of deprecated and not-really-supported code. Delete deprecated code -- Key: MECLIPSE-697 URL: https://jira.codehaus.org/browse/MECLIPSE-697 Project: Maven Eclipse Plugin Issue Type: Improvement Reporter: Barrie Treloar Fix For: 2.10 Attachments: 0001-MECLIPSE-697-Delete-PDE-support-and-deprecated-class.patch There are deprecated classes that have been there for a while. As part of cleaning up, its time for them to go. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MECLIPSE-758) Use mojo annotations
[
https://jira.codehaus.org/browse/MECLIPSE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MECLIPSE-758:
---
Attachment: 0002-MECLIPSE-758-Use-annotations-for-mojos.patch
Patch attached to use annotations. Most cases are transliterated, so a couple
of possibly-unnecessary properties are carried over, but this results in
generally smaller and safer definitions.
(This patch is on top of MECLIPSE-697, and assumes that deprecated mojos and
parameters have been deleted.)
Use mojo annotations
Key: MECLIPSE-758
URL: https://jira.codehaus.org/browse/MECLIPSE-758
Project: Maven Eclipse Plugin
Issue Type: Improvement
Reporter: Joseph Walton
Attachments: 0002-MECLIPSE-758-Use-annotations-for-mojos.patch
{{maven-eclipse-plugin}} is one of the only core plugins still using Javadoc
to define mojos and parameters. Moving over to annotations would make things
more consistent.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-277) Default phase for helpmojo should agree with that for descriptor
[
https://jira.codehaus.org/browse/MPLUGIN-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359805#comment-359805
]
Joseph Walton commented on MPLUGIN-277:
---
You're absolutely right; this is invalid.
I was running into MPLUGIN-238 and avoided build failure by moving {{helpmojo}}
into {{process-classes}}. This avoided the error (as the annotated classes were
now present), but I hadn't noticed that it was generating a {{HelpMojo.java}}
that was never compiled.
The first comment on MNG-5346 suggests {{process-classes}}, as do a number of
Stackoverflow answers (http://stackoverflow.com/a/1868,
http://stackoverflow.com/a/23405494) which were presumably copied from there.
This works for me:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
idhelp-goal/id
goals
goalhelpmojo/goal
/goals
configuration
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
/execution
/executions
/plugin
{code}
and I will be able to drop the {{sENDF}} when 3.4 is released.
Default phase for helpmojo should agree with that for descriptor
Key: MPLUGIN-277
URL: https://jira.codehaus.org/browse/MPLUGIN-277
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Joseph Walton
Since MPLUGIN-189, {{descriptor}} has a default phase of {{process-classes}}.
Since MNG-5346, that's also the phase of the default execution in the default
lifecycle binding. However, {{helpmojo}} still has a default phase of
{{generate-sources}}, which needs to be overridden when using annotations.
That is, I need to specify:
{noformat}
execution
idhelp-goal/id
phaseprocess-classes/phase
goals
goalhelpmojo/goal
/goals
/execution
{noformat}
Changing the default phase would only save one of those lines, but it would
make things more consistent between the two goals.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-277) Default phase for helpmojo should agree with that for descriptor
Joseph Walton created MPLUGIN-277:
-
Summary: Default phase for helpmojo should agree with that for
descriptor
Key: MPLUGIN-277
URL: https://jira.codehaus.org/browse/MPLUGIN-277
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Joseph Walton
Since MPLUGIN-189, {{descriptor}} has a default phase of {{process-classes}}.
Since MNG-5346, that's also the phase of the default execution in the default
lifecycle binding. However, {{helpmojo}} still has a default phase of
{{generate-sources}}, which needs to be overridden when using annotations.
That is, I need to specify:
{noformat}
execution
idhelp-goal/id
phaseprocess-classes/phase
goals
goalhelpmojo/goal
/goals
/execution
{noformat}
Changing the default phase would only save one of those lines, but it would
make things more consistent between the two goals.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5493) Concurrency exception in Maven core while using parallel build
[ https://jira.codehaus.org/browse/MNG-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354210#comment-354210 ] Joseph Walton commented on MNG-5493: Looks like this was duplicated, and fixed, as MNG-5670 ([8980f67b9b1d|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=8980f67b9b1d0dbc06b68f74a88b9f8589c40e23;hp=e3000a09c94396d7fd7d65fc236904aa07c7f7f2] in 3.2.3). Concurrency exception in Maven core while using parallel build -- Key: MNG-5493 URL: https://jira.codehaus.org/browse/MNG-5493 Project: Maven Issue Type: Bug Components: Deployment, Errors, General, Plugins and Lifecycle Affects Versions: 3.0.3, 3.0.5 Reporter: Pengfei Zhang My project uses parallel build for my deployment job in Hudson. From time to time, the build failed because of the following ConcurrencyModificationException. This apparently is not a plugin-in bug. Instead, it is a deeper issue in the core. I checked the source code, I think the Properties should be replaced by a concurrentHashMap. Accordingt to the java doc of Properties, it cannot support concurrency. org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on project ssm-viewer-spread: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1200) at java.util.Hashtable.putAll(Hashtable.java:614) at org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166) at org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:162) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:124) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:76) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:183) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436) at org.apache.maven -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3056) Dependencies should not be able to introduce repositories to the build
[
https://jira.codehaus.org/browse/MNG-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340281#comment-340281
]
Joseph Walton commented on MNG-3056:
For anyone looking for how to force resolution through a single URL, it's under
[Using A Single
Repository|http://maven.apache.org/guides/mini/guide-mirror-settings.html]. Add
a mirror to your {{~/.m2/settings.xml}} with {{mirrorOf}} set to {{*}}:
{noformat}
settings
...
mirrors
mirror
idinternal-repository/id
nameMaven Repository Manager running on repo.mycompany.com/name
urlhttp://repo.mycompany.com/proxy/url
mirrorOf*/mirrorOf
/mirror
/mirrors
...
/settings
{noformat}
Dependencies should not be able to introduce repositories to the build
--
Key: MNG-3056
URL: https://jira.codehaus.org/browse/MNG-3056
Project: Maven 2 3
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 2.2.x (to be reviewed)
Reporter: Wendy Smoak
Assignee: Jason van Zyl
Fix For: Issues to be reviewed for 3.x
If you depend on an artifact that has repositories or pluginRepositories
defined in the pom, those repositories are also searched for artifacts.
It's disconcerting when you think you've overridden 'central' and set things
up to use only internal repositories, and Maven still tries to to download
artifacts from elsewhere.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories/_remote.repositories contains other repository ids than requested
[ https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton updated MNG-5185: --- Attachment: 0001-MNG-5185-Warn-about-artifacts-present-but-not-available-eclipse-aether.patch bq. This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it. I've updated the patch to apply against the Eclipse aether-core master branch. This gets more complicated now Aether and Maven are separate projects: is this a useful change? What would the next steps be to get this into an Eclipse release that Maven could then consume? Improve missing dependency error message when _maven.repositories/_remote.repositories contains other repository ids than requested - Key: MNG-5185 URL: https://jira.codehaus.org/browse/MNG-5185 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 3.0.2, 3.0.3, 3.0.4 Reporter: Mark Derricutt Assignee: Olivier Lamy Fix For: Issues to be reviewed for 4.x Attachments: 0001-MNG-5185-Warn-about-artifacts-present-but-not-available-eclipse-aether.patch, 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch Based on a discussion on the users list [1], [Maven 3 has changed how it resolves artifacts from local repositories|https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository]. Unfortunately, when conflicts arise (GAV is cached in local repo, but restricted to some repository ids, and actual POM has no matching repository id declared), Maven just tells the user that the artifact could not be resolved. This leads to confusion from users who find the .jar files in their local repository without knowing this restriction feature: they just get frustrated and complain that maven sucks. It would be good if Maven was updated with some improved error messages along the lines of: The (GAV) artifact was found in your local repository, but came from remote repository xxx: either configure this in your pom with (insert sample XML block in error message), or in your yyy mirror. The mirror section of the error message should be included -if- the current ~/.m2/settings.xml declares a mirror. By improving the messages here we can help the users move on to building software, rather than pulling out their hair :) [1] http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-766) release:prepare stores settings.xml in a public directory
[
https://jira.codehaus.org/browse/MRELEASE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=333724#comment-333724
]
Joseph Walton commented on MRELEASE-766:
MRELEASE-846 talks about the {{release.properties}} file, where this issue is
specifically about a copied {{settings.xml}}. Would that fix also cover this
case?
release:prepare stores settings.xml in a public directory
-
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent
other users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3056) Dependencies should not be able to introduce repositories to the build
[
https://jira.codehaus.org/browse/MNG-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305676#comment-305676
]
Joseph Walton commented on MNG-3056:
We're using a dependency with a repository definition that points to a URL that
no longer resolves. The workaround is to redefine that repository ID with a
real repository in our {{settings.xml}}, but it would be great to be able to
pass a flag on the command line to ensure that only the repositories defined in
our settings are used.
Dependencies should not be able to introduce repositories to the build
--
Key: MNG-3056
URL: https://jira.codehaus.org/browse/MNG-3056
Project: Maven 2 3
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 2.2.x (to be reviewed)
Reporter: Wendy Smoak
Assignee: Jason van Zyl
Fix For: Issues to be reviewed for 3.x
If you depend on an artifact that has repositories or pluginRepositories
defined in the pom, those repositories are also searched for artifacts.
It's disconcerting when you think you've overridden 'central' and set things
up to use only internal repositories, and Maven still tries to to download
artifacts from elsewhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-361) dependency:tree's use of version selected from constraint is too verbose
[
https://jira.codehaus.org/browse/MDEP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305113#comment-305113
]
Joseph Walton commented on MDEP-361:
Yes, confirming that the change fixes this issue for me, and also shows the
constraint when it's a range. Thanks.
dependency:tree's use of version selected from constraint is too verbose
--
Key: MDEP-361
URL: https://jira.codehaus.org/browse/MDEP-361
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joseph Walton
Assignee: Herve Boutemy
Attachments:
0001-MDEP-361-Only-print-versions-that-differ-from-their-.patch
MDEP-339's fix increases the level of verbosity in the dependency tree to
include the specified constraint as well as the actual version. In many
builds, these will be identical.
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
The format change makes diffing the old and new versions difficult to see
what behaviour has changed. In the case where the constraint is the same as
the version it doesn't seem to add much information.
I'd suggest omitting it when the version exactly matches the constraint.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-361) dependency:tree's use of version selected from constraint is too verbose
Joseph Walton created MDEP-361:
--
Summary: dependency:tree's use of version selected from
constraint is too verbose
Key: MDEP-361
URL: https://jira.codehaus.org/browse/MDEP-361
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joseph Walton
MDEP-339's fix increases the level of verbosity in the dependency tree to
include the specified constraint as well as the actual version. In many builds,
these will be identical.
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from 2.4;
version selected from constraint 2.4)
{noformat}
The format change makes diffing the old and new versions difficult to see what
behaviour has changed. In the case where the constraint is the same as the
version it doesn't seem to add much information.
I'd suggest omitting it when the version exactly matches the constraint.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-361) dependency:tree's use of version selected from constraint is too verbose
[
https://jira.codehaus.org/browse/MDEP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MDEP-361:
---
Attachment: 0001-MDEP-361-Only-print-versions-that-differ-from-their-.patch
This patch omits the constraint when identical to the resolved version. In
testing with Maven 3, they were identical even when the POM specified a range.
dependency:tree's use of version selected from constraint is too verbose
--
Key: MDEP-361
URL: https://jira.codehaus.org/browse/MDEP-361
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joseph Walton
Attachments:
0001-MDEP-361-Only-print-versions-that-differ-from-their-.patch
MDEP-339's fix increases the level of verbosity in the dependency tree to
include the specified constraint as well as the actual version. In many
builds, these will be identical.
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
The format change makes diffing the old and new versions difficult to see
what behaviour has changed. In the case where the constraint is the same as
the version it doesn't seem to add much information.
I'd suggest omitting it when the version exactly matches the constraint.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-362) dependency:tree report switches managed scope and version
[
https://jira.codehaus.org/browse/MDEP-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MDEP-362:
---
Attachment: 0002-MDEP-362-Report-managed-scope-and-version-changes-co.patch
dependency:tree report switches managed scope and version
-
Key: MDEP-362
URL: https://jira.codehaus.org/browse/MDEP-362
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 2.5
Reporter: Joseph Walton
Attachments:
0002-MDEP-362-Report-managed-scope-and-version-changes-co.patch
The dependency:tree report switches scope and version when reporting managed
changes:
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
instead of
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (version managed from
2.4; version selected from constraint 2.4)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-362) dependency:tree report switches managed scope and version
Joseph Walton created MDEP-362:
--
Summary: dependency:tree report switches managed scope and version
Key: MDEP-362
URL: https://jira.codehaus.org/browse/MDEP-362
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 2.5
Reporter: Joseph Walton
The dependency:tree report switches scope and version when reporting managed
changes:
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from 2.4;
version selected from constraint 2.4)
{noformat}
instead of
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (version managed from
2.4; version selected from constraint 2.4)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-334) Patch to make additionalDependencies easier
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MJAVADOC-334:
---
Attachment: MJAVADOC-334.patch
Adding a new class doesn't seem to be necessary now that config parsing
considers the generic type of collections
([SISU-60|https://issues.sonatype.org/browse/SISU-60]?), so I'm attaching a
patch without that change, but which fixes the spelling for the mojo and for
its integration tests.
Patch to make additionalDependencies easier
-
Key: MJAVADOC-334
URL: https://jira.codehaus.org/browse/MJAVADOC-334
Project: Maven 2.x Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.8.1
Reporter: Ben Speakmon
Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
This patch corrects the spelling of {{additionalDependencies}} and adds the
wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
allows us to declare {{additionalDependency}} without also requiring us to
use the {{implementation}} attribute to manually specify
{{org.apache.maven.model.Dependency}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-728) The commit message for release:branch is wrong
[
https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302156#comment-302156
]
Joseph Walton commented on MRELEASE-728:
You're right, the current behaviour doesn't match the original report exactly,
but I think it's correct.
By default, there is no commit in the new branch - it keeps the same version as
the original branch. The commit message in the original branch is:
{noformat}
[maven-release-plugin] prepare for next development iteration
{noformat}
Which is what you want in a branch-for-release workflow. If you use
{{updateBranchVersions}} then you end up with:
||commit||branch||commit message||
|3|master|[maven-release-plugin] prepare for next development iteration|
|2|new-branch|[maven-release-plugin] prepare branch new-branch|
|1| |[maven-release-plugin] prepare for next development iteration|
The unnecessary commit in master is due to MRELEASE-729, but I think the
messages are fine.
The commit message for release:branch is wrong
--
Key: MRELEASE-728
URL: https://jira.codehaus.org/browse/MRELEASE-728
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch, Git
Affects Versions: 2.2.1
Environment: git 1.7.5.4
Reporter: Adrien Ragot
Assignee: Robert Scholte
Fix For: 2.3
Using Git, when you do mvn release:branch -DbranchName=xxx,
the commit message for master is [maven-release-plugin] prepare release xxx.
The right commit message should be [maven-release-plugin] prepare branch
xxx, like for Svn.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories conflict
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MNG-5185:
---
Attachment: 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
Aether doesn't make it easy to expose this information back to Maven. I've
attached a simple patch to Sonatype Aether to log when this is encountered.
Improve missing dependency error message when _maven.repositories conflict
Key: MNG-5185
URL: https://jira.codehaus.org/browse/MNG-5185
Project: Maven 2 3
Issue Type: Improvement
Reporter: Mark Derricutt
Attachments:
0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
Based on a discussion on the users list [1], Maven 3 has changed how it
resolves artifacts from custom repositories. Unfortunately, when conflicts
arise ( GAV is in local repo, but POM has no matching repository id declared
) Maven just tells the user that the artifact could not be resolved.
This leads to confusion from users who find the .jar files in their local
repository, and they just get frustrated and complain that maven sucks.
It would be good if Maven was updated with some improved error messages along
the lines of:
The {GAV} artifact was found in your local repository, but came from the
undeclared repository xxx, either configure this in your pom with {insert
sample XML block in error message}, or in your yyy mirror.
The mirror section of the error message should be included -if- the current
~/.m2/settings.xml declares a mirror. By improving the messages here we can
help the users move on to building software, rather than pulling out their
hair :)
[1]
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[ https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton updated MSHADE-103: - Attachment: 0001-MSHADE-103-Use-the-ProjectBuilder-API-to-include-rem.patch Maven 3's ProjectBuilder API makes it possible to pass in the remote repositories: the attached patch works with Maven 3. Of course, this breaks compatibility with Maven 2. The difficulty, and value, of maintaining a dual Maven 2/Maven 3 plugin is a topic for discussion. maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3, 1.4 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc Attachments: 0001-MSHADE-103-Use-the-ProjectBuilder-API-to-include-rem.patch, MSHADE-103.tar.gz maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] - [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-728) The commit message for release:branch is wrong
[ https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301117#comment-301117 ] Joseph Walton commented on MRELEASE-728: This is fixed by [r1326398|https://svn.apache.org/viewvc?view=revisionrevision=1326398], for MRELEASE-745, in 2.3. The commit message for release:branch is wrong -- Key: MRELEASE-728 URL: https://jira.codehaus.org/browse/MRELEASE-728 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch, Git Affects Versions: 2.2.1 Environment: git 1.7.5.4 Reporter: Adrien Ragot Using Git, when you do mvn release:branch -DbranchName=xxx, the commit message for master is [maven-release-plugin] prepare release xxx. The right commit message should be [maven-release-plugin] prepare branch xxx, like for Svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-211) @Mojo annotations aren't inherited
Joseph Walton created MPLUGIN-211: - Summary: @Mojo annotations aren't inherited Key: MPLUGIN-211 URL: https://jira.codehaus.org/browse/MPLUGIN-211 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-tools-annotations Affects Versions: 3.0 Reporter: Joseph Walton Priority: Trivial We have a project where a mojo defined in one plugin module is inherited from in another. With Javadoc-style markup, the child class is also declared as an mojo. With @Mojo, the child class needs to re-declare @Mojo in order to be included in the plugin definition. I'm reporting this as 'trivial' priority. I've fixed it by copying those @Mojo annotations across. I wouldn't have a problem with WONTFIXing this. I think the new behaviour is clearer, and I'm not convinced that the previous behaviour was intentional or desirable. However, it is still a change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-211) @Mojo annotations aren't inherited
[ https://jira.codehaus.org/browse/MPLUGIN-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton closed MPLUGIN-211. - Resolution: Not A Bug Apologies for the mistake - this was a migration from Anno Mojo to maven-plugin-tools-annotations, not from Javadoc. There's no need to duplicate their behaviour. @Mojo annotations aren't inherited -- Key: MPLUGIN-211 URL: https://jira.codehaus.org/browse/MPLUGIN-211 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-tools-annotations Affects Versions: 3.0 Reporter: Joseph Walton Priority: Trivial We have a project where a mojo defined in one plugin module is inherited from in another. With Javadoc-style markup, the child class is also declared as an mojo. With @Mojo, the child class needs to re-declare @Mojo in order to be included in the plugin definition. I'm reporting this as 'trivial' priority. I've fixed it by copying those @Mojo annotations across. I wouldn't have a problem with WONTFIXing this. I think the new behaviour is clearer, and I'm not convinced that the previous behaviour was intentional or desirable. However, it is still a change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300169#comment-300169
]
Joseph Walton commented on MSHADE-103:
--
If, after a failed build, I remove the {{_maven.repositories}} file from the
local repository then the build succeeds. Looks like MNG-5185 would make this
clearer.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300169#comment-300169
]
Joseph Walton edited comment on MSHADE-103 at 6/1/12 2:33 AM:
--
If, after a failed build, I remove the {{_maven.repositories}} file from the
local repository then the build succeeds. The call to
{{mavenProjectBuilder.build}} only knows about the local repository but the
artifact is specifically tagged as coming from the alternate remote repo.
Looks like MNG-5185 would make this clearer.
was (Author: joewalton):
If, after a failed build, I remove the {{_maven.repositories}} file from
the local repository then the build succeeds. Looks like MNG-5185 would make
this clearer.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-766) release:prepare stores settings.xml in a public directory
[
https://jira.codehaus.org/browse/MRELEASE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300153#comment-300153
]
Joseph Walton commented on MRELEASE-766:
I've seen it happening. It's possible that the build was hung, rather than
failed, so it hadn't cleaned up. It's also possible that the JVM was killed.
But while this finally block will reduce the window the file is public for it
won't eliminate it, so I think there's room for an improvement here.
release:prepare stores settings.xml in a public directory
-
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent
other users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[ https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=39#comment-39 ] Joseph Walton edited comment on MSHADE-103 at 6/1/12 12:23 AM: --- -This doesn't seem to occur with Maven 3.0.4. Could it be due to- MNG-5149 -or- MNG-5224? Sorry, I'm still seeing this with 3.0.4. was (Author: joewalton): This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149 or MNG-5224? maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3, 1.4 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] - [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MSHADE-103:
-
Attachment: MSHADE-103.tar.gz
I have a case where the remote repository is a local directory and the local
repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300161#comment-300161
]
Joseph Walton edited comment on MSHADE-103 at 6/1/12 12:34 AM:
---
I have a case where the remote repository is a local directory and the local
repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds. Shading also succeeds when createDependencyReducedPom is set to false.
was (Author: joewalton):
I have a case where the remote repository is a local directory and the
local repository is configured to keep the build isolated.
In MSHADE-103.tar.gz, with {{settings.xml}} configured with local paths:
{code}
mvn3 --settings settings.xml clean package
{code}
fails to find the parent pom even though it's already in the configured local
repository.
The dependency is an arbitrary choice of jar. If it's removed then the shading
succeeds.
maven-shade-plugin does not resolve from user-defined repositories
--
Key: MSHADE-103
URL: https://jira.codehaus.org/browse/MSHADE-103
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.3.3, 1.4
Environment: Maven 3.0.3 (works with 2.2.1)
Reporter: Lukas Fryc
Attachments: MSHADE-103.tar.gz
maven-shade-plugin doesn't consult repositories defined in
settings.xml when trying to resolve parents of given pom. It contacts
only central repo:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
project richfaces-components-api: Error creating shaded jar: 1 problem
was encountered while building the effective model for
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
[ERROR] [FATAL] Non-resolvable parent POM for
org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
org.richfaces:richfaces-parent:pom:10 in central
(http://repo1.maven.org/maven2) and 'parent.relativePath' points at
wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
/home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
[ERROR] for project
org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
/home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
[ERROR] - [Help 1]
There is affected project (it references version 1.3.3, but the behavior is
same with 1.4) if you would like to try at own:
https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[ https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=39#comment-39 ] Joseph Walton commented on MSHADE-103: -- This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149? maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3, 1.4 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] - [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories
[ https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=39#comment-39 ] Joseph Walton edited comment on MSHADE-103 at 5/30/12 4:25 AM: --- This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149 or MNG-5224? was (Author: joewalton): This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149? maven-shade-plugin does not resolve from user-defined repositories -- Key: MSHADE-103 URL: https://jira.codehaus.org/browse/MSHADE-103 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.3.3, 1.4 Environment: Maven 3.0.3 (works with 2.2.1) Reporter: Lukas Fryc maven-shade-plugin doesn't consult repositories defined in settings.xml when trying to resolve parents of given pom. It contacts only central repo: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project richfaces-components-api: Error creating shaded jar: 1 problem was encountered while building the effective model for org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT [ERROR] [FATAL] Non-resolvable parent POM for org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact org.richfaces:richfaces-parent:pom:10 in central (http://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 [ERROR] for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml [ERROR] - [Help 1] There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own: https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-766) release:prepare stores settings.xml in a public directory
Joseph Walton created MRELEASE-766:
--
Summary: release:prepare stores settings.xml in a public directory
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent other
users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-206) Annotations in superclasses are not found if an intermediate class is not annotated
[ https://jira.codehaus.org/browse/MPLUGIN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=299862#comment-299862 ] Joseph Walton commented on MPLUGIN-206: --- Thanks, that fix is working for me. Nice work on the annotations. Annotations in superclasses are not found if an intermediate class is not annotated --- Key: MPLUGIN-206 URL: https://jira.codehaus.org/browse/MPLUGIN-206 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-annotations Affects Versions: 3.0 Reporter: Joseph Walton Assignee: Olivier Lamy Fix For: 3.0 My concrete mojo class extends an intermediate class which in turn extends an abstract mojo that defines parameters. Those parameters aren't being picked up when inheritance is indirect. i.e., * A: Defines a @Parameter paramA * B extends A * C extends B, defines @Parameter paramC C's results only includes paramC. Adding a dummy @Parameter to B means C sees parameters from all three classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-205) @Mojo in maven-plugin-annotations does not use the specified value of requiresProject
Joseph Walton created MPLUGIN-205:
-
Summary: @Mojo in maven-plugin-annotations does not use the
specified value of requiresProject
Key: MPLUGIN-205
URL: https://jira.codehaus.org/browse/MPLUGIN-205
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.0
Reporter: Joseph Walton
A mojo defined as:
{noformat}
@Mojo(name = sample, requiresProject = false)
public class SampleMojo extends AbstractMojo
{noformat}
still indicates that it requires a project in the generated plugin descriptor:
{noformat}
requiresProjecttrue/requiresProject
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-205) @Mojo in maven-plugin-annotations does not use the specified value of requiresProject
[
https://jira.codehaus.org/browse/MPLUGIN-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MPLUGIN-205:
--
Attachment: MPLUGIN-205.diff
@Mojo in maven-plugin-annotations does not use the specified value of
requiresProject
-
Key: MPLUGIN-205
URL: https://jira.codehaus.org/browse/MPLUGIN-205
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.0
Reporter: Joseph Walton
Attachments: MPLUGIN-205.diff
A mojo defined as:
{noformat}
@Mojo(name = sample, requiresProject = false)
public class SampleMojo extends AbstractMojo
{noformat}
still indicates that it requires a project in the generated plugin descriptor:
{noformat}
requiresProjecttrue/requiresProject
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-206) Annotations in superclasses are not found if an intermediate class is not annotated
Joseph Walton created MPLUGIN-206: - Summary: Annotations in superclasses are not found if an intermediate class is not annotated Key: MPLUGIN-206 URL: https://jira.codehaus.org/browse/MPLUGIN-206 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-annotations Affects Versions: 3.0 Reporter: Joseph Walton My concrete mojo class extends an intermediate class which in turn extends an abstract mojo that defines parameters. Those parameters aren't being picked up when inheritance is indirect. i.e., * A: Defines a @Parameter paramA * B extends A * C extends B, defines @Parameter paramC C's results only includes paramC. Adding a dummy @Parameter to B means C sees parameters from all three classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-206) Annotations in superclasses are not found if an intermediate class is not annotated
[
https://jira.codehaus.org/browse/MPLUGIN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=299855#comment-299855
]
Joseph Walton commented on MPLUGIN-206:
---
Looks like {{DefaultMojoAnnotationsScanner}} gathers all the classes in the
project that use annotations and
{{JavaAnnotationsMojoDescriptorExtractor#getParametersParent}} later relies on
this being an exhaustive record.
If the missing parent class is {{AbstractMojo}} then that's expected to be
missing from the project, but anything else suggests that something is missing
from the hierarchy. Maybe this should be an error? I'd have found a build error
less surprising than missing parameters.
Annotations in superclasses are not found if an intermediate class is not
annotated
---
Key: MPLUGIN-206
URL: https://jira.codehaus.org/browse/MPLUGIN-206
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.0
Reporter: Joseph Walton
My concrete mojo class extends an intermediate class which in turn extends an
abstract mojo that defines parameters. Those parameters aren't being picked
up when inheritance is indirect.
i.e.,
* A: Defines a @Parameter paramA
* B extends A
* C extends B, defines @Parameter paramC
C's results only includes paramC.
Adding a dummy @Parameter to B means C sees parameters from all three classes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-193) Allow for generic parameter types in plugin.xml
Joseph Walton created MPLUGIN-193:
-
Summary: Allow for generic parameter types in plugin.xml
Key: MPLUGIN-193
URL: https://jira.codehaus.org/browse/MPLUGIN-193
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 2.9
Reporter: Joseph Walton
Anno Mojo generates a {{plugin.xml}} that includes generic parameter types.
This causes {{PluginXdocGenerator}} to generate non-well-formed XML in one case
and an unclear description in another, so {{site}} fails.
Without a clear specification of whether generics are permitted or not, it
would be better to deal with them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-193) Allow for generic parameter types in plugin.xml
[
https://jira.codehaus.org/browse/MPLUGIN-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297498#comment-297498
]
Joseph Walton commented on MPLUGIN-193:
---
A patch by [~bspeakmon] is here for both cases:
https://bitbucket.org/jwalton/maven-plugin-tools/changeset/82fa6eb01f95 .
Allow for generic parameter types in plugin.xml
---
Key: MPLUGIN-193
URL: https://jira.codehaus.org/browse/MPLUGIN-193
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 2.9
Reporter: Joseph Walton
Anno Mojo generates a {{plugin.xml}} that includes generic parameter types.
This causes {{PluginXdocGenerator}} to generate non-well-formed XML in one
case and an unclear description in another, so {{site}} fails.
Without a clear specification of whether generics are permitted or not, it
would be better to deal with them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-577) release:prepare does not pass argument --settings with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296187#comment-296187 ] Joseph Walton commented on MRELEASE-577: This change seems to publish the passwords from a private settings.xml into a world-readable file in /tmp during a build. release:prepare does not pass argument --settings with current settings.xml to inner maven Key: MRELEASE-577 URL: https://jira.codehaus.org/browse/MRELEASE-577 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9, 2.0 Reporter: Petr Kozelka Assignee: Stephen Connolly Priority: Critical Labels: contributers-welcome Fix For: 2.2.2 The impact is that release:prepare tries to use $HOME/.m2/settings.xml instead of the one supplied by --settings cmdline option, which leads to unexpected behavior Of course if it does not exist, the inhouse repository is avoided and release often fails due to a ResourceDoesNotExistException when an inhouse artifact is requested by the pom. To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml and run this: mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-577) release:prepare does not pass argument --settings with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=296189#comment-296189 ] Joseph Walton commented on MRELEASE-577: Note that this change will *not* work in Maven 3.0.3 due to MNG-5224. release:prepare does not pass argument --settings with current settings.xml to inner maven Key: MRELEASE-577 URL: https://jira.codehaus.org/browse/MRELEASE-577 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9, 2.0 Reporter: Petr Kozelka Assignee: Stephen Connolly Priority: Critical Labels: contributers-welcome Fix For: 2.2.2 The impact is that release:prepare tries to use $HOME/.m2/settings.xml instead of the one supplied by --settings cmdline option, which leads to unexpected behavior Of course if it does not exist, the inhouse repository is avoided and release often fails due to a ResourceDoesNotExistException when an inhouse artifact is requested by the pom. To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml and run this: mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MASSEMBLY-595:
Attachment: 0001-MASSEMBLY-595-Upgrade-to-pick-up-PLXCOMP-196-and-PLX.patch
Now fixed in PLXCOMP. Upgrade to 2.0.2 to pick up the fixes.
Tar file contains world-writeable files when fileSets with and without
fileMode are mixed
-
Key: MASSEMBLY-595
URL: https://jira.codehaus.org/browse/MASSEMBLY-595
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Joseph Walton
Attachments:
0001-MASSEMBLY-595-Upgrade-to-pick-up-PLXCOMP-196-and-PLX.patch,
MASSEMBLY-595.tar.gz
I have an assembly descriptor with some fileSets that do and some that don't
set the fileMode. Any resources after fileMode has been set end up with
world-writable permissions.
This assembly descriptor:
{code}
assembly
iddist/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/files/directory
outputDirectorya/outputDirectory
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryb/outputDirectory
fileMode0744/fileMode
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryc/outputDirectory
/fileSet
/fileSets
/assembly
{code}
gives:
{code}
$ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
-rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
-rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
-rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
{code}
The third copy of the fileSet, with no {{fileMode}} set, is now
world-writable, unlike the first. The second directory, with no
{{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-728) The commit message for release:branch is wrong
[ https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289107#comment-289107 ] Joseph Walton commented on MRELEASE-728: It looks like svn uses 'prepare for next development iteration' for the commit that bumps the trunk version; git refers to it as a release. The commit message for release:branch is wrong -- Key: MRELEASE-728 URL: https://jira.codehaus.org/browse/MRELEASE-728 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.2.1 Environment: git 1.7.5.4 Reporter: Adrien Ragot Using Git, when you do mvn release:branch -DbranchName=xxx, the commit message for master is [maven-release-plugin] prepare release xxx. The right commit message should be [maven-release-plugin] prepare branch xxx, like for Svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-729) release:branch makes pom changes for branch in 'master' before branching
Joseph Walton created MRELEASE-729:
--
Summary: release:branch makes pom changes for branch in 'master'
before branching
Key: MRELEASE-729
URL: https://jira.codehaus.org/browse/MRELEASE-729
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git
Affects Versions: 2.2.2
Reporter: Joseph Walton
{{release:branch}} makes the change for the branch version before branching.
This means the version change is seen in the trunk's history.
If master is currently '1-SNAPSHOT':
{code}
* 1-SNAPSHOT [master]
{code}
and I create a new 'branch-with-hacks' branch as '1.hacks-SNAPSHOT' then I'll
see this in my log:
{code}
* 1-SNAPSHOT [master]
|
* 1.hacks-SNAPSHOT [branch-with-hacks]
|
* 1-SNAPSHOT
{code}
with a commit and a revert on master where I would expect:
{code}
* 1.hacks-SNAPSHOT [branch-with-hacks]
|
* 1-SNAPSHOT [master]
{code}
with 'master' remaining unaffected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
Joseph Walton created MASSEMBLY-595:
---
Summary: Tar file contains world-writeable files when fileSets
with and without fileMode are mixed
Key: MASSEMBLY-595
URL: https://jira.codehaus.org/browse/MASSEMBLY-595
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Joseph Walton
I have an assembly descriptor with some fileSets that do and some that don't
set the fileMode. Any resources after fileMode has been set end up with
world-writable permissions.
This assembly descriptor:
{code}
assembly
iddist/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/files/directory
outputDirectorya/outputDirectory
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryb/outputDirectory
fileMode0744/fileMode
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryc/outputDirectory
/fileSet
/fileSets
/assembly
{code}
gives:
{code}
$ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
-rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
-rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
-rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
{code}
The third copy of the fileSet, with no {{fileMode}} set, is now world-writable,
unlike the first. The second directory, with no {{directoryMode}} specified,
has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MASSEMBLY-595:
Attachment: MASSEMBLY-595.tar.gz
Tar file contains world-writeable files when fileSets with and without
fileMode are mixed
-
Key: MASSEMBLY-595
URL: https://jira.codehaus.org/browse/MASSEMBLY-595
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Joseph Walton
Attachments: MASSEMBLY-595.tar.gz
I have an assembly descriptor with some fileSets that do and some that don't
set the fileMode. Any resources after fileMode has been set end up with
world-writable permissions.
This assembly descriptor:
{code}
assembly
iddist/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/files/directory
outputDirectorya/outputDirectory
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryb/outputDirectory
fileMode0744/fileMode
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryc/outputDirectory
/fileSet
/fileSets
/assembly
{code}
gives:
{code}
$ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
-rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
-rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
-rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
{code}
The third copy of the fileSet, with no {{fileMode}} set, is now
world-writable, unlike the first. The second directory, with no
{{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287571#comment-287571
]
Joseph Walton commented on MASSEMBLY-595:
-
Caused by [PLXCOMP-196|https://jira.codehaus.org/browse/PLXCOMP-196] and
[PLXCOMP-197|https://jira.codehaus.org/browse/PLXCOMP-197].
Tar file contains world-writeable files when fileSets with and without
fileMode are mixed
-
Key: MASSEMBLY-595
URL: https://jira.codehaus.org/browse/MASSEMBLY-595
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Joseph Walton
Attachments: MASSEMBLY-595.tar.gz
I have an assembly descriptor with some fileSets that do and some that don't
set the fileMode. Any resources after fileMode has been set end up with
world-writable permissions.
This assembly descriptor:
{code}
assembly
iddist/id
formats
formattar.gz/format
/formats
fileSets
fileSet
directorysrc/main/files/directory
outputDirectorya/outputDirectory
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryb/outputDirectory
fileMode0744/fileMode
/fileSet
fileSet
directorysrc/main/files/directory
outputDirectoryc/outputDirectory
/fileSet
/fileSets
/assembly
{code}
gives:
{code}
$ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
-rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
-rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
-rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
{code}
The third copy of the fileSet, with no {{fileMode}} set, is now
world-writable, unlike the first. The second directory, with no
{{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-590) Upgrade plexus dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MASSEMBLY-590:
Attachment: MASSEMBLY-590.diff
Upgrade plexus dependencies
---
Key: MASSEMBLY-590
URL: https://jira.codehaus.org/browse/MASSEMBLY-590
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Reporter: Odd Vinje
Attachments: MASSEMBLY-590.diff
The plexus dependencies used internally are outdated. There are major issues
with plexus-io version 1.x (one example:
http://jira.codehaus.org/browse/PLXCOMP-149)
The assembly plugin uses plexus-io 1.0.1, but the latest is 2.0.1.
{code}
[INFO] --- maven-assembly-plugin:2.2.1:single (attach-artifacts) ---
[DEBUG]org.codehaus.plexus:plexus-io:jar:1.0.1:compile
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-126) requirePluginVersions misreports plugins with artifactIds defined through properties
Joseph Walton created MENFORCER-126:
---
Summary: requirePluginVersions misreports plugins with artifactIds
defined through properties
Key: MENFORCER-126
URL: https://jira.codehaus.org/browse/MENFORCER-126
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Joseph Walton
Priority: Minor
When a plugin artifact is defined through a property:
{code}
properties
plugin.namemaven-enforcer-plugin/plugin.name
/properties
...
build
plugins
plugin
artifactId${plugin.name}/artifactId
version1/version
/plugin
/plugins
/build
{code}
then {{requirePluginVersions}} will complain about a missing valid version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-486) Support signed tags for git when releasing
[
https://jira.codehaus.org/browse/SCM-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated SCM-486:
--
Attachment: SCM-486_sign_git_tags.diff
Enabled signing Git tags when {{-Dmaven.scm.gitexe.sign_tags}} is passed on the
command line.
Support signed tags for git when releasing
--
Key: SCM-486
URL: https://jira.codehaus.org/browse/SCM-486
Project: Maven SCM
Issue Type: Wish
Components: maven-scm-provider-git
Reporter: Chris Searle
Attachments: SCM-486_sign_git_tags.diff
When tagging the release - it would be nice if the git plugin for scm allowed
for an annotated and signed tag rather than just an annotated tag.
If this is already possible then either I need a pointer to the correct doc
;) (or it would be nice if the doc covered how to configure it).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4733) project.build.directory should be settable by default
project.build.directory should be settable by default
-
Key: MNG-4733
URL: http://jira.codehaus.org/browse/MNG-4733
Project: Maven 2 3
Issue Type: Improvement
Components: Apache or Maven Parent poms
Affects Versions: 2.2.1
Reporter: Joseph Walton
Priority: Minor
Attachments: target-dir.diff
I'd like to be able to use a different target directory for projects without
having to edit their poms directly. I can set project.build.directory in my
parent pom but would also like to be able to make the change when building
third-party projects.
I have two use cases.
1. A temporary build that doesn't affect the target directories used by Eclipse
e.g. mvn -Dtarget.dir=target.tmp test
2. A complete build outside the source tree of a multi-module project
e.g. mvn -Dtarget.dir=/tmp/build/\${project.artifactId} test
I attach a simple patch to the superpom that allows this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
