[jira] Reopened: (MPJAVACC-6) Documentation is missing for package parameters
[ http://jira.codehaus.org/browse/MPJAVACC-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl reopened MPJAVACC-6: -- > Documentation is missing for package parameters > --- > > Key: MPJAVACC-6 > URL: http://jira.codehaus.org/browse/MPJAVACC-6 > Project: Maven 1.x JavaCC Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: dion gillard >Assignee: Lukas Theussl > Fix For: 1.2.1 > > Attachments: properties.xml.package.patch > > > maven.javacc.javacc.package > and > maven.javacc.jjtree.package > property docs are missing. -- 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: (MPJAVACC-6) Documentation is missing for package parameters
[ http://jira.codehaus.org/browse/MPJAVACC-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPJAVACC-6. Resolution: Fixed > Documentation is missing for package parameters > --- > > Key: MPJAVACC-6 > URL: http://jira.codehaus.org/browse/MPJAVACC-6 > Project: Maven 1.x JavaCC Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: dion gillard >Assignee: Lukas Theussl > Fix For: 1.3 > > Attachments: properties.xml.package.patch > > > maven.javacc.javacc.package > and > maven.javacc.jjtree.package > property docs are missing. -- 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: (MPJAVACC-7) Update to JavaCC 4.0
[ http://jira.codehaus.org/browse/MPJAVACC-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPJAVACC-7. Assignee: Lukas Theussl Resolution: Fixed > Update to JavaCC 4.0 > > > Key: MPJAVACC-7 > URL: http://jira.codehaus.org/browse/MPJAVACC-7 > Project: Maven 1.x JavaCC Plugin > Issue Type: Improvement >Reporter: dion gillard >Assignee: Lukas Theussl >Priority: Minor > Fix For: 1.3 > > Attachments: javacc-upgradeto4.patch > > > This allows use of some very handy new options e.g. NODE_EXTENDS -- 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: (SUREFIRE-397) Failing tests
Failing tests - Key: SUREFIRE-397 URL: http://jira.codehaus.org/browse/SUREFIRE-397 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4 Environment: ubuntu gutsy, java 1.6 Reporter: Erik Drolshammer Tests in error: testTestNgTestWithSpaces(org.apache.maven.surefire.its.TestNgPathWithSpaces) testTestNgBeforeMethodFailure(org.apache.maven.surefire.its.TestNgBeforeMethodFailure) testSingleTestNonExistent(org.apache.maven.surefire.its.TestSingleTest) testFailIfNoTestsForkModeAlways(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) testFailIfNoTestsForkModeNever(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) testFailIfNoTestsForkModeOnce(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) testFailIfNoTests(org.apache.maven.surefire.its.TestFailIfNoTests) testTimeoutForked(org.apache.maven.surefire.its.TimeoutForkedTest) testUmlaut(org.apache.maven.surefire.its.UmlautDirTest) -- 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: (SUREFIRE-397) Failing tests
[ http://jira.codehaus.org/browse/SUREFIRE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115660 ] Brett Porter commented on SUREFIRE-397: --- I've also noticed that these don't report a failure when using the latest surefire - which seems a more critical problem > Failing tests > - > > Key: SUREFIRE-397 > URL: http://jira.codehaus.org/browse/SUREFIRE-397 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 > Environment: ubuntu gutsy, java 1.6 >Reporter: Erik Drolshammer > > Tests in error: > testTestNgTestWithSpaces(org.apache.maven.surefire.its.TestNgPathWithSpaces) > > testTestNgBeforeMethodFailure(org.apache.maven.surefire.its.TestNgBeforeMethodFailure) > testSingleTestNonExistent(org.apache.maven.surefire.its.TestSingleTest) > > testFailIfNoTestsForkModeAlways(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) > > testFailIfNoTestsForkModeNever(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) > > testFailIfNoTestsForkModeOnce(org.apache.maven.surefire.its.TestFailIfNoTestsForkMode) > testFailIfNoTests(org.apache.maven.surefire.its.TestFailIfNoTests) > testTimeoutForked(org.apache.maven.surefire.its.TimeoutForkedTest) > testUmlaut(org.apache.maven.surefire.its.UmlautDirTest) -- 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: (MECLIPSE-358) plugin installed via eclipse:install-plugins have the wrong name
[ http://jira.codehaus.org/browse/MECLIPSE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115659 ] luigi malpeli commented on MECLIPSE-358: Thanks Carlos, I did it already. It works fine. I Didn't check all the eclipse plugins but about file names works properly now. I think we can close the bug. > plugin installed via eclipse:install-plugins have the wrong name > > > Key: MECLIPSE-358 > URL: http://jira.codehaus.org/browse/MECLIPSE-358 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Dependencies resolution and build path >Affects Versions: 2.4, 2.5 > Environment: jdk 1.5.0_12 eclipse 3.2.x maven 2.0.7 win xp > professional >Reporter: luigi malpeli >Assignee: Carlos Sanchez > Attachments: eclipse-create.zip, eclipse-plugin-patch.txt, > eclipse.patch > > > when processing eclipse:install-plugins the plugins are installed using just > the artifactId as name. This gives problems at least in the following cases: > 1) when trying to modify/construct from scratch an original eclipse > installation; > 2) when trying to install different plugins with the same artifactId and > version but different groupId, the first installed atrifact or the latter > wins depending on the overwrite=false/true parameter setting; > In my opinion the name should be a concat of the groupid a dot and the > current proposed name. > I'll attach a proposed patch and some test files ASAP. -- 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: (MINVOKER-15) http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER"
http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER" -- Key: MINVOKER-15 URL: http://jira.codehaus.org/browse/MINVOKER-15 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Gerhard Langs Assignee: John Casey Priority: Minor Subject should say it all. People trying to look at the issues of the invoker plugin are directed to the wrong place -- 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: (MINVOKER-16) http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER"
http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER" -- Key: MINVOKER-16 URL: http://jira.codehaus.org/browse/MINVOKER-16 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: Gerhard Langs Assignee: John Casey Priority: Minor Subject should say it all. People trying to look at the issues of the invoker plugin are directed to the wrong place -- 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: (MPMD-54) "excludes" appears to be ignored under Linux, even though it works fine under Windows
[ http://jira.codehaus.org/browse/MPMD-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115665 ] Immo Huneke commented on MPMD-54: - Hi Xavier, Sorry, that was many months ago and I have moved on to a different project. I therefore don't have an example I can show you. If this problem doesn't get reported by anyone else, it probably isn't important. If anyone has an explicit example where the exclude configuration fails under Linux but works under Windows, please post it here. Best regards, Immo. > "excludes" appears to be ignored under Linux, even though it works fine under > Windows > - > > Key: MPMD-54 > URL: http://jira.codehaus.org/browse/MPMD-54 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: CPD, PMD >Affects Versions: 2.2 > Environment: Red Hat Enterprise Linux 3 (64bit) >Reporter: Immo Huneke >Priority: Minor > > The "excludes" configuration does not seem to work in all environments. In > my project I find that if I express the "excludes" clause in any of the > following ways, it is honoured under Windows, but the affected source files > are still included when the same project is built under Linux. I have > explicitly made sure that version 2.2 of the PMD plugin is being used and > that the same version of Maven is used in both environments: > > **/generated-sources/ > > > **/generated-sources/** > > > **/generated-sources/**/*.java > -- 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: (MASSEMBLY-243) Support for patching
[ http://jira.codehaus.org/browse/MASSEMBLY-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115679 ] Frank Cornelis commented on MASSEMBLY-243: -- Thanks, will check out the maven-patch-plugin. > Support for patching > > > Key: MASSEMBLY-243 > URL: http://jira.codehaus.org/browse/MASSEMBLY-243 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Frank Cornelis > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > What I'm still missing from Ant is the ability to apply patches to assemblies > that you're creating via the maven-assembly-plugin. > In our project we're using JBoss AS bundled as a ZIP. To create a final > distribution of the product we unpack and then have to change quite some > configuration files within the JBoss AS tree. The problem right now is that > for every JBoss AS update we have to re-patch the configuration files > manually. It would be great if the maven-assembly-plugin would have inherent > support for patches. That way it's also more clear what configuration section > you're changing exactly. > See also: http://ant.apache.org/manual/CoreTasks/patch.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] Updated: (MRM-606) docs appear in wrong directory for Archiva 1.0 release
[ http://jira.codehaus.org/browse/MRM-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-606: - Fix Version/s: 1.1 > docs appear in wrong directory for Archiva 1.0 release > -- > > Key: MRM-606 > URL: http://jira.codehaus.org/browse/MRM-606 > Project: Archiva > Issue Type: Bug > Components: build >Affects Versions: 1.0 >Reporter: Brett Porter > Fix For: 1.1 > > > while it is fine on trunk, the docs appear in an archiva-1.0-docs.zip > subdirectory of the released distribution - check whether we need to lock > down to a better assembly plugin version -- 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-605) unit tests fail on archiva 1.0 source distribution
[ http://jira.codehaus.org/browse/MRM-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-605: - Fix Version/s: 1.1 > unit tests fail on archiva 1.0 source distribution > -- > > Key: MRM-605 > URL: http://jira.codehaus.org/browse/MRM-605 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0 >Reporter: Brett Porter > Fix For: 1.1 > > > there is one test failure in the repository-layer when built from the source > distribution - though it remains fine on trunk. I'm not sure what's different. > It detects 6 results instead of 5 in a query. -- 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-611) unstable test case: MavenProjectInfoReportsPluginDependencyGraphTest
[ http://jira.codehaus.org/browse/MRM-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-611: - Fix Version/s: 1.1 > unstable test case: MavenProjectInfoReportsPluginDependencyGraphTest > > > Key: MRM-611 > URL: http://jira.codehaus.org/browse/MRM-611 > Project: Archiva > Issue Type: Bug > Components: build >Affects Versions: 1.0 >Reporter: Brett Porter > Fix For: 1.1 > > > this test appears to depend on the current remote repository contents of a > snapshot which changes from time to time. Needs adjusting. -- 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-610) a number of unit tests fail on windows
[ http://jira.codehaus.org/browse/MRM-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-610: - Fix Version/s: 1.1 > a number of unit tests fail on windows > -- > > Key: MRM-610 > URL: http://jira.codehaus.org/browse/MRM-610 > Project: Archiva > Issue Type: Bug > Components: build >Affects Versions: 1.0 > Environment: Windows Vista Professional >Reporter: Brett Porter > Fix For: 1.1 > > > I have failures in the following: > BytecodeIndexTest (I'm not sure if this is Windows-specific though) > EditManagedRepositoryActionTest (c: vs C: - need canonicalisation) > All repository tests in archiva-webapp (these are intermittent, failure to > delete files in the setUp of the abstract test case for WebDAV - this suite > of tests need a review due to their time consuming nature and timing issues) -- 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-610) a number of unit tests fail on windows
a number of unit tests fail on windows -- Key: MRM-610 URL: http://jira.codehaus.org/browse/MRM-610 Project: Archiva Issue Type: Bug Components: build Affects Versions: 1.0 Environment: Windows Vista Professional Reporter: Brett Porter I have failures in the following: BytecodeIndexTest (I'm not sure if this is Windows-specific though) EditManagedRepositoryActionTest (c: vs C: - need canonicalisation) All repository tests in archiva-webapp (these are intermittent, failure to delete files in the setUp of the abstract test case for WebDAV - this suite of tests need a review due to their time consuming nature and timing issues) -- 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-611) unstable test case: MavenProjectInfoReportsPluginDependencyGraphTest
unstable test case: MavenProjectInfoReportsPluginDependencyGraphTest Key: MRM-611 URL: http://jira.codehaus.org/browse/MRM-611 Project: Archiva Issue Type: Bug Components: build Affects Versions: 1.0 Reporter: Brett Porter this test appears to depend on the current remote repository contents of a snapshot which changes from time to time. Needs adjusting. -- 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: (MECLIPSE-34) Goals to build eclipse plugin/feature and site
[ http://jira.codehaus.org/browse/MECLIPSE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115689 ] krishna commented on MECLIPSE-34: - I am having an issue with mave-pde-plugin. When i try to build my eclipse feature using mave-pde-plugin. In the generated artifact the dependent plugins are not being included. The generated artifact is only bundled with my plugins, it is not bundling any of the eclipse runtime plugins. I could export the same feature from eclipse ide without any issue. i could build this feature with headless pde build also. Does any body had this issue in building the building the eclipse feature using maven? I very much appreciate, any help in this regard. > Goals to build eclipse plugin/feature and site > -- > > Key: MECLIPSE-34 > URL: http://jira.codehaus.org/browse/MECLIPSE-34 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.0 >Reporter: Eugene Kuleshov > > Please provide new goals to build eclipse plugin/feature and site using > Eclipse's builder. > See following articles on the topic: > Build and Test Automation for plug-ins and features > http://eclipse.org/articles/Article-PDE-Automation/automation.html > Followup article - Building features and plugins with Ant > http://eclipse.techforge.com/index.php/articles/188 > So, plugin can issue command like this: > set ECLIPSE_HOME=D:\eclipse\eclipse-3.0.2 > java -cp %ECLIPSE_HOME%\startup.jar org.eclipse.core.launcher.Main > -application org.eclipse.ant.core.antRunner -buildfile build.xml > -Dcomponent=sdk.examples -Dconfigs="*,*,*" -Dbaseos=win32 -Dbasews=win32 > -Dbasearch=x86 -Djavacfailonerror=true > -Dpde.build.scripts=%ECLIPSE_HOME%/plugins/org.eclipse.pde.build_3.0.1/scripts > -DbaseLocation=%ECLIPSE_HOME% > It will sort of run ant under the hood, but nobody will see 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115687 ] Barrett Nuzum commented on MRELEASE-261: I got an email from John Allen that signified his team did not make significant progress on modifying the plugin, and has since abandoned the research, using, instead, a plugin to modify eclipse imports. I'm looking at the solution he found -- http://eclipse-tools.sourceforge.net/projecttransfer/usage.html -- but I don't think it will work for us. Paul, have you been able to make any progress? > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MECLIPSE-358) plugin installed via eclipse:install-plugins have the wrong name
[ http://jira.codehaus.org/browse/MECLIPSE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-358. --- Resolution: Fixed Fix Version/s: 2.5 > plugin installed via eclipse:install-plugins have the wrong name > > > Key: MECLIPSE-358 > URL: http://jira.codehaus.org/browse/MECLIPSE-358 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Dependencies resolution and build path >Affects Versions: 2.4, 2.5 > Environment: jdk 1.5.0_12 eclipse 3.2.x maven 2.0.7 win xp > professional >Reporter: luigi malpeli >Assignee: Carlos Sanchez > Fix For: 2.5 > > Attachments: eclipse-create.zip, eclipse-plugin-patch.txt, > eclipse.patch > > > when processing eclipse:install-plugins the plugins are installed using just > the artifactId as name. This gives problems at least in the following cases: > 1) when trying to modify/construct from scratch an original eclipse > installation; > 2) when trying to install different plugins with the same artifactId and > version but different groupId, the first installed atrifact or the latter > wins depending on the overwrite=false/true parameter setting; > In my opinion the name should be a concat of the groupid a dot and the > current proposed name. > I'll attach a proposed patch and some test files ASAP. -- 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-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115695 ] [EMAIL PROTECTED] commented on MRELEASE-261: Nope Sorry I got no where I just put up with the pain. :( Paul > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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-607) HTTP 500 when opening proxyConnectors.jsp
[
http://jira.codehaus.org/browse/MRM-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Kieselhorst closed MRM-607.
--
Resolution: Won't Fix
A hint in the upgrading archiva section,
http://maven.apache.org/archiva/docs/1.0/adminguide/standalone.html would be
nice.
> HTTP 500 when opening proxyConnectors.jsp
> -
>
> Key: MRM-607
> URL: http://jira.codehaus.org/browse/MRM-607
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0
> Environment: SunOS 5.8, JDK 1.5.0_06
>Reporter: Dennis Kieselhorst
>Priority: Critical
>
> proxyConnectors cannot be opened after updating to version 1.0:
> HTTP ERROR: 500
> Exception in JSP: /WEB-INF/jsp/admin/proxyConnectors.jsp:127
> 124: "/>
> 125: ${connector.targetRepoId}
> 126: ${repoMap[connector.targetRepoId].name}
> 127:href="${repoMap[connector.targetRepoId].url}">${repoMap[connector.targetRepoId].url}
> 128:
> 129:
> 130: onclick="Effect.toggle('proxySettings_${connector.sourceRepoId}_${connector.targetRepoId}','slide');
> return false;">Expand
> Stacktrace:
> RequestURI=/archiva/admin/proxyConnectors.action
> Powered by Jetty://
--
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-612) Repository scanning does not recognize newly added artifacts if they have an old timestamp
Repository scanning does not recognize newly added artifacts if they have an old timestamp -- Key: MRM-612 URL: http://jira.codehaus.org/browse/MRM-612 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0 Environment: Win32 Reporter: Arne Degenring After starting up a fresh instance with default configuration, I copied parts of my existing repository to Archiva's default internal repository. Then I used the "Scan Repository Now" button on the repository administration page. Afterwards, all artifacts were visible on the "Browse" page. So far so good. I then copied some more groups of my existing repo to Archiva's default internal repository, and used "Scan Repository Now" once again. But this time, the "Browse" page did not show the newly added groups. This was quite surprising, as the log output of RepositoryScanner clearly showed that Archiva DID walk over these new artifacts, without errors or warnings. I tried to use the "Update Database Now" button, but still no effect. I finally touched one of the POM files in the missing groups, i.e. I gave the POM file a new timestamp. After doing "Scan Repository Now" again, the artifact appeared on the Browse page. As discussed on http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html#a14132393 -- 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-613) [FEATURE] Archiva ArtifactRank
[FEATURE] Archiva ArtifactRank -- Key: MRM-613 URL: http://jira.codehaus.org/browse/MRM-613 Project: Archiva Issue Type: New Feature Components: reporting Affects Versions: 1.1 Reporter: Joakim Erdfelt This is a new feature request. ArtifactRank (the Archiva version of Googles PageRank) I'd like to see some badging of the health of the artifact, encourage the proper creation of artifacts this way. We can provide a graphic on the artifact page (and even the artifact search results and browse screens). This rank can also be used to increase the importance of hits on the search results. 100% = Gold Award for excellence. 70% to 99% = Green Award (Good) 40% to 69% = Yellow Award (Warning) 0% to 39% = Red Badge(Warning++) * How many other projects use the artifact. (junit would be highly ranked) * License is fully defined. * License file exists in the artifact archive. * URL is defined. * At least 1 contact point is defined. (Developer email address or mailing list) * A POM is defined. * Checksums are defined. * The maven pom manifest information exists. * All dependencies exist in the repository too. * All parent poms exist in the repository too. * All plugins used exist in the repository too. * If the artifact contains java ... ** All of the *.class files are within the same groupId that is defined in the POM. This is to indicate bad deployment, or bad ** All of the declared imports have an associated dependency defined. ** The manifest.mf file contains the version specified. ** The source.jar exists. ** The javadoc.jar exists. This list of checks can feed the reporting too. And the list of checks should be able to be extended / enhanced by administrators of Archiva installs too. -- 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: (MREPOSITORY-12) any and all attempts to use locate and download maven-clean-plugin fail
any and all attempts to use locate and download maven-clean-plugin fail --- Key: MREPOSITORY-12 URL: http://jira.codehaus.org/browse/MREPOSITORY-12 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.0 Environment: mvn 2.0.8 Reporter: Martin Gainty any all attempts to find/locate/use/download maven-clean-plugin fail [INFO] The plugin 'org.apache.maven.plugins:clean' does not exist or no valid ve rsion could be found [INFO] the clean plugin is not available anywhere -- 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: (MINVOKER-16) http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER"
[ http://jira.codehaus.org/browse/MINVOKER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-16. Assignee: Olivier Lamy (was: John Casey) Resolution: Duplicate > http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html > points to "MPA" and not to "MINVOKER" > -- > > Key: MINVOKER-16 > URL: http://jira.codehaus.org/browse/MINVOKER-16 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Reporter: Gerhard Langs >Assignee: Olivier Lamy >Priority: Minor > > Subject should say it all. > People trying to look at the issues of the invoker plugin are directed to the > wrong place -- 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: (MINVOKER-15) http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html points to "MPA" and not to "MINVOKER"
[ http://jira.codehaus.org/browse/MINVOKER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-15. Assignee: Olivier Lamy (was: John Casey) Resolution: Fixed Fix Version/s: 1.1 fix in rev 600704 > http://maven.apache.org/plugins/maven-invoker-plugin/issue-tracking.html > points to "MPA" and not to "MINVOKER" > -- > > Key: MINVOKER-15 > URL: http://jira.codehaus.org/browse/MINVOKER-15 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Reporter: Gerhard Langs >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1 > > > Subject should say it all. > People trying to look at the issues of the invoker plugin are directed to the > wrong place -- 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: (MANTRUN-78) Use of AntRun causes clean to fail for multiproject
Use of AntRun causes clean to fail for multiproject --- Key: MANTRUN-78 URL: http://jira.codehaus.org/browse/MANTRUN-78 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Brian Jackson Attachments: test.zip Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached. The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. -- 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-612) Repository scanning does not recognize newly added artifacts if they have an old timestamp
[ http://jira.codehaus.org/browse/MRM-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-612: - Fix Version/s: 1.1 > Repository scanning does not recognize newly added artifacts if they have an > old timestamp > -- > > Key: MRM-612 > URL: http://jira.codehaus.org/browse/MRM-612 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0 > Environment: Win32 >Reporter: Arne Degenring > Fix For: 1.1 > > > After starting up a fresh instance with default configuration, I copied parts > of my existing repository to Archiva's default internal repository. Then I > used the "Scan Repository Now" button on the repository administration page. > Afterwards, all artifacts were visible on the "Browse" page. So far so good. > I then copied some more groups of my existing repo to Archiva's default > internal repository, and used "Scan Repository Now" once again. But this > time, the "Browse" page did not show the newly added groups. This was quite > surprising, as the log output of RepositoryScanner clearly showed that > Archiva DID walk over these new artifacts, without errors or warnings. I > tried to use the "Update Database Now" button, but still no effect. > I finally touched one of the POM files in the missing groups, i.e. I gave the > POM file a new timestamp. After doing "Scan Repository Now" again, the > artifact appeared on the Browse page. > As discussed on > http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html#a14132393 -- 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-1833) Upload Retroweaver 2.0.2
Upload Retroweaver 2.0.2 Key: MAVENUPLOAD-1833 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1833 Project: maven-upload-requests Issue Type: Task Reporter: Xavier Le Vourch Two bundles for retroweaver for the tool itself and runtime. The bundle URL above is only for one of them. They're on sourceforge at: http://retroweaver.sourceforge.net/files/retroweaver-bundle-2.0.2.jar http://retroweaver.sourceforge.net/files/retroweaver-rt-bundle-2.0.2.jar This may be needed to fix the problem with java 1.5 for using pmd4.1 in the pmd maven plugin (see maven dev mailing list) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-10) Capability to define profiles per it test
[ http://jira.codehaus.org/browse/MINVOKER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-10. Resolution: Fixed fix in rev 600713. > Capability to define profiles per it test > - > > Key: MINVOKER-10 > URL: http://jira.codehaus.org/browse/MINVOKER-10 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > > The current trunk (rev 596005) contains new feature to use profiles. > But this can not be defined for each it. We could use something like > profilesFile (as goalsFile). -- 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-1834) jdk 1.4 compatible version for pmd 4.1
jdk 1.4 compatible version for pmd 4.1 -- Key: MAVENUPLOAD-1834 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1834 Project: maven-upload-requests Issue Type: Task Reporter: Xavier Le Vourch this create a new jdk1.4 based artifact pmd:pmd-jdk14 that may be needed for core pmd plugin. -- 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: (MWAR-129) WebRessource not filtered
[ http://jira.codehaus.org/browse/MWAR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115741 ] Olivier Lamy commented on MWAR-129: --- A simple workaround for your attached it is to have : true src/main/webapp param.jsp Note the empty instead of . > WebRessource not filtered > - > > Key: MWAR-129 > URL: http://jira.codehaus.org/browse/MWAR-129 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 > Environment: windows, maven 2.0.7 >Reporter: Jean-Yves LEBLEU >Assignee: Olivier Lamy > Fix For: 2.1-alpha-2 > > Attachments: mwar_129.zip > > > Previously Webressources were correctly filtered and are not filtered any > more > See above extract from pom.xml > > maven-war-plugin > 2.0.2 > > src/main/webapp > > > true > src/main/webapp > . > > param.jsp > > > > > -- 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-1587) Unable to change default build definition where one definition is a PROJECT definition and one is a GROUP
Unable to change default build definition where one definition is a PROJECT definition and one is a GROUP - Key: CONTINUUM-1587 URL: http://jira.codehaus.org/browse/CONTINUUM-1587 Project: Continuum Issue Type: Bug Components: Project Grouping Affects Versions: 1.1-beta-4 Reporter: Ross Lamont This is perhaps related to CONTINUUM-1410: We create a MVN2 project in the usual manner within a predefined project group. We then added a non-default build definition to the project - the GROUP definition continues to be the default. Sometime later, we wanted to temporarily change the default to the PROJECT definition. When attempting to change the default back to the GROUP, the default field for both definitions (from the Project page) is read-only set to true. -- 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: (MWAR-129) WebRessource not filtered
[ http://jira.codehaus.org/browse/MWAR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-129. - Resolution: Fixed fix in rev 600742. Filtering targetPath which contains only . or ./ because they cause failures in the PathSet recording. > WebRessource not filtered > - > > Key: MWAR-129 > URL: http://jira.codehaus.org/browse/MWAR-129 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 > Environment: windows, maven 2.0.7 >Reporter: Jean-Yves LEBLEU >Assignee: Olivier Lamy > Fix For: 2.1-alpha-2 > > Attachments: mwar_129.zip > > > Previously Webressources were correctly filtered and are not filtered any > more > See above extract from pom.xml > > maven-war-plugin > 2.0.2 > > src/main/webapp > > > true > src/main/webapp > . > > param.jsp > > > > > -- 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-614) User validation message has incorrect URL
User validation message has incorrect URL - Key: MRM-614 URL: http://jira.codehaus.org/browse/MRM-614 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0 Reporter: Nicholas Daley The URL that was sent in the validation email lost the port and the prefix path for archiva's context. i.e. the URL sent in the email was http://192.168.0.100/security/login!login.action?validateMe=1a9e7e81b84f4c56a5deaa752343a212 it should have been http://192.168.0.100:8080/archiva/security/login!login.action?validateMe=1a9e7e81b84f4c56a5deaa752343a212 -- 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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115751 ] zhongbing commented on MPCHECKSTYLE-20: --- I have got this problem. I used the ant to call checkstyle, then I got the problem:Got an exception - java.lang.RuntimeException: Unable to get class information for @throws tag 'ServletException'. The cause is that checkstyle can't find out the exception class in classpath. So It only needs to add the jar of the exception class to the classpath. For example: I add the in classpath, it will run successfully. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- 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
