[jira] Closed: (CONTINUUM-1264) Editing a Project Group's name to an empty string generates an exception
[ http://jira.codehaus.org/browse/CONTINUUM-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed CONTINUUM-1264. --- Resolution: Fixed Applied patch -r536738. Thanks! > Editing a Project Group's name to an empty string generates an exception > > > Key: CONTINUUM-1264 > URL: http://jira.codehaus.org/browse/CONTINUUM-1264 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Maria Odea Ching > Attachments: CONTINUUM-1264-continuum-webapp.patch > > > To replicate (assuming the user has sufficient roles): > 1. Create a project group (name="asdf", id="asdf") > 2. Edit a project group, change name into "" > Result: > Caused by: org.codehaus.plexus.rbac.profile.RoleProfileException: invalid role > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:405) > at > org.codehaus.plexus.rbac.profile.DefaultRoleProfileManager.renameDynamicRole(DefaultRoleProfileManager.java:134) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:262) > ... 78 more > Caused by: org.codehaus.plexus.security.rbac.RbacObjectInvalidException: > Resource.identifier must not be empty. > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:123) > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:110) > at > org.codehaus.plexus.security.authorization.rbac.store.jdo.JdoRbacManager.saveResource(JdoRbacManager.java:458) > at > org.codehaus.plexus.security.authorization.rbac.store.cached.CachedRbacManager.saveResource(CachedRbacManager.java:662) > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:381) > ... 80 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2695) -o makes build fail for snapshot plugins
[
http://jira.codehaus.org/browse/MNG-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95523
]
Nathan McDonald commented on MNG-2695:
--
Am having the same problem with maven 2.0.6
> -o makes build fail for snapshot plugins
>
>
> Key: MNG-2695
> URL: http://jira.codehaus.org/browse/MNG-2695
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
>
> I've set the maven-eclipse-plugin version to 2.3-SNAPSHOT in my root pom.
> When I run without -o, the build works fine. All 100 non-deployed
> snapshot artifacts are resolved 100 times from all of my 10 remote
> repo's so the build takes ages.
> After a succesful build, I run with -o and the build fails:
> {noformat}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.plugins
> ArtifactId: maven-eclipse-plugin
> Version: 2.3-SNAPSHOT
> Reason: System is offline.
> org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> NOTE: Maven is executing in offline mode. Any artifacts not already in your
> local
> repository will be inaccessible.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM
> 'org.apache.maven.
> plugins:maven-eclipse-plugin' not found in repository: System is offline.
> org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1269)
> 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:393)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:394)
> 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)
> Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build
> project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM
> 'org.apache.mav
> en.plugins:maven-eclipse-plugin' not found in repository: System is offline.
> org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:266)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:184)
> at
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:164)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252)
> ... 15 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM
> 'org.apache.maven.plugins:maven-eclipse-plugin' not found in repository:
> System is offline.
> org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:522)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:227)
> at
> org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:250)
> ... 18 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
> System is offline.
> org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.r
[jira] Closed: (MAVENUPLOAD-1525) Upload JSON-RPC 1.0 to maven 1 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Eade closed MAVENUPLOAD-1525. --- Resolution: Won't Fix Already there - don't know how I missed it before. > Upload JSON-RPC 1.0 to maven 1 repo > --- > > Key: MAVENUPLOAD-1525 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1525 > Project: maven-upload-requests > Issue Type: Task >Reporter: Scott Eade > > This is the ASL 2.0 licensed metaparadigm.com implementation of JSON-RPC-Java. > It already exists in the maven 2 repository, but I need it in the maven 1 > repository so that I can include it as a dependency for a project that is > still using maven 1 as its build system. > The bundle file will be available when people.apache.org next does an rsysnc > TIA. -- 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: (MIDEA-91) Incorrect web module definition if repository drive letter is lowercase
[ http://jira.codehaus.org/browse/MIDEA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Shevchuk updated MIDEA-91: -- Attachment: bug_mvn_idea.gif > Incorrect web module definition if repository drive letter is lowercase > --- > > Key: MIDEA-91 > URL: http://jira.codehaus.org/browse/MIDEA-91 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows >Reporter: Vitaliy Shevchuk > Attachments: bug_mvn_idea.gif > > > In Windows, if local repository is defined with a lower case letter for a > disk drive (for example: c:\repo instead of C:\repo), some incorrect values > appears in "Web Module Setting->Modules and Libraries to Package". > The workaround is to declare the local repository with a capital disk drive > letter. > However it is not obvious for everyone. I'm sure the correction (Or just a > warning message) would be greatly appreciated by the IntelliJ lovers. > Cheers -- 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: (MIDEA-91) Incorrect web module definition if repository drive letter is lowercase
[ http://jira.codehaus.org/browse/MIDEA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95511 ] Vitaliy Shevchuk commented on MIDEA-91: --- sure! check out the attached file > Incorrect web module definition if repository drive letter is lowercase > --- > > Key: MIDEA-91 > URL: http://jira.codehaus.org/browse/MIDEA-91 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows >Reporter: Vitaliy Shevchuk > > In Windows, if local repository is defined with a lower case letter for a > disk drive (for example: c:\repo instead of C:\repo), some incorrect values > appears in "Web Module Setting->Modules and Libraries to Package". > The workaround is to declare the local repository with a capital disk drive > letter. > However it is not obvious for everyone. I'm sure the correction (Or just a > warning message) would be greatly appreciated by the IntelliJ lovers. > Cheers -- 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: (MEV-520) retroweaver 1.2.4 jar is corrupt
retroweaver 1.2.4 jar is corrupt Key: MEV-520 URL: http://jira.codehaus.org/browse/MEV-520 Project: Maven Evangelism Issue Type: Bug Reporter: Brian Fox http://repo1.maven.org/maven2/net/sourceforge/retroweaver/retroweaver/1.2.4/ This jar can't be opened with zip,winrar or my compiler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-229) Links in site.xml get translated to ../../../
[ http://jira.codehaus.org/browse/MSITE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95508 ] Dennis Lundberg commented on MSITE-229: --- This happens because the site plugin tries to make all URLs relative, when possible. I think that you have something like this defined in the pom.xml for this project: http://sirdsite.dsths.ad.dstcorp.net/x/y/z/ where x, y and z are some directory names. > Links in site.xml get translated to ../../../ > - > > Key: MSITE-229 > URL: http://jira.codehaus.org/browse/MSITE-229 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Linux FC6 Sun Java (build 1.5.0_10-b03, mixed mode, > sharing) >Reporter: Mykel Alvis >Priority: Minor > Attachments: site.xml > > > In Site.xml for a project (that has a parent POM) > > http://sirdsite.dsths.ad.dstcorp.net/"; /> > http://www.apache.org/"; /> > http://maven.apache.org/maven2/"/> > > Gets rendered as > > SIRD Site > | > http://www.apache.org/";>Apache > | > http://maven.apache.org/maven2/";>Maven 2 > > " http://sirdsite.dsths.ad.dstcorp.net/"; != "../../.." -- 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: (MIDEA-91) Incorrect web module definition if repository drive letter is lowercase
[ http://jira.codehaus.org/browse/MIDEA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95507 ] Dennis Lundberg commented on MIDEA-91: -- Can you explain in more detail what you mean by "incorrect values". I don't understand the problem you are describing. If you have a pom.xml that shows off this behavior, that would really be helpful. > Incorrect web module definition if repository drive letter is lowercase > --- > > Key: MIDEA-91 > URL: http://jira.codehaus.org/browse/MIDEA-91 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows >Reporter: Vitaliy Shevchuk > > In Windows, if local repository is defined with a lower case letter for a > disk drive (for example: c:\repo instead of C:\repo), some incorrect values > appears in "Web Module Setting->Modules and Libraries to Package". > The workaround is to declare the local repository with a capital disk drive > letter. > However it is not obvious for everyone. I'm sure the correction (Or just a > warning message) would be greatly appreciated by the IntelliJ lovers. > Cheers -- 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: (MECLIPSE-267) Enhance make-artifacts to not create POMs that have version ranges
[ http://jira.codehaus.org/browse/MECLIPSE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Beermann updated MECLIPSE-267: -- Attachment: MECLIPSE-267-maven-eclipse-plugin.patch I believe that this patch fixes the issue. > Enhance make-artifacts to not create POMs that have version ranges > -- > > Key: MECLIPSE-267 > URL: http://jira.codehaus.org/browse/MECLIPSE-267 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: Micah Whitacre > Attachments: MECLIPSE-267-maven-eclipse-plugin.patch > > > Currently when using the make-artifacts goal to deploy Eclipse artifacts to a > remote repository the POMs are created in such a way the versions of the > dependencies have ranges similar to [3.3,4). This information is pulled from > the Manifest. I'd like a way to specify not to use those version ranges in > the POM but to instead have a soft dependency on a specific version. The > situation that is occurring is that when I have deployed both Eclipse 3.2 and > 3.3 endstates to a remote repository, the 3.2 dependencies have ranges > specified which then pull in the 3.3 endstates. This causes conflicts when I > want to only include 3.2 endstates. If there was a way to 1. not use version > ranges in the POM and 2. instead have a soft dependency on a specific > version. This would eliminate the need to specify each and every Eclipse 3.2 > artifact for fear a transitive 3.3 dependency got pulled in. > I have also seen this cause errors when a transitive dependency pulls in a > 3.3 endstate that has conflicting version ranges for an artifact I have a > dependency on. Since the 3.3 endstates will have version ranges of [3.3,4) > but I might specify 3.2 dependencies, if I have a first class dependency on > 3.2 and a transitive dependency on the same artifact but the range is > [3.3,4), I will not be able to build my project. -- 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: (MANTTASKS-15) scp:// urls not recognised, even when wagon-ssh is installed.
[
http://jira.codehaus.org/browse/MANTTASKS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95499
]
Mykel Alvis commented on MANTTASKS-15:
--
I managed to work around this particular issue.
I WAS doing the following:
{blahblahblah}
The thing I was failing to recognize is the nature of antcall'd tasks.
Declaring the artifact:provider in one task makes it accessible in another
task, but not if I do an "antcall" to a subtask in an effort to consolidate
certain behaviors.. Dunno why I thought it would work. When I inheritRefs, the
pom reference I have in the artifact:deploy (not shown) has a reference
conflict.
So you can't do an antcall to call a task to do a deploy without re-decalaring
the provider. I have a provider call setup as part of the "init" call that's a
"depends" above, but the provider isn't available after the antcall.
It appears that wagon-ssh:1.0-alpha-7 is a valid scp provider, but 1.0-beta-2
gives an error:
java.lang.NoSuchMethodError:
org.apache.maven.wagon.CommandExecutor.executeCommand
(Ljava/lang/String;Z)Lorg/apache/maven/wagon/Streams;
> scp:// urls not recognised, even when wagon-ssh is installed.
> -
>
> Key: MANTTASKS-15
> URL: http://jira.codehaus.org/browse/MANTTASKS-15
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: ant-v-logfile.txt, MANTTASKS-15.diff
>
>
> I have got the task working to pull in the various deployment wagons
>
> version="${wagon-ssh.version}"/>
> version="${wagon-ssh-external.version}"/>
> version="${wagon-file.version}"/>
> version="${wagon-ftp.version}"/>
>
> But when I run a deploy target and use the scp:// protocol , I get the
> unknown protocol error.
>
>
>value="scp://${ssh.host}/www/repository"/>
>
>
>privateKey="${ssh.keyfile}"/>
>
>
>
>
> This is only for scp:, the others, scpexe, file: and ftp: do work. Is the url
> schema wrong? Is there any way to enum what protocols are currently supported?
> I would recommend that the error message "unsupported protocol" is
> supplemented with a listing of what protocols are supported. That way its
> easier to differentiate spelling error from uninstalled wagon.
--
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: (MECLIPSE-251) Allows prefixing of eclipse project name
[
http://jira.codehaus.org/browse/MECLIPSE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Fernandes updated MECLIPSE-251:
Attachment: 20070509-maven-eclipse-plugin.patch
As I've had the same problem, here's a little patch which should do the work. I
would appreciate any feedback and notes about it. This patch is based on the
revision 520045 at
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin.
To prefix a project with a specific name just add
-Declipse.projectNamePrefix=myprefix to the command line and it should work.
Inside the configuration of the plugin just specifiy
myprefix.
One thing I haven't done (shame on me) was to generate testcases (again, shame
on me). The probleme was, that I have no idea of the correct way how to
implement such a testcase using the existing plexus framework.
> Allows prefixing of eclipse project name
>
>
> Key: MECLIPSE-251
> URL: http://jira.codehaus.org/browse/MECLIPSE-251
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: multiproject
>Affects Versions: 2.4
>Reporter: Martin Desruisseaux
> Attachments: 20070509-maven-eclipse-plugin.patch
>
>
> This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They
> were closed as fixed by MECLIPSE-189, but the later doesn't adress fully our
> issue (or works only if we are lucky).
> We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
> modules. Some Geoserver modules may (by accident) have the same name than
> Geotools modules. For example both Geotools and Geoserver have a module named
> "_main_". We need to import those two projects in Eclipse, because they are
> closely related and share the same pool of developpers. Before MECLIPSE-189,
> it was not possible with those names, because of module name clash like
> "_main_". Since MECLIPSE-189, it is possible if we are lucky enough to have
> different Geotools and Geoserver version numbers.
> We would like a way to prefix every Eclipse module names. For example we
> would like a way to add {{"gt-"}} in front of every Geotools modules imported
> in Eclipse. I realize that the common practice in Maven projects seems to be
> long module names (for example "{{maven-eclipse-plugin}}"), but such practice
> seems quite redundant with group name. We would like to keep module names
> that match SVN directory names or Maven report directory names (otherwise we
> often get broken links in generated HTML pages), and we would like to keep
> the path names simple and intelligible (long module names don't bring much
> compared to full path names, which should already be unique).
> The ability to add some prefix before Eclipse project names would help. If
> this is not possible, something like {{addGroupNameToProjectName}} property
> (similar to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a
> fallback.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95492 ] Joakim Erdfelt commented on MRM-243: This can occur (according to the code) due to the following # temp directory not specified in system environment. # temp directory is full. # temp directory has too many files in it. # java.io can't flush contents to disk. # java.io can't write bytes to disk. That's it. A stacktrace from the server side should help narrow down which of these is causing the problem. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen > Fix For: 1.0 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1526) Sync jXLS repository to the central repository
Sync jXLS repository to the central repository -- Key: MAVENUPLOAD-1526 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1526 Project: maven-upload-requests Issue Type: Task Reporter: Leonid Vysochyn Attachments: net.sf.jxls.sh Please do a sync of jxls repository /home/groups/j/jx/jxls/htdocs/repository/releases to central repository as there is a new release of jXLS library (0.9.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] Commented: (MSITE-229) Links in site.xml get translated to ../../../
[ http://jira.codehaus.org/browse/MSITE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95488 ] Mykel Alvis commented on MSITE-229: --- When I change the hostname to it's IP address, it works. > Links in site.xml get translated to ../../../ > - > > Key: MSITE-229 > URL: http://jira.codehaus.org/browse/MSITE-229 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Linux FC6 Sun Java (build 1.5.0_10-b03, mixed mode, > sharing) >Reporter: Mykel Alvis >Priority: Minor > Attachments: site.xml > > > In Site.xml for a project (that has a parent POM) > > http://sirdsite.dsths.ad.dstcorp.net/"; /> > http://www.apache.org/"; /> > http://maven.apache.org/maven2/"/> > > Gets rendered as > > SIRD Site > | > http://www.apache.org/";>Apache > | > http://maven.apache.org/maven2/";>Maven 2 > > " http://sirdsite.dsths.ad.dstcorp.net/"; != "../../.." -- 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: (MCHANGES-79) Allow for overriding the announcement email from address
Allow for overriding the announcement email from address
Key: MCHANGES-79
URL: http://jira.codehaus.org/browse/MCHANGES-79
Project: Maven 2.x Changes Plugin
Issue Type: New Feature
Reporter: Alexander Schwartz
Currently the goal {{changes:announcement-mail}} uses the email address of the
first developer found in the pom as the from address of the announcement email.
Very often a project is released by a developer that is not the first on in the
list of developers in the pom -- which results is an announcement email with
awron, confusing from address. (Of course one can change the list of developers
for each release, or add a dummy developer "buildmaster" as the first one in
the developer list, but this is not my preferred option).
The maven1 announcement plugin has a parameter {{from}} which allows to specify
a different from address.
I suggest to add an optional parameter {{fromAdress}} to the goal
{{changes:announcement-mail}} of the {{maven-changes-plugin}} such that one
can specify the sender as follows:
{noformat}
...
org.apache.maven.plugins
maven-changes-plugin
[EMAIL PROTECTED]
...
{noformat}
If the paremter {{fromAdress}} is given its content is taken as the the
sender address of the announcement mail. If the option is not specified, the
fallback is the email address of the first developer in the POM.
--
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: (MSITE-229) Links in site.xml get translated to ../../../
Links in site.xml get translated to ../../../ - Key: MSITE-229 URL: http://jira.codehaus.org/browse/MSITE-229 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Linux FC6 Sun Java (build 1.5.0_10-b03, mixed mode, sharing) Reporter: Mykel Alvis Priority: Minor Attachments: site.xml In Site.xml for a project (that has a parent POM) http://sirdsite.dsths.ad.dstcorp.net/"; /> http://www.apache.org/"; /> http://maven.apache.org/maven2/"/> Gets rendered as SIRD Site | http://www.apache.org/";>Apache | http://maven.apache.org/maven2/";>Maven 2 " http://sirdsite.dsths.ad.dstcorp.net/"; != "../../.." -- 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: (MRELEASE-161) If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated
[ http://jira.codehaus.org/browse/MRELEASE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Wewerka updated MRELEASE-161: --- Attachment: release-test.zip Testcase for the above comment > If there is more than one artifact with the same artifactId in > dependencyManagement only the first one is updated > - > > Key: MRELEASE-161 > URL: http://jira.codehaus.org/browse/MRELEASE-161 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven 2.0.4 under windows >Reporter: Sébastien Cesbron > Attachments: multipleArtifacts.patch, release-test.zip > > > I have a multi module project. When I do release:prepare, the release plugin > update the version tag of all my submodules in the dependencyManagement > section. > For the same module I have declared two artifacts like this : > > com.bla > blabla > 1.0-SNAPSHOT > test-jar > test > > > com.bla > blabla > 1.0-SNAPSHOT > > In this case, the release plugin only update the first dependency. > This is due to element search in the "updateDomVersion" method of the > AbstractRewritePomsPhase class. I've attached a patch to solve the problem. I > don't know if this is the right way to do. I change all the artifacts in the > same pass. I don't take car of different type/classifier -- 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-161) If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated
[ http://jira.codehaus.org/browse/MRELEASE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95484 ] Chris Wewerka commented on MRELEASE-161: With 2.0-beta-5 and maven 2.0.6 a related issue (two dependencies to a project, one to the normal artifact, one to the test-jar) results in an error: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.o2.release-test:release-test-module-one:test-jar:tests:5.0.2 I've attached a testcase to reproduce this bug. > If there is more than one artifact with the same artifactId in > dependencyManagement only the first one is updated > - > > Key: MRELEASE-161 > URL: http://jira.codehaus.org/browse/MRELEASE-161 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven 2.0.4 under windows >Reporter: Sébastien Cesbron > Attachments: multipleArtifacts.patch > > > I have a multi module project. When I do release:prepare, the release plugin > update the version tag of all my submodules in the dependencyManagement > section. > For the same module I have declared two artifacts like this : > > com.bla > blabla > 1.0-SNAPSHOT > test-jar > test > > > com.bla > blabla > 1.0-SNAPSHOT > > In this case, the release plugin only update the first dependency. > This is due to element search in the "updateDomVersion" method of the > AbstractRewritePomsPhase class. I've attached a patch to solve the problem. I > don't know if this is the right way to do. I change all the artifacts in the > same pass. I don't take car of different type/classifier -- 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: (MIDEA-91) Incorrect web module definition if repository drive letter is lowercase
Incorrect web module definition if repository drive letter is lowercase --- Key: MIDEA-91 URL: http://jira.codehaus.org/browse/MIDEA-91 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Windows Reporter: Vitaliy Shevchuk In Windows, if local repository is defined with a lower case letter for a disk drive (for example: c:\repo instead of C:\repo), some incorrect values appears in "Web Module Setting->Modules and Libraries to Package". The workaround is to declare the local repository with a capital disk drive letter. However it is not obvious for everyone. I'm sure the correction (Or just a warning message) would be greatly appreciated by the IntelliJ lovers. Cheers -- 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: (MRELEASE-230) release:prepare cannot update the version of a module in a multi-module build if you have both normal artifact and attached artifact in dependencies
release:prepare cannot update the version of a module in a multi-module build if you have both normal artifact and attached artifact in dependencies Key: MRELEASE-230 URL: http://jira.codehaus.org/browse/MRELEASE-230 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Chris Wewerka Attachments: release-test.zip Following situation: you have a multimodule build with 2 modules A,B, and B has two dependencies to A, one for the "normal" jar artifact and one for an attached artifact (e.g. the test-jar of A). The release will fail with: ... [INFO] Transforming 'O2 Release test Base Module'... [INFO] Checking out file: E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\pom.xml [INFO] Transforming 'release-test-module-one'... [INFO] Checking out file: E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\release-test-module-one\pom.xml [INFO] Transforming 'release-test-module-two'... [INFO] Updating release-test-module-one to 5.0.2 [INFO] Updating release-test-module-one to 5.0.2 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The version could not be updated: 5.0.2 [INFO] [INFO] For more information, run Maven with the -e switch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-267) Enhance make-artifacts to not create POMs that have version ranges
[ http://jira.codehaus.org/browse/MECLIPSE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95483 ] Matthew Beermann commented on MECLIPSE-267: --- I just wanted to chime in and point out that: * Version ranges appear to be discouraged within Maven, in general - they're used almost nowhere within Maven itself. * Although Maven and OSGi both appear to support version ranges, the resemblance is superficial. In particular, they make opposite assumptions about whether a qualified version is greater than or less than its unqualified counterpart. Which means that blindly reusing the OSGi range in Maven (as the plugin does today) is actually quite dangerous. > Enhance make-artifacts to not create POMs that have version ranges > -- > > Key: MECLIPSE-267 > URL: http://jira.codehaus.org/browse/MECLIPSE-267 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: Micah Whitacre > > Currently when using the make-artifacts goal to deploy Eclipse artifacts to a > remote repository the POMs are created in such a way the versions of the > dependencies have ranges similar to [3.3,4). This information is pulled from > the Manifest. I'd like a way to specify not to use those version ranges in > the POM but to instead have a soft dependency on a specific version. The > situation that is occurring is that when I have deployed both Eclipse 3.2 and > 3.3 endstates to a remote repository, the 3.2 dependencies have ranges > specified which then pull in the 3.3 endstates. This causes conflicts when I > want to only include 3.2 endstates. If there was a way to 1. not use version > ranges in the POM and 2. instead have a soft dependency on a specific > version. This would eliminate the need to specify each and every Eclipse 3.2 > artifact for fear a transitive 3.3 dependency got pulled in. > I have also seen this cause errors when a transitive dependency pulls in a > 3.3 endstate that has conflicting version ranges for an artifact I have a > dependency on. Since the 3.3 endstates will have version ranges of [3.3,4) > but I might specify 3.2 dependencies, if I have a first class dependency on > 3.2 and a transitive dependency on the same artifact but the range is > [3.3,4), I will not be able to build my project. -- 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-267) Enhance make-artifacts to not create POMs that have version ranges
Enhance make-artifacts to not create POMs that have version ranges -- Key: MECLIPSE-267 URL: http://jira.codehaus.org/browse/MECLIPSE-267 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: PDE support Affects Versions: 2.3 Reporter: Micah Whitacre Currently when using the make-artifacts goal to deploy Eclipse artifacts to a remote repository the POMs are created in such a way the versions of the dependencies have ranges similar to [3.3,4). This information is pulled from the Manifest. I'd like a way to specify not to use those version ranges in the POM but to instead have a soft dependency on a specific version. The situation that is occurring is that when I have deployed both Eclipse 3.2 and 3.3 endstates to a remote repository, the 3.2 dependencies have ranges specified which then pull in the 3.3 endstates. This causes conflicts when I want to only include 3.2 endstates. If there was a way to 1. not use version ranges in the POM and 2. instead have a soft dependency on a specific version. This would eliminate the need to specify each and every Eclipse 3.2 artifact for fear a transitive 3.3 dependency got pulled in. I have also seen this cause errors when a transitive dependency pulls in a 3.3 endstate that has conflicting version ranges for an artifact I have a dependency on. Since the 3.3 endstates will have version ranges of [3.3,4) but I might specify 3.2 dependencies, if I have a first class dependency on 3.2 and a transitive dependency on the same artifact but the range is [3.3,4), I will not be able to build my project. -- 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-2981) [PATCH] NPE in PluginXDocGenerator while creating plugin site
[PATCH] NPE in PluginXDocGenerator while creating plugin site - Key: MNG-2981 URL: http://jira.codehaus.org/browse/MNG-2981 Project: Maven 2 Issue Type: Bug Components: Plugin Creation Tools Affects Versions: 2.0.6 Reporter: Steve Rowe Attachments: PluginXdocGenerator.diff I'm running into (what appears to be) the exact same problem that Tom Huybrechts described on the Maven user list a few months ago (quoted below), with Maven v2.0.6, maven-plugin-plugin v2.3, and maven-plugin-tools-api v2.1. I attach a patch that fixes the problem for me. Output: [INFO] [site:site] [INFO] Skipped "About" report, file "index.html" already exists for the English version. [INFO] Skipped "Maven Surefire Report" report, file "surefire-report.html" already exists for the English version. [INFO] Generate "Plugin documentation" report. [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] Extractor for language: java found 3 mojo descriptors. [INFO] Applying extractor for language: bsh [INFO] Extractor for language: bsh found 0 mojo descriptors. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.tools.plugin.generator.PluginXdocGenerator.filterParameters(PluginXdocGenerator.java:253) at org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeGoalParameterTable(PluginXdocGenerator.java:239) at org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeBody(PluginXdocGenerator.java:122) at org.apache.maven.tools.plugin.generator.PluginXdocGenerator.processMojoDescriptor(PluginXdocGenerator.java:61) at org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:49) at org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:192) at org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:141) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) 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:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) On 2007-01-03, Tom Huybrechts wrote: > > Hi folks, > > > > I'm getting aNPE when generating a site for a plugin. It looks like > > the java mojos get processed OK, but when it looks for bsh mojos > > (which I don't have) the NPE is thrown. > > > > Running 2.0.4 with the latest releases of all plugins > > > > Any tips ? > > > > [INFO] [site:site] > > [WARNING] No URL defined for the project - decoration links will not be > > resolved > > [INFO] Generate "Plugin docume
[jira] Created: (SCM-310) Aggregator in mojos
Aggregator in mojos --- Key: SCM-310 URL: http://jira.codehaus.org/browse/SCM-310 Project: Maven SCM Issue Type: Improvement Reporter: Wally Wallou Adding @aggregator in mojos for SCM goals should be helpful. Otherwise if user doesn't know that scm goals are not supposed to be recursive and so doesn't add -N option to mvn it get error for sub-module that are purposely not under 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] Commented: (MWAR-101) dependency with scope compile missing in WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95475 ] Stephane Nicoll commented on MWAR-101: -- Yes, the verifier does not take the classifier into account apparently. Thanks for the report. > dependency with scope compile missing in WEB-INF/lib > > > Key: MWAR-101 > URL: http://jira.codehaus.org/browse/MWAR-101 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: maven-2.0.6 >Reporter: Jörg Hohwiller > > I have a maven module with packaging war that has various dependencies. When > the webapp is build by the war-plugin, some dependencies are NOT copied to > the WEB-INF/lib directory of the webapp. > This seems to have something to do with the fact that in this case I have the > same dependency twice once as a regular dependency and another time with > classifier "sources". This is necessary since I am using the > Google-Web-Toolkit that needs the sources of dependent client modules. > So I have such dependecies in my POM: > > foo.bar > web-client > 1.0 > compile > > > foo.bar > web-client > 1.0 > compile > sources > > This works fine for compilation where the GWT reads the sources from the > classpath. > However there is no "web-client-*.jar" in WEB-INF/lib but one > "foo.bar-web-client-1.0.jar" that holds the content > of the "web-client-1.0-sources.jar". > I do not know what goes wrong here, but I looks that the war-plugin detects > some kind of clush for this "duplicate" depdency and makes some magic that > seems wrong here... -- 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: (MJAVADOC-109) Able to point to different JVM, rather then just using what is set in JAVA_HOME
[ http://jira.codehaus.org/browse/MJAVADOC-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-109. Assignee: Vincent Siveton Resolution: Duplicate Fix Version/s: 2.3 Duplicate MJAVADOC-98 > Able to point to different JVM, rather then just using what is set in > JAVA_HOME > --- > > Key: MJAVADOC-109 > URL: http://jira.codehaus.org/browse/MJAVADOC-109 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-3, 2.0, 2.1, 2.2 > Environment: All >Reporter: Pratik Parikh >Assignee: Vincent Siveton > Fix For: 2.3 > > > Hi Everyone, > It would be nice to have an ability to change the jvm/javadoc in use. > For example in compiler plugin you can use a different version of java by > point to it location in jvm tag. So we could have something similar then it > would make it consitant. > Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-117) sourcepath and aggregate don"t work to generate javaodc of test classes
[
http://jira.codehaus.org/browse/MJAVADOC-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MJAVADOC-117.
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.3
The MJAVADOC-117's fix should resolve this
> sourcepath and aggregate don"t work to generate javaodc of test classes
> ---
>
> Key: MJAVADOC-117
> URL: http://jira.codehaus.org/browse/MJAVADOC-117
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: maven 2.0.4
>Reporter: David Vicente
>Assignee: Vincent Siveton
> Fix For: 2.3
>
>
> HI,
> i try to customize javadoc plugin configuration to generate javadoc fo test
> classes as done below.
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.1
>
>
> ${project.reporting.outputDirectory}/test-apidocs
>
> ${basedir}/src/test
> true
>
>
> and nothing as result.
> related with these issues :
> http://jira.codehaus.org/browse/MJAVADOC-110
> http://jira.codehaus.org/browse/MJAVADOC-95
> i can't generate the javadoc for all test classes of my multi-modules project.
> I put this issue as bug but it could be an improvement.
> could we hope a simple mechanism to generate test classes javadoc with
> aggregate parameter ?
--
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: (MJAVADOC-110) sourcepath element is not working
[ http://jira.codehaus.org/browse/MJAVADOC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-110. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.3 Fixed in SVN Added your test case as IT. > sourcepath element is not working > - > > Key: MJAVADOC-110 > URL: http://jira.codehaus.org/browse/MJAVADOC-110 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 >Reporter: Adam Lally >Assignee: Vincent Siveton > Fix For: 2.3 > > Attachments: maven-javadoc-test.zip > > > The attached zip demonstrates the problem. It is a parent project that has > one component. Just execute "mvn package" in the parent and you will get a > File Not Found exception from the javadoc plugin. > I've attached the javadoc plugin to the package step, and am using the > element to configure it to look in the subcomponent to get the > source files. This works in 2.0, but fails in 2.1 and 2.2. > (I know, I can use instead in this case, but I have other uses > cases for and this is just a simple example to demonstrate the > problem.) -- 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: (MDEP-89) change separators in build-classpath
[ http://jira.codehaus.org/browse/MDEP-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95461 ] Christophe Domas commented on MDEP-89: -- 2 parameters (file.separator and path.separator) will be fine for me. Thanks a lot. > change separators in build-classpath > > > Key: MDEP-89 > URL: http://jira.codehaus.org/browse/MDEP-89 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: build-classpath >Affects Versions: 2.0-alpha-5 > Environment: Windows / Unix >Reporter: Christophe Domas >Assignee: Brian Fox >Priority: Minor > Fix For: 2.0-alpha-5 > > > Hi, > I'm trying to use the build-classpath to generate a unix-style classpath on a > windows laptop (associated with the assembly plugin). I saw that you are > using file.separator and path.separator to generate the classpath string but > I'm affraid of side effect by overriding them in a properties file. Could you > add a way to choose a style (windows|unix) or to override them in the plugin > configuration? > thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-323) Managed repo in archiva cannot be accessed thru direct webdav url even with valid credentials (Archiva deployed in Tomcat)
[ http://jira.codehaus.org/browse/MRM-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95460 ] Maria Odea Ching commented on MRM-323: -- I still can't seem to make it work.. I did the workaround but I still can't access the webdav urls. The username and password I entered were not accepted (I already made sure that I have the necessary permissions), and the authorization window just keeps popping up. When I click the Cancel button in the authorization window, I get a 401 - Authorization Denied. Could this be an issue with Tomcat's webdav and the OS maybe, or with the browser? It seems the workaround works on Windows? > Managed repo in archiva cannot be accessed thru direct webdav url even with > valid credentials (Archiva deployed in Tomcat) > -- > > Key: MRM-323 > URL: http://jira.codehaus.org/browse/MRM-323 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0 > Environment: - Tomcat 5.5.20 > - Linux > - Mozilla Firefox >Reporter: Maria Odea Ching > > Steps to re-create issue: > - Deploy Archiva in Tomcat, then start tomcat > - Access Archiva in browser and set the required configurations > - Add A Managed Repository with the following configuration: > - id: snapshots > - name: snapshots > - url: snapshots (it would have the value > http://localhost:[PORT]/archiva/repository/snapshots) > - directory: snapshots > - Go to User Management and add the Repository Observer role for the > 'snapshots' repo to the current user > - Open a new tab in your browser then type the webdav URL: > http://localhost:[PORT]/archiva/repository/snapshots > - Supply the user credentials for the 'snapshots' repository. You still > wouldn't be able to access it even if you supply the correct credentials. > Also, the following error shows up in the Archiva logs when you try to build > a Maven project with your settings.xml file configured to use the > repositories in archiva: > 102476 [http-9696-Processor23] ERROR > org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/archiva].[RepositoryServlet] > - Servlet.service() for servlet RepositoryServlet threw exception > javax.servlet.ServletException: Unable to service DAV request due to > unconfigured DavServerComponent for prefix [snapshots]. > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:93) > 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$ControlRunnabl
[jira] Commented: (CONTINUUM-1264) Editing a Project Group's name to an empty string generates an exception
[ http://jira.codehaus.org/browse/CONTINUUM-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95454 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-1264: I forgot to paste the main exception, here it is: org.apache.maven.continuum.ContinuumException: unable to rename the project group at org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:270) 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) > Editing a Project Group's name to an empty string generates an exception > > > Key: CONTINUUM-1264 > URL: http://jira.codehaus.org/browse/CONTINUUM-1264 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Napoleon Esmundo C. Ramirez > Attachments: CONTINUUM-1264-continuum-webapp.patch > > > To replicate (assuming the user has sufficient roles): > 1. Create a project group (name="asdf", id="asdf") > 2. Edit a project group, change name into "" > Result: > Caused by: org.codehaus.plexus.rbac.profile.RoleProfileException: invalid role > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:405) > at > org.codehaus.plexus.rbac.profile.DefaultRoleProfileManager.renameDynamicRole(DefaultRoleProfileManager.java:134) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:262) > ... 78 more > Caused by: org.codehaus.plexus.security.rbac.RbacObjectInvalidException: > Resource.identifier must not be empty. > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:123) > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:110) > at > org.codehaus.plexus.security.authorization.rbac.store.jdo.JdoRbacManager.saveResource(JdoRbacManager.java:458) > at > org.codehaus.plexus.security.authorization.rbac.store.cached.CachedRbacManager.saveResource(CachedRbacManager.java:662) > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:381) > ... 80 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1264) Editing a Project Group's name to an empty string generates an exception
[ http://jira.codehaus.org/browse/CONTINUUM-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Napoleon Esmundo C. Ramirez updated CONTINUUM-1264: --- Attachment: CONTINUUM-1264-continuum-webapp.patch Attached patch contains a quick fix for validating the empty string. > Editing a Project Group's name to an empty string generates an exception > > > Key: CONTINUUM-1264 > URL: http://jira.codehaus.org/browse/CONTINUUM-1264 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Napoleon Esmundo C. Ramirez > Attachments: CONTINUUM-1264-continuum-webapp.patch > > > To replicate (assuming the user has sufficient roles): > 1. Create a project group (name="asdf", id="asdf") > 2. Edit a project group, change name into "" > Result: > Caused by: org.codehaus.plexus.rbac.profile.RoleProfileException: invalid role > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:405) > at > org.codehaus.plexus.rbac.profile.DefaultRoleProfileManager.renameDynamicRole(DefaultRoleProfileManager.java:134) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:262) > ... 78 more > Caused by: org.codehaus.plexus.security.rbac.RbacObjectInvalidException: > Resource.identifier must not be empty. > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:123) > at > org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:110) > at > org.codehaus.plexus.security.authorization.rbac.store.jdo.JdoRbacManager.saveResource(JdoRbacManager.java:458) > at > org.codehaus.plexus.security.authorization.rbac.store.cached.CachedRbacManager.saveResource(CachedRbacManager.java:662) > at > org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:381) > ... 80 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-34) Incorrect Resolving of an Executable with Dependencies
[ http://jira.codehaus.org/browse/NMAVEN-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95452 ] Shane Isbell commented on NMAVEN-34: Fixed within the SI_XPT branch. > Incorrect Resolving of an Executable with Dependencies > -- > > Key: NMAVEN-34 > URL: http://jira.codehaus.org/browse/NMAVEN-34 > Project: NMaven > Issue Type: Bug >Reporter: Shane Isbell >Priority: Minor > > When an executable (with dependent assemblies) is downloaded and installed > into the local repo, the dependencies are not placed within the same > directory as the executable. These dependent assemblies need to be copied > into the executable directory within the local repo, after resolving. This > does not affect purely local builds, as the dependencies are copied as part > of the installation. -- 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: (NMAVEN-47) Addin Packaging and Deploying for Visual Studio Addins
[ http://jira.codehaus.org/browse/NMAVEN-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95451 ] Shane Isbell commented on NMAVEN-47: Completed in the SI_XPT branch. > Addin Packaging and Deploying for Visual Studio Addins > -- > > Key: NMAVEN-47 > URL: http://jira.codehaus.org/browse/NMAVEN-47 > Project: NMaven > Issue Type: New Feature > Environment: Visual Studio 2005 >Reporter: Shane Isbell > > The feature should include support for generation the visual studio addin XML > file and for putting the XML addin file within the appropriate directory for > the IDE to read. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1264) Editing a Project Group's name to an empty string generates an exception
Editing a Project Group's name to an empty string generates an exception Key: CONTINUUM-1264 URL: http://jira.codehaus.org/browse/CONTINUUM-1264 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Napoleon Esmundo C. Ramirez To replicate (assuming the user has sufficient roles): 1. Create a project group (name="asdf", id="asdf") 2. Edit a project group, change name into "" Result: Caused by: org.codehaus.plexus.rbac.profile.RoleProfileException: invalid role at org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:405) at org.codehaus.plexus.rbac.profile.DefaultRoleProfileManager.renameDynamicRole(DefaultRoleProfileManager.java:134) at org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:262) ... 78 more Caused by: org.codehaus.plexus.security.rbac.RbacObjectInvalidException: Resource.identifier must not be empty. at org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:123) at org.codehaus.plexus.security.rbac.RBACObjectAssertions.assertValid(RBACObjectAssertions.java:110) at org.codehaus.plexus.security.authorization.rbac.store.jdo.JdoRbacManager.saveResource(JdoRbacManager.java:458) at org.codehaus.plexus.security.authorization.rbac.store.cached.CachedRbacManager.saveResource(CachedRbacManager.java:662) at org.codehaus.plexus.rbac.profile.AbstractDynamicRoleProfile.renameRole(AbstractDynamicRoleProfile.java:381) ... 80 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-6) IDE Support
[ http://jira.codehaus.org/browse/NMAVEN-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95450 ] Shane Isbell commented on NMAVEN-6: --- I opened the JIRA http://jira.codehaus.org/browse/NMAVEN-51 for this issue. It is a simple fix. I will have this fix in the trunk, with all the other new features, by May 21st. > IDE Support > --- > > Key: NMAVEN-6 > URL: http://jira.codehaus.org/browse/NMAVEN-6 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux, SharpDevelop, Visual Studio, .NET 2.0+ >Reporter: Shane Isbell > > Generation of csproj and solution files from pom.xml. files This feature will > support project files compatible with SharpDevelop and Visual Studio 2005. -- 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: (NMAVEN-51) Remove Hard-Coded Local Repository Path in Visual Studio Solution Plugin
Remove Hard-Coded Local Repository Path in Visual Studio Solution Plugin Key: NMAVEN-51 URL: http://jira.codehaus.org/browse/NMAVEN-51 Project: NMaven Issue Type: Improvement Reporter: Shane Isbell Priority: Minor The visual studio solution plugin (in .NET) contains a hard-coded value for the local repository. This can be fixed by adding a local repository attribute to the solution plugin and passing that to the NMaven.Core assembly. -- 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: (NMAVEN-6) IDE Support
[ http://jira.codehaus.org/browse/NMAVEN-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95446 ] Amol Manjure commented on NMAVEN-6: --- Thanks for the reply, Shane. A prerequisite to running this command is to run bootstrap-build.bat with the withIde property set when compiling NMaven for the first time. bootstrap-build.bat -DwithIde Is there a way to ensure that all the references are resolved when the csproj is generated? I have the dependencies installed in my local repository but the csproj shows that the references are unresolved because the HintPath node in the project file assumes that the local repository is always under my home directory. If this can made configurable, that should resolve most of the references > IDE Support > --- > > Key: NMAVEN-6 > URL: http://jira.codehaus.org/browse/NMAVEN-6 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux, SharpDevelop, Visual Studio, .NET 2.0+ >Reporter: Shane Isbell > > Generation of csproj and solution files from pom.xml. files This feature will > support project files compatible with SharpDevelop and Visual Studio 2005. -- 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: (NMAVEN-6) IDE Support
[ http://jira.codehaus.org/browse/NMAVEN-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95432 ] Shane Isbell commented on NMAVEN-6: --- Type: "mvn org.apache.maven.dotnet.plugins:maven-solution-plugin:solution" from the directory containing your pom.xml file (it handles multi-module poms, as well). This command runs the plugin that generates the VS2005 project/solution files. > IDE Support > --- > > Key: NMAVEN-6 > URL: http://jira.codehaus.org/browse/NMAVEN-6 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux, SharpDevelop, Visual Studio, .NET 2.0+ >Reporter: Shane Isbell > > Generation of csproj and solution files from pom.xml. files This feature will > support project files compatible with SharpDevelop and Visual Studio 2005. -- 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-309) Use existing tag to use starteam promotion states
Use existing tag to use starteam promotion states - Key: SCM-309 URL: http://jira.codehaus.org/browse/SCM-309 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-starteam Affects Versions: 1.0-beta-4 Reporter: Jan Edelbroek Starteam has the possibility to use promotion states. Now only view labels can be used by configuring the tag. My proposal is to modify the handling of the tag slightly so that promotion states can also be used. For example: when the tag is configured as "-pbeta" then the tag will not be handled as a view label, but as a promotion state. In this example the promotion state is "beta". The promotion state is simply indicated by the "-p" prefix in the tag. Configuring continuum with this tag is also easy, no changes are needed for continuum. The modification involves small changes in the StarteamUpdateCommand and StarteamCheckOutCommand. I can provide a patch when needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NMAVEN-6) IDE Support
[ http://jira.codehaus.org/browse/NMAVEN-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95428 ] Amol Manjure commented on NMAVEN-6: --- Is there any documentation on how to do this for Visual Studio 2005? I tried running the maven-vstudio-plugin from the trunk but it generated a VS 2003 csproj and the VS conversion wizard gave an error while converting it to VS2005 format. > IDE Support > --- > > Key: NMAVEN-6 > URL: http://jira.codehaus.org/browse/NMAVEN-6 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux, SharpDevelop, Visual Studio, .NET 2.0+ >Reporter: Shane Isbell > > Generation of csproj and solution files from pom.xml. files This feature will > support project files compatible with SharpDevelop and Visual Studio 2005. -- 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
