[jira] Commented: (MEAR-50) Add the loader-repository node for jboss configuration
[ http://jira.codehaus.org/browse/MEAR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90868 ] Greg Jones commented on MEAR-50: It would be nice to get this patch applied and into a SNAPSHOT so that we can use this property rather than having to copy our own jboss-app.xml file as part of the build. Please! > Add the loader-repository node for jboss configuration > -- > > Key: MEAR-50 > URL: http://jira.codehaus.org/browse/MEAR-50 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Maurice Zeijen > Assigned To: Stephane Nicoll > Fix For: 2.4 > > Attachments: MEAR-50.patch > > > In the jboss-app.xml file it is possible to add a loader-repository node. To > complement the jboss configuration in the ear plugin, it should be possible > to add this node. -- 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-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MNG-1889: - Attachment: maven-no-plugin-descriptors.patch Here's an updated version. Please note, that I had to catch the new exception in the test suite at some point. It mighe be better to remove the final check for size() == 0 in that test. > Plugins without descriptors > --- > > Key: MNG-1889 > URL: http://jira.codehaus.org/browse/MNG-1889 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann >Priority: Minor > Fix For: 2.0.x > > Attachments: maven-no-plugin-descriptors.patch, > numMojoDescriptors.patch > > > The attached patch throws an exception, if no Mojos are found in a plugin. > Background: If such a plugin is installed, then an NPE is caused in the > DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo > descriptors. Obviously, the actual error is in the plugin itself, where it > should be exposed. It took me some hours to find this actual reason. (I still > do not know, why the Mojos aren't found in my plugin, but that's another > story.) The patch should be able to save the same number of hours for other > plugin developers. > Note: The InvalidPluginDescriptorException, which is triggered by the patch, > is possibly not proper. I choosed it, because it allowed to leave the method > signature unchanged and keep the patch simple. It is up to the reviewer to > choose another exception. -- 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: (MNG-2669) bootstrap of components/trunk fails with ant-1.7.0RC1
[ http://jira.codehaus.org/browse/MNG-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2669. -- Resolution: Fixed We only use it too bootstrap and don't care if it works with every version of Ant. > bootstrap of components/trunk fails with ant-1.7.0RC1 > - > > Key: MNG-2669 > URL: http://jira.codehaus.org/browse/MNG-2669 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build >Affects Versions: 2.1 >Reporter: Alfred Nathaniel >Priority: Blocker > > Bootstrap build of components/trunk with ant-1.7.0RC1 fails. > [javac] > /home/alfred/apache/maven/components/trunk/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/LocalRepository.java:32: > getLocation() in org.apache.maven.artifact.ant.LocalRepository cannot > override getLocation() in org.apache.tools.ant.ProjectComponent; attempting > to use incompatible return type[javac] found : java.io.File > [javac] required: org.apache.tools.ant.Location > [javac] public File getLocation() > [javac] ^ -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-13: --- Attachment: nofork.patch My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited! > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Sources Plugin > Issue Type: Improvement > Environment: ALL >Reporter: Ben Tatham > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
No-Forking mojos for use within a POM instead of CLI Key: MSOURCES-13 URL: http://jira.codehaus.org/browse/MSOURCES-13 Project: Maven 2.x Sources Plugin Issue Type: Improvement Environment: ALL Reporter: Ben Tatham Attachments: nofork.patch The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them. This behaviour is similar to the difference between assembly:assembly and assembly:attached. -- 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-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90858 ] Jason van Zyl commented on MNG-1889: Jochen, I now look for your name for patches :-) This one doesn't apply. Could you take another pass and I promise I'll apply it. > Plugins without descriptors > --- > > Key: MNG-1889 > URL: http://jira.codehaus.org/browse/MNG-1889 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann >Priority: Minor > Fix For: 2.0.x > > Attachments: numMojoDescriptors.patch > > > The attached patch throws an exception, if no Mojos are found in a plugin. > Background: If such a plugin is installed, then an NPE is caused in the > DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo > descriptors. Obviously, the actual error is in the plugin itself, where it > should be exposed. It took me some hours to find this actual reason. (I still > do not know, why the Mojos aren't found in my plugin, but that's another > story.) The patch should be able to save the same number of hours for other > plugin developers. > Note: The InvalidPluginDescriptorException, which is triggered by the patch, > is possibly not proper. I choosed it, because it allowed to leave the method > signature unchanged and keep the patch simple. It is up to the reviewer to > choose another exception. -- 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-1437) Trove 1.1 beta 5
Trove 1.1 beta 5 Key: MAVENUPLOAD-1437 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1437 Project: maven-upload-requests Issue Type: Task Reporter: Eric Redmond Require this version of Trove for Terracotta - figured this would be a good excuse to upload 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] Closed: (MNG-1637) Maven bootstrap requires old libraries, like 2.0-beta-3
[ http://jira.codehaus.org/browse/MNG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1637. -- Resolution: Fixed This is released plugins using older versions of the plugin-api for example that pull in older libraries. Only building entirely from source would prevent this for all plugins needed in the bootstrap. > Maven bootstrap requires old libraries, like 2.0-beta-3 > --- > > Key: MNG-1637 > URL: http://jira.codehaus.org/browse/MNG-1637 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Reporter: Brett Porter > Fix For: 2.0.x > > > haven't checked where these are pulled from - could be plugins, or a > dependency. Need to hunt them down and update them, and should problbay > filter them out in the bootstrap. For any library built via the bootstrap, > only the newest version should be used. -- 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: (MNG-1875) Cannot deploy artifact with classifier
[ http://jira.codehaus.org/browse/MNG-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1875. -- Resolution: Fixed Dupe and fixed. > Cannot deploy artifact with classifier > -- > > Key: MNG-1875 > URL: http://jira.codehaus.org/browse/MNG-1875 > Project: Maven 2 > Issue Type: Bug >Reporter: Miguel Griffa > Assigned To: Brett Porter > Fix For: 2.0.x > > > Intro: > I have an artifact I want to deploy with different confs, I use profiles and > I want confs to be deployed, so I want somethings like > core-1.0.dev.jar > core-1.0.-test.jar > core-1.0.-prod.jar > profiles is the way to go. > The problem is how to set the name of the artifact with profiles. simple > overwriting finalName does not work, I was told to put the classifier in the > version, but this is incorrect, since all jars above should be in 1.0 dir. > putting the classifier in verison makes them appear in different version dirs. -- 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: (MNG-1817) Debug System.out statement snuck through
[ http://jira.codehaus.org/browse/MNG-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1817. -- Resolution: Fixed No System.out|err calls in the ant tasks. > Debug System.out statement snuck through > > > Key: MNG-1817 > URL: http://jira.codehaus.org/browse/MNG-1817 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks >Affects Versions: 2.0.1 >Reporter: Eric Andresen >Priority: Trivial > Fix For: 2.0.x > > > In the maven-artifact-ant tasks, a debug statement snuck through to the final > release: > Repository.getId() == central > This happens in the task. -- 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-310) surefire-reports failes to locate java, returns "There are test failures."
surefire-reports failes to locate java, returns "There are test failures." -- Key: SUREFIRE-310 URL: http://jira.codehaus.org/browse/SUREFIRE-310 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.3.1 Environment: Windows, Sun JDK 1.5 u10, environment variables include: "JAVA_HOME = C:\Program Files\Java\jdk1_5" Reporter: Steve Lewis Priority: Critical Attachments: execution_error.txt When the JAVA_HOME environment variable includes spaces, surefire-reports execution failes to locate java Partial error below, full error in context is available in attachment. Forking command line: "C:\Program Files\Java\jdk1.5.0_10\jre\bin\java" -classpath [...] 'C:\Program' is not recognized as an internal or external command, operable program or batch file. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] This is similar to behavior the gwt-maven plugin experienced a little while back, http://groups.google.com/group/gwt-maven/browse_thread/thread/b8ccf7896b0f65f0/df999ee333246567%23df999ee333246567 WORKAROUNDS: Either changing JAVA_HOME to not use spaces such as "c:\progra~1\java\jdk1_5" Explicitly use a previous version of the maven-surefire-plugin such as maven-surefire-plugin 2.3 -- 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: (MNG-2048) Quote args in mvn script
[
http://jira.codehaus.org/browse/MNG-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2048.
--
Resolution: Duplicate
Dupe and fixed.
> Quote args in mvn script
>
>
> Key: MNG-2048
> URL: http://jira.codehaus.org/browse/MNG-2048
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 2.0.2
> Environment: Windows XP
> Cygwin
>Reporter: Dale Wyttenbach
>Priority: Minor
> Fix For: 2.0.x
>
>
> The mvn script as distributed does not handle quoted args such as:
> m2 -Dgreeting="huh bah" hello:sayhi
> You get the error:
> Invalid task 'bah': you must specify a valid lifecycle phase, or a goal in
> the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal
> Here is a fix for the mvn script:
> *** mvn 2006/02/07 15:58:33 1.1
> --- mvn 2006/02/07 15:58:38
> ***
> *** 134,138
> -classpath "${M2_HOME}"/core/boot/classworlds-*.jar \
> "-Dclassworlds.conf=${M2_HOME}/bin/m2.conf" \
> "-Dmaven.home=${M2_HOME}" \
> ! ${CLASSWORLDS_LAUNCHER} $@
>
> --- 134,138
> -classpath "${M2_HOME}"/core/boot/classworlds-*.jar \
> "-Dclassworlds.conf=${M2_HOME}/bin/m2.conf" \
> "-Dmaven.home=${M2_HOME}" \
> ! ${CLASSWORLDS_LAUNCHER} "$@"
--
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: (MNG-1491) Reactor should print out a message if it detects a collision of artifact ids
[ http://jira.codehaus.org/browse/MNG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1491. -- Resolution: Fixed The new feature in the dependency plugin can do this nicely now. > Reactor should print out a message if it detects a collision of artifact ids > > > Key: MNG-1491 > URL: http://jira.codehaus.org/browse/MNG-1491 > Project: Maven 2 > Issue Type: Wish > Components: Plugins and Lifecycle >Reporter: Anuerin Diaz >Priority: Trivial > Fix For: 2.0.x > > > It might be a good idea to have the Reactor print out a warning message if it > detects similar artifact IDs (copy and paste problem) when scanning for the > build order at the start of the build. > Currently, there are no messages shown in the screen even if "-X" is used. -- 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: (MNG-2239) Null pointer exception when typo is in plugin name
[ http://jira.codehaus.org/browse/MNG-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2239. -- Resolution: Fixed Fixed. > Null pointer exception when typo is in plugin name > -- > > Key: MNG-2239 > URL: http://jira.codehaus.org/browse/MNG-2239 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 >Reporter: Carlos Sanchez >Priority: Minor > Fix For: 2.0.x > > > Running mvn eclipsE:eclipse > $ mvn eclipsE:eclipse > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'eclipsE'. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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 Apr 25 16:32:32 PDT 2006 > [INFO] Final Memory: 1M/3M > [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: (MNG-1498) [PATCH] Add all mailing lists to Maven's main site
[ http://jira.codehaus.org/browse/MNG-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1498. -- Resolution: Fixed This will be generated. > [PATCH] Add all mailing lists to Maven's main site > -- > > Key: MNG-1498 > URL: http://jira.codehaus.org/browse/MNG-1498 > Project: Maven 2 > Issue Type: Improvement >Reporter: Felipe Leme >Priority: Minor > Fix For: 2.0.x > > Attachments: MAVEN-1468.patch > > Original Estimate: 5 minutes > Remaining Estimate: 5 minutes > > Maven's mailing list page (http://maven.apache.org/mail-lists.html) currently > lists only the user and dev lists. I think it would be more useful for new > users if this page listed all maven-related mailing lists (even though some > lists belong to sub-projects, such as Wagon and SCM). -- 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-1120) don't require if there is a valid schema element
[ http://jira.codehaus.org/browse/MNG-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1120: --- Description: This can't happen in 2.0.x. Fix Version/s: (was: 2.0.x) 2.1.x > don't require if there is a valid schema element > - > > Key: MNG-1120 > URL: http://jira.codehaus.org/browse/MNG-1120 > Project: Maven 2 > Issue Type: Bug >Reporter: Brett Porter >Priority: Minor > Fix For: 2.1.x > > > This can't happen in 2.0.x. -- 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: (MNG-2089) APT & AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2089. -- Resolution: Fixed These exist at mojo.codehaus.org. > APT & AspectJ plugins > - > > Key: MNG-2089 > URL: http://jira.codehaus.org/browse/MNG-2089 > Project: Maven 2 > Issue Type: Wish > Components: Sandbox >Affects Versions: 2.0.3 >Reporter: Juraj Burian >Priority: Minor > Fix For: 2.0.x > > Attachments: APTexamplePrj.zip, plugins.zip > > > We have prototypes of AspectJ & APT plugins ready. > Can you put it into the Sanbox? > Thanx. > best regards > J.Burian -- 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: (MNG-1395) Change all m2.bat and m2 references in sources to mvn.bat and mvn
[ http://jira.codehaus.org/browse/MNG-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1395. -- Resolution: Fixed Patch applied. > Change all m2.bat and m2 references in sources to mvn.bat and mvn > - > > Key: MNG-1395 > URL: http://jira.codehaus.org/browse/MNG-1395 > Project: Maven 2 > Issue Type: Bug >Reporter: Piotr Bzdyl >Priority: Minor > Fix For: 2.0.x > > Attachments: m2-to-mvn.diff > > > See attached patch (for all files I "grepped" for m2.bat and m2 - shell > script calls). -- 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: (MNG-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2481. -- Resolution: Fixed We decided the caching should not be done in the project builder. It is being done at a session level in the reactor manager now. > project builder should make the processed project cache configurable > > > Key: MNG-2481 > URL: http://jira.codehaus.org/browse/MNG-2481 > Project: Maven 2 > Issue Type: Bug > Components: Performance, POM >Affects Versions: 2.0.4 >Reporter: Brett Porter > Fix For: 2.0.x > > > the cache in the project builder is a simple map. This is usually fine for > Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE > plugins as it gets used more) it can chew up quite some memory. > I'd suggest we make it configurable: > - can turn it on or off using plexus configuration > - can limit its size using plexus configuration > - can change other options, such as adding expiry ages to items regardless of > size > Rather than implementing something in the project builder itself, I suggest > having a cache plexus component that does everything we need it to (this > could be reused in the webapps as well). I'm not sure of any existing caching > solutions (I know OSCache has a general Java cache but don't know how > suitable it is). One alterantive might be to round out commons-cache with > some features and plexus descriptors. -- 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-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90842 ] Parolini Antonio commented on MRELEASE-145: --- I agree with Jorg: the release-plugin should be have the ability to make partial release without touching the not-snapshot poms. My workaround for this issue so far as been to use profiles, in order to choose what module are released. > release:prepare requires all modules to be SNAPSHOTS > > > Key: MRELEASE-145 > URL: http://jira.codehaus.org/browse/MRELEASE-145 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Jörg Hohwiller > > The biggest need for the maven-release-plugin is in complex projects with a > lot of modules (that may again have modules). If I do not get it wrong, the > current released version forces all modules to be snapshots and releases them > individually. This is completely useless in my situation because in the end > this forces me to release alle modules together for every change that is to > be released and more or less causes that all modules have the same version > number. When I call mvn replease:prepare on my toplevel project this is no > snapshot, it fails with this error: > The project : isn't a snapshot (). > I would expect release:prepare to leave non SNAPSHOT modules untouched (and > only verify that they do not have SNAPSHOT dependencies, what should never be > the case if the version is no snapshot). > All reactor projects that have a "-SNAPHSOT" version should be released and > theier project-internal dependencies should also be set to the acording > released version (and later be set to the new SNAPSHOT). > Additionally I want to have the complete project to be tagged as a whole > instead of each module. This could potentially be configureable (especially > which directory is actually tagged, e.g. if the toplevel project is not in > trunk/ but somewhere deeper say trunk/develop because other directories in > trunk are huge but do not need to be checked out by every developer but need > to be tagged). > I personally think that the best flexibility and final freedom would be to > split off the release:prepare goal into 3 goals: > -create release version(s) > -create tag(s) > -update to snapshot version(s) > These goals could be used individually and one could add some custom steps or > replace one with something else. > For creating the snapshot versions there is also the problem, that you do not > know right away which project will be modified when in the future. The > coolest thing would be if this would happen automatically when the first > change is commited to the module. But this is of cause not praticable in > reality (maybe if all commits would be done with 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] Closed: (MNG-380) migrate integration tests belonging to non-core plugins
[ http://jira.codehaus.org/browse/MNG-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-380. - Resolution: Fixed Issue contained in notes about the ITs. > migrate integration tests belonging to non-core plugins > --- > > Key: MNG-380 > URL: http://jira.codehaus.org/browse/MNG-380 > Project: Maven 2 > Issue Type: Bug >Reporter: Brett Porter > Fix For: 2.0.x > > > some of the integration tests depend on plugins not part of the core (eg war, > ear, verifier). Make these tests be integration tests on those plugins > themselves when the lifecycle supports it. After this, the integration tests > should all relate to the core plugins, so the second step in the bootstrap > that rebuilds all plugins with m2 should be 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: (MNG-2091) NPE when including middlegen-hibernate-plugin
[ http://jira.codehaus.org/browse/MNG-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2091. -- Resolution: Fixed Plugin related problem. If still a problem submit a working build that can be tested. > NPE when including middlegen-hibernate-plugin > - > > Key: MNG-2091 > URL: http://jira.codehaus.org/browse/MNG-2091 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.2 > Environment: SUSE Linux 9.3 on i386; JVM: 1.5.0_04-b05; Kernel: > 2.6.11.4.20a-11-default >Reporter: Bernd Adamowicz > Fix For: 2.0.x > > > As soon as the plugin middlegen-hibernat-plugin is integrated into the POM, a > NPE is thrown when the plugin is added. This is the stacktrace: > [EMAIL PROTECTED]:~/THEMEN/ECLIPSE_WORKBENCH/Buttenlauf> mvn compile > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Buttenlauf Auswertung - GVC Criesbach > [INFO]task-segment: [compile] > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:295) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:200) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:165) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1218) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1182) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:950) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:450) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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: 2 seconds > [INFO] Finished at: Mon Feb 20 21:04:30 CET 2006 > [INFO] Final Memory: 1M/4M > [INFO] > > This is how the Middlegen-part of the POM looks like: > > > > > middlegen > > middlegen-hibernate-plugin > 2.1 > > > > I know this issue has been around with Maven 1.x. The cause there was a > corrupted plugin pom from middlegen. But I wasn't able to reproduce this. I > couldn't find anything wrong with the pom. > This problem can be reproduced with Maven 2.0 and on Windows systems, too. So > I think the problem really is the plugin. I will open an issue on the > Middlegen page, too and will (hopefully) post a solution here. But maybe > someone has a workaround to fix this in the meantime. > Thanks in advance for any help. > Bernd -- 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 mor
[jira] Closed: (MNG-1981) move maven snapshots to the apache snapshot repo
[ http://jira.codehaus.org/browse/MNG-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1981. -- Resolution: Fixed Yes, everything is published to Apache now. > move maven snapshots to the apache snapshot repo > > > Key: MNG-1981 > URL: http://jira.codehaus.org/browse/MNG-1981 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Reporter: Brett Porter > Fix For: 2.0.x > > -- 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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-262: - Component/s: maven-scm-provider-svn > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner > Fix For: future > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- 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: (SCM-263) Subversion http url should support password on the url
[ http://jira.codehaus.org/browse/SCM-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-263. Assignee: Emmanuel Venisse Resolution: Fixed > Subversion http url should support password on the url > -- > > Key: SCM-263 > URL: http://jira.codehaus.org/browse/SCM-263 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-4 > Environment: xp, linux, >Reporter: Dan Tran > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > both cvs and staream urls allow password on url. > currently > scm:svn:http://user:[EMAIL PROTECTED]/path see user:password as username > Having password on url simplifies lots of work my a test application i am > writing > that has no concern about password in the url > comments? why do we not support this feature to beginning with? -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-2854:
-
Attachment: maven-archiver-properties-2.patch
Ok, here's an updated version of the patch. Note, that it contains a test case
(MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed
created when invoked for the first time, but isn't for the second time.
> Recreating pom.properties always breaks the archivers uptodate check
>
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.5
>Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch,
> maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation.
> (Unless the flag "addMavenDescriptor" is set to false, which few people do.)
> This forced recreation makes the uptodate check fail. In other words, jar
> files are always recreated, regardless whether anything was recompiled.
> Obviously, this makes the uptodate check of war files etc. fail as well,
> because the included jar files are always changed.. This is a major drawback,
> because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch
> does:
> - It is obviously bad, that the generated pom.properties file is in the
> projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which
> seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create
> multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the
> pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
> unique.
> - Finally, the patch makes the maven-archiver check, whether the
> pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version
> have changed.)
> It does so, by writing the file to an internal buffer and comparing the
> file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version
> haven't changed, the pom.properties file remains unchanged. In particular,
> the jar file doesn't need to be recreated.
--
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: (MJXR-26) JXR does not handle empty (completely commented) java-files...
[
http://jira.codehaus.org/browse/MJXR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MJXR-26.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.1
This has already been fixed by previous commits. I created a small project for
this and verified that I got an NPE when running 'mvn site'. Using the same
project with maven-jxr-plugin 2.1-SNAPSHOT I do not get the NPE anymore.
> JXR does not handle empty (completely commented) java-files...
> --
>
> Key: MJXR-26
> URL: http://jira.codehaus.org/browse/MJXR-26
> Project: Maven 2.x JXR Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Maven 2.0.5 (Windows 2003 Srv/Windows XP)
>Reporter: Jan Palmquist
> Assigned To: Dennis Lundberg
>Priority: Minor
> Fix For: 2.1
>
>
> I have detected that the jxr-plugin (or sub components) does not handle
> java-files being completely commented away e.g.
> //package my.demopackage;
> //public class MyClass {
> //}
> This is not a big issue, however it is quite annoying to have to notify
> developers that this not only is bad coding style but also breaks site
> generation.
> My stack trace:
> INFO] Generate "Test Source Xref" report.
> Unable to processPath
> C:\CC\projects\MyProject\src\test\java\my\demopackage\MyClass.java =>
> c:\CC\projects\MyProject\target/site/xref-test\my\demopackage\MyClass.html
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.jxr.JavaCodeTransform.getHeader(JavaCodeTransform.java:651)
> at
> org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:716)
> at
> org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:787)
> at org.apache.maven.jxr.JXR.transform(JXR.java:195)
> at org.apache.maven.jxr.JXR.processPath(JXR.java:114)
> at org.apache.maven.jxr.JXR.xref(JXR.java:335)
> at
> org.apache.maven.plugin.jxr.AbstractJxrReport.createXref(AbstractJxrReport.java:226)
> at
> org.apache.maven.plugin.jxr.AbstractJxrReport.executeReport(AbstractJxrReport.java:352)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
> at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> 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: 9 minutes 24 seconds
> [INFO] Finished at: Thu Mar 22 07:26:14 CET 2007
> [INFO] Final Memory: 73M/200M
> [INFO]
>
--
This message is automatically generated by JIRA.
-
[jira] Closed: (MAVENUPLOAD-1435) Upload ZK 2.3.0 to the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1435. --- Assignee: Carlos Sanchez Resolution: Fixed You are going to have to start setting up an automated sync http://maven.apache.org/guides/mini/guide-central-repository-upload.html Sync'ing your own repository with ibiblio > Upload ZK 2.3.0 to the central repository > - > > Key: MAVENUPLOAD-1435 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1435 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tom M. Yeh > Assigned To: Carlos Sanchez > > http://www.zkoss.org/maven/bundles/2.3.0/zcommon-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/zweb-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/zk-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/zul-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/zhtml-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/zkplus-2.3.0-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/dojoz-0.4.1-1-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/gmapsz-2.0-3-bundle.jar > http://www.zkoss.org/maven/bundles/2.3.0/timelinez-1.1-1-bundle.jar > http://www.zkoss.org > http://sourceforge.net/users/tomyeh/ > ZK is an open-source Ajax Web framework that enables rich user interface for > Web applications with no JavaScript and little programming. -- 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: (MAVENUPLOAD-1432) upload winstone to maven central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1432. --- Assignee: Carlos Sanchez Resolution: Fixed > upload winstone to maven central > > > Key: MAVENUPLOAD-1432 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1432 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jorg Heymans > Assigned To: Carlos Sanchez > > There is also a lite version which is provided in a separate bundle: > www.domek.be/winstone-lite-bundle.tar -- 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: (MAVENUPLOAD-1436) xSocket V1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1436. --- Assignee: Carlos Sanchez Resolution: Fixed > xSocket V1.0 > > > Key: MAVENUPLOAD-1436 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1436 > Project: maven-upload-requests > Issue Type: Task >Reporter: grro > Assigned To: Carlos Sanchez > > xSocket is a easy to use nio-based library to build high performance, high > scalable network applications. -- 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: (MAVENUPLOAD-1434) please upload new version of vafer.org dependency
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1434. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload new version of vafer.org dependency > - > > Key: MAVENUPLOAD-1434 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1434 > Project: maven-upload-requests > Issue Type: Task >Reporter: Torsten Curdt > Assigned To: Carlos Sanchez > > required for the new release of minijar which is supposed to be used for the > maven 2.0..6 release -- 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-2892) Use minijar to hide the use of plexus-utils internally so that plugins can use their own version
[ http://jira.codehaus.org/browse/MNG-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2892: --- Fix Version/s: 2.0.6 > Use minijar to hide the use of plexus-utils internally so that plugins can > use their own version > > > Key: MNG-2892 > URL: http://jira.codehaus.org/browse/MNG-2892 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > -- 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-2892) Use minijar to hide the use of plexus-utils internally so that plugins can use their own version
Use minijar to hide the use of plexus-utils internally so that plugins can use their own version Key: MNG-2892 URL: http://jira.codehaus.org/browse/MNG-2892 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.5 Reporter: Jason van Zyl Fix For: 2.0.6 -- 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-1436) xSocket V1.0
xSocket V1.0 Key: MAVENUPLOAD-1436 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1436 Project: maven-upload-requests Issue Type: Task Reporter: grro xSocket is a easy to use nio-based library to build high performance, high scalable network applications. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90828 ] Emmanuel Venisse commented on SCM-291: -- -MM-dd HH:mm:ssZ format is used by default now as it work in cvs 1.11 too If a cvs can't use this format, he'll can define an other one in cvs-settings.xml > Errors during date parsing with cvs version 1.12.12. > > > Key: SCM-291 > URL: http://jira.codehaus.org/browse/SCM-291 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0-beta-4 > Environment: Linux Suse 10 > CVS 1.12.12 >Reporter: johann angeli > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > The changelog plugin used with cvs client 1.12.12, failed with the following > error : > >> [ERROR] cvs [log aborted]: Can't parse date/time: > >> `2007-02-20T12:15:51+0100' > The problem comes from the cvs client version 1.12.12 that doesn't seem any > more to support the specified time format (-MM-dd'T'HH:mm:ssZ). > Tests made with changelog and cvs client version 1.11.6 are ok. Older > versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 > work also correctly. > The problem is solved by replacing the format "-MM-dd'T'HH:mm:ssZ" by > this one "-MM-dd HH:mm:ssZ" in class AbstractCvsChangeLogCommand. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-291. Resolution: Fixed > Errors during date parsing with cvs version 1.12.12. > > > Key: SCM-291 > URL: http://jira.codehaus.org/browse/SCM-291 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0-beta-4 > Environment: Linux Suse 10 > CVS 1.12.12 >Reporter: johann angeli > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > The changelog plugin used with cvs client 1.12.12, failed with the following > error : > >> [ERROR] cvs [log aborted]: Can't parse date/time: > >> `2007-02-20T12:15:51+0100' > The problem comes from the cvs client version 1.12.12 that doesn't seem any > more to support the specified time format (-MM-dd'T'HH:mm:ssZ). > Tests made with changelog and cvs client version 1.11.6 are ok. Older > versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 > work also correctly. > The problem is solved by replacing the format "-MM-dd'T'HH:mm:ssZ" by > this one "-MM-dd HH:mm:ssZ" in class AbstractCvsChangeLogCommand. -- 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: (MDEP-78) analyze-dep-mgt has the labels reversed
[ http://jira.codehaus.org/browse/MDEP-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-78. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 > analyze-dep-mgt has the labels reversed > --- > > Key: MDEP-78 > URL: http://jira.codehaus.org/browse/MDEP-78 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0-alpha-3 >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.0-alpha-4 > > > The resolved line and the DepMgt outputs are reversed. -- 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: (MNG-2891) Fix deployment permissions so by default group write works
[ http://jira.codehaus.org/browse/MNG-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2891. -- Resolution: Fixed Test deployment to apache shows we're all set. > Fix deployment permissions so by default group write works > -- > > Key: MNG-2891 > URL: http://jira.codehaus.org/browse/MNG-2891 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 2.0.6 > > > We will change some code in Maven to set these defaults reasonably. -- 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: (MDEP-78) analyze-dep-mgt has the labels reversed
analyze-dep-mgt has the labels reversed --- Key: MDEP-78 URL: http://jira.codehaus.org/browse/MDEP-78 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0-alpha-3 Reporter: Brian Fox Assigned To: Brian Fox The resolved line and the DepMgt outputs are reversed. -- 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: (SCM-232) Improve error message when CVS URL is not correct
[ http://jira.codehaus.org/browse/SCM-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-232. Assignee: Emmanuel Venisse Resolution: Fixed > Improve error message when CVS URL is not correct > - > > Key: SCM-232 > URL: http://jira.codehaus.org/browse/SCM-232 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0-beta-3 > Environment: Win XP >Reporter: Christoph Amshoff > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > When the CVS URL is not correct because the module name is misspelled, the > error output always is "Embedded error: Exception while executing SCM > command. Username isn't defined." > This is misleading, since the username is definitely correct. This took me > more than 2 hours to figure out and should be fixed by issuing a more > applicable error message. -- 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-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
[ http://jira.codehaus.org/browse/MRELEASE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90825 ] Christian Gruber commented on MRELEASE-146: --- Sadly, I can't. I have returned my laptop and now have a MacBook Pro which I am more than happy with, and does not exhibit this behaviour. > Release tag with SVN under Cygwin fails when sending the svn command a bad > absolute path > > > Key: MRELEASE-146 > URL: http://jira.codehaus.org/browse/MRELEASE-146 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 > Environment: Windows XP >Reporter: Christian Gruber > > When release:prepare is invoked, on a cygwin system using svn provided with > cygwin, the following error occurs. > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml > [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: > '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' > is not a working copy > ... > SVN on cygwin interprets > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be > /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, > essentially appending the absolute path on the current working driectory as > if it were a relative path. > This is very odd, since "svn > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4" works like a charm. I > tried it with E: and e: to no avail. > Proposed solution: Use relative paths > Alternative - really really bad alternative: detect the presence of cygwin > and re-structure the file path to use /cygdrive/e/blah/blah format. > Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. > -Christian. -- 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: (MGPG-6) Attached jars/assemblies that would have renamed files result in wacky .asc files deployed....
Attached jars/assemblies that would have renamed files result in wacky .asc files deployed -- Key: MGPG-6 URL: http://jira.codehaus.org/browse/MGPG-6 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-3 Reporter: Daniel Kulp If an assembly or jar plugin uses a config element to change the name of the artifacts, when installed/deployed, they get renamed. However, the .asc files usually end up with a different name. In this case, the .asc files should not be attached and warning issued. Alternatively, they could be copied to the proper "deploy" name and attached in that form. -- 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-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
[ http://jira.codehaus.org/browse/MRELEASE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90823 ] Emmanuel Venisse commented on MRELEASE-146: --- Can you test with 2.0-beta-5-SNAPSHOT? Normally, we use relative path and I can't reproduce it but maybe the release plugin use somewhere an absolute path. > Release tag with SVN under Cygwin fails when sending the svn command a bad > absolute path > > > Key: MRELEASE-146 > URL: http://jira.codehaus.org/browse/MRELEASE-146 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 > Environment: Windows XP >Reporter: Christian Gruber > > When release:prepare is invoked, on a cygwin system using svn provided with > cygwin, the following error occurs. > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml > [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: > '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' > is not a working copy > ... > SVN on cygwin interprets > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be > /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, > essentially appending the absolute path on the current working driectory as > if it were a relative path. > This is very odd, since "svn > E:/projects/israfil-fw/net.israfil.foundation-JDK1.4" works like a charm. I > tried it with E: and e: to no avail. > Proposed solution: Use relative paths > Alternative - really really bad alternative: detect the presence of cygwin > and re-structure the file path to use /cygdrive/e/blah/blah format. > Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. > -Christian. -- 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: (SCM-213) Broken with Cygwin
[ http://jira.codehaus.org/browse/SCM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-213. Assignee: Emmanuel Venisse Resolution: Fixed I can't reproduce with latest code so I think it's fixed. Tested on the Maven-SCM TCK with windows svn and cygwin svn > Broken with Cygwin > -- > > Key: SCM-213 > URL: http://jira.codehaus.org/browse/SCM-213 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-3 > Environment: Cygwin under Windows, Maven release plugin version > 2.0-beta-4 >Reporter: Chas Douglass > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > svn doesn't like absolute path for the files to commit when we run it under > cygwin with a windows svn and a cygwin svn. > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit > e:/newapps/JEC/pom.xml > Working directory: e:\newapps\JEC > doesn't works with the same error you have > svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit pom.xml > Working directory: e:\newapps\JEC > works fine. -- 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: (MNG-2760) Fix deployment so that assemblies are signed with the GPG plugin
[ http://jira.codehaus.org/browse/MNG-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2760. -- Resolution: Won't Fix We can't actually do this because the install/deploy rename any attached artifacts which is the right thing to do. We need to make the assembly in the correct place to have it named correctly. Or we deploy separately and we typically have not pushed assemblies to the repo. At least for apache. > Fix deployment so that assemblies are signed with the GPG plugin > > > Key: MNG-2760 > URL: http://jira.codehaus.org/browse/MNG-2760 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > Currenty, the attached assemblies are not signed. -- 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-2891) Fix deployment permissions so by default group write works
[ http://jira.codehaus.org/browse/MNG-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2891: --- Description: We will change some code in Maven to set these defaults reasonably. Fix Version/s: 2.0.6 > Fix deployment permissions so by default group write works > -- > > Key: MNG-2891 > URL: http://jira.codehaus.org/browse/MNG-2891 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 2.0.6 > > > We will change some code in Maven to set these defaults reasonably. -- 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-2891) Fix deployment permissions so by default group write works
Fix deployment permissions so by default group write works -- Key: MNG-2891 URL: http://jira.codehaus.org/browse/MNG-2891 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Jason van Zyl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-188) Add the posibility of adding an entire directory to SCM
[ http://jira.codehaus.org/browse/SCM-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-188: - Fix Version/s: (was: 1.0) future > Add the posibility of adding an entire directory to SCM > --- > > Key: SCM-188 > URL: http://jira.codehaus.org/browse/SCM-188 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api >Affects Versions: 1.0-beta-3 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: future > > > For the scm wagon I'd need to add a whole directory to scm. > Right now the only solution is create a ScmFileSet, but none of the current > methods adds directories, i have to look for them and add in order so the svn > add works correctly. > It'd be a nice to have in the API an addDirectory or make the add command add > directories recursively (I don't know what's the use case of the current > behaviour) > eg. translated to svn it would call a svn add recursively, also optimizing > the current approach of calling lots of times to external svn -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90820
]
Jason van Zyl commented on MNG-2854:
Point one is fine.
Point two is not fine. One artifact and so many people expect the
pom.properties file and is what we document. That can't change and I will never
support the widespread production of multiple artifacts.
Point three is fine.
Fix up the second point and I will apply the patch. Also, how did you test this?
> Recreating pom.properties always breaks the archivers uptodate check
>
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.5
>Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation.
> (Unless the flag "addMavenDescriptor" is set to false, which few people do.)
> This forced recreation makes the uptodate check fail. In other words, jar
> files are always recreated, regardless whether anything was recompiled.
> Obviously, this makes the uptodate check of war files etc. fail as well,
> because the included jar files are always changed.. This is a major drawback,
> because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch
> does:
> - It is obviously bad, that the generated pom.properties file is in the
> projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which
> seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create
> multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the
> pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
> unique.
> - Finally, the patch makes the maven-archiver check, whether the
> pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version
> have changed.)
> It does so, by writing the file to an internal buffer and comparing the
> file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version
> haven't changed, the pom.properties file remains unchanged. In particular,
> the jar file doesn't need to be recreated.
--
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-2890) Allow for deploying to multiple repositories
Allow for deploying to multiple repositories Key: MNG-2890 URL: http://jira.codehaus.org/browse/MNG-2890 Project: Maven 2 Issue Type: Improvement Components: Deployment Reporter: David Jackman There is currently no way to list multiple repositories for deployment. When I've brought this question up before, people say to create mirrors of the repository, but that's not really the right solution in many cases. In my own case, I need to deploy to a Maven 1.x repository as well as the 2.x repository for the time being (while projects are moving from Maven 1 to Maven 2). This situation can't be solved by a repository mirror. -- 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: (SCM-185) Validity check rejects valid protocol
[ http://jira.codehaus.org/browse/SCM-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-185. Assignee: Emmanuel Venisse Resolution: Fixed > Validity check rejects valid protocol > - > > Key: SCM-185 > URL: http://jira.codehaus.org/browse/SCM-185 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-2 >Reporter: Joerg Schaible > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > According to the subversion manual a user can add arbitrary protocols by > defining new tunnels in his local subversion configuration. Such definitions > are necessary to tunnel ports, define the usage of a smart card, ... e.g. > defining an entry in the tunnel section of the .subversion/config file to > access over SSH protocol version 1 can be defined like: > ssh1=ssh -1 > A repo would be accessed with "svn+ssh1://repo/url" > This is not possible, since the SvnScmProvider checks against a fixed set of > protocols, which is not correct. -- 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: (MRRESOURCES-18) Error when no 'inceptionYear' is specified in POM
[
http://jira.codehaus.org/browse/MRRESOURCES-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90815
]
Konstantin Pavlov commented on MRRESOURCES-18:
--
Error when no 'inceptionYear' is *NOT* specified in the POM
> Error when no 'inceptionYear' is specified in POM
> -
>
> Key: MRRESOURCES-18
> URL: http://jira.codehaus.org/browse/MRRESOURCES-18
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Konstantin Pavlov
>Priority: Minor
>
> [INFO] [remote-resources:process {execution: default}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] You must specify an inceptionYear.
> 'inceptionYear' is optionl element in the POM (see
> http://maven.apache.org/maven-v4_0_0.xsd), but plugin requires it to be
> specified.
--
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: (MRRESOURCES-18) Error when no 'inceptionYear' is specified in POM
Error when no 'inceptionYear' is specified in POM
-
Key: MRRESOURCES-18
URL: http://jira.codehaus.org/browse/MRRESOURCES-18
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.0-alpha-3
Reporter: Konstantin Pavlov
Priority: Minor
[INFO] [remote-resources:process {execution: default}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] You must specify an inceptionYear.
'inceptionYear' is optionl element in the POM (see
http://maven.apache.org/maven-v4_0_0.xsd), but plugin requires it to be
specified.
--
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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-291: - Assignee: Emmanuel Venisse Fix Version/s: 1.0 > Errors during date parsing with cvs version 1.12.12. > > > Key: SCM-291 > URL: http://jira.codehaus.org/browse/SCM-291 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0-beta-4 > Environment: Linux Suse 10 > CVS 1.12.12 >Reporter: johann angeli > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > The changelog plugin used with cvs client 1.12.12, failed with the following > error : > >> [ERROR] cvs [log aborted]: Can't parse date/time: > >> `2007-02-20T12:15:51+0100' > The problem comes from the cvs client version 1.12.12 that doesn't seem any > more to support the specified time format (-MM-dd'T'HH:mm:ssZ). > Tests made with changelog and cvs client version 1.11.6 are ok. Older > versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 > work also correctly. > The problem is solved by replacing the format "-MM-dd'T'HH:mm:ssZ" by > this one "-MM-dd HH:mm:ssZ" in class AbstractCvsChangeLogCommand. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90814 ] Emmanuel Venisse commented on SCM-291: -- cvs 1.12.* isn't yet a stable release but a "feature" release and it isn't supported yet by Maven-SCM. The date format is totally different in cvs 1.12 and we need to allow new formats. I can't change the actual format by "-MM-dd HH:mm:ssZ" for all cvs client because lot of them doesn't support this format. I think I'll allow to change the format in cvs-settings.xml > Errors during date parsing with cvs version 1.12.12. > > > Key: SCM-291 > URL: http://jira.codehaus.org/browse/SCM-291 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0-beta-4 > Environment: Linux Suse 10 > CVS 1.12.12 >Reporter: johann angeli > Fix For: 1.0 > > > The changelog plugin used with cvs client 1.12.12, failed with the following > error : > >> [ERROR] cvs [log aborted]: Can't parse date/time: > >> `2007-02-20T12:15:51+0100' > The problem comes from the cvs client version 1.12.12 that doesn't seem any > more to support the specified time format (-MM-dd'T'HH:mm:ssZ). > Tests made with changelog and cvs client version 1.11.6 are ok. Older > versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 > work also correctly. > The problem is solved by replacing the format "-MM-dd'T'HH:mm:ssZ" by > this one "-MM-dd HH:mm:ssZ" in class AbstractCvsChangeLogCommand. -- 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-309) relocated artifacts are not delivered
relocated artifacts are not delivered - Key: MRM-309 URL: http://jira.codehaus.org/browse/MRM-309 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: latest version from SVN (rev. 521221) archiva running in tomcat-5.5.17 on a linux system Reporter: Joerg Vater One managed repository with two proxied repositories. When I request an artifact that is relocated in the proxied repository, the relocaated artifact is downloaded to the local repository but not delivered to the requestor. -- log messages: 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact requested is: easymock:easymock:jar:2.0:runtime 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/easymock/easymock/2.0/easymock-2.0.pom does not exist 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository 2007-03-22 13:32:05,877 8868794 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded 2007-03-22 13:32:05,889 8868806 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact easymock:easymock:2.0 has been relocated to org.easymock:easymock:2.0 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.pom does not exist 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository 2007-03-22 13:32:06,157 8869074 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.jar from ComBOTS Maven2 Repository 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.jar does not exist 2007-03-22 13:32:06,159 8869076 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.jar from Maven2 Central Repository 2007-03-22 13:32:07,017 8869934 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded -- html response: Error 404 Not Found Resource in error: http://mavenproxy:9080/archiva/repository/easymock/easymock/2.0/easymock-2.0.jar/easymock/easymock/2.0/easymock-2.0.jar Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.open
[jira] Commented: (MRM-308) Maven1 requests are not served
[ http://jira.codehaus.org/browse/MRM-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90813 ] Joerg Vater commented on MRM-308: - When I change the layout of the managed repository to legacy it works for maven1 requests but not for maven2 requests. > Maven1 requests are not served > -- > > Key: MRM-308 > URL: http://jira.codehaus.org/browse/MRM-308 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: using latest version from SVN: revision 521221 > archiva running on Tomcat-5.5.17 >Reporter: Joerg Vater > > I got one managed repository with two proxied repositories, one for our > locally built artifacts and the central repository. > When I try to retreive an artifact with maven2 path layout (e.g. > ant/ant/1.6.5/ant-1.6.5.jar) everything works fine. > When I try to retreive the same artifact with maven1 path layout > (ant/jars/ant-1.6.5.jar) the jar gets downloaded from the proxied repository > but is not delivered to the client. Client response is a 404 (s. below). In > the local directory it is stored with the maven2 path layout > -- log output: > 2007-03-22 12:20:51,278 4594195 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > requested is: ant:ant:jar:1.6.5:runtime > 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > ant/ant/1.6.5/ant-1.6.5.pom from ComBOTS Maven2 Repository > 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/ant/ant/1.6.5/ant-1.6.5.pom does not > exist > 2007-03-22 12:20:51,281 4594198 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > ant/ant/1.6.5/ant-1.6.5.pom from Maven2 Central Repository > 2007-03-22 12:20:51,728 4594645 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > -- http response: > Error 404 Not Found > Resource in error: > http://mavenproxy:9080/archiva/repository/ant/jars/ant-1.6.5.jar/ant/jars/ant-1.6.5.jar > Exception details: > it.could.webdav.DAVException: Not found > at it.could.webdav.methods.HEAD.process(HEAD.java:52) > at it.could.webdav.methods.GET.process(GET.java:58) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Htt
[jira] Created: (MECLIPSE-248) Clean build of maven-eclipse-plugin-2.3 tag fails
Clean build of maven-eclipse-plugin-2.3 tag fails - Key: MECLIPSE-248 URL: http://jira.codehaus.org/browse/MECLIPSE-248 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally empty local repository, no remote repositories other than central Reporter: Max Bowsher Attachments: org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test failure: Tests in error: testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) (build log for this test is attached) Presumably this is not the fault of the eclipse plugin code, since it must have built at one time in order to be released, but I'm not sure where else to report it. The test failure poses a problem for people trying to make modified versions of the plugin based on the last released 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] Created: (SCM-291) Errors during date parsing with cvs version 1.12.12.
Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli The changelog plugin used with cvs client 1.12.12, failed with the following error : >> [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format "-MM-dd'T'HH:mm:ssZ" by this one "-MM-dd HH:mm:ssZ" in class AbstractCvsChangeLogCommand. -- 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-308) Maven1 requests are not served
Maven1 requests are not served -- Key: MRM-308 URL: http://jira.codehaus.org/browse/MRM-308 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: using latest version from SVN: revision 521221 archiva running on Tomcat-5.5.17 Reporter: Joerg Vater I got one managed repository with two proxied repositories, one for our locally built artifacts and the central repository. When I try to retreive an artifact with maven2 path layout (e.g. ant/ant/1.6.5/ant-1.6.5.jar) everything works fine. When I try to retreive the same artifact with maven1 path layout (ant/jars/ant-1.6.5.jar) the jar gets downloaded from the proxied repository but is not delivered to the client. Client response is a 404 (s. below). In the local directory it is stored with the maven2 path layout -- log output: 2007-03-22 12:20:51,278 4594195 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact requested is: ant:ant:jar:1.6.5:runtime 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from ComBOTS Maven2 Repository 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/ant/ant/1.6.5/ant-1.6.5.pom does not exist 2007-03-22 12:20:51,281 4594198 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from Maven2 Central Repository 2007-03-22 12:20:51,728 4594645 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded -- http response: Error 404 Not Found Resource in error: http://mavenproxy:9080/archiva/repository/ant/jars/ant-1.6.5.jar/ant/jars/ant-1.6.5.jar Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) -- T
[jira] Closed: (SCM-290) Improved documentation for ClearCase SCM provider
[ http://jira.codehaus.org/browse/SCM-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-290. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 > Improved documentation for ClearCase SCM provider > - > > Key: SCM-290 > URL: http://jira.codehaus.org/browse/SCM-290 > Project: Maven SCM > Issue Type: Improvement > Components: documentation, maven-scm-provider-clearcase, > maven-scm-site >Affects Versions: 1.0 >Reporter: Arne Degenring > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > Attachments: maven-scm-provider-clearcase-patch.txt, > maven-scm-site-patch.txt > > > The attached patches contain improved documentation for the ClearCase SCM > provider. -- 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: (SCM-289) Allow to store clearcase-settings.xml in ${maven.home}/conf instead of ${user.home}/.scm
[
http://jira.codehaus.org/browse/SCM-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed SCM-289.
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 1.0
> Allow to store clearcase-settings.xml in ${maven.home}/conf instead of
> ${user.home}/.scm
>
>
> Key: SCM-289
> URL: http://jira.codehaus.org/browse/SCM-289
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0
>Reporter: Arne Degenring
> Assigned To: Emmanuel Venisse
> Fix For: 1.0
>
> Attachments: maven-scm-provider-clearcase-ClearCaseUtil-patch.txt
>
>
> The clearcase-settings.xml contain environment-specific, not user-specific
> settings. It should there be possible to store it in ${maven.home}/conf
> instead of ${user.home}/.scm. If it is present at both places, the file at
> ${user.home}/.scm wins.
> See attached patch.
--
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: (SCM-290) Improved documentation for ClearCase SCM provider
Improved documentation for ClearCase SCM provider - Key: SCM-290 URL: http://jira.codehaus.org/browse/SCM-290 Project: Maven SCM Issue Type: Improvement Components: documentation, maven-scm-provider-clearcase, maven-scm-site Affects Versions: 1.0 Reporter: Arne Degenring Attachments: maven-scm-provider-clearcase-patch.txt, maven-scm-site-patch.txt The attached patches contain improved documentation for the ClearCase SCM provider. -- 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: (SCM-289) Allow to store clearcase-settings.xml in ${maven.home}/conf instead of ${user.home}/.scm
Allow to store clearcase-settings.xml in ${maven.home}/conf instead of
${user.home}/.scm
Key: SCM-289
URL: http://jira.codehaus.org/browse/SCM-289
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-clearcase
Affects Versions: 1.0
Reporter: Arne Degenring
Attachments: maven-scm-provider-clearcase-ClearCaseUtil-patch.txt
The clearcase-settings.xml contain environment-specific, not user-specific
settings. It should there be possible to store it in ${maven.home}/conf instead
of ${user.home}/.scm. If it is present at both places, the file at
${user.home}/.scm wins.
See attached patch.
--
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-1435) Upload ZK 2.3.0 to the central repository
Upload ZK 2.3.0 to the central repository - Key: MAVENUPLOAD-1435 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1435 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh http://www.zkoss.org/maven/bundles/2.3.0/zcommon-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zweb-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zk-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zul-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zhtml-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zkplus-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/dojoz-0.4.1-1-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/gmapsz-2.0-3-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/timelinez-1.1-1-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- 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-1434) please upload new version of vafer.org dependency
please upload new version of vafer.org dependency - Key: MAVENUPLOAD-1434 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1434 Project: maven-upload-requests Issue Type: Task Reporter: Torsten Curdt required for the new release of minijar which is supposed to be used for the maven 2.0..6 release -- 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: (MJXR-26) JXR does not handle empty (completely commented) java-files...
JXR does not handle empty (completely commented) java-files...
--
Key: MJXR-26
URL: http://jira.codehaus.org/browse/MJXR-26
Project: Maven 2.x JXR Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Maven 2.0.5 (Windows 2003 Srv/Windows XP)
Reporter: Jan Palmquist
Priority: Minor
I have detected that the jxr-plugin (or sub components) does not handle
java-files being completely commented away e.g.
//package my.demopackage;
//public class MyClass {
//}
This is not a big issue, however it is quite annoying to have to notify
developers that this not only is bad coding style but also breaks site
generation.
My stack trace:
INFO] Generate "Test Source Xref" report.
Unable to processPath
C:\CC\projects\MyProject\src\test\java\my\demopackage\MyClass.java =>
c:\CC\projects\MyProject\target/site/xref-test\my\demopackage\MyClass.html
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.jxr.JavaCodeTransform.getHeader(JavaCodeTransform.java:651)
at org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:716)
at org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:787)
at org.apache.maven.jxr.JXR.transform(JXR.java:195)
at org.apache.maven.jxr.JXR.processPath(JXR.java:114)
at org.apache.maven.jxr.JXR.xref(JXR.java:335)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.createXref(AbstractJxrReport.java:226)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.executeReport(AbstractJxrReport.java:352)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
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: 9 minutes 24 seconds
[INFO] Finished at: Thu Mar 22 07:26:14 CET 2007
[INFO] Final Memory: 73M/200M
[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
