[jira] Created: (MCLOVER-73) Support Clover 2.x
Support Clover 2.x -- Key: MCLOVER-73 URL: http://jira.codehaus.org/browse/MCLOVER-73 Project: Maven 2.x Clover Plugin Issue Type: New Feature Reporter: Chris Beams Clover 2.0 is currently in Early Access (http://cenqua.com/clover/20/eap/). They have released Ant and Eclipse support, but are counting on Codehaus to release an updated maven-clover-plugin to support the new features. I'm sure this is already well-known amongst the developers of this plugin, but I didn't see an issue officially addressing it. Perhaps this can be that issue. Is there any ETA on this functionality? Thanks - this plugin is critical to our use of Clover, and we're eagerly anticipating this update! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-227) release:perform fails when using Perforce
release:perform fails when using Perforce - Key: MRELEASE-227 URL: http://jira.codehaus.org/browse/MRELEASE-227 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.6 Reporter: Patrick Schneider Priority: Minor The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:perform goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point. -- 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-325) Create web UI tests for Archiva - Maven connection to Archiva
[ http://jira.codehaus.org/browse/MRM-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94889 ] Maria Odea Ching commented on MRM-325: -- Committed in -r534696, although 2 of the tests were currently commented out because of http://jira.codehaus.org/browse/MRM-323. Also, there are still revisions coming up because of the changes during the branch and trunk merge. > Create web UI tests for Archiva - Maven connection to Archiva > - > > Key: MRM-325 > URL: http://jira.codehaus.org/browse/MRM-325 > Project: Archiva > Issue Type: Task >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > > Test: > 1. Using a bad dependency > 2. Using a dependency that is in the snapshot repository > 3. Using a dependency that is in the central (ibiblio) proxied repository > but not yet in the managed repository -- 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-325) Create web UI tests for Archiva - Maven connection to Archiva
Create web UI tests for Archiva - Maven connection to Archiva - Key: MRM-325 URL: http://jira.codehaus.org/browse/MRM-325 Project: Archiva Issue Type: Task Reporter: Maria Odea Ching Test: 1. Using a bad dependency 2. Using a dependency that is in the snapshot repository 3. Using a dependency that is in the central (ibiblio) proxied repository but not yet in the managed repository -- 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: (MINSTALL-36) install:install-file ignores -DrepositoryLayout
[ http://jira.codehaus.org/browse/MINSTALL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MINSTALL-36. - Resolution: Fixed Fix Version/s: 2.2 patch applied + tests added. thanks > install:install-file ignores -DrepositoryLayout > --- > > Key: MINSTALL-36 > URL: http://jira.codehaus.org/browse/MINSTALL-36 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Joerg Vater > Fix For: 2.2 > > Attachments: InstallFileMojo.java.patch > > > install:install-file accepts parameter -DrepositoryLayout=legacy, but the > parameter is ignored. > This is due to an error in InstallFileMojo.java. The repositoryLayout > parameter must be of type String and then be mapped to an > ArtifactRepositoryLayout (see e.g. maven-deploy-plugin). With the attached > patch for me it worked 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: (MINSTALL-29) Can't use maven-install-plugin with install-file in POM
[ http://jira.codehaus.org/browse/MINSTALL-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MINSTALL-29. - Resolution: Fixed Fix Version/s: 2.2 already fixed > Can't use maven-install-plugin with install-file in POM > > > Key: MINSTALL-29 > URL: http://jira.codehaus.org/browse/MINSTALL-29 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: WinXP, running M2 in Cygwin >Reporter: Brad Harper >Priority: Minor > Fix For: 2.2 > > > This issue is related to another I submitted recently. In fact, the earlier > issue was encounted > in an earlier attempt to get the same results. (see bottom, below.) > Consider the POM descriptor containing > > > snapshots > http://svn.apache.org/maven-snapshot-repository > > > > > > maven-install-plugin > 2.2-SNAPSHOT > > > install-library > install > > install-file > > > com.epsiia.dxr.third-party > > dxr-third-party-WINDOWS-X86-com-emc-centera-fplibrary-lib > 2.0SP1 > lib > FPLibrary.lib > > > > > > > M2 fails to build in this project because all elements are > read-only. [I'm attempting > to use the 2.2-SNAPSHOT because I get the same error in stable versions. ] > Shouldn't this execution be allowable and equivalent to the CLI invocation >% mvn install:install-file -DgroupId=com.epsiia.dxr.third-party .. > I'm trying to create a mind-numbingly simple environment, so that other > less-experienced developers > aren't required to know which of the third-party libraries need to be > manually installed via once-only > occurances should the local repository need to be re-constructed. -- 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: (MINSTALL-18) Bad algorithm to decide if the main artifact is to be installed or not
[
http://jira.codehaus.org/browse/MINSTALL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94881
]
Brian Fox commented on MINSTALL-18:
---
any chance you have a test case for this?
> Bad algorithm to decide if the main artifact is to be installed or not
> --
>
> Key: MINSTALL-18
> URL: http://jira.codehaus.org/browse/MINSTALL-18
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Massol
> Fix For: 2.2
>
>
> Here' s what's in InstallMojo's execute method:
> {code}
> // Here, we have a temporary solution to MINSTALL-3
> (isDirectory() is true if it went through compile
> // but not package). We are designing in a proper solution
> for Maven 2.1
> if ( file != null && !file.isDirectory() )
> {
> installer.install( file, artifact, localRepository );
> }
> else if ( !attachedArtifacts.isEmpty() )
> {
> getLog().info( "No primary artifact to install,
> installing attached artifacts instead." );
> }
> {code}
> This fails if we're building a JAR with no sources but with an attached
> artifact and only the attached artifact is created (this is the case when
> using the clover plugin). In that case, the install mojo tries to install the
> main artifact which doesn't exist).
> The error is in "!file.isDirectory". In the case of a jar with no sources,
> this directory will not have been created...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINSTALL-19) install-file sets distributionManagement status to deployed
[ http://jira.codehaus.org/browse/MINSTALL-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MINSTALL-19. - Resolution: Fixed Fixed in this change to maven-project: http://svn.apache.org/viewvc/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java/?revision=506108&r1=506108&r2=506107 > install-file sets distributionManagement status to deployed > --- > > Key: MINSTALL-19 > URL: http://jira.codehaus.org/browse/MINSTALL-19 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Carlos Sanchez > Fix For: 2.2 > > > not setting it or setting to none would be better > http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1812) Add MAVEN_HOME/bin in the PATH
[ http://jira.codehaus.org/browse/MAVEN-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1812. -- Resolution: Fixed done. Added at the beginning of the path. > Add MAVEN_HOME/bin in the PATH > -- > > Key: MAVEN-1812 > URL: http://jira.codehaus.org/browse/MAVEN-1812 > Project: Maven 1 > Issue Type: Improvement > Components: installer >Affects Versions: 1.0, 1.0.1, 1.0.2, 1.1-beta-1, 1.1-beta-2, 1.1-beta-3 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > > Actually the installer set the environment variable MAVEN_HOME but don't add > MAVEN_HOME/bin to the PATH. > We have to add it in the head of the PATH to not have a conflict with a > previous version of maven 1.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] Commented: (MINSTALL-37) Add support to force install:install to use a specific version
[ http://jira.codehaus.org/browse/MINSTALL-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94874 ] Brian Fox commented on MINSTALL-37: --- Discussion of this issue here: http://www.nabble.com/forceVersion-for-maven-install-plugin--tf3341272s177.html#a9292710 > Add support to force install:install to use a specific version > -- > > Key: MINSTALL-37 > URL: http://jira.codehaus.org/browse/MINSTALL-37 > Project: Maven 2.x Install Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Jason Dillon >Assignee: Brian Fox > Fix For: 2.2 > > Attachments: MINSTALL-37.diff > > > Allow the install:install goal to force the version of artifacts (including > 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] Closed: (MAVEN-1848) Upgrade maven-multichanges-plugin to v 1.3
[ http://jira.codehaus.org/browse/MAVEN-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1848. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-multichanges-plugin to v 1.3 > -- > > Key: MAVEN-1848 > URL: http://jira.codehaus.org/browse/MAVEN-1848 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1849) Upgrade maven-plugin-plugin to v 1.7.1
[ http://jira.codehaus.org/browse/MAVEN-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1849. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-plugin-plugin to v 1.7.1 > -- > > Key: MAVEN-1849 > URL: http://jira.codehaus.org/browse/MAVEN-1849 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1847) Upgrade maven-javadoc-plugin to v 1.9
[ http://jira.codehaus.org/browse/MAVEN-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1847. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-javadoc-plugin to v 1.9 > - > > Key: MAVEN-1847 > URL: http://jira.codehaus.org/browse/MAVEN-1847 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1846) Upgrade maven-jar-plugin to v 1.8.1
[ http://jira.codehaus.org/browse/MAVEN-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1846. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-jar-plugin to v 1.8.1 > --- > > Key: MAVEN-1846 > URL: http://jira.codehaus.org/browse/MAVEN-1846 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1847) Upgrade maven-javadoc-plugin to v 1.9
Upgrade maven-javadoc-plugin to v 1.9 - Key: MAVEN-1847 URL: http://jira.codehaus.org/browse/MAVEN-1847 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1845) Upgrade maven-jalopy-plugin to v 1.5.1
[ http://jira.codehaus.org/browse/MAVEN-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1845. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-jalopy-plugin to v 1.5.1 > -- > > Key: MAVEN-1845 > URL: http://jira.codehaus.org/browse/MAVEN-1845 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1849) Upgrade maven-plugin-plugin to v 1.7.1
Upgrade maven-plugin-plugin to v 1.7.1 -- Key: MAVEN-1849 URL: http://jira.codehaus.org/browse/MAVEN-1849 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1844) Upgrade maven-idea-plugin to v 1.7
[ http://jira.codehaus.org/browse/MAVEN-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1844. -- Resolution: Fixed Fix Version/s: 1.1-rc1 > Upgrade maven-idea-plugin to v 1.7 > -- > > Key: MAVEN-1844 > URL: http://jira.codehaus.org/browse/MAVEN-1844 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > -- 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: (MAVEN-1848) Upgrade maven-multichanges-plugin to v 1.3
Upgrade maven-multichanges-plugin to v 1.3 -- Key: MAVEN-1848 URL: http://jira.codehaus.org/browse/MAVEN-1848 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1846) Upgrade maven-jar-plugin to v 1.8.1
Upgrade maven-jar-plugin to v 1.8.1 --- Key: MAVEN-1846 URL: http://jira.codehaus.org/browse/MAVEN-1846 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1845) Upgrade maven-jalopy-plugin to v 1.5.1
Upgrade maven-jalopy-plugin to v 1.5.1 -- Key: MAVEN-1845 URL: http://jira.codehaus.org/browse/MAVEN-1845 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MAVEN-1844) Upgrade maven-idea-plugin to v 1.7
[ http://jira.codehaus.org/browse/MAVEN-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MAVEN-1844: --- Summary: Upgrade maven-idea-plugin to v 1.7 (was: Upgrade maven-idea-plugin to v1.7) > Upgrade maven-idea-plugin to v 1.7 > -- > > Key: MAVEN-1844 > URL: http://jira.codehaus.org/browse/MAVEN-1844 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > -- 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: (MAVEN-1844) Upgrade maven-idea-plugin to v1.7
[ http://jira.codehaus.org/browse/MAVEN-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MAVEN-1844: --- Summary: Upgrade maven-idea-plugin to v1.7 (was: Upgrade maven-idea-plugin 1.7) > Upgrade maven-idea-plugin to v1.7 > - > > Key: MAVEN-1844 > URL: http://jira.codehaus.org/browse/MAVEN-1844 > Project: Maven 1 > Issue Type: Sub-task >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > -- 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: (MAVEN-1844) Upgrade maven-idea-plugin 1.7
Upgrade maven-idea-plugin 1.7 - Key: MAVEN-1844 URL: http://jira.codehaus.org/browse/MAVEN-1844 Project: Maven 1 Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier -- 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: (MINSTALL-37) Add support to force install:install to use a specific version
[ http://jira.codehaus.org/browse/MINSTALL-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94870 ] Brian Fox commented on MINSTALL-37: --- this patch looks ok, but the classifier should be passed through to the factory instead of null. > Add support to force install:install to use a specific version > -- > > Key: MINSTALL-37 > URL: http://jira.codehaus.org/browse/MINSTALL-37 > Project: Maven 2.x Install Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Jason Dillon > Fix For: 2.2 > > Attachments: MINSTALL-37.diff > > > Allow the install:install goal to force the version of artifacts (including > 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] Closed: (MAVEN-1808) Put MAVEN_HOME in the system environment variables if the user has admin rights
[ http://jira.codehaus.org/browse/MAVEN-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1808. -- Resolution: Fixed Already done > Put MAVEN_HOME in the system environment variables if the user has admin > rights > --- > > Key: MAVEN-1808 > URL: http://jira.codehaus.org/browse/MAVEN-1808 > Project: Maven 1 > Issue Type: Improvement > Components: installer >Affects Versions: 1.1-beta-3 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 1.1-rc1 > > > On windows we often encounter different problems when this variable is set in > the user environment system. -- 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-519) com.jgoodies:binding:1.4.0 - POM invalid due to missing "/" character. Please correct this typo!
com.jgoodies:binding:1.4.0 - POM invalid due to missing "/" character. Please correct this typo! Key: MEV-519 URL: http://jira.codehaus.org/browse/MEV-519 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Stefan Prange In the POM file the section is not valid, because the closing XML tag doesn't contain a "/" character. Please correct this to Thank you. -- 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: (MPIR-57) URLs only link if they are FQDNs
[ http://jira.codehaus.org/browse/MPIR-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94847 ] Mykel Alvis commented on MPIR-57: - Just started encountering this when I switched from internal IP addresses to alias'ed hostnames that aren't FQDNs. I agree with Mike. It's nice that getValidHref uses Validator,etc, to determine an actual href, but we're (usually) smart enough to put in something that makes sense here and it's not particularly critical if we don't. It's not even relevant that the scheme be httpx, as far as I'm concerned. What if I want to do a file: based version? I'm not sure how I would, but it's impossible with this validation in place. > URLs only link if they are FQDNs > > > Key: MPIR-57 > URL: http://jira.codehaus.org/browse/MPIR-57 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Mike Perham > > We are trying to create internal site documentation for our projects with > links to our Confluence user home pages: > > mperham > http://wiki:9090/display/~mperham > > But the project info report does not link this URL. If I add .com or .org to > the end of it, it does link so I suspect the validation is just a little > over-zealous. It should just link whatever the user puts in there. -- 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: (MEV-518) Google Juice POM has wrong "" - should be "jar" and not "pom"
[ http://jira.codehaus.org/browse/MEV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-518. -- Resolution: Duplicate this is not going to be fixed if nobody provides the correct pom. It's not just the packaging entry as it's explained in the linked issue > Google Juice POM has wrong "" - should be "jar" and not "pom" > > > Key: MEV-518 > URL: http://jira.codehaus.org/browse/MEV-518 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Arik Kfir >Assignee: Carlos Sanchez > > The pom for guice-1.0 states a packaging of "pom", but it really represents a > jar (sits alongside the guice-1.0.jar file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1433) Include guice in the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez reopened MAVENUPLOAD-1433: - > Include guice in the central repository > --- > > Key: MAVENUPLOAD-1433 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1433 > Project: maven-upload-requests > Issue Type: Task >Reporter: Hani Suleiman >Assignee: Carlos Sanchez > Attachments: guice.jar, guice.jar, guice.jar > > > Would also appreciate it if someone could take a peek at the pom.xml to make > sure it's sane, as it's user contributed with some tweaks. jar file contains > the guice jar + pom.xml -- 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-1433) Include guice in the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1433. --- Resolution: Incomplete > Include guice in the central repository > --- > > Key: MAVENUPLOAD-1433 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1433 > Project: maven-upload-requests > Issue Type: Task >Reporter: Hani Suleiman >Assignee: Carlos Sanchez > Attachments: guice.jar, guice.jar, guice.jar > > > Would also appreciate it if someone could take a peek at the pom.xml to make > sure it's sane, as it's user contributed with some tweaks. jar file contains > the guice jar + pom.xml -- 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] Reopened: (MEV-518) Google Juice POM has wrong "" - should be "jar" and not "pom"
[ http://jira.codehaus.org/browse/MEV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arik Kfir reopened MEV-518: --- Problem seems to still exist, although the duplicated issue is marked as fixed. Packaging is still "pom" in the "pom.xml" file... > Google Juice POM has wrong "" - should be "jar" and not "pom" > > > Key: MEV-518 > URL: http://jira.codehaus.org/browse/MEV-518 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Arik Kfir >Assignee: Carlos Sanchez > > The pom for guice-1.0 states a packaging of "pom", but it really represents a > jar (sits alongside the guice-1.0.jar file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NMAVEN-42) Conversion from a csproj File to a pom.xml File
Conversion from a csproj File to a pom.xml File --- Key: NMAVEN-42 URL: http://jira.codehaus.org/browse/NMAVEN-42 Project: NMaven Issue Type: New Feature Reporter: Shane Isbell The framework should support converting from a csproject file to a pom. This has two advantages: 1) recovering from a corrupted or outdated pom (one that is older than the csproject file) and 2) helping to transition existing projects to NMaven. -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94832 ] Joerg Schaible commented on MNG-2968: - Isn't it possible to use a colon as separator? This is also used in several notations already e.g. when defining the included artifacts in the depednencySet of the assembly descriptor. > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- 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-1512) Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another
Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another - Key: MAVENUPLOAD-1512 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1512 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke Attachments: dozer-3.3.1-bundle.jar Dozer is a powerful, yet simple Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types. Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level. Dozer not only supports mapping between attribute names, but also converting between types. Many conversion scenarios are supported out of the box, but Dozer also allows you to specify custom conversions via XML. The mapper is used any time you need to take one type of Java Bean and map it to another type of Java Bean. Most field mapping can be done automatically by Dozer using reflection, but any custom mapping can be predescribed in XML format. Mapping is bi-directional so only one relationship between classes needs defining. If any property names on both objects are the same you do not even need to do any explicit property mapping for these fields. -- 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-41) Configuration of Remote Services through the IDE
Configuration of Remote Services through the IDE Key: NMAVEN-41 URL: http://jira.codehaus.org/browse/NMAVEN-41 Project: NMaven Issue Type: New Feature Environment: Visual Studio, Sharp Develop Reporter: Shane Isbell The developer will be able to add/delete remote/local repository access through the IDE. This action would modify the repository tag in the pom.xml and is also used in conjunction with NMaven-39, where the developer can then add a dependency from the repo to the project. This feature also includes the ability to change which MavenEmbedder to use for the IDE. -- 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: (MEV-518) Google Juice POM has wrong "" - should be "jar" and not "pom"
[ http://jira.codehaus.org/browse/MEV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-518. -- Assignee: Carlos Sanchez Resolution: Duplicate > Google Juice POM has wrong "" - should be "jar" and not "pom" > > > Key: MEV-518 > URL: http://jira.codehaus.org/browse/MEV-518 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Arik Kfir >Assignee: Carlos Sanchez > > The pom for guice-1.0 states a packaging of "pom", but it really represents a > jar (sits alongside the guice-1.0.jar file). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (NMAVEN-6) IDE Support
[ http://jira.codehaus.org/browse/NMAVEN-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed NMAVEN-6. - Resolution: Fixed The generation of cs project files and solutions feature is in the trunk. > 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-40) Execute maven life-cycle phases through a menu
Execute maven life-cycle phases through a menu -- Key: NMAVEN-40 URL: http://jira.codehaus.org/browse/NMAVEN-40 Project: NMaven Issue Type: New Feature Environment: Visual Studio, Sharp Develop Reporter: Shane Isbell The IDE will display a tree of .NET projects and subprojects. The developer can right-click on a project and do one of the following: build, test, clean, install. The results will be displayed within the output console. -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94830 ] Jacob Robertson commented on MNG-2968: -- I certainly understand and respect what you're trying to accomplish, but the sad fact is that if this suggested fix is implemented, it will break 90% of the artifacts in my company, and will mean we have to do re-tooling on the inhouse things we've done that depend on artifact id, cvs module name, and project name all being the same. This is a sweeping, non-backwards-compatible change, and it shouldn't be done lightly. > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1507) Request for new release for a maven project -- facelets deployment
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94829 ] Carlos Sanchez commented on MAVENUPLOAD-1507: - all dependencies must be already in central repo, at least jboss seam is missing, you have to request their upload first you have to remove the repositories section to use other repos > Request for new release for a maven project -- facelets deployment > -- > > Key: MAVENUPLOAD-1507 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1507 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andrew Robinson > > This is a project for deploying JSF Facelet files via JDK 1.5 annotations > This version is now deploying correctly. The failed request was: > http://jira.codehaus.org/browse/MAVENUPLOAD-1505 -- 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-1508) upload vraptor 2.3.2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1508. --- Assignee: Carlos Sanchez Resolution: Fixed > upload vraptor 2.3.2.2 > -- > > Key: MAVENUPLOAD-1508 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1508 > Project: maven-upload-requests > Issue Type: Task >Reporter: Nico Steppat >Assignee: Carlos Sanchez > > VRaptor 2.3.2.2 framework update with some urgent bug fixes. > > VRaptor 2 is a mvc controller based on the idea (stolen) from Rails > that configuration should be minimal and conventions should be > maximized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1509) JETM 1.2.1 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1509. --- Assignee: Carlos Sanchez Resolution: Fixed > JETM 1.2.1 bundles > --- > > Key: MAVENUPLOAD-1509 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1509 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Jens Schumann >Assignee: Carlos Sanchez > > Please upload jetm 1.2.1 to central maven2 repository. > Thanks again, > Jens > http://jetm.void.fm/maven2/jetm-1.2.1/jetm-1.2.1-bundle.jar > http://jetm.void.fm/maven2/jetm-1.2.1/jetm-optional-1.2.1-bundle.jar -- 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-39) Browse Maven Repository and Add/Delete Dependencies through the IDE
Browse Maven Repository and Add/Delete Dependencies through the IDE --- Key: NMAVEN-39 URL: http://jira.codehaus.org/browse/NMAVEN-39 Project: NMaven Issue Type: New Feature Environment: Windows, Linux, Visual Studio, Sharp Develop Reporter: Shane Isbell The developer should be able to browse local and remote repositories and attach/delete dependencies (including transitive) to both the IDE project file and the pom.xml. -- 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-1510) MulTEx - the Multi-Tier Exception Handling Framework
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1510. --- Assignee: Carlos Sanchez Resolution: Fixed > MulTEx - the Multi-Tier Exception Handling Framework > > > Key: MAVENUPLOAD-1510 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1510 > Project: maven-upload-requests > Issue Type: Task >Reporter: Christoph Knabe >Assignee: Carlos Sanchez > Attachments: multex-7.1-bundle.jar > > > MulTEx is a simple, but powerful framework for organizing exceptions and > messages in a multi-tier Java software system. > It offers the key features: > - Causal chains/trees as a means to capture low-level error information > - Redundancy-free stack traces in the case of indirectly caused exceptions > - Internationalizable message texts and parameters for exceptions > - Services for reporting an exception with its causal chain/tree onto streams > and screens > - A standard way for writing method bodies with regard to exceptions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1511) Upload objenesis-1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94828 ] Carlos Sanchez commented on MAVENUPLOAD-1511: - who owns objenesis.org domain to use it as groupId? > Upload objenesis-1.0 > > > Key: MAVENUPLOAD-1511 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1511 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mauro Talevi > > Please upload. -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94826 ] Carlos Sanchez commented on MNG-2968: - I understand, and this change won't happen before the tools like the copy-dependencies support this other way this is how I see it project name:util groupId:com.mycompany.webservices artifactId:util war, copy-dependencies, eclipse,... would use as id/name of the jar/... com.mycompany.webservices.util because still, webservices.util may conflict with something else > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94824 ] Jacob Robertson commented on MNG-2968: -- Let me give an example of where you might like to have dots which follow the expected java package structure inside a project. project name:webservices.util cvs module name:webservices.util groupId:com.mycompany.webservices artifactId:webservices.util project name:webservices.xfire cvs module name:webservices.xfire groupId:com.mycompany.webservices artifactId:webservices.xfire We wouldn't want to have an artifact id of just "util" for the first project, because that would be confusing and problematic with tools like copy-dependencies since we'd undoubtably have more than one project with an artifact of "util". So, we'd be more likely to do "webservices-util" which now means our artifact id is out of synch with (A) the project name, (B) the cvs module name and (C) the java package name. > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94822 ] Carlos Sanchez commented on MNG-2968: - to mimic the package names is why there's groupId+artifactId groupId can have dots, artifactId shouldn't but to do this the other plugins should use the concatenation of groupId+artifactId, like the eclipse plugin. > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- 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-2975) test scope does not work with pom dependency
test scope does not work with pom dependency Key: MNG-2975 URL: http://jira.codehaus.org/browse/MNG-2975 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: jdk1.5 Reporter: Franck HUGOT I have a project A with pom packaging (pom) that use this dependency : org.springframework spring-mock 2.0 test In project B , I try to use the project A like a dependency like this : xxx SOFFWK_LIBS 1.0 pom I don't get the spring-mock transitive dependency when I compile or test project B. Is it because it has a test scope? -- 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-5) Support for Adding Compile-time References from the GAC
[ http://jira.codehaus.org/browse/NMAVEN-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94808 ] Shane Isbell commented on NMAVEN-5: --- Issue above fixed within the SI_XPT branch. In the case of using the MS environment, the developer can directly specify whether to use a GAC, GAC32 or GAC_MSIL reference, regardless of which framework version they are building with. > Support for Adding Compile-time References from the GAC > --- > > Key: NMAVEN-5 > URL: http://jira.codehaus.org/browse/NMAVEN-5 > Project: NMaven > Issue Type: Improvement > Environment: Windows, Linux, Mono, Microsoft >Reporter: Shane Isbell > > NMaven currently supports compile-time reference from the local maven repo on > the file system: these dependencies are specified within the pom build file. > In some circumstances, the artifacts cannot be legally distributed > (Microsoft); so I need a way for adding compile-time references from the GAC > itself. This improvement does not preclude the ability to import the > artifacts from the GAC into the local maven repo, it only extends the types > of dependencies that NMaven recognizes. -- 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_94806 ] Shane Isbell commented on NMAVEN-6: --- The SI_XPT branch contains an addin for both VS and SD. The GUI displays a list of .NET projects and the developer can right-click to choose an option to build, clean, install and test.projects. > 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: (MAVENUPLOAD-1511) Upload objenesis-1.0
Upload objenesis-1.0 Key: MAVENUPLOAD-1511 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1511 Project: maven-upload-requests Issue Type: Task Reporter: Mauro Talevi Please upload. -- 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-12) Support for Invoking the MavenEmbedder Methods from .NET Applications
[ http://jira.codehaus.org/browse/NMAVEN-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94805 ] Shane Isbell commented on NMAVEN-12: Branch SI_XPT has an implementation of this feature using 2.1 SNAPSHOT of maven. It supports the basic build phases: clean, install, build, test. > Support for Invoking the MavenEmbedder Methods from .NET Applications > - > > Key: NMAVEN-12 > URL: http://jira.codehaus.org/browse/NMAVEN-12 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux >Reporter: Shane Isbell >Priority: Minor > > As part of the IDE integration, Visual Studio and Sharp Develop need to use > maven functionality. This feature will support a way for .NET applications to > invoke the MavenEmbedder methods. -- 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: (NMAVEN-17) Create MVC Framework and Widgets for IDE
[ http://jira.codehaus.org/browse/NMAVEN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed NMAVEN-17. -- Resolution: Won't Fix This feature is not necessary for the IDE addins because the existing .NET winforms works well, with a clean implementation. > Create MVC Framework and Widgets for IDE > > > Key: NMAVEN-17 > URL: http://jira.codehaus.org/browse/NMAVEN-17 > Project: NMaven > Issue Type: New Feature > Environment: Visual Studio, SharpDevelop >Reporter: Shane Isbell >Priority: Minor > > Create a simple MVC framework (and some widgets) for the NMaven plugin to > IDEs. This should, if possible, be reusable for both SD and VS. The framework > should also be extendable by developers. In seaching for existing .NET MVC > frameworks I found ingenious mvc > (http://sourceforge.net/projects/ingeniousmvc) but its LGPL licensing is > incompatible -- 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-15) Support for Writing Maven Plugins in .NET
[ http://jira.codehaus.org/browse/NMAVEN-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94803 ] Shane Isbell commented on NMAVEN-15: This feature is now implemented within the SI_XPT branch. The developer can specify fields (using attributes) into their .NET Abstract Mojo implementation and the framework will inject the values. > Support for Writing Maven Plugins in .NET > - > > Key: NMAVEN-15 > URL: http://jira.codehaus.org/browse/NMAVEN-15 > Project: NMaven > Issue Type: New Feature >Reporter: Shane Isbell >Priority: Minor > > Currently, the developer needs to create a plugin in Java, create a .NET > executable and then add an entry in the net-dependencies.xml file. NMaven > should allow the developer to write the maven plugin in .NET and then have > the NMaven framework automatically pick it up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:14 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC dependencies.
> We
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:14 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
* if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC dependencies.
> We
[jira] Issue Comment Edited: (NMAVEN-19) Dependency resolution and Maven integration (site, deploy)
[
http://jira.codehaus.org/browse/NMAVEN-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91763
]
Christophe Lallement edited comment on NMAVEN-19 at 5/2/07 9:15 AM:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
* 1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
* 2/ Into dependancy, we can fill the name tag which bypass the naming
convention to build the full name of dependancy.
* 3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
* 4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
was:
Hi Shane
I work with Alexandre but and i'm not agree with his last comment.
Actually nmaven does't work as we wish because it seems the naming convention
to build the delivery name (jar, war in java / assembly, dll in .net) is not
the same as the maven jar packaging.
To explain our pb, we can deploy (with the attached patch) but after that all
other maven plugins which are not "language dependant" and are based on the
maven naming convention (package, dependancies resolving, ...)
For example, after the deploy of an assembly with the right name in a remote
repository, we can not use this name into another projet dependancies and have
an automatic donwload to get the right version.
For me it's important that nmaven use the maven convention (in fact i don't
understand why your plugin has to manipulate direclty the name of the
delivery).
1/ The name of a delivery is build like this
=> if the finalname is not fill into the pom, this name is build with the
naming convention "${artifactId}-${version}.${packaging}" or if classifier is
given "${artifactId}-${version}-${classifier}.${packaging}"
2/ Into dependancy, we can fill the name tag which bypass the naming convention
to build the full name of dependancy.
3/ The path resolution must include the local maven repository lookup before
the GAC lookup.
4/ If we have a pb to deploy delivery (assembly) with a name non supported by
the gac, "foo-2.3.1-AAA", maybe we can adopt a second naming convention, just
for the GAC deployement (maybe is should be a specific plugin/goal: mvn
gac:deploy.
Don't remember that the way to manage delivery version is not a "java feature"
but a "maven" convention.
Thx
Christophe
> Dependency resolution and Maven integration (site, deploy)
> --
>
> Key: NMAVEN-19
> URL: http://jira.codehaus.org/browse/NMAVEN-19
> Project: NMaven
> Issue Type: Wish
>Reporter: Alexandre Garcia
> Attachments: components.patch
>
>
> First of all Shane, we really appreciate your effort.
> We tried to complement your packaging lifecycles in order to test site and
> deploy
> The Maven plugins site and deploy use the standard Maven artefact layout:
> ArtefactId-Version.dll
> We were able to use mvn site after renaming accordingly installed artefacts
> in the local repo ($reports is not expanded though).
> We rebuilt NMaven after altering
> NMaven\plugins\maven-compile-plugin\src\main\resources\META-INF\plexus\components.xml
> to include the deploy phase in the packaging lifecycles.
> The deploy phase is successful but is once again maven style.
> Unfortunately, the deployed artefacts cannot be downloaded because NMaven
> dependency resolution doesnot include the version suffix and hence doesnot
> find the artefact on the remote repo.
> More generally, i wish NMaven could adopt default Maven style artefact layout
> or a mixed mode for GAC depende
[jira] Created: (MWAR-100) War overlay with merged web.xml
War overlay with merged web.xml --- Key: MWAR-100 URL: http://jira.codehaus.org/browse/MWAR-100 Project: Maven 2.x War Plugin Issue Type: Wish Affects Versions: 2.0 Reporter: Anders Romin I'm looking for a way to use the war overlay feature and have the web.xml merged with the content of both the parent war and the child war. For example, we have two wars A and B, and B is depending on A using the overlay feature. Now, I'd like all filters, servlets etc that are configured in A to be available in the resulting war, as well as all filters, servlets etc from B. If the id attributes clash, then the objects from B should be used. Any ideas how this could be accomplished? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-208) Assembly plugin does not resolve version ranges correctly
Assembly plugin does not resolve version ranges correctly - Key: MASSEMBLY-208 URL: http://jira.codehaus.org/browse/MASSEMBLY-208 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: XP Pro SP2 Reporter: David Hoffer Similar to MRELEASE-134 in maven-release-plugin [1.1.0,) This version range can resolve to the latest dev SNAPSHOT. The assembly plugin should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary". I think this requirement was forgetten when version ranges were implemented. -- 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-306) Bad URL in .cvspass if using non standard port number for CVS server
Bad URL in .cvspass if using non standard port number for CVS server Key: SCM-306 URL: http://jira.codehaus.org/browse/SCM-306 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0 Environment: Windows, Reporter: Alain Coetmeur Using latest evolution of CVS provider, that create the .cvspass on Windows, NOT needing CVSNT summary : when using a SCM URL targeting a CVS server with a non standard port, the CVS root inside .cvspass is badly generated, with the 2401 numbers preceding the indicated port number, preventing this .cvspass line to be used later for authentication. detail: when I set a password and a username for a SCM operation on CVS with a CVS root including a non standard port like this: scm url: scm:cvs|pserver|@s.serv.cdc.fr|12021/s/cvsdata/XX|project it create a line in .cvspass like this /1 :pserver:[EMAIL PROTECTED]:240112021/s/cvsdata/XX A:yZZ30 e and then fails with "bad password" If I edit manually the line, removing the "2401" spurious numbers this way /1 :pserver:[EMAIL PROTECTED]:12021/s/cvsdata/XX A:yZZ30 e it works, even if it add again the /1 :pserver:[EMAIL PROTECTED]:240112021/s/cvsdata/XX A:yZZ30 e line, after the previous... thanks in advance... -- 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-88) Dependency plugin does not resolve version ranges correctly
Dependency plugin does not resolve version ranges correctly --- Key: MDEP-88 URL: http://jira.codehaus.org/browse/MDEP-88 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-4 Environment: XP Pro SP2 Reporter: David Hoffer Assignee: Brian Fox Similar to MRELEASE-134 in maven-release-plugin [1.1.0,) This version range can resolve to the latest dev SNAPSHOT. The dependency plugin should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary". I think this requirement was forgetten when version ranges were implemented. -- 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-90) IDEA Plugin does not resolve version ranges correctly
IDEA Plugin does not resolve version ranges correctly - Key: MIDEA-90 URL: http://jira.codehaus.org/browse/MIDEA-90 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0, 2.1 Environment: Xp Pro SP2 Reporter: David Hoffer Similar to MRELEASE-134 in maven-release-plugin [1.1.0,) This version range can resolve to the latest dev SNAPSHOT. The idea plugin should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary". I think this requirement was forgetten when version ranges were implemented. -- 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: (ARCHETYPE-71) Allow for more flexable directory strucuture in custom archetype
Allow for more flexable directory strucuture in custom archetype Key: ARCHETYPE-71 URL: http://jira.codehaus.org/browse/ARCHETYPE-71 Project: Maven Archetype Issue Type: Improvement Affects Versions: 1.0-alpha-4 Environment: XP Pro SP2 Reporter: David Hoffer The process given for creating a custom archetype seems limiting and confusing. I want the standard maven directory layout but in addition I want to add higher level folders called trunk & tags this way my new artifact projects will be configured correctly for VCS usage. (The maven build usage of this will be in the trunk folder so we do use the standard maven layout.) The docs say that these elements represent different sections of the project, what is not clear is if these are hard coded paths or if these have this path because the archetype descriptor defines them this way. If they are hard coded it makes no sense for the path to be included in the descriptor file, which it is. * = src/main/java * = src/main/resources * = src/test/java * = src/test/resources * = src/site Here is my descriptor: xrite-archetype-default trunk/src/main/java/App.java trunk/src/test/java/AppTest.java trunk/src/site/site.xml trunk/src/site/apt/overview.apt trunk/src/site/fml/faqs.fml Although my files do have this layout pattern when I run this archetype I an error "Template 'trunk/src/main/java/App.java' not in directory 'src/main/java' This should be supported. -- 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: (MENFORCER-4) Typos in Version Range Specification document
[ http://jira.codehaus.org/browse/MENFORCER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-4. - Resolution: Fixed Fix Version/s: 1.0-alpha-3 fixed, thanks. > Typos in Version Range Specification document > - > > Key: MENFORCER-4 > URL: http://jira.codehaus.org/browse/MENFORCER-4 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug >Reporter: Grzegorz Kossakowski >Assignee: Brian Fox >Priority: Minor > Fix For: 1.0-alpha-3 > > > In > http://maven.apache.org/plugins/maven-enforcer-plugin/rules/versionRanges.html > there two typos in table: > (1.0,2.0) 1.0 >= x <= 2.0 > should be: > (1.0,2.0) 1.0 > x < 2.0 > and: > [1.0,2.0] 1.0 > x < 2.0 > should be: > (1.0,2.0) 1.0 >= x <= 2.0 -- 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-2968) Forbid dots in artifactId
[ http://jira.codehaus.org/browse/MNG-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94788 ] Jacob Robertson commented on MNG-2968: -- Making this change would be costly for my company, as our standard is to use dots in all our artifact names instead of dashes. Our group ids and artifact ids are designed to closely mimic the top-level package names in each java project. This allows us to use consistent naming standards in eclipse, maven, cvs, and java packages. All with dots. To make this change, I think you'll first have to quantify very clearly what the actual benefits are versus the risk of making another sweeping backwards incompatible change. > Forbid dots in artifactId > - > > Key: MNG-2968 > URL: http://jira.codehaus.org/browse/MNG-2968 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.6, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > artifactIds with dots are potential trouble. They prevent using > groupId.artifactId as identifier and later parse it back -- 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-103) Simple test case where compile succeeds but javadoc fails
[ http://jira.codehaus.org/browse/MJAVADOC-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94782 ] Matt Kern commented on MJAVADOC-103: [ This post is just to help others who might stumble across this bug looking for a solution to a problem I had ] I saw this exact issue using the maven-psteclipse-plugin v1.1.0 (direct from pst) and the maven-javadoc-plugin v2.2. The issue I had was that the psteclipse:update goal is bound to the process-resources lifecycle stage. Running "mvn javadoc:jar" would fail in the master directory but succeed in the child (project) directories. However, running "mvn psteclipse:update javadoc:jar" from the master directory got around this problem. I suspect there is still something wrong somewhere, but at least this allowed me to proceed. > Simple test case where compile succeeds but javadoc fails > - > > Key: MJAVADOC-103 > URL: http://jira.codehaus.org/browse/MJAVADOC-103 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Adam Lally >Assignee: Vincent Siveton > Fix For: 2.1 > > Attachments: maven-javadoc-test.zip > > > The attached project has a parent POM with one module. The module has just > one simple Java class in it, but it has dependencies on some 3rd party > artifacts (available from a shared repository). > When I run "mvn install" for the parent, it succeeds. > If I run "mvn javadoc:javadoc" from the module, it succeeds. > If I run "mvn javadoc:javadoc" from the parent, it fails: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation. > Embedded error: Exit code: 1 - > C:/alally/dev/maven-javadoc-test/test-module/src/ > main/java/Test.java:3: package org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.ISharedImages; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:4: > package > org.eclipse.jdt.ui does not exist > import org.eclipse.jdt.ui.JavaUI; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:5: > package > org.eclipse.swt.graphics does not exist > import org.eclipse.swt.graphics.Image; > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : class Image > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(IShare > dImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable ISharedImages > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); > ^ > C:/alally/dev/maven-javadoc-test/test-module/src/main/java/Test.java:8: > cannot find symbol > symbol : variable JavaUI > location: class test.module1.Test > public static final Image CLASS_ICON= > JavaUI.getSharedImages().getImage(ISharedImages.IMG_OBJS_CLASS); -- 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: (MENFORCER-4) Typos in Version Range Specification document
Typos in Version Range Specification document - Key: MENFORCER-4 URL: http://jira.codehaus.org/browse/MENFORCER-4 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: Grzegorz Kossakowski Assignee: Brian Fox Priority: Minor In http://maven.apache.org/plugins/maven-enforcer-plugin/rules/versionRanges.html there two typos in table: (1.0,2.0) 1.0 >= x <= 2.0 should be: (1.0,2.0) 1.0 > x < 2.0 and: [1.0,2.0] 1.0 > x < 2.0 should be: (1.0,2.0) 1.0 >= x <= 2.0 -- 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-2974) Unable to resolve & download snapshot versions from CLI
[ http://jira.codehaus.org/browse/MNG-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94767 ] Yves Van Steen commented on MNG-2974: - Sorry, I seem to made it a major bug. This wasn't my intent and now I am unable to change this. > Unable to resolve & download snapshot versions from CLI > --- > > Key: MNG-2974 > URL: http://jira.codehaus.org/browse/MNG-2974 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 > Environment: Windows >Reporter: Yves Van Steen > > When I try to use a snapshot released version of a plugin on the command line > interface maven doesn't resolve these and download them from registered the > plugin repositories. When using non snapshot versions it is not a problem to > resolve and download them. When I add the plugin (a snapshot version) to a > POM and run it it does download it. So the problem does not lie with the > repo which is registered in the settings.xml in a profile which is active. > The problem just seems to lie with the resolving and dowloading part of the > process. Cause after the snapshot plugin is download using the POM way it > does find the plugin when running it from the CLI. > I first discovered this bug when trying to use the Maven install plugin. > Here are commands used in the process. Reproding this way of use I got the > same result when requesting other snapshot version of plugins that were not > in the repository. > Command used to load snapshot version from the CLI (this gives the error you > find below) > mvn org.apache.maven.plugins:maven-install-plugin:2.2-SNAPSHOT:install-file > (... + correct plugin params ) > Command used to load a specific released version from the CLI > mvn org.apache.maven.plugins:maven-install-plugin:2.1:install-file (... + > correct plugin params ) > Command used to load a the top released version from the CLI > mvn org.apache.maven.plugins:maven-install-plugin:install-file (... + correct > plugin params ) > Settings.xml File > > apachesnapshots > > > d > > http://people.apache.org/repo/m2-snapshot-repository/ > > false > > > true > > allways > > ignore > > > > > Hope I gave you enough information to fix this error. It's not major but > does hinder me at this point cause now I have to manually place this plugin > in everyone of my developers local repo. -- 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-2974) Unable to resolve & download snapshot versions from CLI
Unable to resolve & download snapshot versions from CLI --- Key: MNG-2974 URL: http://jira.codehaus.org/browse/MNG-2974 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.6, 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Environment: Windows Reporter: Yves Van Steen When I try to use a snapshot released version of a plugin on the command line interface maven doesn't resolve these and download them from registered the plugin repositories. When using non snapshot versions it is not a problem to resolve and download them. When I add the plugin (a snapshot version) to a POM and run it it does download it. So the problem does not lie with the repo which is registered in the settings.xml in a profile which is active. The problem just seems to lie with the resolving and dowloading part of the process. Cause after the snapshot plugin is download using the POM way it does find the plugin when running it from the CLI. I first discovered this bug when trying to use the Maven install plugin. Here are commands used in the process. Reproding this way of use I got the same result when requesting other snapshot version of plugins that were not in the repository. Command used to load snapshot version from the CLI (this gives the error you find below) mvn org.apache.maven.plugins:maven-install-plugin:2.2-SNAPSHOT:install-file (... + correct plugin params ) Command used to load a specific released version from the CLI mvn org.apache.maven.plugins:maven-install-plugin:2.1:install-file (... + correct plugin params ) Command used to load a the top released version from the CLI mvn org.apache.maven.plugins:maven-install-plugin:install-file (... + correct plugin params ) Settings.xml File apachesnapshots d http://people.apache.org/repo/m2-snapshot-repository/ false true allways ignore Hope I gave you enough information to fix this error. It's not major but does hinder me at this point cause now I have to manually place this plugin in everyone of my developers local repo. -- 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-1510) MulTEx - the Multi-Tier Exception Handling Framework
MulTEx - the Multi-Tier Exception Handling Framework Key: MAVENUPLOAD-1510 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1510 Project: maven-upload-requests Issue Type: Task Reporter: Christoph Knabe Attachments: multex-7.1-bundle.jar MulTEx is a simple, but powerful framework for organizing exceptions and messages in a multi-tier Java software system. It offers the key features: - Causal chains/trees as a means to capture low-level error information - Redundancy-free stack traces in the case of indirectly caused exceptions - Internationalizable message texts and parameters for exceptions - Services for reporting an exception with its causal chain/tree onto streams and screens - A standard way for writing method bodies with regard to exceptions. -- 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: (MANTTASKS-68) artifact:depencies doesnt work with Snapshot
[
http://jira.codehaus.org/browse/MANTTASKS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David N'DIAYE closed MANTTASKS-68.
--
Resolution: Fixed
Solve by patch MANTTASKS-18
> artifact:depencies doesnt work with Snapshot
>
>
> Key: MANTTASKS-68
> URL: http://jira.codehaus.org/browse/MANTTASKS-68
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: David N'DIAYE
> Attachments: testDependencySnapshots.zip
>
>
> -- I have a repository with snapshot
> -- I create a pom with a dependency to snapshot artifact
> {code:xml}
>
>
> commons-io
> commons-io
> 1.3-SNAPSHOT
>
>
> {code}
> -- In ant, I obtain dependencies on my application
> {code:xml}
> useScope="compile" verbose="true">
>
>
>
>
> {code}
>
> The {{compile.dependency.fileset}} *doesn't contains the snapshot artifact*
>
> To test this bug, you can launch my ant test by : {color:red} *{{ant
> test}}*{color}
--
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-68) artifact:depencies doesnt work with Snapshot
[
http://jira.codehaus.org/browse/MANTTASKS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94763
]
David N'DIAYE commented on MANTTASKS-68:
I confirm, MANTTASKS-18 solve my problem.
I vote for your issue, and i close this jira
thanks a lot
> artifact:depencies doesnt work with Snapshot
>
>
> Key: MANTTASKS-68
> URL: http://jira.codehaus.org/browse/MANTTASKS-68
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: David N'DIAYE
> Attachments: testDependencySnapshots.zip
>
>
> -- I have a repository with snapshot
> -- I create a pom with a dependency to snapshot artifact
> {code:xml}
>
>
> commons-io
> commons-io
> 1.3-SNAPSHOT
>
>
> {code}
> -- In ant, I obtain dependencies on my application
> {code:xml}
> useScope="compile" verbose="true">
>
>
>
>
> {code}
>
> The {{compile.dependency.fileset}} *doesn't contains the snapshot artifact*
>
> To test this bug, you can launch my ant test by : {color:red} *{{ant
> test}}*{color}
--
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
