[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359189#comment-359189
]
Kristian Rosenvold commented on MSHARED-394:
You make a compelling argument for a combined solution and basically use
content-based copying/filtering for the velocity templates. If you want to have
a shot at changing *just* the Velocity generation to use such an algorithm I'll
happily review this; I want to do the interpolation stuff as a christmas hack
:) If you you switch to using MavenReaderFilter instead of MavenFileFilter you
should be able to solve such an issue entirely within resources-plugin. Take a
look at ReaderFormatter.java in assembly plugin for inspiration.
DeferredFileOutputStream from commons-io would probably be a nice thing to use
so you can keep the transformed output in memory until it reaches a given
maxsize. I seem to remember we also use that in assembly :) If we need to move
bits of your change elsewhere later we can look at this when you finish :)
I'm still pondering this a bit. One one hand we have a fixed set of templates
that have known interpolation requirements. Rather than solving the general
problem of any Velocity inteprolation, we could just solve the *specific*
problem of interpolating the few specific ones we know to be used and delegate
the generic problem elsewhere. So we might still be able to go for some kind
of combined strategy (Thinking thinking...)
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359190#comment-359190
]
Kristian Rosenvold commented on MSHARED-394:
Looking at the code I am not even sure if filtering is applied to velocity
templates after being evaluated by velocity. Finding this out would be a nice
place to start. If thay aren't then things are a lot simpler :)
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359191#comment-359191
]
Vladimir Sitnikov commented on MSHARED-394:
---
Well, I thought Velocity is somewhere inside maven-filtering.
I did a double-check and it turns out the offending velocity is inside
maven-remote-resources-plugin.
I'll file a pull request there.
However, the improvement to properties filtering still makes sense.
For resource-based filtering, you'll have hard time caching input properties
for reader-based filtering.
It does not contain file name, thus you can't tell if the source was modified
or not.
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-394) Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when producing the same contents
[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359194#comment-359194
]
Vladimir Sitnikov commented on MSHARED-394:
---
This https://github.com/apache/maven-plugins/pull/40 solves DEPENDENCIES,
LICENSE, NOTICE being overwritten.
However the following properties resource file triggers jar rebuild:
{noformat}
driver.name=Calcite JDBC Driver
driver.version=${pom.version}
product.name=Calcite
product.version=${pom.version}{noformat}
So, technically, some kind of smart maven-filtering is required.
Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
producing the same contents
--
Key: MSHARED-394
URL: https://jira.codehaus.org/browse/MSHARED-394
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Vladimir Sitnikov
Assignee: Kristian Rosenvold
See relevant MRESOURCES-168.
When processing filtered resources, maven-filtering always overwrites
destination files, leading to rebuild of the upstream results (e.g. jar file
being repackaged due to DEBUG] isUp2date: false (Resource with newer
modification date found.)).
I think maven-filtering can do better job here: it can double-check if the
resource contents after filtering is equal to the contents of the existing
file, then it should avoid overwrite of the destination file.
The change would be localized in
{{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
{code:java}
private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
String encoding, @Nullable ListFilterWrapper wrappers) throws IOException,
MavenFilteringException {
if(wrappers != null wrappers.size() 0) {
Reader fileReader = null;
Writer fileWriter = null;
try {
fileReader = this.getFileReader(encoding, from);
fileWriter = this.getFileWriter(encoding, to); // Here
temporary buffer should be used to avoid accidental file overwrite
Reader src = this.readerFilter.filter(fileReader, true,
wrappers);
IOUtil.copy(src, fileWriter);
} finally {
IOUtil.close(fileReader);
IOUtil.close(fileWriter);
}
} else if(to.lastModified() from.lastModified()) {
FileUtils.copyFile(from, to);
}
}{code}
The change would require to buffer the contents in memory, thus it might lead
to OutOfMemory errors. I suggest disabling this buffering if the size of the
source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRRESOURCES-91) Avoid overwrite of the destination file if the produced contents is the same
Vladimir Sitnikov created MRRESOURCES-91: Summary: Avoid overwrite of the destination file if the produced contents is the same Key: MRRESOURCES-91 URL: https://jira.codehaus.org/browse/MRRESOURCES-91 Project: Maven Remote Resources Plugin Issue Type: Bug Affects Versions: 1.5 Reporter: Vladimir Sitnikov maven-remote-resource-plugin is used in Apache pom to add DEPENDENCIES, and the resulting file is overwritten on each build. It leads to jar being rebuild, etc leading to longer compilation times. I suggest to compare the produced contents with the existing file. If both are equal, skip the file being overwritten. The net win is subsequent build times are improved. Here's pull request that fixes the problem: https://github.com/apache/maven-plugins/pull/40 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
Andy Wilkinson created MNG-5737:
---
Summary: Adding a test dependency can move dependencies from the
compile scope to the test scope
Key: MNG-5737
URL: https://jira.codehaus.org/browse/MNG-5737
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.3
Reporter: Andy Wilkinson
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of the
hierarchy wins and, for a number of the Jetty dependencies, the shortest route
is via the test-scoped {{org.apache.solr:sole-core}}. I can understand a
test-scoped dependency being upgraded to the compile scope when a dependency is
added, but downgrading a dependency from the compile scope to the test scope
feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on the
transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MNG-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated MNG-5737:
Description:
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of the
hierarchy wins and, for a number of the Jetty dependencies, the shortest route
is via the test-scoped {{org.apache.solr:sole-core}}. I can understand a
test-scoped dependency being upgraded to the compile scope when a dependency is
added, but downgrading a dependency from the compile scope to the test scope
feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on the
transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
was:
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+-
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MNG-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll updated MNG-5737:
-
Attachment: pom.xml
{{mvn dependency:list}} on that project shows a set of jetty dependencies in
{{test}} scope (such as {{jetty-security}} and {{jetty-deploy}}
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MNG-5737
URL: https://jira.codehaus.org/browse/MNG-5737
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.3
Reporter: Andy Wilkinson
Attachments: pom.xml
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5737) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MNG-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359209#comment-359209
]
Stéphane Nicoll edited comment on MNG-5737 at 12/17/14 8:30 AM:
{{mvn dependency:list}} on that project shows {{jetty-security}} in {{test}}
scope. If the {{solr}} dependency is commented out, that same artifact is
resolved with the {{compile}} scope.
was (Author: sni):
{{mvn dependency:list}} on that project shows a set of jetty dependencies in
{{test}} scope (such as {{jetty-security}} and {{jetty-deploy}}
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MNG-5737
URL: https://jira.codehaus.org/browse/MNG-5737
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.3
Reporter: Andy Wilkinson
Attachments: pom.xml
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1121) java.lang.NullPointerException org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
[
https://jira.codehaus.org/browse/SUREFIRE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359234#comment-359234
]
Francisco Lozano commented on SUREFIRE-1121:
Fix version is 2.18.1 but so far I can't find it in maven central. What's the
plan for this release?
java.lang.NullPointerException
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
-
Key: SUREFIRE-1121
URL: https://jira.codehaus.org/browse/SUREFIRE-1121
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.18
Environment: Apache Maven 3.2.3
(33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
Maven home: C:\Java\apache-maven-3.2.3
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_71\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Assignee: Tibor Digana
Priority: Blocker
Fix For: 2.18.1
Attachments: effective.pom
git clone http://git-wip-us.apache.org/repos/asf/logging-log4j2.git
Check out Log4j 2 commit {{d033a71eb0047ca35ec1582f0eab73abe3e04919}}. This
is currently the latest.
Run: {{mvn -e clean test}}
I get:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [ 0.566
s]
[INFO] Apache Log4j API ... SUCCESS [ 26.239
s]
[INFO] Apache Log4j Core .. SUCCESS [05:09
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [ 9.233
s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [ 8.507
s]
[INFO] Apache Log4j to SLF4J Adapter .. FAILURE [ 5.781
s]
[INFO] Apache Log4j Commons Logging Bridge SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 06:02 min
[INFO] Finished at: 2014-12-01T10:51:31-05:00
[INFO] Final Memory: 34M/266M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on
project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test failed.
NullPointerExc
eption - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test)
on project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-
surefire-plugin:2.18:test failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at
[jira] (SUREFIRE-1121) java.lang.NullPointerException org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
[
https://jira.codehaus.org/browse/SUREFIRE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359238#comment-359238
]
Tibor Digana commented on SUREFIRE-1121:
@Francisco
I'll make the release asap this week, but don't expect the binary immediately
since the voting process takes additional 3 days.
java.lang.NullPointerException
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
-
Key: SUREFIRE-1121
URL: https://jira.codehaus.org/browse/SUREFIRE-1121
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.18
Environment: Apache Maven 3.2.3
(33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
Maven home: C:\Java\apache-maven-3.2.3
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_71\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Assignee: Tibor Digana
Priority: Blocker
Fix For: 2.18.1
Attachments: effective.pom
git clone http://git-wip-us.apache.org/repos/asf/logging-log4j2.git
Check out Log4j 2 commit {{d033a71eb0047ca35ec1582f0eab73abe3e04919}}. This
is currently the latest.
Run: {{mvn -e clean test}}
I get:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [ 0.566
s]
[INFO] Apache Log4j API ... SUCCESS [ 26.239
s]
[INFO] Apache Log4j Core .. SUCCESS [05:09
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [ 9.233
s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [ 8.507
s]
[INFO] Apache Log4j to SLF4J Adapter .. FAILURE [ 5.781
s]
[INFO] Apache Log4j Commons Logging Bridge SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 06:02 min
[INFO] Finished at: 2014-12-01T10:51:31-05:00
[INFO] Final Memory: 34M/266M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on
project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test failed.
NullPointerExc
eption - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test)
on project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-
surefire-plugin:2.18:test failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
[jira] (SUREFIRE-1121) java.lang.NullPointerException org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
[
https://jira.codehaus.org/browse/SUREFIRE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359245#comment-359245
]
Gary Gregory commented on SUREFIRE-1121:
@Tibor: Sorry I did not reply to your test request; swamped...
java.lang.NullPointerException
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82)
-
Key: SUREFIRE-1121
URL: https://jira.codehaus.org/browse/SUREFIRE-1121
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.18
Environment: Apache Maven 3.2.3
(33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
Maven home: C:\Java\apache-maven-3.2.3
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_71\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Assignee: Tibor Digana
Priority: Blocker
Fix For: 2.18.1
Attachments: effective.pom
git clone http://git-wip-us.apache.org/repos/asf/logging-log4j2.git
Check out Log4j 2 commit {{d033a71eb0047ca35ec1582f0eab73abe3e04919}}. This
is currently the latest.
Run: {{mvn -e clean test}}
I get:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [ 0.566
s]
[INFO] Apache Log4j API ... SUCCESS [ 26.239
s]
[INFO] Apache Log4j Core .. SUCCESS [05:09
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [ 9.233
s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [ 8.507
s]
[INFO] Apache Log4j to SLF4J Adapter .. FAILURE [ 5.781
s]
[INFO] Apache Log4j Commons Logging Bridge SKIPPED
[INFO] Apache Log4j Flume Bridge .. SKIPPED
[INFO] Apache Log4j Web ... SKIPPED
[INFO] Apache Log4j Tag Library ... SKIPPED
[INFO] Apache Log4j JMX GUI ... SKIPPED
[INFO] Apache Log4j Samples ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
[INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
[INFO] Apache Log4j BOM ... SKIPPED
[INFO] Apache Log4j NoSQL . SKIPPED
[INFO] Apache Log4J Performance Tests . SKIPPED
[INFO] Apache Log4j Streaming Interface ... SKIPPED
[INFO] Apache Log4j JUL Adapter ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 06:02 min
[INFO] Finished at: 2014-12-01T10:51:31-05:00
[INFO] Final Memory: 34M/266M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on
project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test failed.
NullPointerExc
eption - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test)
on project log4j-to-slf4j: Execution default-test of goal
org.apache.maven.plugins:maven-
surefire-plugin:2.18:test failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-5737 to MDEP-475:
--
Complexity: (was: Intermediate)
Component/s: (was: Dependencies)
tree
Affects Version/s: (was: 3.2.3)
Key: MDEP-475 (was: MNG-5737)
Project: Maven Dependency Plugin (was: Maven)
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359247#comment-359247
]
Robert Scholte commented on MDEP-475:
-
Moved to {{maven-dependency-plugin}}. It is a presentation problem of this
plugin, not a Maven core one. IIRC such as issue has already been fixed, so
please try to call {{mvn
org.apache.maven.plugins:maven-dependency-plugin:2.9:tree}} to ensure you're
using the latest version and verify the result.
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359248#comment-359248 ] Robert Scholte commented on MJAVADOC-384: - Yes, now I'm only missing the unittests... Allow whitespace in javadoc exclude list Key: MJAVADOC-384 URL: https://jira.codehaus.org/browse/MJAVADOC-384 Project: Maven Javadoc Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Omair Majid Priority: Minor Attachments: spaces-for-javadoc-exclude-02.patch, spaces-for-javadoc-exclude-list One of the projects that I am working on has a fairly large exclude list for javadoc packages. maven-javadoc-plugin requires me to put this in on line in the pom, which makes it very hard to read. I think it would be nicer to allow separating the items in the list with newlines and other whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Wilkinson updated MDEP-475:
Attachment: test-scope-problem.zip
I think it's more than a presentation problem. The attached project will fail
to compile due to the `org.eclipse.jetty.server` package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml, test-scope-problem.zip
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-475) Adding a test dependency can move dependencies from the compile scope to the test scope
[
https://jira.codehaus.org/browse/MDEP-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359251#comment-359251
]
Andy Wilkinson edited comment on MDEP-475 at 12/17/14 1:23 PM:
---
I think it's more than a presentation problem. The attached project will fail
to compile due to the {{org.eclipse.jetty.server}} package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
was (Author: wilkinsona):
I think it's more than a presentation problem. The attached project will fail
to compile due to the `org.eclipse.jetty.server` package not being on the
classpath. If you comment out the solr dependency from the pom, the project
will compile.
Adding a test dependency can move dependencies from the compile scope to the
test scope
---
Key: MDEP-475
URL: https://jira.codehaus.org/browse/MDEP-475
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Reporter: Andy Wilkinson
Attachments: pom.xml, test-scope-problem.zip
I'm seeing some strange behaviour where the transitive dependencies of a
test-scope dependency are causing transitive dependencies of a compile-scope
dependency to become test-scoped.
A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
the following dependencies:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO]| \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
[INFO]\- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
[INFO] +-
org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
[INFO] \-
org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
[INFO]\-
org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
{noformat}
If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
dependencies that were previously in the compile scope are now in the test
scope:
{noformat}
$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
[INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
[INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
[INFO]+- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]+- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
{noformat}
My understanding is that this is because the shortest route to the root of
the hierarchy wins and, for a number of the Jetty dependencies, the shortest
route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
a test-scoped dependency being upgraded to the compile scope when a
dependency is added, but downgrading a dependency from the compile scope to
the test scope feels broken to me.
I can work around the problem by using dependency management to force the
dependencies into the compile scope, or by declaring direct dependencies on
the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
approaches require me to know what all those dependencies are and duplicate
them in my pom, undermining the value of the dependencies being pulled in
transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359253#comment-359253
]
Michael Osipov commented on MPIR-263:
-
Robert, thanks for the confirmation. Hervé, I hope you see now why I have
implemented it that way. In my opion, there is no need to reopen this ticket
and apply the solution from MPLUGIN. The general issue could be resolved with
Maven 4.
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-321) Disable dev/contrib current time generation because it is broken
[ https://jira.codehaus.org/browse/MPIR-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPIR-321: --- Assignee: Michael Osipov Disable dev/contrib current time generation because it is broken Key: MPIR-321 URL: https://jira.codehaus.org/browse/MPIR-321 Project: Maven Project Info Reports Plugin Issue Type: Sub-task Components: project-team Affects Versions: 2.7 Reporter: Michael Osipov Assignee: Michael Osipov Currently, the entire current time generation suffers from a design flaw and is most of the time confusing or simply incorrect. MPIR-278 describes it in all glory. We should disable the generation of this column until MPIR-278 is resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-321) Disable dev/contrib current time generation because it is broken
[ https://jira.codehaus.org/browse/MPIR-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-321: Fix Version/s: 2.8 Disable dev/contrib current time generation because it is broken Key: MPIR-321 URL: https://jira.codehaus.org/browse/MPIR-321 Project: Maven Project Info Reports Plugin Issue Type: Sub-task Components: project-team Affects Versions: 2.7 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.8 Currently, the entire current time generation suffers from a design flaw and is most of the time confusing or simply incorrect. MPIR-278 describes it in all glory. We should disable the generation of this column until MPIR-278 is resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omair Majid updated MJAVADOC-384: - Attachment: spaces-for-javadoc-exclude-03.patch This adds an integration test. I am happy to add a unit test too; any suggestions/examples on where to add it? Allow whitespace in javadoc exclude list Key: MJAVADOC-384 URL: https://jira.codehaus.org/browse/MJAVADOC-384 Project: Maven Javadoc Plugin Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Omair Majid Priority: Minor Attachments: spaces-for-javadoc-exclude-02.patch, spaces-for-javadoc-exclude-03.patch, spaces-for-javadoc-exclude-list One of the projects that I am working on has a fairly large exclude list for javadoc packages. maven-javadoc-plugin requires me to put this in on line in the pom, which makes it very hard to read. I think it would be nicer to allow separating the items in the list with newlines and other whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-322) Dependencies Files Details should reuse installed jars instead of target/classes
[
https://jira.codehaus.org/browse/MPIR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359257#comment-359257
]
Michael Osipov commented on MPIR-322:
-
Very nice, thanks for the fix however, have noticed MPIR-238? I believe this
ticket is a dup of 238. Am I right?
Dependencies Files Details should reuse installed jars instead of
target/classes
Key: MPIR-322
URL: https://jira.codehaus.org/browse/MPIR-322
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: dependencies
Affects Versions: 2.7
Reporter: Herve Boutemy
Assignee: Herve Boutemy
Fix For: 2.8
Attachments: MPIR-322.zip
in general, site is generated in a mvn run separate from initial build:
{noformat}mvn install
mvn site{noformat}
what I expect is that the {{mvn site}} command reuse packaged artifacts from
{{mvn install}} (or even {{mvn package}})
but that's not what happens, and I can't tell it's a bug: AFAIK, there is no
feature in Maven for the site phase to reuse
the result is unfortunate in multi-module builds with dependencies inside the
reactor: Dependencies Files Details display {{xxx/target/classes}} instead of
{{xxx-version.jar}}
see real world example:
http://maven.apache.org/wagon-archives/wagon-2.8/wagon-providers/wagon-file/dependencies.html#Dependency_File_Details
{{wagon-provider-api/target/classes}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359258#comment-359258
]
Michael Osipov commented on MPIR-238:
-
Christian, check MPIR-322 please.
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-707) release plugin does not use neither ${project.scm.connection} nor ${project.scm.developerConnection}
[
https://jira.codehaus.org/browse/MRELEASE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359261#comment-359261
]
Andreas Weise (agito) commented on MRELEASE-707:
The use of -Dproject.scm.developerConnection is documented here:
http://maven.apache.org/guides/mini/guide-releasing.html
So it should work or not?
release plugin does not use neither ${project.scm.connection} nor
${project.scm.developerConnection}
Key: MRELEASE-707
URL: https://jira.codehaus.org/browse/MRELEASE-707
Project: Maven Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.2.1
Environment: ArchLinux
Maven 3.0.3
Mercurial 1.9.1
Reporter: Alexander Betaev
Assignee: Robert Scholte
Use case: I don't want to include scm/ section in all my POM's since I want
to perform releases only using CI software. It seems for me to be more useful
configuration for distributed SCM's than using release plugins locally.
So I am providing '-Dproject.scm.connection=scm:hg:file://${basedir}/../' and
'-Dproject.scm.developerConnection=scm:hg:file://${basedir}/../' to Maven's
JVM. But it does not affect anything in maven-release-plugin. Also I did not
find any property which I should use instead of project.scm.connection.
The error message I receive looks like I forgot to configure maven-scm-plugin:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on
project parent: Missing required setting: scm connection or
developerConnection must be specified. - [Help 1]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359262#comment-359262
]
Christian Schulte commented on MPIR-238:
Thanks for bringing this up. The solution to MPIR-322 as it got committed is
incorrect in my opinion. Searching for a {{jar}} file in {{target}} is not what
should be done. Resolution is to take place solely in the core. Issues with the
solution to MPIR-322 are things like:
{{mvn package|install|deploy clean site}}
No {{jar}} in {{target}} will be found. The same problem exists for artifacts
not installed locally. For example, checking out some multi-module project
release version and just executing {{mvn site}} needs to make Maven 3 download
the deployed artifacts of the modules from the remote repositories. Exactly the
same way Maven 2 behaves. There are use cases where falling back to loose class
files isn't wanted/needed/expected. I am thinking about introducing a new
command line flag similar to the {{legacy-local-repository}}. Maybe
{{legacy-reactor-resolution}}. I could provide a patch doing this. However,
there would need to be some consensus on how to solve MPIR-322 and MPIR-238
properly.
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGINTESTING-44) support maven 3.2.4
[ https://jira.codehaus.org/browse/MPLUGINTESTING-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MPLUGINTESTING-44. Resolution: Fixed Fix Version/s: 3.3.0 Assignee: Igor Fedorenko Implemented. https://git-wip-us.apache.org/repos/asf?p=maven-plugin-testing.gita=searchh=HEADst=commits=MPLUGINTESTING-44 support maven 3.2.4 --- Key: MPLUGINTESTING-44 URL: https://jira.codehaus.org/browse/MPLUGINTESTING-44 Project: Maven Plugin Testing Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.3.0 Need to update maven-plugin-testing-harness to work with maven 3.2.4. The incompatibility was introduced as part of MNG-5695 fix and boils down to class name change of one of internal classes and different way to setup MojoExecutionScope. Given the nature of the changes in maven, I plan to update maven-plugin-testing-harness version to 3.3.0 (up from 3.2.x) and to require maven 3.2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359265#comment-359265
]
Herve Boutemy edited comment on MPIR-263 at 12/17/14 8:49 PM:
--
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- {{maven.compiler.source}} and {{maven.compiler.target}} conventions were
created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the algorithm.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switch to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
a few days ago, I started the discussion with I'm not convinced but I didn't
have strong opinion at that time: now, after working on this and having
rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 geenric
API is the graal, perhaps in the future if the need is found for more than
compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
was (Author: hboutemy):
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- we have done {{maven.compiler.source}} and {{maven.compiler.target}}
conventions were created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the algorithm.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switch to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
a few days ago, I started the discussion with I'm not convinced but I didn't
have strong opinion at that time: now, after working on this and having
rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 geenric
API is the graal, perhaps in the future if the need is found for more than
compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359265#comment-359265
]
Herve Boutemy commented on MPIR-263:
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- we have done {{maven.compiler.source}} and {{maven.compiler.target}}
conventions were created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the algorithm.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switch to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
a few days ago, I started the discussion with I'm not convinced but I didn't
have strong opinion at that time: now, after working on this and having
rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 geenric
API is the graal, perhaps in the future if the need is found for more than
compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-263) Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
[
https://jira.codehaus.org/browse/MPIR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359265#comment-359265
]
Herve Boutemy edited comment on MPIR-263 at 12/17/14 8:53 PM:
--
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- {{maven.compiler.source}} and {{maven.compiler.target}} conventions were
created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the different algorithms.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switched to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback to support every classical ways of configuring
the plugin.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
A few days ago, I started the discussion with I'm not convinced since I
really didn't have any strong opinion at that time: now, after working on this
and having rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 generic
API to share configuration between plugins is the graal, perhaps in the future
if the need is found for more than compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
and avoid the regression that would be the actual fix
was (Author: hboutemy):
yes, I understand what was told you to do, and I understand Jason explanations
in the Hangout:
- {{maven.compiler.source}} and {{maven.compiler.target}} conventions were
created exactly for that,
- what we do with plugins configuration analysis is not ideal, should be made
easier with a new Maven 4 API if we really want a generalized solution for any
parameter
but we had an algorithm which worked pretty well for years in MPIR and in
MPLUGIN when we did not use standard properties
One month ago, when we started to use standard property convention, we saw we
missed this case in the algorithm.
In MPLUGIN, I just added the case as fallback, and I added IT to show that it
works really well
In MPIR, the whole algorithm was removed and switch to force everybody to use
standard properties: wow, that's excessive, since what is needed is just to add
the standard properties fallback.
Yes, it's not ideal, ideally we need to wait for Maven 4 API if someone takes
time to create one.
a few days ago, I started the discussion with I'm not convinced but I didn't
have strong opinion at that time: now, after working on this and having
rewritten MPLUGIN-279 with ITs, I have a strong opinion:
1. we just missed the standard properties in existing algorithms: adding
support is easy
2. it would be better if we merged existing algorithms to have one reference:
not a big deal to fix each place quickly now and let a TODO to prepare future
3. of course, this is not something we'd do for any parameter value of any
plugin, and automatic detection of property name, and so on: Maven 4 geenric
API is the graal, perhaps in the future if the need is found for more than
compiler's target
If you're not convinced, tell me and I prepare a branch to show how I see
bq. adding support is easy
Add parameter 'targetJavaVersion' and inject ${maven.compiler.target}
-
Key: MPIR-263
URL: https://jira.codehaus.org/browse/MPIR-263
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: summary
Affects Versions: 2.6
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 2.8
If you define {{maven.compiler.target}} in the {{properties}} section or
per command line, that value is not taken into account in report generation.
The source and target version are retrieved from the static model.
If someone could use an interpolated model that would solve the issue. At
least this should be in the FAQ list.
--
This message was sent by
[jira] (MPIR-322) Dependencies Files Details should reuse installed jars instead of target/classes
[
https://jira.codehaus.org/browse/MPIR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359266#comment-359266
]
Herve Boutemy commented on MPIR-322:
you're right: I knew I already saw it but couldn't find it when I had the idea
on how to write the IT: I'll jump in the MPIR-238 discussion
Dependencies Files Details should reuse installed jars instead of
target/classes
Key: MPIR-322
URL: https://jira.codehaus.org/browse/MPIR-322
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: dependencies
Affects Versions: 2.7
Reporter: Herve Boutemy
Assignee: Herve Boutemy
Fix For: 2.8
Attachments: MPIR-322.zip
in general, site is generated in a mvn run separate from initial build:
{noformat}mvn install
mvn site{noformat}
what I expect is that the {{mvn site}} command reuse packaged artifacts from
{{mvn install}} (or even {{mvn package}})
but that's not what happens, and I can't tell it's a bug: AFAIK, there is no
feature in Maven for the site phase to reuse
the result is unfortunate in multi-module builds with dependencies inside the
reactor: Dependencies Files Details display {{xxx/target/classes}} instead of
{{xxx-version.jar}}
see real world example:
http://maven.apache.org/wagon-archives/wagon-2.8/wagon-providers/wagon-file/dependencies.html#Dependency_File_Details
{{wagon-provider-api/target/classes}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359267#comment-359267
]
Herve Boutemy commented on MPIR-238:
bq. The solution to MPIR-322 as it got committed is incorrect in my opinion
+1, it's not the perfect and most generic solution
bq. things like {{mvn package|install|deploy clean site}}
cleaning after compile then generating site is just a proof of the it's not
ideal concept: but who wants to do that, not only to show that the MPIR-322
solution is only a workaround for core limitations?
bq. The same problem exists for artifacts not installed locally
+1: I never said MPIR-322 is perfect
a plugin can't fix a core issue: it only can sometime workaround it, like the
great idea in MPIR-247 after fixing MNG-5568
the more I work on m-site-p (and I really mean *work* on it), the more I see
the limitations we have in Maven core for really supporting a lot of things
But m-site-p works not so bad for a long time
Then even if I know that there are strong limitations that will require strong
changes in Maven core, we'll have to live with limited workarounds to extend
the m-site-p works not so bad for a long time mantra as much as possible
instead of focusing only on there are strong limitations that will require
strong changes in Maven core
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359267#comment-359267
]
Herve Boutemy edited comment on MPIR-238 at 12/17/14 9:10 PM:
--
bq. The solution to MPIR-322 as it got committed is incorrect in my opinion
+1, it's not the perfect and most generic solution
bq. things like {{mvn package|install|deploy clean site}}
cleaning after compile then generating site is just a proof of the it's not
ideal concept: but who wants to do that, not only to show that the MPIR-322
solution is only a workaround for core limitations?
bq. The same problem exists for artifacts not installed locally
+1: I never said MPIR-322 is perfect
a plugin can't fix a core issue: it only can sometime workaround it, like the
great idea in MPIR-247 after fixing MNG-5568
the more I work on m-site-p (and I really mean *work* on it), the more I see
the limitations we have in Maven core for really supporting a lot of things
such a plugin require, ie coordination of plugins in a lifecycle parallel to
the standard build lifecycle to summarize the whole idea
But m-site-p works not so bad for a long time
Then even if I know that there are strong limitations that will require strong
changes in Maven core, we'll have to live with limited workarounds to extend
the m-site-p works not so bad for a long time mantra as much as possible
instead of focusing only on there are strong limitations that will require
strong changes in Maven core
was (Author: hboutemy):
bq. The solution to MPIR-322 as it got committed is incorrect in my opinion
+1, it's not the perfect and most generic solution
bq. things like {{mvn package|install|deploy clean site}}
cleaning after compile then generating site is just a proof of the it's not
ideal concept: but who wants to do that, not only to show that the MPIR-322
solution is only a workaround for core limitations?
bq. The same problem exists for artifacts not installed locally
+1: I never said MPIR-322 is perfect
a plugin can't fix a core issue: it only can sometime workaround it, like the
great idea in MPIR-247 after fixing MNG-5568
the more I work on m-site-p (and I really mean *work* on it), the more I see
the limitations we have in Maven core for really supporting a lot of things
But m-site-p works not so bad for a long time
Then even if I know that there are strong limitations that will require strong
changes in Maven core, we'll have to live with limited workarounds to extend
the m-site-p works not so bad for a long time mantra as much as possible
instead of focusing only on there are strong limitations that will require
strong changes in Maven core
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359268#comment-359268
]
Christian Schulte commented on MPIR-238:
There are ways to solve this without having to change the core and without
having to work around anything. Just updating the reports expecting a packaged
archive to {{@execute phase=package}} will already make the core resolve to
the {{jar}} instead of {{target/classes}} as expected. Meanwhile I've opened a
pull request https://github.com/apache/maven/pull/32 to add the option
mentioned above.
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359269#comment-359269
]
Herve Boutemy commented on MPIR-238:
bq. Just updating the reports expecting a packaged archive to {{@execute
phase=package}} will already make the core resolve to the jar instead of
target/classes as expected
I see the idea
I also know the problems with such a solution: see MJAVADOC-171 which is why
reporting plugins which used to have such execution finally add new -nofork
goals
for https://github.com/apache/maven/pull/32, we need a MNG issue since it's a
core fix
and it will require core IT and discussions on dev@ IMHO: I think such a
discussion will be useful but can be complex (since adding an option is just a
workaround too, then I don't think it will be pleasant for everybody :) )
I don't have time to do it at the moment, but I'm interested to work with other
in january on that (which is a can of worms that we'll need to open one day or
the other)
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359271#comment-359271
]
Christian Schulte commented on MPIR-238:
{quote}
(since adding an option is just a workaround too, then I don't think it will be
pleasant for everybody )
{quote}
Absolutely. Some enhancements in Maven 3 made it misbehave in certain cases. An
option to revert those enhancements temporarily is a work around for this.
Retains backwards compatibility. I will open a new core issue for this.
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5738) Addition of command line flag '--legacy-reactor-resolution'.
Christian Schulte created MNG-5738: -- Summary: Addition of command line flag '--legacy-reactor-resolution'. Key: MNG-5738 URL: https://jira.codehaus.org/browse/MNG-5738 Project: Maven Issue Type: New Feature Components: Command Line Affects Versions: 3.2.3 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_71, vendor: Oracle Corporation Java home: /usr/local/jdk-1.7.0/jre Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Priority: Trivial For a discussion please see MPIR-238. Pull request is at https://github.com/apache/maven/pull/32. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.
[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359277#comment-359277
]
Herve Boutemy commented on MPIR-238:
thank you Christian: I'll work on MNG-5738 in early january (if nobody beats me
at it)
Dependency File Details section of the dependencies report shows
'target/classes' for reactor artifacts.
Key: MPIR-238
URL: https://jira.codehaus.org/browse/MPIR-238
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
Generating the dependencies report in a multi-module project leads to
incorrect entries in the 'Dependency File Details' section of the
dependencies report. For example, the [Maven Release Plugin Dependency File
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
report contains the following entry:
||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|
Building the site of a single module ('mvn site' in that modules directory),
the correct entries are shown.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
