[jira] (MSHARED-280) reporting fails with Eclipse Aether
[ https://jira.codehaus.org/browse/MSHARED-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-280: -- Fix Version/s: maven-reporting-exec-1.0.3 > reporting fails with Eclipse Aether > --- > > Key: MSHARED-280 > URL: https://jira.codehaus.org/browse/MSHARED-280 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-reporting-exec >Affects Versions: maven-reporting-exec-1.0.2 >Reporter: Herve Boutemy > Fix For: maven-reporting-exec-1.0.3 > > > cause of MSITE-683 > [DefaultMavenReportExecutor line > 128|http://maven.apache.org/shared/maven-reporting-exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#128] > is using Sonatype Aether ExclusionsDependencyFilter for > MavenPluginManager.setupPluginRealm(...) API call at [line > 267|http://maven.apache.org/shared/maven-reporting-exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#267] > which is affected > by switching to Eclipse Aether > We will need some tweaks in maven-reporting-exec to detect Eclipse Aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-280) reporting fails with Eclipse Aether
Herve Boutemy created MSHARED-280: - Summary: reporting fails with Eclipse Aether Key: MSHARED-280 URL: https://jira.codehaus.org/browse/MSHARED-280 Project: Maven Shared Components Issue Type: Bug Components: maven-reporting-exec Affects Versions: maven-reporting-exec-1.0.2 Reporter: Herve Boutemy cause of MSITE-683 [DefaultMavenReportExecutor line 128|http://maven.apache.org/shared/maven-reporting-exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#128] is using Sonatype Aether ExclusionsDependencyFilter for MavenPluginManager.setupPluginRealm(...) API call at [line 267|http://maven.apache.org/shared/maven-reporting-exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#267] which is affected by switching to Eclipse Aether We will need some tweaks in maven-reporting-exec to detect Eclipse Aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-271) Multiple reportSets don't work
[
https://jira.codehaus.org/browse/MSHARED-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-271:
--
Description:
Having several report sets only the last one is created.
Example: Create java doc report twice, with different parameters. First time
with deprecated api list, second time without.
Expected behaviour: The two directories are created with the different javadocs.
However, currently onle one directory is created.
{code:xml}
...
org.apache.maven.plugins
maven-javadoc-plugin
2.9
without-deprecations
${project.reporting.outputDirectory}/myoutput
myapidocs-without-deprecations
true
javadoc
with-deprecations
${project.reporting.outputDirectory}/myoutput
myapidocs-with-deprecations
false
javadoc
{code}
was:
Having several report sets only the last one is created.
Example: Create java doc report twice, with different parameters. First time
with deprecated api list, second time without.
Expected behaviour: The two directories are created with the different javadocs.
However, currently onle one directory is created.
...
org.apache.maven.plugins
maven-javadoc-plugin
2.9
without-deprecations
${project.reporting.outputDirectory}/myoutput
myapidocs-without-deprecations
true
javadoc
with-deprecations
${project.reporting.outputDirectory}/myoutput
myapidocs-with-deprecations
false
javadoc
> Multiple reportSets don't work
> --
>
> Key: MSHARED-271
> URL: https://jira.codehaus.org/browse/MSHARED-271
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.0.2
> Environment: maven 3.0.4
> maven-site-plugin 3.2
>Reporter: Max Schaefer
>Assignee: Olivier Lamy
>Priority: Critical
> Attachments: test.zip
>
>
> Having several report sets only the last one is created.
> Example: Create java doc report twice, with different parameters. First time
> with deprecated api list, second time without.
> Expected behaviour: The two directories are created with the different
> javadocs.
> However, currently onle one directory is created.
> {code:xml}
> ...
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.9
>
>
> without-deprecations
>
> ${project.reporting.outputDirectory}/myoutput
> myapidocs-without-deprecations
> true
>
>
> javadoc
>
>
>
> with-deprecations
>
> ${project.reporting.outputDirectory}/myoutput
> myapidocs-with-deprecations
> false
>
>
> javadoc
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-833) Support for annotated JUnit @Category
[
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322161#comment-322161
]
Paul Sprague edited comment on SUREFIRE-833 at 3/19/13 10:50 AM:
-
Attaching a second patch that builds on the 1st:
Most class level annotations on a test class are now able to be used within
surefire's groups/excludedGroups configuration properties. Annotations are
added recursively so that annotations of annotations are supported. Annotations
within java.lang.annotation and org.junit.experimental.categories.Category are
excluded.
*Example of how this works:*
{code:java}
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(value = {ElementType.ANNOTATION_TYPE, ElementType.TYPE})
@interface AnnotationParent {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationA {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationB {}
// No parent annotation
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationC {}
@AnnotationA
class ATest {}
@AnnotationB
class BTest {}
@AnnotationC
class CTest{}
// No Annottion
class NTest{}
{code}
*Some possible includes/excludes using surefire:*
{code:xml}
my.pkg.AnnotationA, my.pkg.AnnotationB
my.pkg.AnnotationParent
my.pkg.AnnotationA, my.pkg.AnnotationB
my.pkg.AnnotationParent
{code}
was (Author: spraguep):
Attaching a second patch that builds on the 1st:
Most class level annotations on a test class are now able to be used within
surefire's groups/excludedGroups configuration properties. Annotations are
added recursively so that annotations of annotations are supported. Annotations
within java.lang.annotation and org.junit.experimental.categories.Category are
excluded.
*Example of how this works:*
{code:java}
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(value = {ElementType.ANNOTATION_TYPE, ElementType.TYPE})
@interface AnnotationParent {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationA {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationB {}
// No parent annotation
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationC {}
@AnnotationA
class ATest {}
@AnnotationB
class BTest {}
@AnnotationC
class CTest{}
// No Annottion
class NTest{}
{code}
*Some possible includes/excludes using surefire:*
{code:xml}
// Including/Excluding tests using surefire/failsafe
// Run A,B only
my.pkg.AnnotationA, my.pkg.AnnotationB
or
my.pkg.AnnotationParent
// Run C,N only
my.pkg.AnnotationA, my.pkg.AnnotationB
or
my.pkg.AnnotationParent
{code}
> Support for annotated JUnit @Category
> -
>
> Key: SUREFIRE-833
> URL: https://jira.codehaus.org/browse/SUREFIRE-833
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.12
>Reporter: Jan Goyvaerts
> Fix For: 2.15
>
> Attachments: SUREFIRE-833-spraguep-2.patch,
> SUREFIRE-833-spraguep.patch
>
>
> The current implementation of Surefire seems to look for explicit @Category
> annotations in the test classes. And will only consider those. Suppose I'd
> like to add a more concise annotation for this:
> @Category(IntegrationTests.class) <== JUnit @Category
> @Target({ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> @Documented
> public @interface IntegrationTest {}
> Annotating my test class with @IntegrationTest does not work. Although I
> think it looks much better than repeating everywhere in my code
> "@Category(com.foo.bar.IntegrationTests.class)". For which I add an
> additional dependency in the interface class btw.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-833) Support for annotated JUnit @Category
[
https://jira.codehaus.org/browse/SUREFIRE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Sprague updated SUREFIRE-833:
--
Attachment: SUREFIRE-833-spraguep-2.patch
Attaching a second patch that builds on the 1st:
Most class level annotations on a test class are now able to be used within
surefire's groups/excludedGroups configuration properties. Annotations are
added recursively so that annotations of annotations are supported. Annotations
within java.lang.annotation and org.junit.experimental.categories.Category are
excluded.
*Example of how this works:*
{code:java}
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(value = {ElementType.ANNOTATION_TYPE, ElementType.TYPE})
@interface AnnotationParent {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationA {}
@AnnotationParent
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationB {}
// No parent annotation
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface AnnotationC {}
@AnnotationA
class ATest {}
@AnnotationB
class BTest {}
@AnnotationC
class CTest{}
// No Annottion
class NTest{}
{code}
*Some possible includes/excludes using surefire:*
{code:xml}
// Including/Excluding tests using surefire/failsafe
// Run A,B only
my.pkg.AnnotationA, my.pkg.AnnotationB
or
my.pkg.AnnotationParent
// Run C,N only
my.pkg.AnnotationA, my.pkg.AnnotationB
or
my.pkg.AnnotationParent
{code}
> Support for annotated JUnit @Category
> -
>
> Key: SUREFIRE-833
> URL: https://jira.codehaus.org/browse/SUREFIRE-833
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.12
>Reporter: Jan Goyvaerts
> Fix For: 2.15
>
> Attachments: SUREFIRE-833-spraguep-2.patch,
> SUREFIRE-833-spraguep.patch
>
>
> The current implementation of Surefire seems to look for explicit @Category
> annotations in the test classes. And will only consider those. Suppose I'd
> like to add a more concise annotation for this:
> @Category(IntegrationTests.class) <== JUnit @Category
> @Target({ElementType.TYPE})
> @Retention(RetentionPolicy.RUNTIME)
> @Documented
> public @interface IntegrationTest {}
> Annotating my test class with @IntegrationTest does not work. Although I
> think it looks much better than repeating everywhere in my code
> "@Category(com.foo.bar.IntegrationTests.class)". For which I add an
> additional dependency in the interface class btw.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5455) mvn -amd should honour dependencyManagement POM imports
Ansgar Konermann created MNG-5455:
-
Summary: mvn -amd should honour dependencyManagement POM imports
Key: MNG-5455
URL: https://jira.codehaus.org/browse/MNG-5455
Project: Maven 2 & 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.0.5, 3.0.4
Environment: *JAVA*
java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
*MAVEN*
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: /home/ansgar/opt/maven3
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: /opt/java/jdk1.7.0_13/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "3.7.9-104.fc17.x86_64", arch: "amd64", family:
"unix"
Reporter: Ansgar Konermann
mvn -amd does not build submodules which depend on a POM via means of a POM
import in the dependencyManagement section, like so:
{code}
amd-test
dependency-management
1.0
import
pom
{code}
I set up an example project here:
https://github.com/ansgarkonermann/maven-amd-experiment
The project has three submodules:
{code}
dependency-management
java-library
gui
{code}
Both 'java-library' and 'gui' import 'dependency-management'.
We'd expect Maven to build gui and java-library when issuing mvn -amd
-pl dependency-management, however only dependency-management gets build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4639) Be able to profile a maven build
[
https://jira.codehaus.org/browse/MNG-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated MNG-4639:
---
Attachment: 0001-MNG-4639-Be-able-to-profile-a-maven-build.patch
I implemented this - see [attached
patch|^0001-MNG-4639-Be-able-to-profile-a-maven-build.patch] or the [diff in my
github maven
fork|https://github.com/alexkli/maven/commit/efb72827d2df44abf1114bcc7aeff3efeca2cd55].
Output looks like this at the end of the build (running "mvn -a install" for
maven itself):
{noformat}
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:55.148s
[INFO] Finished at: Tue Mar 19 15:50:33 CET 2013
[INFO] Final Memory: 29M/102M
[INFO]
[INFO] MOJO EXECUTION TIMES
[INFO]
[INFO] 35% maven-surefire-plugin [40.74s]
[INFO] * test
[INFO] 23% animal-sniffer-maven-plugin [27.65s]
[INFO] * check
[INFO] 13% project setup [15.85s]
[INFO] 7% maven-assembly-plugin [8.83s]
[INFO] * single
[INFO] 4% maven-jar-plugin [4.86s]
[INFO] * jar
[INFO] 3% maven-compiler-plugin [4.21s]
[INFO] * compile 3% [4.10s]
[INFO] * testCompile 0% [0.11s]
[INFO] 3% maven-remote-resources-plugin [4.12s]
[INFO] * process
[INFO] 3% plexus-component-metadata [3.49s]
[INFO] * generate-metadata 2% [2.65s]
[INFO] * generate-test-metadata 0% [0.85s]
[INFO] 1% modello-maven-plugin [1.56s]
[INFO] * java 0% [1.13s]
[INFO] * xpp3-reader 0% [0.20s]
[INFO] * xpp3-writer 0% [0.15s]
[INFO] * xpp3-extended-reader 0% [0.08s]
[INFO] 0% maven-site-plugin [1.10s]
[INFO] * attach-descriptor
[INFO] 0% other [0.78s]
[INFO] 0% maven-resources-plugin [0.71s]
[INFO] * resources 0% [0.45s]
[INFO] * testResources 0% [0.25s]
[INFO] 0% scanning for projects [0.71s]
[INFO] 0% buildnumber-maven-plugin [0.61s]
[INFO] * create-timestamp 0% [0.39s]
[INFO] * create 0% [0.22s]
[INFO] 0% maven-install-plugin [0.35s]
[INFO] * install
[INFO]
{noformat}
Details from the commit message:
* adds new option "-a / --analyze" to the maven cli
* which will profile mojo executions and output their time and percentage of
total time sorted at the end of the build
* groups by maven plugin and shows measurements split up by plugin goals
* also measures project discovery ("scanning"), project setup time before first
mojo ("project setup") and anything else ("other")
* implemented in a special ExecutionListener called ProfilingExecutionListener
* which is chained with the normal ExecutionEventLogger by a new
ExecutionListenerChain helper that forwards the events to multiple listeners
WDYT?
> Be able to profile a maven build
>
>
> Key: MNG-4639
> URL: https://jira.codehaus.org/browse/MNG-4639
> Project: Maven 2 & 3
> Issue Type: New Feature
>Reporter: Baptiste MATHUS
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: 0001-MNG-4639-Be-able-to-profile-a-maven-build.patch
>
>
> A common problem with builds is that they can become quite long to run. As it
> is a know anti-pattern for CI for example, one has the need to try and
> optimize their builds.
> The thing is: the current granularity isn't sufficiently precise. In fact,
> you only only the time spent to build each module. This is a good start,
> though.
> Maven currently displays something like the following (let's speak only about
> maven 3):
> {quote}
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] p1 SUCCESS [1:12.938s]
> [INFO] p2 SUCCESS [5.750s]
> [INFO] p3 SUCCESS [3:58.488s]
> [INFO] p4 SUCCESS [24.437s]
> [INFO] p5 SUCCESS [1.563s]
> [INFO]
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 5 minutes 46 seconds
> {quote}
> What would be great would be adding an option that would higher the details.
> Something like -A/--analyze (--profile would be too close to -P/profile
> option) would add detailed analysis, would print something like.
> {quote}
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] p1
[jira] (MJAVADOC-362) aggregate-jar: javadoc build on multi-module maven project in parent pom does not aggreate classpath
Thomas Pasch created MJAVADOC-362:
-
Summary: aggregate-jar: javadoc build on multi-module maven
project in parent pom does not aggreate classpath
Key: MJAVADOC-362
URL: https://jira.codehaus.org/browse/MJAVADOC-362
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9
Environment: Ubuntu 12.04/quantal 64-bit
Reporter: Thomas Pasch
When building aggregated javadocs for a multi-module maven project in parent
pom, maven-javadoc-plugin does not aggreate classpath. Maybe this is the same
problem as reported as MJAVADOC-116 .
You can see the the problem at https://bitbucket.org/nuclos/nuclos-api (git
repository, branch master, commits *before*
2bda1542282a7bac52d0c929c51a4a0546583bcb).
With commit 2bda1542282a7bac52d0c929c51a4a0546583bcb, I fixed the problem by
hard-wiring the needed dependency into the parent pom (well, this is really a
HACK).
This is the actual output in the error case:
[...]
Generating
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/target/apidocs/constant-values.html...
Generating
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/target/apidocs/serialized-form.html...
134 warnings
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Nuclos API FAILURE [23.216s]
[INFO] nuclos-rigid-api .. SKIPPED
[INFO] nuclos-common-api . SKIPPED
[INFO] nuclos-server-api . SKIPPED
[INFO] nuclos-client-api . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 23.380s
[INFO] Finished at: Tue Mar 19 15:15:13 CET 2013
[INFO] Final Memory: 15M/981M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9:aggregate-jar (aggregate-jar)
on project nuclos-api: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 -
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/nuclos-common-api/src/main/java/org/nuclos/api/service/UserSettingsService.java:19:
package javax.annotation.security does not exist
[ERROR] import javax.annotation.security.RolesAllowed;
[ERROR] ^
[ERROR]
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/nuclos-common-api/src/main/java/org/nuclos/api/service/UserSettingsService.java:31:
cannot find symbol
[ERROR] symbol : class RolesAllowed
[ERROR] location: interface org.nuclos.api.service.UserSettingsService
[ERROR] @RolesAllowed("Login")
[ERROR] ^
[ERROR]
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/nuclos-common-api/src/main/java/org/nuclos/api/service/UserSettingsService.java:39:
cannot find symbol
[ERROR] symbol : class RolesAllowed
[ERROR] location: interface org.nuclos.api.service.UserSettingsService
[ERROR] @RolesAllowed("Login")
[ERROR] ^
[ERROR] javadoc: warning - Error fetching URL:
http://commons.apache.org/lang/api-release/package-list
[ERROR] javadoc: warning - Error fetching URL:
http://commons.apache.org/collections/api-release/package-list
[ERROR] javadoc: warning - Error fetching URL:
http://commons.apache.org/dbcp/api-1.4/package-list
[ERROR] javadoc: warning - Error fetching URL:
http://commons.apache.org/codec/api-release/package-list
[ERROR]
/var/lib/jenkins/jobs/nuclos-api-trunk/workspace/nuclos-common-api/src/main/java/org/nuclos/api/statemodel/State.java:12:
warning - Tag @link: reference not found: StatemodelProvider
[ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot
be cast to com.sun.javadoc.AnnotationTypeDoc
[ERROR] at
com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46)
[ERROR] at
com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:811)
[ERROR] at
com.sun.tools.doclets.formats.html.SubWriterHolderWriter.printIndexComment(SubWriterHolderWriter.java:101)
[ERROR] at
com.sun.tools.doclets.formats.html.SubWriterHolderWriter.printSummaryLinkComment(SubWriterHolderWriter.java:137)
[ERROR] at
com.sun.tools.doclets.formats.html.AbstractMemberWriter.writeMemberSummary(AbstractMemberWriter.java:407)
[ERROR] at
com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.buildSummary(MemberSummaryBuilder.java:309)
[ERROR] at
com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.buildMethodsSummary(MemberSummaryBuilder.java:260)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[ERROR] at j
[jira] (MNG-5059) --also-make-phase
[
https://jira.codehaus.org/browse/MNG-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322144#comment-322144
]
Milos Kleint commented on MNG-5059:
---
in some situations, even getting the other projects linked in reactor is
enough, no phase has to be executed:
eg. mvn -pl mainProject -Dexec.args="-cp %classpath Main" exec:exec
currently puts the library project's local repository jars on cp but in some
situations it would be preferable to have the target/classes folders included.
That seems to be happening when you run mvn -am -pl compile phase, all compiles
nicely without local repository jars.
"-amp validate" would be a nice workaround when this issue is implemented, but
maybe we could get away without executing any phases?
> --also-make-phase
> -
>
> Key: MNG-5059
> URL: https://jira.codehaus.org/browse/MNG-5059
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Assignee: Jason van Zyl
>
> Background:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
> {{--also-make}} (with {{--projects}}) is useful, but suffers from the problem
> that dependent projects are always built to the same goal/phase as the
> selected project(s). That is fine for e.g. {{compile}} or {{install}}, but
> not for e.g. {{test}} where you would only want to build {{compile}} (or
> {{test-compile}}) for dependencies, not actually test them.
> Suggest a variant form of this parameter (say {{--also-make-phase}} /
> {{-amp}}) which would accept a goal or phase to run on dependencies in place
> of the regular arguments. For example, to run a unit test after making sure
> all its dependencies have been (re-)compiled:
> {noformat}
> mvn -amp test-compile -pl testedmod test -Dtest=OneTest
> {noformat}
> or to run an (unpacked) web application after (re-)compiling libraries it
> uses:
> {noformat}
> mvn -amp compile -pl webapp jetty:run
> {noformat}
> You might want to pass a goal rather than a phase, so the name could be
> misleading, but I think that would be a rarer use case. Ditto passing
> multiple goals/phases for the upstream projects.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-167) CPD performance issues
Andrey Utis created MPMD-167: Summary: CPD performance issues Key: MPMD-167 URL: https://jira.codehaus.org/browse/MPMD-167 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: CPD Affects Versions: 3.0.1 Environment: Windows 7 Reporter: Andrey Utis Priority: Critical I'm not sure if this is a maven plugin issue or CPD issue itself (I suspect CPD). Has anyone else experienced much longer CPD runtimes on large codebases with the 3.x plugin upgrade? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322131#comment-322131
]
Jörg Hohwiller commented on MNG-5199:
-
Yes. Please add this feature.
See also:
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html
https://issues.jenkins-ci.org/browse/JENKINS-8704
There are use-cases where this feature makes sense and is very helpful.
I am working with various projects on the same machine. Each project has its
own settings.
I added an option that if I open the context menu of a folder, I can open a
shell.
Then it automatically finds the project root and sets environment variables
accordingly (JAVA_HOME, MAVEN_HOME, MAVEN_OPTS, PATH, etc.).
I want to be able to just call "mvn ..." and have everything working for the
right project.
The only workaround I found so far is to add something like
"-Duser.home=project/conf/" to MAVEN_OPTS.
However, this is a hack and has undesired side effects.
Are there any reasons why this ticket is not implemented except for time and
effort?
I might be willing to try creating a patch. But only if the chances are really
high to get this into the mainline.
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://jira.codehaus.org/browse/MNG-5199
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5384) Declarative artifacts
[
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322128#comment-322128
]
Tuomas Kiviaho edited comment on MNG-5384 at 3/19/13 6:16 AM:
--
This is how I'm currently circumventing the problem (MBUILDHELPER-41)
was (Author: tuomas_kiviaho):
This is how I'm currently circumventing the problem
> Declarative artifacts
> -
>
> Key: MNG-5384
> URL: https://jira.codehaus.org/browse/MNG-5384
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Artifacts and Repositories, POM, Reactor and workspace
>Affects Versions: 3.0.4
>Reporter: Tuomas Kiviaho
>
> Currently there's no way to know what attachments a project is going to have
> beforehand. Lack of this feature is currently patched inside Aether where
> test-jar for instance has a special treatment prior packaging phase so that
> we can get a file pointer to ${project.target.testOutputDirectory}.
> Maven 2 had this hack embedded inside of it, but with Maven 3 the project
> attachments list doesn't contain test-jar until it is actually added to the
> project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior
> packaging phase and remove it at prepare-package so that the actual
> attachment could be added to the project.
> I propose that POM could have a section similar to {{build.finalName}} where
> you'd list the attacments that the project is going to introduce. For
> backwards compatibility this of course would not be required. Plugins such as
> jar, sources and javadoc could kick in automatically when pom contains the
> respective declarations (race conditions would arise between
> maven-bundle-plugin and jar for instance).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-648) lineEnding in fileSet corrupts jar files
Anders Hammar created MASSEMBLY-648: --- Summary: lineEnding in fileSet corrupts jar files Key: MASSEMBLY-648 URL: https://jira.codehaus.org/browse/MASSEMBLY-648 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Maven 3.0.5 on Mac Os 10.8.3 with Apple JDK 1.6.0_43 Maven 3.0.5 on Windows XP with Oracle JDK 1.6.0_31 Reporter: Anders Hammar Attachments: assembly-lineEnding.zip I've found a difference in behavior between v2.3 and v2.4 of the plugin. If lineEnding is set to, for example, unix for a fileSet which contains jar files, the jar files are modified and corrupt with v2.4. This was not the case with v2.3. See attached test project. Not sure if this is an actual bug in the plugin, or rather a misconfiguation in the project. But the behavioral change between the versions is a fact. :-) If this is not a bug, maybe we could try to detect misconfiguration like this and output a warning? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-695) Mvn release plugin problems with too many - in name
[ https://jira.codehaus.org/browse/SCM-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322119#comment-322119 ] Sven Kubiak commented on SCM-695: - As we had the exact same issue, I think the problem is not the plugin, rather the project structure. Not Working: /project/parent/pom.xml /project/submodule-1/pom.xml /project/submodule-2/pom.xml We have changed to the following project structure and no everything is working fine. /project/pom.xml /project/submodule-1/pom.xml /project/submodule-2/pom.xml As shown in the example from Kristian. > Mvn release plugin problems with too many - in name > --- > > Key: SCM-695 > URL: https://jira.codehaus.org/browse/SCM-695 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.7 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: /home/devent/apps/apache-maven-3.0.3 > Java version: 1.7.0_b147-icedtea, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.1.9-1.fc16.i686", arch: "i386", family: "unix" >Reporter: Erwin Mueller >Priority: Blocker > Attachments: mvn-release-prepare.log > > > Have maven problems with modules containing too many "-"? > I have projects that are named: > globalpom-groovy/ > globalpom-groovy/globalpom-groovy/pom.xml < parent pom > globalpom-groovy/globalpom-groovy-izpack/pom.xml > globalpom-groovy/globalpom-groovy-izpack-snglejar/pom.xml > globalpom-groovy/globalpom-groovy-testutils/pom.xml > But if I do mvn release:prepare inside of globalpom-groovy/globalpom-groovy/, > then I get the error: > [INFO] Executing: /bin/sh -c cd > /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom- > groovy && git add -- pom.xml -izpack/pom.xml -izpack-singlejar/pom.xml - > testutils/pom.xml > [INFO] Working directory: > /mnt/read/projects/com.anrisoftware/globalpom/globalpom-groovy/globalpom- > groovy > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Global POM Groovy . FAILURE [12.365s] > [INFO] Global POM Groovy IzPack .. SKIPPED > [INFO] Global POM Groovy IzPack Single Jar ... SKIPPED > [INFO] Global POM Groovy Test Utilities .. SKIPPED > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 13.066s > [INFO] Finished at: Sat Jan 21 15:45:50 CET 2012 > [INFO] Final Memory: 12M/152M > [INFO] > > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release- > plugin:2.0:prepare (default-cli) on project globalpom-groovy: Unable to > commit > files > [ERROR] Provider message: > [ERROR] The git-add command failed. > [ERROR] Command output: > [ERROR] fatal: pathspec 'globalpom-groovy/-izpack/pom.xml' did not match any > files > Of course that's wrong 'globalpom-groovy/-izpack/pom.xml' should be > '../globalpom-groovy-izpack/pom.xml', or something like that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-647) Archiver drops file/directory mode most significant bits
Leif Rilbe created MASSEMBLY-647:
Summary: Archiver drops file/directory mode most significant bits
Key: MASSEMBLY-647
URL: https://jira.codehaus.org/browse/MASSEMBLY-647
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.4
Reporter: Leif Rilbe
Problem detected when trying to build a zip assembly with directories having
the setgid bit set.
Wanted directory mode: drwxrws---
Archiver config:
1528
1528
FileSet config in assembly descriptor:
${project.build.directory}
./
/
2770
Actual directory mode: drwxrwx---
If I do not specify in the assembly descriptor, the modes from
the archiverConfig prevale, thus yielding the wanted directory mode. However,
this behaviour seems brittle and possibly any use of or
in the assembly descriptors seems to "break" the use of the
archiverConfig modes.
>From source code analysis it seems to me that fileset modes are handled by
>means of the org.codehaus.plexus.components.io.attributes.FileAttributes
>class. This class seems to not handle the most significant file mode bits
>(i.e. setuid/setgid/sticky bits). It seems that the assembly plugin sometimes
>routes permission through this class and sometimes not, which causes the most
>significant bits to be sometimes lost and sometimes not.
Perhaps the best route would be to add handling of the setuid/setgid/sticky
bits to the org.codehaus.plexus.components.io.attributes.FileAttributes class?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
