[jira] Closed: (CONTINUUM-548) Can't change project name
[ http://jira.codehaus.org/browse/CONTINUUM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-548. -- Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-1 With project group feature, it's fixed. > Can't change project name > - > > Key: CONTINUUM-548 > URL: http://jira.codehaus.org/browse/CONTINUUM-548 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.0.2 >Reporter: Tim McCune > Fix For: 1.1-alpha-1 > > > I have created a new Maven 1.x project in Continuum and after doing so, > edited its project name in the web UI. The edit seems to work fine, but the > next time the project gets built, its name gets reverted back to the original > name that it picked up from the POM. This is a real pain in the ass because > I want multiple Continuum projects created from the same POM (so they are all > getting the same name) to do things like building multiple branches, and > running different goals on different schedules. -- 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-256) ArrayIndexOutOfBoundsException using custom tagBase.
[ http://jira.codehaus.org/browse/MRELEASE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104153 ] Andrew Lynch commented on MRELEASE-256: --- I see the same issue with version 2.0-beta-6, 2.0-beta4 works OK: > ArrayIndexOutOfBoundsException using custom tagBase. > > > Key: MRELEASE-256 > URL: http://jira.codehaus.org/browse/MRELEASE-256 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: Ubuntu 7.04 > Java 1.6.0_02-ea > Maven 2.0.6 >Reporter: Mark Soderquist > > My project SVN connection is: > http://svn.novaworx.org/software/utility/trunk > I would like to put the release tag at > http://svn.novaworx.org/software/utility/1.0. > I specified the following on the command line: > mvn release:prepare -DdryRun=true > -DtagBase="http://svn.novaworx.org/software/utility"; > What is the release version for "Novaworx Utility Library"? > (org.novaworx:utility) 1.0: : [Enter] > What is SCM release tag or label for "Novaworx Utility Library"? > (org.novaworx:utility) utility-1.0: : 1.0[Enter] > What is the new development version for "Novaworx Utility Library"? > (org.novaworx:utility) 1.1-SNAPSHOT: : [Enter] > and received the following exception: > java.lang.ArrayIndexOutOfBoundsException: 48 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:691) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:190) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > 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.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > 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:597) > 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] Updated: (MNG-3138) MavenIT0114ExtensionThatProvidesResources fails on trunk only
[ http://jira.codehaus.org/browse/MNG-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3138: -- Fix Version/s: 2.1-alpha-1 > MavenIT0114ExtensionThatProvidesResources fails on trunk only > - > > Key: MNG-3138 > URL: http://jira.codehaus.org/browse/MNG-3138 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Can't find it0114_rule_set.xml on classpath!! > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: Can't find it0114_rule_set.xml on > classpath!! > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:911) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) > 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Can't find > it0114_rule_set.xml on classpath!! > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:379) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:255) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > ... 11 more > Caused by: org.apache.maven.plugin.MojoExecutionException: Can't find > it0114_rule_set.xml on classpath!! > at org.apache.maven.plugin.It0014Mojo.execute(It0014Mojo.java:26) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:647) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:354) > ... 14 more -- 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-3137) IT 0108 (snapshot updates) fail intermittently
IT 0108 (snapshot updates) fail intermittently --- Key: MNG-3137 URL: http://jira.codehaus.org/browse/MNG-3137 Project: Maven 2 Issue Type: Bug Components: integration tests Reporter: Brett Porter testSnapshotUpdatedWithMetadata(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest) Time elapsed: 4.443 sec <<< FAILURE! junit.framework.ComparisonFailure: expected: but was: at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.it.Verifier.assertArtifactContents(Verifier.java:1493) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertArtifactContents(MavenIT0108SnapshotUpdateTest.java:255) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) testSnapshotUpdatedWithMetadataUsingFileTimestamp(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest) Time elapsed: 5.265 sec <<< FAILURE! junit.framework.ComparisonFailure: expected: but was: at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.it.Verifier.assertArtifactContents(Verifier.java:1493) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertArtifactContents(MavenIT0108SnapshotUpdateTest.java:255) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadataUsingFileTimestamp(MavenIT0108SnapshotUpdateTest.java:195) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadataUsingFileTimestamp(MavenIT0108SnapshotUpdateTest.java:195) -- 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-3138) MavenIT0114ExtensionThatProvidesResources fails on trunk only
MavenIT0114ExtensionThatProvidesResources fails on trunk only - Key: MNG-3138 URL: http://jira.codehaus.org/browse/MNG-3138 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Can't find it0114_rule_set.xml on classpath!! [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Can't find it0114_rule_set.xml on classpath!! at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:911) at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Can't find it0114_rule_set.xml on classpath!! at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:379) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:255) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) ... 11 more Caused by: org.apache.maven.plugin.MojoExecutionException: Can't find it0114_rule_set.xml on classpath!! at org.apache.maven.plugin.It0014Mojo.execute(It0014Mojo.java:26) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:647) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:354) ... 14 more -- 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-3136) review excluded integration tests
review excluded integration tests - Key: MNG-3136 URL: http://jira.codehaus.org/browse/MNG-3136 Project: Maven 2 Issue Type: Bug Components: integration tests Reporter: Brett Porter The following ITs are excluded at present: IT 0091 IT 0093 IT 0098 IT 0106 IT 0107 We need to check whether they actually work, and what issue they are testing, then either re-include them or comment on the issue that must be fixed before including them. -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104150
]
William Ferguson commented on WAGON-73:
---
Ah good. I'd just realised that my cursory investigation from before was a
little off as the actual time is read from the 'lastUpdated' element of the
Metadata and won't be resolved until it is requested. But I did wonder about
time zone.
I wish #assertEquals printed the full content for the expected and actual
values. It would have been useful.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104149
]
Brian Fox commented on WAGON-73:
You're right, it's not the patch, but the test. The constructLocalMetadata
doesn't take into account that the lastUpdated tag in the metadata is in UTC.
It's not yet Aug 7 here so it's failing the comparison.
I removed the patch and the test is failing now. It was a coincidence that I
tried it just after midnight UTC such that it passed before.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104148
]
William Ferguson commented on WAGON-73:
---
I can't checkout the all the code necessary to fully inspect this right now,
but it looks like an error in the testcase.
Line #215 of MavenIT0108SnapshotUpdateTest calls #assertLocalMetadataIsToday
but passes in the localMetadata (File) that it resolved *before* the install
goal is run instead of after. Otherwise it will be comparing the localMetadata
File from a previous run (perhaps yesterday) which would explain the failure.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (CONTINUUM-1369) Profile add button does not work in IE6
Profile add button does not work in IE6 --- Key: CONTINUUM-1369 URL: http://jira.codehaus.org/browse/CONTINUUM-1369 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-beta-1 Environment: AIX Reporter: apache maillist While adding Installation into a Profile, click "Add" button does not add the installation into profile in IE6 (6.0.2800), but works in Firefox (2.0.0.5) -- 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-2166) Provide the help listing as default when no arguments are provided
[ http://jira.codehaus.org/browse/MNG-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104146 ] Brian Fox commented on MNG-2166: It is possible to set a default goal in the pom such that "mvn" is a valid invocation, however if no goals are found even after processing the pom, it would make sense to display some info. > Provide the help listing as default when no arguments are provided > -- > > Key: MNG-2166 > URL: http://jira.codehaus.org/browse/MNG-2166 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line >Affects Versions: 2.0, 2.0.1, 2.0.2 > Environment: Any >Reporter: Andre Ranvik >Priority: Minor > Fix For: 2.2.x > > > When just writing "mvn" with no arguments on the command line I get a message > such as this: > >mvn > [INFO] Scanning for projects... > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] You must specify at least one goal. Try 'install' > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Wed Mar 22 09:15:04 CET 2006 > [INFO] Final Memory: 1M/2M > [INFO] > > Many new users to maven or any other such tools are used to getting at least > some basic info of what is expected. How about just displaying the listing > that shows up when a user writes "mvn -h" as default when no arguments are > privided? This is also a feature that most other similar products have. I > also would suggest printing a URL for where they can get basic information > for how to use maven. -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104145
]
Brian Fox commented on WAGON-73:
I ran the ITs using Maven 2.0.7 and I get one additional failure with the patch
applied:
{noformat}
testSnapshotLocalMetadataUpdatedOnInstall(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest)
{noformat}
The ones that fail regardless of the patch or not are:
{noformat}
Failed tests:
testit0002(org.apache.maven.integrationtests.MavenIT0002Test)
testit0008(org.apache.maven.integrationtests.MavenIT0008Test)
testit0009(org.apache.maven.integrationtests.MavenIT0009Test)
testit0012(org.apache.maven.integrationtests.MavenIT0012Test)
testit0022(org.apache.maven.integrationtests.MavenIT0022Test)
testit0023(org.apache.maven.integrationtests.MavenIT0023Test)
testit0025(org.apache.maven.integrationtests.MavenIT0025Test)
testit0026(org.apache.maven.integrationtests.MavenIT0026Test)
testit0027(org.apache.maven.integrationtests.MavenIT0027Test)
testit0040(org.apache.maven.integrationtests.MavenIT0040Test)
testit0041(org.apache.maven.integrationtests.MavenIT0041Test)
testit0044(org.apache.maven.integrationtests.MavenIT0044Test)
testit0045(org.apache.maven.integrationtests.MavenIT0045Test)
testit0046(org.apache.maven.integrationtests.MavenIT0046Test)
testit0049(org.apache.maven.integrationtests.MavenIT0049Test)
testit0064(org.apache.maven.integrationtests.MavenIT0064Test)
testit0071(org.apache.maven.integrationtests.MavenIT0071Test)
testit0073(org.apache.maven.integrationtests.MavenIT0073Test)
testit0082(org.apache.maven.integrationtests.MavenIT0082Test)
testit0088(org.apache.maven.integrationtests.MavenIT0088Test)
testit0090(org.apache.maven.integrationtests.MavenIT0090Test)
Tests in error:
testit0086(org.apache.maven.integrationtests.MavenIT0086Test)
testit0087(org.apache.maven.integrationtests.MavenIT0087Test)
testit0104(org.apache.maven.integrationtests.MavenIT0104Test)
Tests run: 115, Failures: 21, Errors: 3, Skipped: 0
{noformat}
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104145
]
Brian Fox edited comment on WAGON-73 at 8/6/07 8:33 PM:
I ran the ITs using Maven 2.0.7 and I get one additional failure with the patch
applied:
{noformat}
testSnapshotLocalMetadataUpdatedOnInstall(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest)
{noformat}
The ones that fail regardless of the patch or not are:
{noformat}
Failed tests:
testit0002(org.apache.maven.integrationtests.MavenIT0002Test)
testit0008(org.apache.maven.integrationtests.MavenIT0008Test)
testit0009(org.apache.maven.integrationtests.MavenIT0009Test)
testit0012(org.apache.maven.integrationtests.MavenIT0012Test)
testit0022(org.apache.maven.integrationtests.MavenIT0022Test)
testit0023(org.apache.maven.integrationtests.MavenIT0023Test)
testit0025(org.apache.maven.integrationtests.MavenIT0025Test)
testit0026(org.apache.maven.integrationtests.MavenIT0026Test)
testit0027(org.apache.maven.integrationtests.MavenIT0027Test)
testit0040(org.apache.maven.integrationtests.MavenIT0040Test)
testit0041(org.apache.maven.integrationtests.MavenIT0041Test)
testit0044(org.apache.maven.integrationtests.MavenIT0044Test)
testit0045(org.apache.maven.integrationtests.MavenIT0045Test)
testit0046(org.apache.maven.integrationtests.MavenIT0046Test)
testit0049(org.apache.maven.integrationtests.MavenIT0049Test)
testit0064(org.apache.maven.integrationtests.MavenIT0064Test)
testit0071(org.apache.maven.integrationtests.MavenIT0071Test)
testit0073(org.apache.maven.integrationtests.MavenIT0073Test)
testit0082(org.apache.maven.integrationtests.MavenIT0082Test)
testit0088(org.apache.maven.integrationtests.MavenIT0088Test)
testit0090(org.apache.maven.integrationtests.MavenIT0090Test)
Tests in error:
testit0086(org.apache.maven.integrationtests.MavenIT0086Test)
testit0087(org.apache.maven.integrationtests.MavenIT0087Test)
testit0104(org.apache.maven.integrationtests.MavenIT0104Test)
Tests run: 115, Failures: 21, Errors: 3, Skipped: 0
{noformat}
The error for this test is:
{noformat}
testSnapshotLocalMetadataUpdatedOnInstall(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest)
Time elapsed: 3.5 sec <<< FAILURE!
junit.framework.ComparisonFailure: expected:<...6...> but was:<...7...>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at
org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertLocalMetadataIsToday(MavenIT0108SnapshotUpdateTest.java:243)
at
org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotLocalMetadataUpdatedOnInstall(MavenIT0108SnapshotUpdateTest.java:215)
at
org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotLocalMetadataUpdatedOnInstall(MavenIT0108SnapshotUpdateTest.java:215)
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 junit.framework.TestCase.runTest(TestCase.java:154)
{noformat}
was:
I ran the ITs using Maven 2.0.7 and I get one additional failure with the patch
applied:
{noformat}
testSnapshotLocalMetadataUpdatedOnInstall(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest)
{noformat}
The ones that fail regardless of the patch or not are:
{noformat}
Failed tests:
testit0002(org.apache.maven.integrationtests.MavenIT0002Test)
testit0008(org.apache.maven.integrationtests.MavenIT0008Test)
testit0009(org.apache.maven.integrationtests.MavenIT0009Test)
testit0012(org.apache.maven.integrationtests.MavenIT0012Test)
testit0022(org.apache.maven.integrationtests.MavenIT0022Test)
testit0023(org.apache.maven.integrationtests.MavenIT0023Test)
testit0025(org.apache.maven.integrationtests.MavenIT0025Test)
testit0026(org.apache.maven.integrationtests.MavenIT0026Test)
testit0027(org.apache.maven.integrationtests.MavenIT0027Test)
testit0040(org.apache.maven.integrationtests.MavenIT0040Test)
testit0041(org.apache.maven.integrationtests.MavenIT0041Test)
testit0044(org.apache.maven.integrationtests.MavenIT0044Test)
testit0045(org.apache.maven.integrationtests.MavenIT0045Test)
testit0046(org.apache.maven.integrationtests.MavenIT0046Test)
testit0049(org.apache.maven.integrationtests.MavenIT0049Test)
testit0064(org.apache.maven.integrationtests.MavenIT0064Test)
testit0071(org.apache.maven.integrationtests.MavenIT0071Test)
testit0073(org.apache.maven.integrationtests.MavenIT0073Test)
testit0082(org.apache.maven.integrationtests.MavenIT0082Test)
testit0088(org.apache.maven.integrationtests.MavenIT0088Test
[jira] Created: (MRM-459) prune the distributed dependencies
prune the distributed dependencies -- Key: MRM-459 URL: http://jira.codehaus.org/browse/MRM-459 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.0-beta-1 Reporter: Brett Porter Fix For: 1.0-beta-2 a large number of unneeded dependencies are distributed with Archiva (or if they are needed, we might want to review why). For example: ant-optional (probably for jsp compiler), commons-logging impl + slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we have geronimo-jat already), classworlds (we have plexus-classworlds already), backport (we require JDK 5, no need for this). I'm also uncertain if all the maven libraries are still needed. -- 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: (MRM-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-459: - Fix Version/s: 1.0-beta-2 > prune the distributed dependencies > -- > > Key: MRM-459 > URL: http://jira.codehaus.org/browse/MRM-459 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > a large number of unneeded dependencies are distributed with Archiva (or if > they are needed, we might want to review why). > For example: ant-optional (probably for jsp compiler), commons-logging impl + > slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we > have geronimo-jat already), classworlds (we have plexus-classworlds already), > backport (we require JDK 5, no need for this). > I'm also uncertain if all the maven libraries are still needed. -- 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: (MRM-458) the NOTICE file is overzealous in declaring dependencies
[ http://jira.codehaus.org/browse/MRM-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-458: - Fix Version/s: 1.0-beta-2 > the NOTICE file is overzealous in declaring dependencies > > > Key: MRM-458 > URL: http://jira.codehaus.org/browse/MRM-458 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > we only need to say, for example, software developed by the ASF once, and all > the unnamed ones don't need to be there. > This might require fixes in the remote reosurces plugin and an update. -- 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: (MRM-458) the NOTICE file is overzealous in declaring dependencies
the NOTICE file is overzealous in declaring dependencies Key: MRM-458 URL: http://jira.codehaus.org/browse/MRM-458 Project: Archiva Issue Type: Improvement Affects Versions: 1.0-beta-1 Reporter: Brett Porter we only need to say, for example, software developed by the ASF once, and all the unnamed ones don't need to be there. This might require fixes in the remote reosurces plugin and an update. -- 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: (MRM-457) don't display the snapshot removal options in the repository list page if snapshots are not included
don't display the snapshot removal options in the repository list page if snapshots are not included Key: MRM-457 URL: http://jira.codehaus.org/browse/MRM-457 Project: Archiva Issue Type: Improvement Affects Versions: 1.0-beta-1 Reporter: Brett Porter -- 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: (MRM-456) current configuration code is too likely to complain about multiple sources
[
http://jira.codehaus.org/browse/MRM-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-456:
-
Fix Version/s: 1.0-beta-2
> current configuration code is too likely to complain about multiple sources
> ---
>
> Key: MRM-456
> URL: http://jira.codehaus.org/browse/MRM-456
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 1.0-beta-2
>
>
> those with alpha-1 are likely to have config in ~/.m2/archiva.xml.
> But the default is to distribute and work with
> ${appserver.base}/conf/archiva.xml
> This will complain whenever saving by default. I need to review the best
> distribution situation.
--
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: (MRM-456) current configuration code is too likely to complain about multiple sources
current configuration code is too likely to complain about multiple sources
---
Key: MRM-456
URL: http://jira.codehaus.org/browse/MRM-456
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-beta-1
Reporter: Brett Porter
those with alpha-1 are likely to have config in ~/.m2/archiva.xml.
But the default is to distribute and work with
${appserver.base}/conf/archiva.xml
This will complain whenever saving by default. I need to review the best
distribution situation.
--
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: (MDEPLOY-60) Make the build number available at compile time
Make the build number available at compile time --- Key: MDEPLOY-60 URL: http://jira.codehaus.org/browse/MDEPLOY-60 Project: Maven 2.x Deploy Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Antony Stubbs Make the build number which goes into the final filename of a deployed snapshot, available at compile time, so that it can be filtered into a properties file and used in the application. There are a lot of requests for this on the forum, including people trying to implement their own work-arounds [1] There could also be an option to specify a custom build number - e.g. the subversion revision number which is retrieved via the build number plug-in [2]. [1] http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177.html#a12026347 [2] http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/introduction.html -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104144
]
Brian Fox commented on WAGON-73:
I applied the relevant patches and committed to a branch here:
https://svn.apache.org/repos/asf/maven/wagon/branches/WAGON-73
Patches are easier to apply if there is one patch combining all changes
throughout the life of the issue. The patch should be created with svn from the
root of the project where the changes are to be made...otherwise the files need
to be hand-edited before applying. For example:
{noformat}
Index:
/home/philw/mavenide/wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
===
---
/home/philw/mavenide/wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
(revision 519885)
+++
/home/philw/mavenide/wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
(working copy)
{noformat}
should be
{noformat}
Index:
wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
===
---
wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
(revision 519885)
+++
wagon-manager/src/main/java/org/apache/maven/wagon/manager/MirroredWagon.java
(working copy)
{noformat}
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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] Closed: (CONTINUUM-1359) Installations removed from a profile when "Save" is clicked.
[ http://jira.codehaus.org/browse/CONTINUUM-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1359. --- Assignee: Olivier Lamy Resolution: Fixed Fix Version/s: 1.1-beta-2 fix with CONTINUUM-1361 > Installations removed from a profile when "Save" is clicked. > > > Key: CONTINUUM-1359 > URL: http://jira.codehaus.org/browse/CONTINUUM-1359 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1-beta-1 >Reporter: Eric Miles >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > > If I go into a Profile and add installations then click the "Save" button > near the name of the profile, the installations I have added are then > removed. It's a little misleading to click "Save" and to have installations > removed. -- 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] Closed: (CONTINUUM-980) After deleting a project from a group, the UI flow should return to the group summary display.
[ http://jira.codehaus.org/browse/CONTINUUM-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-980. -- Resolution: Fixed already fixed. > After deleting a project from a group, the UI flow should return to the group > summary display. > -- > > Key: CONTINUUM-980 > URL: http://jira.codehaus.org/browse/CONTINUUM-980 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Christian Gruber >Priority: Minor > Fix For: 1.1-beta-2 > > > After deleting a project from a group, the UI flow should return to the group > summary display. Currently the ui returns to the overall list of groups. -- 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: (CONTINUUM-1363) create "automatic" profiles for each installation for simpler configuration by JDK, etc.
[ http://jira.codehaus.org/browse/CONTINUUM-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1363: Attachment: CONTINUUM-1363 patch attached. > create "automatic" profiles for each installation for simpler configuration > by JDK, etc. > > > Key: CONTINUUM-1363 > URL: http://jira.codehaus.org/browse/CONTINUUM-1363 > Project: Continuum > Issue Type: Improvement > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1363 > > -- 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: (CONTINUUM-1363) create "automatic" profiles for each installation for simpler configuration by JDK, etc.
[ http://jira.codehaus.org/browse/CONTINUUM-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1363: Patch Submitted: [Yes] > create "automatic" profiles for each installation for simpler configuration > by JDK, etc. > > > Key: CONTINUUM-1363 > URL: http://jira.codehaus.org/browse/CONTINUUM-1363 > Project: Continuum > Issue Type: Improvement > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1363 > > -- 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: (CONTINUUM-1063) get rid of old models in continuum-webapp
[
http://jira.codehaus.org/browse/CONTINUUM-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104138
]
Olivier Lamy commented on CONTINUUM-1063:
-
A enum class as :
{code:title=org.apache.maven.continuum.ContinuumState.java|borderStyle=solid}
public enum ContinuumState {
NEW(1);
ContinuumState( int value )
{
this.value = value;
}
private final int value;
public int value()
{
return value;
}
}
{code}
Thoughts ?
> get rid of old models in continuum-webapp
> -
>
> Key: CONTINUUM-1063
> URL: http://jira.codehaus.org/browse/CONTINUUM-1063
> Project: Continuum
> Issue Type: Task
>Reporter: Brett Porter
> Fix For: 1.1-beta-2
>
>
> the mdo's in this directory either are not or should not be used. In
> addition, I think the ContinuumState bean in the main model belongs as a
> separate rather than generated class to avoid being caught up in the
> XML/JDO/etc processing. If we really need to generate enums, we should just
> use Java 5 already :)
--
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: (CONTINUUM-1363) create "automatic" profiles for each installation for simpler configuration by JDK, etc.
[ http://jira.codehaus.org/browse/CONTINUUM-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1363: Assignee: Olivier Lamy Fix Version/s: 1.1-beta-2 > create "automatic" profiles for each installation for simpler configuration > by JDK, etc. > > > Key: CONTINUUM-1363 > URL: http://jira.codehaus.org/browse/CONTINUUM-1363 > Project: Continuum > Issue Type: Improvement > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > -- 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: (CONTINUUM-1362) add profile page should take you to the edit page to add installations afterwards
[ http://jira.codehaus.org/browse/CONTINUUM-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1362: Affects Version/s: (was: 1.1-beta-2) 1.1-beta-1 Fix Version/s: 1.1-beta-2 > add profile page should take you to the edit page to add installations > afterwards > - > > Key: CONTINUUM-1362 > URL: http://jira.codehaus.org/browse/CONTINUUM-1362 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1362 > > > currently it goes back to the list, and you need to edit the profile to make > it useful -- 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: (CONTINUUM-1362) add profile page should take you to the edit page to add installations afterwards
[ http://jira.codehaus.org/browse/CONTINUUM-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1362: Affects Version/s: (was: 1.1-beta-1) 1.1-beta-2 Patch Submitted: [Yes] > add profile page should take you to the edit page to add installations > afterwards > - > > Key: CONTINUUM-1362 > URL: http://jira.codehaus.org/browse/CONTINUUM-1362 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1362 > > > currently it goes back to the list, and you need to edit the profile to make > it useful -- 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: (CONTINUUM-1361) saving a profile is confusing
[ http://jira.codehaus.org/browse/CONTINUUM-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1361: Fix Version/s: 1.1-beta-2 Patch Submitted: [Yes] > saving a profile is confusing > - > > Key: CONTINUUM-1361 > URL: http://jira.codehaus.org/browse/CONTINUUM-1361 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1361 > > > I added an installation "JDK 6", and then created a profile called "JDK 6" > and created it. I then went to edit, and added the installation to the > profile and hit save. The installation is not listed on the listing page, and > editing again doesn't show it. > It turns out that once an installation is added, it is added, but if you hit > save all installations are removed -- 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] Closed: (CONTINUUM-1266) Screen navigation should return to project view after adding a project to a group
[ http://jira.codehaus.org/browse/CONTINUUM-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1266. --- Assignee: Olivier Lamy Resolution: Fixed duplicate with CONTINUUM-1305. > Screen navigation should return to project view after adding a project to a > group > -- > > Key: CONTINUUM-1266 > URL: http://jira.codehaus.org/browse/CONTINUUM-1266 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Reporter: Martin Ahrer >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > > Screen navigation should return to project view after adding a project to a > group. > Imagine you need to add a larger number of projects to a group. Currently > after adding a project the UI returns to the group list. So you have to click > the group again and then click add project! > A user would be more happy if the Ui would stay in the view for the current > group (the one a project was added previously)! -- 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: (CONTINUUM-1305) after adding a project to a group from the group page, you should be returned to the group page
[ http://jira.codehaus.org/browse/CONTINUUM-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1305: Attachment: CONTINUUM-1305 patch attached > after adding a project to a group from the group page, you should be returned > to the group page > --- > > Key: CONTINUUM-1305 > URL: http://jira.codehaus.org/browse/CONTINUUM-1305 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-1305 > > > currently returned to the main group summary -- 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: (MAVENUPLOAD-1666) upload vraptor 2.4
upload vraptor 2.4 -- Key: MAVENUPLOAD-1666 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1666 Project: maven-upload-requests Issue Type: Task Reporter: Fabio Kung upload vraptor 2.2 file: http://www.vraptor.org/vraptor-2.2-bundle.jar project: http://www.vraptor.org team: http://www.vraptor.org/team-list.html VRaptor 2.2 framework update with many improvements and new docs. VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that configuration should be minimal and conventions should be maximized. -- 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: (CONTINUUM-1361) saving a profile is confusing
[ http://jira.codehaus.org/browse/CONTINUUM-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1361: Attachment: CONTINUUM-1361 patch attached > saving a profile is confusing > - > > Key: CONTINUUM-1361 > URL: http://jira.codehaus.org/browse/CONTINUUM-1361 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Attachments: CONTINUUM-1361 > > > I added an installation "JDK 6", and then created a profile called "JDK 6" > and created it. I then went to edit, and added the installation to the > profile and hit save. The installation is not listed on the listing page, and > editing again doesn't show it. > It turns out that once an installation is added, it is added, but if you hit > save all installations are removed -- 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: (CONTINUUM-1362) add profile page should take you to the edit page to add installations afterwards
[ http://jira.codehaus.org/browse/CONTINUUM-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1362: Attachment: CONTINUUM-1362 patch attached. > add profile page should take you to the edit page to add installations > afterwards > - > > Key: CONTINUUM-1362 > URL: http://jira.codehaus.org/browse/CONTINUUM-1362 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > Attachments: CONTINUUM-1362 > > > currently it goes back to the list, and you need to edit the profile to make > it useful -- 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-3100) Problem during Ant Plugin development
[ http://jira.codehaus.org/browse/MNG-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104123 ] Marat Radchenko commented on MNG-3100: -- I got the same exception for java plugin without @goal annotation. > Problem during Ant Plugin development > - > > Key: MNG-3100 > URL: http://jira.codehaus.org/browse/MNG-3100 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: Guides >Affects Versions: Documentation >Reporter: Anton Ananich >Priority: Critical > > I'm investigating this manual about Developing Ant Plugins for Maven 2.x: > http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html > I try to create the easiest HelloWorld plugin. As described in this manual: > 1) I create Ant script > 2) I create mojo > 3) I create pom > 4) I build it and install (successfully) > And than I try to run it: > c:\> mvn org.myproject.plugins:hello-plugin:hello > Here is what I got: > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException >at > org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo(PluginDescriptor.java:262) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1529) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:386) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138) >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) > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Tue Jul 10 20:02:10 EEST 2007 > [INFO] Final Memory: 1M/2M > [INFO] > -- 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] Closed: (CONTINUUM-1239) After loss of network connectivity, build status remains in ERROR
[ http://jira.codehaus.org/browse/CONTINUUM-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1239. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 > After loss of network connectivity, build status remains in ERROR > - > > Key: CONTINUUM-1239 > URL: http://jira.codehaus.org/browse/CONTINUUM-1239 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.0.3, 1.1-alpha-1 > Environment: Windows XP >Reporter: D Walker >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > > After loss of network connectivity, build status set to ERROR (because svn > cannot checkout). When connectivity returns, build is not rerun, and status > left at ERROR. > Here is an example log file: > You can see that the build is proceeding fine every 30 minutes, then it fails > because I lose internet connectivity. When the connection recovers and > jmux.svn.sourceforge.net is able to be resolved, the build is not rerun. > This is fine, in theory, because there were no changes, however, the status > should be set to 'SUCCESS' again. > INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,384 [Thread-2] > INFO ContinuumScm - Updating project: id: '1', name 'jmux > - Java Modules Using XML'. > INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] > INFO ScmManager - Executing: svn --non-interactive update > INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] > INFO ScmManager - Working directory: > D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 > INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,109 [Thread-35] > DEBUG ScmManager - At revision 20. > INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,230 [Thread-2] > INFO BuildController- The project was not built because > there are no changes. > INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,012 > [defaultScheduler_Worker-7] INFO SchedulesActivator - > > Executing build job (DEFAULT_SCHEDULE)... > INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,082 > [defaultScheduler_Worker-7] INFO Continuum - Enqueuing > 'jmux - Java Modules Using XML' (Build definition id=1). > INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,362 [Thread-2] > INFO ContinuumScm - Updating project: id: '1', name 'jmux > - Java Modules Using XML'. > INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] > INFO ScmManager - Executing: svn --non-interactive update > INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] > INFO ScmManager - Working directory: > D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 > INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] > WARN ContinuumScm - Error while updating the code for > project: 'jmux - Java Modules Using XML', id: '1' to > 'D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1'. > INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] > WARN ContinuumScm - Command output: svn: PROPFIND request > failed on '/svnroot/jmux/trunk' > INFO | jvm 1| 2007/04/04 15:30:16 | svn: PROPFIND of > '/svnroot/jmux/trunk': Could not resolve hostname `jmux.svn.sourceforge.net': > The requested name is valid and was found in the database, but it does not > have the correct associated data being resolved for. > (http://jmux.svn.sourceforge.net) > INFO | jvm 1| 2007/04/04 15:30:16 | > INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,145 [Thread-2] > WARN ContinuumScm - Provider message: The svn command > failed. > INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] > INFO Notifier:mail - Sending message: From '"[EMAIL > PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] > INFO Notifier:mail - Recipient: To '<[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: setDebug: JavaMail version > 1.3.2 > INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: getProvider() returning > javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun > Microsystems, Inc] > INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG SMTP: useEhlo true, useAuth > false > INFO | jvm 1| 200
[jira] Updated: (CONTINUUM-1361) saving a profile is confusing
[ http://jira.codehaus.org/browse/CONTINUUM-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1361: Assignee: Olivier Lamy > saving a profile is confusing > - > > Key: CONTINUUM-1361 > URL: http://jira.codehaus.org/browse/CONTINUUM-1361 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Olivier Lamy > > I added an installation "JDK 6", and then created a profile called "JDK 6" > and created it. I then went to edit, and added the installation to the > profile and hit save. The installation is not listed on the listing page, and > editing again doesn't show it. > It turns out that once an installation is added, it is added, but if you hit > save all installations are removed -- 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: (CONTINUUM-1365) unable to edit the name of an installation already created
[ http://jira.codehaus.org/browse/CONTINUUM-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1365: Fix Version/s: Future > unable to edit the name of an installation already created > -- > > Key: CONTINUUM-1365 > URL: http://jira.codehaus.org/browse/CONTINUUM-1365 > Project: Continuum > Issue Type: Improvement > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter > Fix For: Future > > -- 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] Closed: (CONTINUUM-617) javax.jdo.JDODataStoreException: Insert request failed
[
http://jira.codehaus.org/browse/CONTINUUM-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-617.
--
Assignee: Emmanuel Venisse
Resolution: Cannot Reproduce
> javax.jdo.JDODataStoreException: Insert request failed
> --
>
> Key: CONTINUUM-617
> URL: http://jira.codehaus.org/browse/CONTINUUM-617
> Project: Continuum
> Issue Type: Bug
> Components: Core system, Database
>Affects Versions: 1.0.2
>Reporter: Brian Fox
>Assignee: Emmanuel Venisse
> Fix For: 1.1-beta-2
>
>
> This happened apparently randomly during a scheduled build. On the next
> scheduled build, it was successfull.
>
> Build Error:
>
> javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO
> PROJECTDEPENDENCY (PROJECTDEPENDENCY_ID,ARTIFACT_ID,VERSION,GROUP_ID) VALUES
> (?,?,?,?)
>at
> org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:329)
>at
> org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1774)
>at org.jpox.store.StoreManager.insert(StoreManager.java:721)
>at
> org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3066)
>at
> org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3039)
>at
> org.jpox.state.StateManagerImpl.attachCopy(StateManagerImpl.java:3452)
>at
> org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1644)
>at org.jpox.sco.List.attachCopy(List.java:326)
>at
> org.jpox.state.AttachFieldManager.storeObjectField(AttachFieldManager.java:107)
>at
> org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2394)
>at
> org.apache.maven.continuum.model.project.Project.jdoProvideField(Project.java)
>at
> org.apache.maven.continuum.model.project.Project.jdoProvideFields(Project.java)
>at
> org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:2732)
>at
> org.jpox.state.StateManagerImpl.internalAttachCopy(StateManagerImpl.java:3518)
>at
> org.jpox.state.StateManagerImpl.attachCopy(StateManagerImpl.java:3446)
>at
> org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1644)
>at
> org.jpox.AbstractPersistenceManager.attachCopy(AbstractPersistenceManager.java:1660)
>at
> org.apache.maven.continuum.store.JdoContinuumStore.updateObject(JdoContinuumStore.java:679)
>at
> org.apache.maven.continuum.store.JdoContinuumStore.updateProject(JdoContinuumStore.java:841)
>at
> org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:94)
>at
> org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:171)
>at
> org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53)
>at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
>at java.lang.Thread.run(Thread.java:534)
> NestedThrowablesStackTrace:
> ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks
> and waiters is:
> Lock : ROW, PROJECTDEPENDENCY, (1614,14)
> Waiting XID : {31204919, X} , SA, INSERT INTO PROJECTDEPENDENCY
> (PROJECTDEPENDENCY_ID,ARTIFACT_ID,VERSION,GROUP_ID) VALUES (?,?,?,?)
> Granted XID : {31204120, X}
> Lock : ROW, PROJECT, (1,34)
> Waiting XID : {31204120, S} , SA, UPDATE PROJECTDEPENDENCY SET
> DEPENDENCIES_ID_OWN = ?,DEPENDENCIESINTEGER_IDX = ? WHERE
> PROJECTDEPENDENCY_ID = ?
> Granted XID : {31204919, X}
> . The selected victim is XID : 31204919.
>at
> org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>at
> org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown Source)
>at
> org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Source)
>at
> org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown Source)
>at
> org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown Source)
>at
> org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown
> Source)
>at
> org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown Source)
>
[jira] Created: (MCLOVER-81) Clover Plugin Errors Out with "code too large" Error
Clover Plugin Errors Out with "code too large" Error Key: MCLOVER-81 URL: http://jira.codehaus.org/browse/MCLOVER-81 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Microsoft Windows Maven 2.0.6 Reporter: David Williams The maven plugin errors out on a java file that is 250 KB with "code too large" error. This error does not occur on the regular Maven compile. Below is the pieces of the Maven build log. [INFO] [clover:instrumentInternal] Clover Version 1.3.13, built on September 04 2006 loaded from: C:\Documents and Settings\me\.m2\repository\com\cenqua\clover\clover\1.3.13\clover-1.3.13.jar No coverage database 'C:\OmniESF\Workspaces\adminweb\OmniManager534\target/clover/clover.db' found. Creating a fresh one. Processing files at 1.4 source level. Instrumented 2557 source files. [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 2557 source files to C:\Workspaces\myGroup\myApp\target\clover\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Workspaces\myGroup\myApp\target\clover\src\com\myCompany\stnweb\formdata\myFile.java:[45,15] code too large C:\Workspaces\myGroup\myApp\target\clover\src\com\myCompany\stnweb\formdata\myFile.java:[45,15] code too large -- 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: (MASSEMBLY-229) Documentation of fileMode could be improved to avoid user trip hazard
Documentation of fileMode could be improved to avoid user trip hazard - Key: MASSEMBLY-229 URL: http://jira.codehaus.org/browse/MASSEMBLY-229 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Environment: n/a Reporter: Kelvin Goodson Priority: Minor The website documentation for the fileMode parameter that occurs in a number of places in the assembly descriptor format description such as [1] does show a leading 0 for its values, but it isn't clear that this is to declare the value as octal. Anyone who is used to using the chmod command on *nix doesn't expect to have to prefix the octal value with a 0, and therefore might assume the 0 to be an insignificant digit. It would be helpful to add a comment in the descriptions of these parameters that the value is interpreted as decimal unless preceded by a leading 0 to indicate an octal value. [1] http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_file -- 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] Closed: (CONTINUUM-1243) wording to explain no-build case
[ http://jira.codehaus.org/browse/CONTINUUM-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1243. --- Assignee: Emmanuel Venisse Resolution: Fixed > wording to explain no-build case > > > Key: CONTINUUM-1243 > URL: http://jira.codehaus.org/browse/CONTINUUM-1243 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.0 > Environment: windows XP java 1.5 >Reporter: Larry Hamel >Assignee: Emmanuel Venisse >Priority: Trivial > Fix For: 1.1-beta-2 > > > If there are no files changed in source, the message in the Continuum log is: > - The project was not built because all changes are unknown. > This is confusing wording. Can you change that to something like: > - - The project was not built because no changes were detected in source > since the last build. > thanks! -- 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] Closed: (CONTINUUM-1211) Mail notification sent for Succes even though it is configured for Error, Failure and Warning only
[ http://jira.codehaus.org/browse/CONTINUUM-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1211. --- Assignee: Emmanuel Venisse Resolution: Fixed > Mail notification sent for Succes even though it is configured for Error, > Failure and Warning only > -- > > Key: CONTINUUM-1211 > URL: http://jira.codehaus.org/browse/CONTINUUM-1211 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail > Environment: SVN-copy of continuum (14/03/07), Maven 2.0.4 >Reporter: Stefan Seidel >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-beta-2 > > > I have set a mail notifier for a project group for the events Error, Failure > and Warning. Still I got emails for every successful build, too. This did > only happen when the project was built for the first time. -- 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: (MJAVADOC-141) regression: Adding "jar" execution to the parent of a multi-module javadoc plugin causes "recursive invocations" error
[ http://jira.codehaus.org/browse/MJAVADOC-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104104 ] Mike Youngstrom commented on MJAVADOC-141: -- I have the above in the section and I have below in the section since I don't believe it's possible to add executions to plugings in the section??? org.apache.maven.plugins maven-javadoc-plugin 2.3 true > regression: Adding "jar" execution to the parent of a multi-module javadoc > plugin causes "recursive invocations" error > -- > > Key: MJAVADOC-141 > URL: http://jira.codehaus.org/browse/MJAVADOC-141 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Mike Youngstrom > > I have a multimodule project with the javadoc plugin declared in my parent. > > org.apache.maven.plugins > maven-javadoc-plugin > 2.3 > > true > > > > attach-javadocs > > jar > > > > > After upgrading to 2.3 and do a build I now get the error: > [WARNING] Removing: jar from forked lifecycle, to prevent recursive > invocation. > [INFO] No goals needed for project - skipping > Which then skips the processing of that module and later gives me dependency > errors because previous dependencies were not compiled. > If I remove jar processing from my plugin definition everything works fine > except no javadoc jars are created. -- 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] Closed: (CONTINUUM-1255) FATAL EnvironmentCheck Failure on Continuum Startup
[ http://jira.codehaus.org/browse/CONTINUUM-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1255. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-alpha-2 > FATAL EnvironmentCheck Failure on Continuum Startup > --- > > Key: CONTINUUM-1255 > URL: http://jira.codehaus.org/browse/CONTINUUM-1255 > Project: Continuum > Issue Type: Sub-task >Affects Versions: 1.1-alpha-1 > Environment: JBoss 4.0.5.GA, JDK 1.4.2_12 >Reporter: Gabriel Misura >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-2 > > > 42734 [http-0.0.0.0-8080-1] INFO > org.codehaus.plexus.security.system.check.EnvironmentCheck:required-roles - > Checking the existance of required roles. > 43501 [http-0.0.0.0-8080-1] FATAL > com.opensymphony.xwork.interceptor.Interceptor:pssEnvironmentCheckInterceptor > - EnvironmentCheck Failure. > == > ENVIRONMENT FAILURE !! > Missing "/security" package namespace in xwork.xml > Missing [1] xwork.xml configuration elements. > == > 43651 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 43876 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 43886 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 45228 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssForceAdminUserInterceptor > - Admin user found. No need to configure admin user. > 49640 [http-0.0.0.0-8080-2] INFO > com.opensymphony.webwork.views.freemarker.FreemarkerManager - Instantiating > Freemarker ConfigManager!, > com.opensymphony.webwork.views.freemarker.FreemarkerManager -- 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: (MECLIPSE-314) PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure
PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure -- Key: MECLIPSE-314 URL: http://jira.codehaus.org/browse/MECLIPSE-314 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: PDE support Affects Versions: 2.4 Environment: java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) Reporter: Graham Leggett Attachments: pde-reactor-fix.patch When the eclipse:eclipse goal synchronises MANIFEST.MF during PDE builds, all reactor projects are accidently left off the dependency list that gets written to Bundle-Classpath. This causes the PDE build to fail. The attached patch fixes this issue by inserting the missing reactor dependencies when writing the Bundle-Classpath. -- 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] Closed: (CONTINUUM-1008) Cannot remove a project
[ http://jira.codehaus.org/browse/CONTINUUM-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1008. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 > Cannot remove a project > --- > > Key: CONTINUUM-1008 > URL: http://jira.codehaus.org/browse/CONTINUUM-1008 > Project: Continuum > Issue Type: Bug >Reporter: Emmanuel Lécharny >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-1 > > Attachments: error.txt > > > I tried to remove some projects from my continuum configuration, and I get an > error (cf attachment). > It seems that the DB is in an inconsistant state. -- 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] Closed: (CONTINUUM-803) Unable to upload pom
[ http://jira.codehaus.org/browse/CONTINUUM-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-803. -- Assignee: Emmanuel Venisse Resolution: Cannot Reproduce Fix Version/s: (was: 1.1-beta-2) > Unable to upload pom > > > Key: CONTINUUM-803 > URL: http://jira.codehaus.org/browse/CONTINUUM-803 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: Linux FC4, Maven 2.0.4, JDK 1.5 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Emmanuel Venisse > > When uploading a pom, I see the ff In the logs: > 21:09:41,890 ERROR > com.opensymphony.webwork.dispatcher.multipart.MultiPartRequest > [com.opensymphony.webwork.dispatcher.multipart.JakartaMultiPartRequest] > org.apache.commons.fileupload.FileUploadException: Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:41,893 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor > [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:42,349 ERROR com.opensymphony.webwork.interceptor.FileUploadInterceptor > [com.opensymphony.webwork.interceptor.FileUploadInterceptor] Processing of > multipart/form-data request failed. > ~/tmp/upload__376f5d97_10cd425ed0c__8000_0001.tmp (No such file or > directory) > 21:09:42,369 WARN com.opensymphony.xwork.DefaultActionInvocation > [com.opensymphony.xwork.DefaultActionInvocation] No result defined for action > org.apache.maven.continuum.web.action.ConfigurationAction and result input -- 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] Closed: (CONTINUUM-722) Project should be built again if svn command fails
[ http://jira.codehaus.org/browse/CONTINUUM-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-722. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-alpha-2 > Project should be built again if svn command fails > -- > > Key: CONTINUUM-722 > URL: http://jira.codehaus.org/browse/CONTINUUM-722 > Project: Continuum > Issue Type: Wish > Components: Core system >Affects Versions: 1.0.3 >Reporter: Laszlo Hornyak Kocka >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-2 > > > If the subversion server goes down, continuum sends a build error message, > which is good, but it wont try to build it again after the subversion server > goes online again, so one needs to rebuild the failed projects manualy. -- 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] Closed: (CONTINUUM-791) put the 3 project buttons next to the project name rather than on the far right hand side
[ http://jira.codehaus.org/browse/CONTINUUM-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-791. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: 1.1-beta-2) > put the 3 project buttons next to the project name rather than on the far > right hand side > - > > Key: CONTINUUM-791 > URL: http://jira.codehaus.org/browse/CONTINUUM-791 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0.3 >Reporter: james strachan >Assignee: Emmanuel Venisse > Attachments: CONTINUUM-791.jpg, CONTINUUM-791.patch > > > When you want to click on a project to build it, edit its details or view its > results, you normally are looking at the project name. However right now the > buttons are as far as is humanly possiblie from the actual name of the > project. When you've a big screen full of different projects its quite an > effort to make sure you are clicking on the right button for the build you > actually want. > How about putting the buttons on the left hand side so they are right next to > the project name - or at least in column 2 next to the project name rather > than after all the other stuff -- 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] Closed: (CONTINUUM-1281) Cannot remove build definitions
[ http://jira.codehaus.org/browse/CONTINUUM-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1281. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 > Cannot remove build definitions > --- > > Key: CONTINUUM-1281 > URL: http://jira.codehaus.org/browse/CONTINUUM-1281 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-1 > Environment: Windows 2003 server >Reporter: Kristoffer Moum >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-1 > > Attachments: deleteBuildDefinitionStacktrace.txt > > > I cannot delete build definitions from my multi-module Continuum installation > (see the attached stackTrace). -- 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] Closed: (CONTINUUM-1304) cannot un-set deployment repository directory in configuration page
[ http://jira.codehaus.org/browse/CONTINUUM-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1304. --- Assignee: Emmanuel Venisse Resolution: Fixed > cannot un-set deployment repository directory in configuration page > --- > > Key: CONTINUUM-1304 > URL: http://jira.codehaus.org/browse/CONTINUUM-1304 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 >Reporter: Brett Porter >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-2 > > > once it's set, unsetting it clears it on the next page, but it returns as it > is not persisted to the database -- 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: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104093 ] Wouter de Vaal commented on MRM-243: I found out I can't delete the maven-metadata.xml file after the first time, so the file is locked. After unlocking the file with a utility (http://ccollomb.free.fr/unlocker/) I can deploy the file again. So somewhere a file is not closed correctly. But without stacktraces I guess it is hard to find which code is keeping the lock on the file, but it only occurs with maven-metadata file. Maybe this helps. This is also the reason why it only occurs on windows servers, unix-based system do not impose such a vicious locking mechanism as windows does. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen > Fix For: 1.0-beta-2 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104091 ] Wouter de Vaal edited comment on MRM-243 at 8/6/07 7:53 AM: I have the same issue, on both client and server I have maven 2.0.7 and archiva is installed with plexus. The server is a Windows 2003 box. Temp directories and permissions on it look just fine by me. Also no stacktraces are shown in any log. was: I have the same issue, on both client and server I have maven 2.0.7 and archiva is installed with plexus. The server is a Windows 2003 box. Temp directories and permissions on it look just fine by me. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen > Fix For: 1.0-beta-2 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104091 ] Wouter de Vaal commented on MRM-243: I have the same issue, on both client and server I have maven 2.0.7 and archiva is installed with plexus. The server is a Windows 2003 box. Temp directories and permissions on it look just fine by me. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen > Fix For: 1.0-beta-2 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MJAR-78) jar:sign skip option does not work
[ http://jira.codehaus.org/browse/MJAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Perkins updated MJAR-78: - Attachment: MJAR-78-maven-jar-plugin.patch Added return statement after message about skipping jar signing, so that signing will actually not happen. > jar:sign skip option does not work > -- > > Key: MJAR-78 > URL: http://jira.codehaus.org/browse/MJAR-78 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: Ryan Perkins >Priority: Minor > Fix For: 2.2 > > Attachments: MJAR-78-maven-jar-plugin.patch > > > The skip option added to jar:sign in MJAR-23 prints a message saying that > signing will be skipped, but signing still happens. -- 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: (MJAR-78) jar:sign skip option does not work
[ http://jira.codehaus.org/browse/MJAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104083 ] Ryan Perkins edited comment on MJAR-78 at 8/6/07 6:07 AM: -- Patch adds a return statement after printing the message about skipping jar signing, so that signing will actually not happen. was: Added return statement after message about skipping jar signing, so that signing will actually not happen. > jar:sign skip option does not work > -- > > Key: MJAR-78 > URL: http://jira.codehaus.org/browse/MJAR-78 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: Ryan Perkins >Priority: Minor > Fix For: 2.2 > > Attachments: MJAR-78-maven-jar-plugin.patch > > > The skip option added to jar:sign in MJAR-23 prints a message saying that > signing will be skipped, but signing still happens. -- 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: (MJAR-78) jar:sign skip option does not work
jar:sign skip option does not work -- Key: MJAR-78 URL: http://jira.codehaus.org/browse/MJAR-78 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1, 2.2 Reporter: Ryan Perkins Priority: Minor Fix For: 2.2 The skip option added to jar:sign in MJAR-23 prints a message saying that signing will be skipped, but signing still happens. -- 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: (MRM-455) Repository Browse not updated after repository purge although the database is updated during the purge
Repository Browse not updated after repository purge although the database is updated during the purge -- Key: MRM-455 URL: http://jira.codehaus.org/browse/MRM-455 Project: Archiva Issue Type: Bug Components: browser Affects Versions: 1.0-beta-1 Reporter: Maria Odea Ching Please see comments on MRM-294 for more info -- 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: (MRM-454) Index not updated after repository purge
Index not updated after repository purge Key: MRM-454 URL: http://jira.codehaus.org/browse/MRM-454 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0-beta-1 Reporter: Maria Odea Ching Please see comments MRM-294 for more info -- 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-3135) Enable skipping clean:clean goal in verifier
Enable skipping clean:clean goal in verifier Key: MNG-3135 URL: http://jira.codehaus.org/browse/MNG-3135 Project: Maven 2 Issue Type: Improvement Components: integration tests Affects Versions: Shared Components Reporter: Arnaud Bailly Priority: Trivial Attachments: autoclean.patch WHen using maven-verifier, clean:clean goal is automatically added at the start of the execution of the plugin. The attached patch simply adds an autoclean property to the verifier that is 'true' by default but may be unset. -- 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-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104077
]
Jason Dillon commented on MNG-2486:
---
Copying my comments from MNG-2796
IMO, maven should *never* change the value of ${pom.version} ... if a pom says:
{code}
...
1.2-SNAPSHOT
...
{code}
Then ${pom.version} should *always* resolve to {{1.2-SNAPSHOT}}. If you need to
know what the _timestamp-build_ version is then I suggest adding
${pom.effectiveVersion} which can change dynamically.
Also, I can hear this coming... "why don't you use ...".
This feature of Maven is great for managing _external_ dependencies, but for
internal module management it becomes unmanageable quickly.
For Geronimo, we have ~200+ modules and to enumerate each one of those in a
is unruly, and tends to become unmaintained quickly. Its
much easier to use ${pom.version} in poms when defining
dependencies sibling modules.
But, as noted by David, this won't work when dealing with snapshots as when
deploying a snapshot, the module being deployed will have its ${pom.version}
changed magically to the _timestamp-build_ version which is going to produce
invalid dependencies, since the dependencies using
${pom.version} now have invalid versions (using the deployed
modules _timestamp-build_ version not the _timestamp-build_ version of the
dependency.
I really think the best way to handle this is to never change the value of
${pom.version} and introduce a ${pom.effectiveVersion} which will dynamically
change.
* * *
I'd really, really really really, really like to see this get fixed sooner
rather than later. I think a pom.version that doesn't change and a
pom.effectiveVersion that does change (to reflect the SNAPSHOT's
timestamp-buildnumber) would be a fine solution... *hint* *hint*
> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
>
>
> Key: MNG-2486
> URL: http://jira.codehaus.org/browse/MNG-2486
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
>Reporter: John Casey
>Priority: Critical
> Fix For: 2.0.8, 2.1-alpha-1
>
>
> when projects specify dependencyManagement sections with a shorthand version
> notation using the current project version (using ${project.version}) the
> version resolved will be that of the POM in which the dependencyManagement
> section is specified. If this POM is a snapshot, these dependency
> specifications will get the timestamp/buildnumber of that POM, instead of the
> actual one used when the dependency it references gets deployed.
> We should look at strategies for limiting or eliminating this practice, or
> else (somehow) pulling the real timestamp/buildnumber for that artifact from
> the reactor...in order to make these deps transitively resolvable for users.
--
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: (MAVENUPLOAD-1619) Please upload XMLUnit for Java 1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104070 ] Erik van Oosten commented on MAVENUPLOAD-1619: -- Meanwhile, is there another repository? > Please upload XMLUnit for Java 1.1 > -- > > Key: MAVENUPLOAD-1619 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1619 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Stefan Bodewig >Assignee: Carlos Sanchez > > XMLUnit for Java 1.1 has been released today. > http://xmlunit.sf.net/ > I am listed as a project admin at http://sourceforge.net/projects/xmlunit/ -- 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: (MRM-453) Create missing tests for repository purge
[ http://jira.codehaus.org/browse/MRM-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-453: - Fix Version/s: 1.0-beta-2 > Create missing tests for repository purge > - > > Key: MRM-453 > URL: http://jira.codehaus.org/browse/MRM-453 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-beta-1 >Reporter: Maria Odea Ching > Fix For: 1.0-beta-2 > > > Comments from MRM-294: > A general thought here too, for later: it might be worth reviewing the > exceptions that can occur in *Purge and see if we can recover better from > each rather than bubbling it > Tests: > * I think you can remove many of the components from the test XML files > where the default suffice (just keep the registry and jdo factory) > * the tests have a lot of bolierplate that can probably be turned into > methods that generate test data > Missing tests: > * no tests for the consumer or the Released Snapshots purge > * days old test is only testing by file age - it should also test the > metadata-driven snapshots > A general thought for Archiva in the long term, too... setting up the > database to test this was probably a pain. We should have stub > implementations of the indexer and dao's to avoid it. -- 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: (MRM-453) Create missing tests for repository purge
Create missing tests for repository purge - Key: MRM-453 URL: http://jira.codehaus.org/browse/MRM-453 Project: Archiva Issue Type: Improvement Affects Versions: 1.0-beta-1 Reporter: Maria Odea Ching Comments from MRM-294: A general thought here too, for later: it might be worth reviewing the exceptions that can occur in *Purge and see if we can recover better from each rather than bubbling it Tests: * I think you can remove many of the components from the test XML files where the default suffice (just keep the registry and jdo factory) * the tests have a lot of bolierplate that can probably be turned into methods that generate test data Missing tests: * no tests for the consumer or the Released Snapshots purge * days old test is only testing by file age - it should also test the metadata-driven snapshots A general thought for Archiva in the long term, too... setting up the database to test this was probably a pain. We should have stub implementations of the indexer and dao's to avoid it. -- 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: (MRM-294) Repository purge feature for snapshots
[ http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104068 ] Brett Porter commented on MRM-294: -- don't forget to create an issue for the index purge and the browse problem too :) > Repository purge feature for snapshots > -- > > Key: MRM-294 > URL: http://jira.codehaus.org/browse/MRM-294 > Project: Archiva > Issue Type: New Feature >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > We need a way to purge a repository of snapshots older than a certain date, > (optionally retaining the most recent one) and fixing the metadata. -- 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] Closed: (MRM-294) Repository purge feature for snapshots
[ http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-294. Resolution: Fixed Applied above comments in -r563064. Btw, some of the exceptions mentioned above are intended to be swallowed. I added a @todo for these to log the errors in the console. I'll just open a separate jira issue for the missing tests. Thanks! :) > Repository purge feature for snapshots > -- > > Key: MRM-294 > URL: http://jira.codehaus.org/browse/MRM-294 > Project: Archiva > Issue Type: New Feature >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > We need a way to purge a repository of snapshots older than a certain date, > (optionally retaining the most recent one) and fixing the metadata. -- 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
