[jira] Updated: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphael Ackermann updated MRELEASE-83: -- Attachment: AbstractCvsCheckInCommand.java.patch The attached patch fixes this issue for me when using CVS (the all java cvs client) I get the same result that the first Login and also the update cvs commands work, but the checkin and tag commands won't work. As others have commented before, it uses the username defined in the CVS/Root file. Debugging the code I found out that it always checks the CVS/Root file, but if there is a -d option that takes precedence. -d cvs_root_directory Use cvs_root_directory as the root directory pathname of the reposi- tory. Overrides the setting of the $CVSROOT environment variable. See `Repository' in the CVS manual. A change in revision 518698 changed the behaviour to not include the -d option when generating the tag, checkin, update and branch cvs commands. The comment for that revision indicates that this was a problem for the update command. I think that maybe it should have only be changed for the update command while leaving the tag and checkin behaviour to include the -d option. See the comment for rev 518698 below: Revision: 518698 Author: evenisse Date: 3/15/07 6:17 PM Comment: Remove cvsroot from the command when it isn't needed. It fix some pb with update when files are updated only on the root directory and not detected. > Wrong username during release:prepare tagging > - > > Key: MRELEASE-83 > URL: http://jira.codehaus.org/browse/MRELEASE-83 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Reporter: Niclas Hedhman > Attachments: AbstractCvsCheckInCommand.java.patch > > > If I my Svn repository requires a different username than the login name, and > I issue >mvn -dmaven.username=nic...@hedhman.org release:prepare > The first phase (checking in modified POMs) will succeed with that username. > Then somewhere between that point and writing out the release.properties > file, the user name falls back to the login name (in my case "niclas"), which > is written into the release.properties file, and used during the tagging of > the repository. > Now, looking at the source, I think that is unwise to keep a username both in > the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that > there is some type of sequencing problem in there. > WORKAROUND; > Before starting the release:prepare, create a release.properties file > manually which contains > maven.username=nic...@hedhman.org > and everything will work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-272) DecoderException trying to download external links
[ http://jira.codehaus.org/browse/MJAVADOC-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221585#action_221585 ] Raphael Ackermann commented on MJAVADOC-272: I ran into the same problem and spent half a day tracking it down. We also had a corrupt pom in our repository manager. Using the correct one with the dependencies solved the issue. +1 for adding it to an FAQ > DecoderException trying to download external links > -- > > Key: MJAVADOC-272 > URL: http://jira.codehaus.org/browse/MJAVADOC-272 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0_14 >Reporter: Paul Benedict >Priority: Minor > > The fetches of external javadoc links are causing failure. > java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException > at > org.apache.commons.httpclient.HttpMethodBase.(HttpMethodBase.java:220) > at > org.apache.commons.httpclient.methods.GetMethod.(GetMethod.java:89) > at > org.apache.maven.plugin.javadoc.JavadocUtil.fetchURL(JavadocUtil.java:787) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.isValidJavadocLink(AbstractJavadocMojo.java:4921) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addLinkArguments(AbstractJavadocMojo.java:3303) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addStandardDocletOptions(AbstractJavadocMojo.java:4038) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1803) > at > org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:124) > at > org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:283) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.codec.DecoderException > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at > org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > ... 28 more > I don't see how this error makes sense, and maybe it needs to be transferred > to the HTTPClient component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrator
[jira] Commented: (MENFORCER-90) Allow "BannedDependencies" to restrict artifacts per-scope
[ http://jira.codehaus.org/browse/MENFORCER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227703#action_227703 ] Raphael Ackermann commented on MENFORCER-90: isn't that the same as http://jira.codehaus.org/browse/MENFORCER-72 ? > Allow "BannedDependencies" to restrict artifacts per-scope > -- > > Key: MENFORCER-90 > URL: http://jira.codehaus.org/browse/MENFORCER-90 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Reporter: Andrew Lee Rubinger > > The current BannedDependencies plugin allows the restriction of any artifact > by groupId, artifactId, etc. We've observed cases where we need to block > only in certain scopes, for instance: > * I have a component which uses some logging backend > * I don't want to allow any code to directly use the logging backend; it > should use an abstraction SPI > * I want to bar all logging backends from the compilation classpath, but they > must be available at runtime for tests > * So I'd set a banned dependency upon the logging backend for scopes > "compile" and "provided", permitting its use in testing > I've mocked this (with hardcoded banned scopes) by copying from the existing > BannedDependency stuff: > http://anonsvn.jboss.org/repos/sandbox/alrubinger/maven-enforcer-rule-nocompiledep/trunk/nocompiledep/src/main/java/org/jboss/maven/plugins/enforcer/rules/nocompiledep/NoCompileDependencyRule.java > ...which works pretty well, but it'd be nice to have this > 1) Configurable > 2) Upstream -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-513) Enable Dependency Management and other actions cause Exception (don't run through)
Enable Dependency Management and other actions cause Exception (don't run through) -- Key: MECLIPSE-513 URL: http://jira.codehaus.org/browse/MECLIPSE-513 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: Windows XP. Eclipse 3.5M4, newest maven dev plugins. Reporter: Raphael Ackermann When checking out a project, or selecting Enable Dependency Management in the context menu I get the following error. java.lang.IllegalArgumentException: Attempted to beginRule: MultiRule[P/usp-sls-framework,P/.org.eclipse.jdt.core.external.folders], does not match outer scope rule: org.maven.ide.eclipse.internal.project.schedulingr...@d150be at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:122) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:232) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:232) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1747) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1795) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:786) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:2832) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:2863) at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.addMavenClasspathContainer(JavaProjectConfigurator.java:583) at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.configure(JavaProjectConfigurator.java:90) at org.maven.ide.eclipse.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:252) at org.maven.ide.eclipse.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:235) at org.maven.ide.eclipse.actions.UpdateSourcesAction$1.runInWorkspace(UpdateSourcesAction.java:74) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) -- 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
