[jira] (MNG-3328) Allow multiple profile activation properties.
[
https://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288796#comment-288796
]
Benjamin Haag commented on MNG-3328:
Same problem here!
Costs me days now, to find a workaround, if that is possible.
What sense does that AND condition make? You could do every AND with several
profiles.
But tell me, is there ANY chance to do an OR condition, as it is described in
MNG-4516?
Bug was for 2.0.8, I'm using 2.2.1 and 3.0.3 and nothing got better ...
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: https://jira.codehaus.org/browse/MNG-3328
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4516) Contradiction between the documentation and Maven's behavior related to profile-activation with multiple criteria
[
https://jira.codehaus.org/browse/MNG-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288807#comment-288807
]
Benjamin Haag commented on MNG-4516:
If this Issue was Issues to be reviewed for 3.x, as it says, what were the
results?
Activation via settings.xml is useless without an OR condition.
And as long as there is an activation used in the settings.xml, it is
impossible to choose the correct profile via -P profile on the commandline ...
Is nobody willing to fix that problem in the official version?
> Contradiction between the documentation and Maven's behavior related to
> profile-activation with multiple criteria
> -
>
> Key: MNG-4516
> URL: https://jira.codehaus.org/browse/MNG-4516
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.2.1
>Reporter: Barnabas Bodnar
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: debug_output.txt, example2.zip, output.txt, pom.xml
>
>
> The chapter 5.3.1 of the Maven Complete Reference (edition 0.2.1, Novemeber
> 2009) speaks unambiguously about considering a logical "AND" between more
> activation-conditions of a profile (cit.: "A profile is activated when all
> activation criteria has been satisfied. For example, a profile could list an
> Operating System family of Windows, and a JDK version of 1.4, this profile
> will only be activated when the build is executed on a Windows machine
> running Java 1.4.").
> Suprisingly, Maven's real behavior suggests, that the logical "OR" operator
> is used. The attached demo project contains a profile with two
> activation-criteria: a property and the existence of a file. As the output
> shows (attachement output.txt), the fulfillment of a single criterion is
> enough for activating the profile. Also the corresponding implementation in
> the Maven core expresses the intention to use an "OR" logic
> (maven-project/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
> r813685 (branch 2.2.x), line 268):
> for ( Iterator activatorIterator = activators.iterator();
> activatorIterator.hasNext(); )
> {
> ProfileActivator activator = (ProfileActivator) activatorIterator.next();
> if ( activator.canDetermineActivation( profile ) )
> {
> if ( activator.isActive( profile ) )
> {
> return true;
> }
> }
> }
> return false;
> As I'm considering the documentation's variant more reasonable, I'm reporting
> this as a bug instead of a documentation-issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-708) mvn eclipse:eclipse fails with NullPointerException on Java 7 if pom.xml contains version range
[ https://jira.codehaus.org/browse/MECLIPSE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288810#comment-288810 ] Robert Novotny commented on MECLIPSE-708: - I can confirm that on Maven 3.0.3, Win 7 64bit, Java 7u2. Redirecting JAVA_HOME to JDK 1.6.0_27 and rerunning mvn.bat resolves that problem. > mvn eclipse:eclipse fails with NullPointerException on Java 7 if pom.xml > contains version range > --- > > Key: MECLIPSE-708 > URL: https://jira.codehaus.org/browse/MECLIPSE-708 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.8 > Environment: Win 7 (32 Bit), JDK 1.7.0_02, MVN 3.0.3, de_DE, Cp1252 >Reporter: Markus KARG >Priority: Blocker > > If pom.xml contains version range (e. g. like this one: > > > javax.ws.rs > jsr311-api > [1.1,1.2) > > > ) and JDK 1.7.0_02 is used, mvn eclipse:eclipse fails with > NullPointerException: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on > project webdav-jaxrs: Execution default-cli of goal > org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse failed. > NullPointerException -> [Help 1] > The bug location seems to be around this place: > Caused by: java.lang.NullPointerException > at > org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:353) > at > org.apache.maven.artifact.versioning.ComparableVersion.(ComparableVersion.java:344) > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.parseVersion(DefaultArtifactVersion.java:111) > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.(DefaultArtifactVersion.java:47) > at > org.apache.maven.artifact.DefaultArtifact.compareTo(DefaultArtifact.java:433) > at > org.apache.maven.artifact.DefaultArtifact.compareTo(DefaultArtifact.java:43) > at java.util.TreeMap.compare(TreeMap.java:1188) > at java.util.TreeMap.put(TreeMap.java:531) > at java.util.TreeSet.add(TreeSet.java:255) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.getProjectArtifacts(AbstractIdeSupportMojo.java:786) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:560) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:507) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-657) SvnExeExportCommand with revision malfunctions for moved/deleted files
[ https://jira.codehaus.org/browse/SCM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288817#comment-288817 ] Olivier Lamy commented on SCM-657: -- could you please provide a patch using svn diff ? > SvnExeExportCommand with revision malfunctions for moved/deleted files > --- > > Key: SCM-657 > URL: https://jira.codehaus.org/browse/SCM-657 > Project: Maven SCM > Issue Type: Bug > Environment: svn, version 1.6.17 (r1128011) >compiled Nov 19 2011, 08:40:40 >Reporter: adam.kopecky > Attachments: fixed_method.txt > > > According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which > is marked 'INVALID' @revision must be used instead of -r revision, otherwise > export does not find specified file. > Attached is a fixed implementation of createCommandLine method of > org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-299) tgz artifacts ungzipped on download
[ https://jira.codehaus.org/browse/WAGON-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-299. -- Resolution: Not A Bug Assignee: Olivier Lamy Agree with Andreas comment > tgz artifacts ungzipped on download > --- > > Key: WAGON-299 > URL: https://jira.codehaus.org/browse/WAGON-299 > Project: Maven Wagon > Issue Type: Bug >Reporter: Steinar Bang >Assignee: Olivier Lamy > > If a tgz artifact (in our case DLLs and shared libs for different platforms, > that accompany a JNI wrapper Java library), is dowloaded from a maven > repository on an HTTP server that sets the HTTP header "content-encoding: > gzip" on the download, the downloaded file will be ungzipped before storing > it in the local maven repository, still with the extension .tgz, and > dependency:unpack will fail when attempting to unpack the library. > This has been an upgrade blocker and have stuck us on version 2.0.4, which is > getting increasingly hard, so from our POV it's at least priority "Major". > We first encountered this problem on 2.0.5, and I unintentionally verified > today that it's present in 2.0.7. > I'm guessing it is in maven itself rather than in the > maven-dependency-plugin, which is where we see it, because the same version > of the maven-dependency-plugin works on 2.0.4, and fails on later mavens. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3832) Allow wildcards in dependency exclusions
[
https://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288853#comment-288853
]
Haakon Nilsen commented on MNG-3832:
Not sure what's going on, but this seems to work in Maven 3.0.3, using this:
{{
*
*
}}
However, this produces these warnings:
{{
[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 31, column 30
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 32, column 33
}}
So I probably shouldn't be doing it, but it does work.
> Allow wildcards in dependency exclusions
>
>
> Key: MNG-3832
> URL: https://jira.codehaus.org/browse/MNG-3832
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3832-maven-artifact.patch
>
>
> I would like to be able to exclude all transitive dependencies from a certain
> dependencies. This is especially useful when depending on an artifact with a
> classifier that may not have the same dependencies as the main artifact.
> Currently the only way to do this is by excluding each dependency
> individually which requires significant effort and is prone to becoming out
> of date. The following syntax is one possibility.
> Exclude all transitive dependencies
> {code}
>
> *
>
> {code}
> Exclude transitive dependencies with the groupId "org.company"
> {code}
>
> org.company
> *
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3832) Allow wildcards in dependency exclusions
[
https://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288853#comment-288853
]
Haakon Nilsen edited comment on MNG-3832 at 1/19/12 9:18 AM:
-
Not sure what's going on, but this seems to work in Maven 3.0.3, using this:
*
*
However, this produces these warnings:
[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 31, column 30
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 32, column 33
So I probably shouldn't be doing it, but it does work.
was (Author: haakon):
Not sure what's going on, but this seems to work in Maven 3.0.3, using this:
{{
*
*
}}
However, this produces these warnings:
{{[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 31, column 30
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 32, column 33}}
So I probably shouldn't be doing it, but it does work.
> Allow wildcards in dependency exclusions
>
>
> Key: MNG-3832
> URL: https://jira.codehaus.org/browse/MNG-3832
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3832-maven-artifact.patch
>
>
> I would like to be able to exclude all transitive dependencies from a certain
> dependencies. This is especially useful when depending on an artifact with a
> classifier that may not have the same dependencies as the main artifact.
> Currently the only way to do this is by excluding each dependency
> individually which requires significant effort and is prone to becoming out
> of date. The following syntax is one possibility.
> Exclude all transitive dependencies
> {code}
>
> *
>
> {code}
> Exclude transitive dependencies with the groupId "org.company"
> {code}
>
> org.company
> *
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3832) Allow wildcards in dependency exclusions
[
https://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288853#comment-288853
]
Haakon Nilsen edited comment on MNG-3832 at 1/19/12 9:16 AM:
-
Not sure what's going on, but this seems to work in Maven 3.0.3, using this:
{{
*
*
}}
However, this produces these warnings:
{{[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 31, column 30
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 32, column 33}}
So I probably shouldn't be doing it, but it does work.
was (Author: haakon):
Not sure what's going on, but this seems to work in Maven 3.0.3, using this:
{{
*
*
}}
However, this produces these warnings:
{{
[WARNING] 'dependencies.dependency.exclusions.exclusion.groupId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 31, column 30
[WARNING] 'dependencies.dependency.exclusions.exclusion.artifactId' for
no.nkf:kredws-ejb:ejb-client with value '*' does not match a valid id pattern.
@ line 32, column 33
}}
So I probably shouldn't be doing it, but it does work.
> Allow wildcards in dependency exclusions
>
>
> Key: MNG-3832
> URL: https://jira.codehaus.org/browse/MNG-3832
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3832-maven-artifact.patch
>
>
> I would like to be able to exclude all transitive dependencies from a certain
> dependencies. This is especially useful when depending on an artifact with a
> classifier that may not have the same dependencies as the main artifact.
> Currently the only way to do this is by excluding each dependency
> individually which requires significant effort and is prone to becoming out
> of date. The following syntax is one possibility.
> Exclude all transitive dependencies
> {code}
>
> *
>
> {code}
> Exclude transitive dependencies with the groupId "org.company"
> {code}
>
> org.company
> *
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5229) Improvement of nearest-wins strategy
Marrache created MNG-5229: - Summary: Improvement of nearest-wins strategy Key: MNG-5229 URL: https://jira.codehaus.org/browse/MNG-5229 Project: Maven 2 & 3 Issue Type: Improvement Components: Dependencies Affects Versions: 3.0.3 Reporter: Marrache I have a project A that uses library L v1.0.0 with test scope. Project A also depends on project B (with scope compile), with B transitively depending on the library L v1.0.0 (with scope compile). So, according to the documentation (Introduction to dependency mechanism), project A depends on project B with scope "compile" and the transitive dependency on L has a "compile" scope, the final scope of L should be "compile". Here, Maven sees one dependency on L with scope "compile" (after applying the dependency algorithm), and one dependency on L with scope "test". And because the second is nearest to the root (project A), it chooses it, so with a 'test' scope. Why the final scope of the library L for project A is not 'compile'? My project A only uses L for unit tests so I define the dependency with 'test' scope. But, at the end, I want L to be on my classpath since project A depends on project B for production, and B needs (transitively) library L also for production. (By production, I mean not unit tests.) Unless I'm missing something, I think that the good behavior would be to choose the compile scope. I open this issue after asking in the mailing list at this link http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3C6EA53FAD386F9D46B97D49BFE148D5140F14B75E6B%40ISR-JLM-MAIL1.xconnect.co.il%3E Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-118) DependencyConvergence gets better if it doesn't fail on snapshots of same baseVersion
[ https://jira.codehaus.org/browse/MENFORCER-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288864#comment-288864 ] Stephan Schroevers commented on MENFORCER-118: -- And another +1. Indeed, this is a show-stopper when using Maven 3. > DependencyConvergence gets better if it doesn't fail on snapshots of same > baseVersion > - > > Key: MENFORCER-118 > URL: https://jira.codehaus.org/browse/MENFORCER-118 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0.1 >Reporter: Poul Bildsøe >Priority: Trivial > > The DependencyVersionMap used by DependencyConvergense uses > node.getArtifact().getVersion() when comparing versions. This makes the rule > fail more often than needed because the version compare doens't ignore the > fact that some snapshots may have been resolved to timestamp. If the code was > node.getArtifact().getBaseVersion() instead then DependencyConvergense would > only fail on real version mismatches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed SUREFIRE-803. --- Resolution: Fixed Fix Version/s: 2.12 Added code to store/check a token in the plugin context to determine whether the failsafe summary already on disk is from a previous execution in the current build vs. output from a previous build. Then, modified to accumulate test results in the failsafe summary instead of overwriting (overwrite still happens if the existing output is not from the current build). This allows multiple failsafe executions in a build without coping with different output locations for the summaries. See revIds 1232091 and 1233522. > Multiple Surefire executions - FAILURE in an execution prevents successive > from running. > > > Key: SUREFIRE-803 > URL: https://jira.codehaus.org/browse/SUREFIRE-803 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.10 >Reporter: Ondrej Zizka >Assignee: John Casey > Fix For: 2.12 > > Attachments: surefire-803-failure-prevents-subsequent-executions.zip > > > Let's have multiple Surefire executions in a single module (different config > needed). > A failure of a test in one of these executions prevents running the > successive. > Surefire's testFailureIgnore is not an option because it makes a run with > failures succeed. > This behavior is undocumented. > Also, it is undesired - the module as a whole should fail, but all it's tests > should run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-803) Multiple Failsafe executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated SUREFIRE-803: Component/s: (was: Maven Surefire Plugin) Maven Failsafe Plugin Summary: Multiple Failsafe executions - FAILURE in an execution prevents successive from running. (was: Multiple Surefire executions - FAILURE in an execution prevents successive from running.) NOTE: NOT fixing this for the surefire plugin, only modifying the failsafe plugin a little bit. This is because the failsafe plugin is better equipped to handle the non-fail-fast use case. > Multiple Failsafe executions - FAILURE in an execution prevents successive > from running. > > > Key: SUREFIRE-803 > URL: https://jira.codehaus.org/browse/SUREFIRE-803 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.10 >Reporter: Ondrej Zizka >Assignee: John Casey > Fix For: 2.12 > > Attachments: surefire-803-failure-prevents-subsequent-executions.zip > > > Let's have multiple Surefire executions in a single module (different config > needed). > A failure of a test in one of these executions prevents running the > successive. > Surefire's testFailureIgnore is not an option because it makes a run with > failures succeed. > This behavior is undocumented. > Also, it is undesired - the module as a whole should fail, but all it's tests > should run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-819) Surefire 2.11 fails if useManifestOnlyJar is false
[
https://jira.codehaus.org/browse/SUREFIRE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288870#comment-288870
]
Scott Carey commented on SUREFIRE-819:
--
Is there a surefire snapshot repository? Or do I have to check out and build
it? If there is a snapshot repository, I can check that quickly and report
back. If not it will be a few weeks before I can get to it.
> Surefire 2.11 fails if useManifestOnlyJar is false
> --
>
> Key: SUREFIRE-819
> URL: https://jira.codehaus.org/browse/SUREFIRE-819
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Scott Carey
>
> When I tried to upgrade Avro
> (http://svn.apache.org/repos/asf/avro/trunk/lang/java) from surefire 2.10 to
> 2.11, I found that every single test failed. They all fail with
> initializationErrors such as
> {quote}
>
> initializationError(org.apache.avro.io.parsing.TestResolvingGrammarGenerator):
> Test class should have exactly one public zero-argument constructor
>
> initializationError(org.apache.avro.io.parsing.TestResolvingGrammarGenerator):
> No runnable methods
> {quote}
> These are valid JUnit 4 type tests that run fine with 2.10. We have JUnit
> 4.10 in our test scope.
> If I change useManifestOnlyJar to true, it works. Unfortunately one of our
> tests will not function with the manifectOnlyJar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[
https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288876#comment-288876
]
Leonids M. commented on MASSEMBLY-588:
--
workaround (worked for me)
{code}
${basedir}
build.sh
false
/
{code}
> Build fails because of 'ls -1nlaR /'
>
>
> Key: MASSEMBLY-588
> URL: https://jira.codehaus.org/browse/MASSEMBLY-588
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Environment: Ubuntu 11.10 (oneiric)
>Reporter: Thomas Pasch
> Attachments: partial_log.bz2
>
>
> This is a report again
> org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single
> (package-assembly) used in conjunction with maven 3.0.3. I'm trying to build
> ebml-viewer from svn r126 (lastest) at
> http://code.google.com/p/ebml-viewer/source/checkout . Build fails on Linux,
> but the developer of ebml-viewer reports that it builds fine on Windows.
> Last lines of output from failed build with 'mvn -DskipTests -X -e package
> 2>&1 | tee log':
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2:37.924s
> [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011
> [INFO] Final Memory: 8M/216M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single
> (package-assembly) on project ebml-viewer: Failed to create assembly: Error
> creating assembly archive bin: Failed to retrieve numeric file attributes
> using: '/bin/sh -c ls -1nlaR /' -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single
> (package-assembly) on project ebml-viewer: Failed to create assembly: Error
> creating assembly archive bin: Failed to retrieve numeric file attributes
> using: '/bin/sh -c ls -1nlaR /'
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create
> assembly: Error creating assembly archive bin: Failed to retrieve numeric
> file attributes using: '/bin/sh -c ls -1nlaR /'
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException:
> Error creating assembly archive bin: Failed to retrieve numeric file
> attributes using: '/bin/sh -c ls -1nlaR /'
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:445)
> ... 21 more
> C
[jira] (DOXIA-438) Problem to create a book with Maven 3
[ https://jira.codehaus.org/browse/DOXIA-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21#comment-21 ] Andres Gomez Casanova commented on DOXIA-438: - The problem still exists. I have a question, this functionality is deprecated or do you have plans to fix the problems in the most recent versions? I am using maven-site-plugin version 3.0 and the same problem appears. > Problem to create a book with Maven 3 > - > > Key: DOXIA-438 > URL: https://jira.codehaus.org/browse/DOXIA-438 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.2 > Environment: Maven 3 >Reporter: Andres Gomez Casanova > Attachments: pom.xml > > > I had a project configured for Maven 2 and everything worked perfectly. > Today, I was trying to update it to Maven 3 and all plugin to newer versions. > However, I found that I cannot use doxia-maven-plugin 1.2 to create the book. > After executing > mvn doxia:render-books > I got > [ERROR] Failed to execute goal > org.apache.maven.doxia:doxia-maven-plugin:1.2:render-books (default-cli) on > project user-site: Execution default-cli of goal > org.apache.maven.doxia:doxia-maven-plugin:1.2:render-books failed: Unable to > load the mojo 'render-books' in the plugin > 'org.apache.maven.doxia:doxia-maven-plugin:1.2'. A required class is missing: > org/codehaus/plexus/util/interpolation/ValueSource > [ERROR] - > [ERROR] realm =plugin>org.apache.maven.doxia:doxia-maven-plugin:1.2 > [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > [ERROR] urls[0] = > file:/C:/Users/Andres/.m2/repository/org/apache/maven/doxia/doxia-maven-plugin/1.2/doxia-maven-plugin-1.2.jar > [ERROR] urls[1] = > file:/C:/Users/Andres/.m2/repository/org/apache/maven/doxia/doxia-book/1.2/doxia-book-1.2.jar > ... > [ERROR] urls[24] = > file:/C:/Users/Andres/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.4/maven-reporting-api-2.0.4.jar > [ERROR] Number of foreign imports: 1 > [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]] > [ERROR] > [ERROR] -: > org.codehaus.plexus.util.interpolation.ValueSource > My pom.xml is > > ... > > > > > > org.apache.maven.doxia > doxia-maven-plugin > 1.2 > > > pre-site > > render-books > > > > > > > src/site/apt > src/books/usersManual.xml > > > pdf > > > > > src/site/es/apt > src/books/usersManual_es.xml > > > pdf > > > > > > > ... > > > > What is the problem? > If I change the Doxia version to 1.1, it works normally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGELOG-123) Patch with support for SCM provider implementations (similar to release plugin)
[
https://jira.codehaus.org/browse/MCHANGELOG-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23#comment-23
]
Dan Rollo commented on MCHANGELOG-123:
--
Cool. Is a snapshot release of the 2.3 version published anywhere? (I could
give it a try).
Also, any thoughts on when the 2.3 version might be released?
Thanks.
> Patch with support for SCM provider implementations (similar to release
> plugin)
> ---
>
> Key: MCHANGELOG-123
> URL: https://jira.codehaus.org/browse/MCHANGELOG-123
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Alex Coyle
>Assignee: Olivier Lamy
> Fix For: 2.3
>
> Attachments: maven-changelog-plugin-scmproviderimpl.patch
>
>
> Hi,
> The attached patch includes support for SCM 'provider implementations',
> similar to what is included in the Maven Release Plugin. I made this change
> because I wanted to use the Changelog plugin with the
> maven-scm-provider-svnjava project (an SVN provider that uses SVNkit):
> http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/
> I can confirm the patch works, and appears to generate a valid changelog
> report in the Maven site, when used with Maven 3.0.3 and a Maven project that
> follows this example POM structure:
> {noformat}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>
> 4.0.0
> uk.co.example
> example-project
> pom
> 1.0.0-SNAPSHOT
> Example Project
>
> http://example.co.uk/example-project
>
> scm:svn:http://svn.example.co.uk/example-project/trunk
>
> scm:svn:http://svn.example.co.uk/example-project/trunk
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.3-SNAPSHOT
>
>
> com.google.code.maven-scm-provider-svnjava
> maven-scm-provider-svnjava
> 1.13
>
>
>
>
> maven-site-plugin
> 3.0-beta-3
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
>
> [A-Z]{2,}-\d+
> http://jira.example.co.uk
>
> javasvn
>
>
>
>
>
>
>
>
>
>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
