[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:
archiverConfig
!-- (rwxrws===) = 2770(oct) --
directoryMode1528/directoryMode
defaultDirectoryMode1528/defaultDirectoryMode
/archiverConfig
FileSet config in assembly descriptor:
fileSet
directory${project.build.directory}/directory
includes
include.//include
/includes
outputDirectory//outputDirectory
directoryMode2770/directoryMode
/fileSet
Actual directory mode: drwxrwx---
If I do not specify directoryMode 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 fileMode or
directoryMode 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
[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-tabpanelfocusedCommentId=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-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] (MNG-5384) Declarative artifacts
[
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (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-5059) --also-make-phase
[
https://jira.codehaus.org/browse/MNG-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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
[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 SUCCESS [1:12.938s]
clean:clean
[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}
dependencyManagement
dependencies
dependency
groupIdamd-test/groupId
artifactIddependency-management/artifactId
version1.0/version
scopeimport/scope
typepom/type
/dependency
/dependencies
/dependencyManagement
{code}
I set up an example project here:
https://github.com/ansgarkonermann/maven-amd-experiment
The project has three submodules:
{code}
modules
moduledependency-management/module
modulejava-library/module
modulegui/module
/modules
{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] (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
groupsmy.pkg.AnnotationA, my.pkg.AnnotationB/groups
or
groupsmy.pkg.AnnotationParent/groups
// Run C,N only
excludedGroupsmy.pkg.AnnotationA, my.pkg.AnnotationB/excludedGroups
or
excludedGroupsmy.pkg.AnnotationParent/excludedGroups
{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:comment-tabpanelfocusedCommentId=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}
!-- Run A,B only --
groupsmy.pkg.AnnotationA, my.pkg.AnnotationB/groups
!-- or --
groupsmy.pkg.AnnotationParent/groups
!-- Run C,N only --
excludedGroupsmy.pkg.AnnotationA, my.pkg.AnnotationB/excludedGroups
!-- or --
excludedGroupsmy.pkg.AnnotationParent/excludedGroups
{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
groupsmy.pkg.AnnotationA, my.pkg.AnnotationB/groups
or
groupsmy.pkg.AnnotationParent/groups
// Run C,N only
excludedGroupsmy.pkg.AnnotationA, my.pkg.AnnotationB/excludedGroups
or
excludedGroupsmy.pkg.AnnotationParent/excludedGroups
{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] (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}
...
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9/version
reportSets
reportSet
idwithout-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-without-deprecations/destDir
nodeprecatedlisttrue/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
reportSet
idwith-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-with-deprecations/destDir
nodeprecatedlistfalse/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting{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.
...
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9/version
reportSets
reportSet
idwithout-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-without-deprecations/destDir
nodeprecatedlisttrue/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
reportSet
idwith-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-with-deprecations/destDir
nodeprecatedlistfalse/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
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}
...
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9/version
reportSets
reportSet
idwithout-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-without-deprecations/destDir
nodeprecatedlisttrue/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
reportSet
idwith-deprecations/id
configuration
reportOutputDirectory${project.reporting.outputDirectory}/myoutput/reportOutputDirectory
destDirmyapidocs-with-deprecations/destDir
nodeprecatedlistfalse/nodeprecatedlist
/configuration
reports
reportjavadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-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
