[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157678#action_157678
]
Kuno Baeriswyl commented on SCM-406:
I've contacted the subversion developer list. Nobody of the subversion team
seams to be aware of this problem...as a consequence, the issue won't get
fixed...
Can anybody reproduce the problem with subversion? Or does anybody know exactly
what does not work with subversion?
If so, please report it the topic in the developer list :
http://www.nabble.com/Maven-scm-tag-does-not-work-with-Subversion-1.5.x-td20930592.html
THanks a lot. I hope we can fixed it this way.
Kuno
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-354) Versions defined in profiles are not updated
[ http://jira.codehaus.org/browse/MRELEASE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157684#action_157684 ] Mathias Arens commented on MRELEASE-354: I have exactly the same problem. My dependencies in a profile section are not updated as well. In my example the 'example-artifact' dependency in the JBoss-4.2.3.GA profile has not been updated to the new 0.5-SNAPSHOT version: ... JBoss-4.2.3.GA true example.groupId example-artifact 0.4-SNAPSHOT ejb asm asm I agree with Martin that all dependencies defined in profile sections should be updated no matter which profile is active at the moment. > Versions defined in profiles are not updated > > > Key: MRELEASE-354 > URL: http://jira.codehaus.org/browse/MRELEASE-354 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_06 > OS name: "windows 2000" version: "5.0" arch: "x86" Family: "windows" >Reporter: Martin von Zweigbergk > > Versions defined in profiles (in either or > ) should be updated, regardless of which profile are > active. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-354) Versions defined in profiles are not updated
[
http://jira.codehaus.org/browse/MRELEASE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157684#action_157684
]
Mathias Arens edited comment on MRELEASE-354 at 12/11/08 4:10 AM:
--
I have exactly the same problem. My dependencies in a profile section are not
updated as well.
In my example the 'example-artifact' dependency in the JBoss-4.2.3.GA profile
has not been updated to the new 0.5-SNAPSHOT version:
{code:xml}
...
JBoss-4.2.3.GA
true
example.groupId
example-artifact
0.4-SNAPSHOT
ejb
asm
asm
{code}
I agree with Martin that all dependencies defined in profile sections should be
updated no matter which profile is active at the moment.
was (Author: mathiasarens):
I have exactly the same problem. My dependencies in a profile section are
not updated as well.
In my example the 'example-artifact' dependency in the JBoss-4.2.3.GA profile
has not been updated to the new 0.5-SNAPSHOT version:
...
JBoss-4.2.3.GA
true
example.groupId
example-artifact
0.4-SNAPSHOT
ejb
asm
asm
I agree with Martin that all dependencies defined in profile sections should be
updated no matter which profile is active at the moment.
> Versions defined in profiles are not updated
>
>
> Key: MRELEASE-354
> URL: http://jira.codehaus.org/browse/MRELEASE-354
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-7
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_06
> OS name: "windows 2000" version: "5.0" arch: "x86" Family: "windows"
>Reporter: Martin von Zweigbergk
>
> Versions defined in profiles (in either or
> ) should be updated, regardless of which profile are
> active.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-263) NullPointerException if build run from a module and no url defined in module or parent
[
http://jira.codehaus.org/browse/MSITE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157715#action_157715
]
Antony Stubbs commented on MSITE-263:
-
I've just hit this issue too:
{code}
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83)
at
org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveBannerPaths(DefaultDecorationModelInheritanceAssembler.java:147)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:56)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:253)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:527)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:466)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}
> NullPointerException if build run from a module and no url defined in module
> or parent
> --
>
> Key: MSITE-263
> URL: http://jira.codehaus.org/browse/MSITE-263
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Reporter: Cameron Jones
>Assignee: Dennis Lundberg
>Priority: Trivial
> Attachments: MSITE-263.zip
>
>
> i've found that you get a null pointer exception if there is no defined
> on a module or on it's parent pom. If the build is run from the parent it
> works but gives a warning that urls will not be decorated. Adding the
> back to the parent fixes the issue. Here's the stacktrace:
> java.lang.NullPointerException
> at
> org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83)
> at
> org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:255)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembl
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157718#action_157718 ] Michal Borowiecki commented on SUREFIRE-482: This is an issue for me too. "Naming a class *Test without making it abstract and without putting any @Test annotation" does not seam unusual to me. Mock object are one case. Another one is starting a new project and creating a test class not having implemented any test methods yet. Having to make it abstract is an unnecessary nuisance. What is worse, you then have to remember to make it non-abstract again once you have written the first test. Another case is wanting to temporarily disabling tests by annotating them with @Ignore. It is inconsistent that you can do it UNLESS there are no more methods with @Test annotation left in the class in which case the exception is raised. In the end even if these cases were unusual they are not in any way an error and should not be reported as such and should not break a build. I hope someone is convinced one day that this should be fixed :) > Surefire tries to run JUnit4 tests that contain no @Test annotations > > > Key: SUREFIRE-482 > URL: http://jira.codehaus.org/browse/SUREFIRE-482 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4.2 >Reporter: Mark Hobson > Attachments: test.zip > > > Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that > contain no @Test annotations as tests, resulting in the exception: > java.lang.Exception: No runnable methods > at > org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) > at > org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) > at > org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) > at > org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) > at > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at > org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > Such classes should be ignored by Surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-263) NullPointerException if build run from a module and no url defined in module or parent
[ http://jira.codehaus.org/browse/MSITE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157717#action_157717 ] Antony Stubbs commented on MSITE-263: - Adding a bogus to the parent pom appears to have fixed the issue. > NullPointerException if build run from a module and no url defined in module > or parent > -- > > Key: MSITE-263 > URL: http://jira.codehaus.org/browse/MSITE-263 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Cameron Jones >Assignee: Dennis Lundberg >Priority: Trivial > Attachments: MSITE-263.zip > > > i've found that you get a null pointer exception if there is no defined > on a module or on it's parent pom. If the build is run from the parent it > works but gives a warning that urls will not be decorated. Adding the > back to the parent fixes the issue. Here's the stacktrace: > java.lang.NullPointerException > at > org.apache.maven.doxia.site.decoration.inheritance.PathUtils.getRelativePath(PathUtils.java:83) > at > org.apache.maven.doxia.site.decoration.inheritance.PathUtils.convertPath(PathUtils.java:43) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.convertPath(DefaultDecorationModelInheritanceAssembler.java:334) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.resolveLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:255) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:277) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:192) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:83) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:251) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:525) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:464) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:114) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157737#action_157737 ] Matthew Lieder commented on MNG-3228: - dfsdfsdf > Maven profile activation does not work when profile is defined in inherited > 'parent' pom > > > Key: MNG-3228 > URL: http://jira.codehaus.org/browse/MNG-3228 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: tony nys > Fix For: Reviewed Pending Version Assignment > > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157737#action_157737 ] Matthew Lieder edited comment on MNG-3228 at 12/11/08 9:59 AM: --- I can confirm this problem still exists in Maven 2.1.0-M1. Any chance of it being fixed in M2? was (Author: igx89): dfsdfsdf > Maven profile activation does not work when profile is defined in inherited > 'parent' pom > > > Key: MNG-3228 > URL: http://jira.codehaus.org/browse/MNG-3228 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: tony nys > Fix For: Reviewed Pending Version Assignment > > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MERCURY-40) DefaultSatSolver is non-deterministic
[
http://jira.codehaus.org/browse/MERCURY-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Gusakov reopened MERCURY-40:
-
Assignee: Oleg Gusakov
This solution is deterministic to the extend of DependencyBuilder being
deterministic, if DependencyBuilder can place nodes of the same tree two timew
in a row in different order - that would raise this issue again.
The DependencyTreeBuilder builder uses ArrayLists to preserver the order of
children, so it is fine.
But when we implement, say, OSGi resolver or another Java resolver - this is
something to watch for.
I will leave this open so that I can permanently fix it.
> DefaultSatSolver is non-deterministic
> -
>
> Key: MERCURY-40
> URL: http://jira.codehaus.org/browse/MERCURY-40
> Project: Mercury
> Issue Type: Bug
>Affects Versions: 1.0.0-alpha-2
>Reporter: Benjamin Bentmann
>Assignee: Oleg Gusakov
> Attachments: mercury-failed.txt, mercury-passed.txt,
> org.apache.maven.mercury.metadata.sat.DefaultSatSolverTest.txt
>
>
> Running the unit test {{DefaultSatSolverTest.testSingleVersionResolution()}}
> once on Java 1.5 and 1.6 revealed a bug in {{DefaultSatSolver.solve()}} due
> to usage of {{HashMap}}. See attached logs (passed with 1.5, failed with 1.6).
> The internal tweaks to the hash algos employed by the different JRE versions
> exhibited a non-deterministic ordering of the artifact metadata list.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-58) typo in rule-api documentation
typo in rule-api documentation -- Key: MENFORCER-58 URL: http://jira.codehaus.org/browse/MENFORCER-58 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Rule API Affects Versions: 1.0-alpha-4 Environment: N/A Reporter: James Nord Assignee: Brian Fox Priority: Trivial The page http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html has a typo in the examples. the word "retrieve" is spelt incorrectly in the sentence: // retreive any component out of the session directly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MERCURY-58) Update POMs to use type=test-jar rather than classifier=tests to reference test artifacts
Update POMs to use type=test-jar rather than classifier=tests to reference test
artifacts
-
Key: MERCURY-58
URL: http://jira.codehaus.org/browse/MERCURY-58
Project: Mercury
Issue Type: Improvement
Components: Misc/All
Affects Versions: 1.0.0-alpha-2
Reporter: Benjamin Bentmann
Assignee: Oleg Gusakov
Priority: Trivial
The combination of MJAR-75 and the current solution for MNG-2045 require the
usage of
{code:xml}
test-jar
{code}
instead of
{code:xml}
tests
{code}
to successfully resolve test dependencies from the reactor when the build
doesn't include the "install" phase, like "mvn verify".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPECLIPSE-132) Maven 1.0.2 - Mevenide Eclipse Plugin issue
Maven 1.0.2 - Mevenide Eclipse Plugin issue --- Key: MPECLIPSE-132 URL: http://jira.codehaus.org/browse/MPECLIPSE-132 Project: Maven 1.x Eclipse Plugin Issue Type: Bug Affects Versions: 1.0 Environment: Windows Reporter: Thomas Priority: Blocker Attachments: Mevenide Plugin issue.doc I installed Maven1.0.2 and eclipse - 3.1.2. The Mevenide plug-in is not working. In eclipse, when I click on Windows ==> Preferences ==> Maven ==> Getting a message - 'Preference Page Creation problems'. Unable to create the selected preference page Reason: Plug-in org.mevenide.ui was unable to load class org.mevenide.ui.eclipse.preferences.pages.MevenidePreferencePage. Could you please let me know, what's causing this issue. Any info you can provide is greatly appreciated! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3895) Have Maven 3.x building on the grid before releasing
Have Maven 3.x building on the grid before releasing Key: MNG-3895 URL: http://jira.codehaus.org/browse/MNG-3895 Project: Maven 2 Issue Type: Task Reporter: Jason van Zyl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3811) Report plugins don't inherit configuration
[ http://jira.codehaus.org/browse/MNG-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157812#action_157812 ] Paul Benedict commented on MNG-3811: I'd like to inherit the UmlGraphDoc doclet from a parent's configuration, but cannot do this bug. > Report plugins don't inherit configuration > -- > > Key: MNG-3811 > URL: http://jira.codehaus.org/browse/MNG-3811 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.9, 2.0.11 > Environment: Ubuntu x64 > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) >Reporter: Nik Everett >Priority: Minor > Attachments: bug.tar.gz, MNG-3811-maven-project.patch > > > 'm trying to set up reporting plugin inheritance and not having any luck. > I'm using Maven 2.0.9 on Java 1.6.0_07. Here is my problem: > parent/pom.xml has > > > > maven-javadoc-plugin > > true > > parentLink > > > > > > child/pom.xml has > > > > maven-javadoc-plugin > > > childLink > > > > > > After installing the parent, mvn help:effective-pom for the child yeilds: > > target/site > > > maven-javadoc-plugin > > > childLink > > > > > > I expected it to look like: > > target/site > > > maven-javadoc-plugin > > true > > parentLink > childLink > > > > > > I'd be happy to make a test case for this if someone would point me in the > right direction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHADE-42) Reactor builds do not use shaded jar
[ http://jira.codehaus.org/browse/MSHADE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MSHADE-42: --- Attachment: MSHADE-42-alternate.diff an alternate patch. This is cleaner and cheaper, but may have side effects if subsequent plugins expected a directory. I'm not that comfortable applying it, so I'll go with the first one. I think this is considered a bug in Maven itself - if the JAR was produced, it should be used instead. The artifact is the output, the target/classes is just an optimisation for running earlier lifecycle phases. > Reactor builds do not use shaded jar > > > Key: MSHADE-42 > URL: http://jira.codehaus.org/browse/MSHADE-42 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Dave Meibusch > Attachments: MSHADE-42-alternate.diff, MSHADE-42.patch > > > I have a multi-module project with several of the modules using shade to > create uber jars. > One the modules depends on an uber jar module. When doing a reactor build, > this module is built with a compile classpath containing: >/xxx/yyy/uberjar-module/target/classes > rather than the shaded uber jar created (and installed) earlier in the > reactor build. > When the module is built alone, the dependency in the compile classpath is > correctly the shaded jar in the local repository. > I don't know enough about the internals of reactor builds to determine if > this is a deficiency of the shade plugin or Maven's reactor mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
