[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[
http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135836#action_135836
]
Joerg Schaible commented on SCM-368:
Note, that the following snippet makes wrong assumptions:
{code}
if ( settings.isUseCygwinPath() )
{
workingDir = "/cygdrive/" + workingDir;
workingDir = StringUtils.replace( workingDir, ":", "" );
workingDir = StringUtils.replace( workingDir, "\\", "/" );
}
{code}
"/cygdrive" may not exist at all. The cygdrive prefix can be set to anything.
See for example on my system:
{noformat}
$ mount --show-cygdrive-prefix
Prefix Type Flags
/mntsystem binmode
{noformat}
Cygwin users set this also often to "/dev" or even "/" (although not
recommended). The cygdrive prefix is currently stored in Windows registry only,
so you will have to retrieve it calling an external utility.
> Windows path length limitations can be overcome by feeding an absolute path
> to SVN
> --
>
> Key: SCM-368
> URL: http://jira.codehaus.org/browse/SCM-368
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-api
>Affects Versions: 1.0
> Environment: Any Windows machine
>Reporter: Kurt Tometich
>Assignee: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.1
>
>
> When calling Subversion with relative paths there is a limit of 255
> characters to the path length. If you call Subversion with an absolute path
> that no longer applies and you now have access to 32K chars. I have tried
> this myself and it does work. Try feeding SVN a path that is relative and is
> over 255 chars. It will not be able to complete the transaction. Now, try
> to the same path again only as an absolute path and it will successfully
> complete the transaction. Here is a link to the forum where I found this
> information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3574) RELEASE versions cause build failures
[ http://jira.codehaus.org/browse/MNG-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milos Kleint closed MNG-3574. - Resolution: Fixed Fix Version/s: 2.1-alpha-1 meta versions need to be replaced with the actual resolved one. http://svn.apache.org/viewvc?rev=659463&view=rev > RELEASE versions cause build failures > - > > Key: MNG-3574 > URL: http://jira.codehaus.org/browse/MNG-3574 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: Milos Kleint > Fix For: 2.1-alpha-1 > > > See: http://www.netbeans.org/issues/show_bug.cgi?id=135070 -- 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-2075) upload jgraph 5.10.2.0
upload jgraph 5.10.2.0 -- Key: MAVENUPLOAD-2075 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2075 Project: maven-upload-requests Issue Type: Wish Reporter: David Delbecq Please upload jgraph 5.10.2.0, and, optionnally, it's source package. JGraph is, unfortunately, not build using maven. However, it's quite usefull in a broad range of app. net.sf.jped:2.0 was uploaded to central maven repo 2 days ago, and we didn't notice that broken dependency (was available locally during build). putting 5.10.2.0 of jgraph in central repository would solve this broken dependency. group ID: jgraph artifact ID: jgraph The groupId already exist in central repo with older versions of jgraph. -- 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-2433) Maven looks for snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135847#action_135847 ] Olivier THIERRY commented on MNG-2433: -- I have the same problem with Maven 2.0.8. It happened to me while doing a demonstration, so I had to improvise, not very comfortable lol I ran maven with -o option because I had no network at the place where I did the demo, so I did not want to check artifacts. All artifacts are in my local repository so there should have been no problem ... but it tried to download artifacts and I can't understand why. I had the following error message : [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.andromda.profiles.uml14:andromda-profile-service:xml.zip:3.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.andromda.profiles.uml14 -DartifactId=andromda-profile-service -Dversion=3.3-SNAPSHOT -Dpackaging=xml.zip -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.andromda.profiles.uml14 -DartifactId=andromda-profile-service -Dversion=3.3-SNAPSHOT -Dpackaging=xml.zip -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) fr.xxx.t4:t4-core-mda:pom:1.0-SNAPSHOT 2) org.andromda.cartridges:andromda-ejb3-cartridge:jar:1.0-SNAPSHOT 3) org.andromda.profiles.uml14:andromda-profile:xml.zip:3.3-SNAPSHOT 4) org.andromda.profiles.uml14:andromda-profile-service:xml.zip:3.3-SNAPSHOT -- 1 required artifact is missing. for artifact: fr.xxx.t4:t4-core-mda:pom:1.0-SNAPSHOT from the specified remote repositories: central (http://10.11.4.108:8080/artifactory/repo), andromda (http://10.11.4.108:8080/artifactory/repo), snapshots (http://10.11.4.108:8080/artifactory/repo) NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. To help to reproduce the problem, note I use artifactory as a repository. I have the following config in pom.xml : andromda http://10.11.4.108:8080/artifactory/repo true daily central http://10.11.4.108:8080/artifactory/repo false snapshots http://10.11.4.108:8080/artifactory/repo true daily andromda http://10.11.4.108:8080/artifactory/repo false central http://10.11.4.108:8080/artifactory/repo false snapshots http://10.11.4.108:8080/artifactory/repo false I tried with updatePolicy as "weekly" or "never" but it changed nothing. I also have the following mirrors in maven settings.xml, but removing them changed nothing : andromda andromda AndroMDA Repository http://10.11.4.108:8080/artifactory/repo apache-incubator apache-incubator Apache Incubator Repository http://10.11.4.108:8080/artifactory/repo I really think there is a bug somewhere, as we run maven with -o option, it should not try to download artifacts. Maybe a problem with transitive dependencies ? > Maven looks for snapshots in offline mode > - > > Key: MNG-2433 > URL: http://jira.codehaus.org/browse/MNG-2433 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.5 >Reporter: Carsten Ziegeler >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.6 > > > It seems that sometimes Maven2 is looking for snapshots in offline mode (this > happens for example in the Cocoon project). here is an output that might help: > :\dev\workspace\cocoon-2.2\core\cocoon-webapp>mvn -o -Dmaven.test.skip=true > coc > oon:deploy > [INFO] > NOTE: Maven is executing in offline mode. Any artifacts not already in your > loca > l > repository will be inaccessible. > [INFO] Scanning for projects... > [INFO] Searching
[jira] Reopened: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse reopened SCM-368: -- oh, I didn't know this option. I wouldn't want to run an external program to find it, so I think i'll add a new property in the conf file to change it > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- 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-3593) Maven tries to download artifacts while it runs in offline mode
Maven tries to download artifacts while it runs in offline mode
---
Key: MNG-3593
URL: http://jira.codehaus.org/browse/MNG-3593
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.8
Environment: Maven 2.0.8, Windows XP, Artifactory
Reporter: Olivier THIERRY
Priority: Critical
I encounter a problem that has been filed before
(http://jira.codehaus.org/browse/MNG-2433), then closed but actually I think it
is not solved yet !
I run maven with -o option. All artifacts are in my local repository (I am
totally sure about this !) so there should have been no downloads ... but Maven
tries to download artifacts and I can't understand why.
I have the following error message :
{quote}[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.andromda.profiles.uml14:andromda-profile-service:xml.zip:3.3-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.andromda.profiles.uml14
-DartifactId=andromda-profile-service -Dversion=3.3-SNAPSHOT
-Dpackaging=xml.zip -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.andromda.profiles.uml14
-DartifactId=andromda-profile-service -Dversion=3.3-SNAPSHOT
-Dpackaging=xml.zip -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) fr.xxx.t4:t4-core-mda:pom:1.0-SNAPSHOT
2) org.andromda.cartridges:andromda-ejb3-cartridge:jar:1.0-SNAPSHOT
3) org.andromda.profiles.uml14:andromda-profile:xml.zip:3.3-SNAPSHOT
4) org.andromda.profiles.uml14:andromda-profile-service:xml.zip:3.3-SNAPSHOT
--
1 required artifact is missing.
for artifact:
fr.xxx.t4:t4-core-mda:pom:1.0-SNAPSHOT
from the specified remote repositories:
central (http://10.11.4.108:8080/artifactory/repo),
andromda (http://10.11.4.108:8080/artifactory/repo),
snapshots (http://10.11.4.108:8080/artifactory/repo)
NOTE: Maven is executing in offline mode. Any artifacts not already in your
local
repository will be inaccessible.{quote}
To help to reproduce the problem, note I use artifactory as a repository. I
have the following config in pom.xml :
{code:xml}
andromda
http://10.11.4.108:8080/artifactory/repo
true
daily
central
http://10.11.4.108:8080/artifactory/repo
false
snapshots
http://10.11.4.108:8080/artifactory/repo
true
daily
andromda
http://10.11.4.108:8080/artifactory/repo
false
central
http://10.11.4.108:8080/artifactory/repo
false
snapshots
http://10.11.4.108:8080/artifactory/repo
false
{code}
I tried with updatePolicy as "weekly" or "never" but it changed nothing.
I also have the following mirrors in maven settings.xml, but removing them
changed nothing :
{code:xml}
andromda
andromda
AndroMDA Repository
http://10.11.4.108:8080/artifactory/repo
apache-incubator
apache-incubator
Apache Incubator Repository
http://10.11.4.108:8080/artifactory/repo
{code}
I really think there is a bug somewhere, as we run maven with -o option, it
should not try to download artifacts. Maybe a problem with transitive
dependencies ? Or a problem with snapshots ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-175) Add skip property
[ http://jira.codehaus.org/browse/MJAVADOC-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-175. Resolution: Duplicate > Add skip property > - > > Key: MJAVADOC-175 > URL: http://jira.codehaus.org/browse/MJAVADOC-175 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Reporter: Christian Brensing >Priority: Minor > > Please add a skip property to skip javadoc generation in child modules. If > the javadoc plugin is configured (with aggregation) in an multimodule project > at a parent level, javadoc will be produced for each child module. The only > way I know to avoid this behaviour is to exclude the provided packages of the > child module in the plugin configuration of the parent. It would be better to > configure the javadoc plugin for the child module with true, > like e.g. the eclipse or pmd plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSOURCES-36) Source jar manifest should contain Specification and Implementation details
[
http://jira.codehaus.org/browse/MSOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135865#action_135865
]
Vincent Siveton commented on MSOURCES-36:
-
We need to use MavenArchiveConfiguration similar to
[http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java]
With this, the configuration could be:
{noformat}
true
true
{noformat}
> Source jar manifest should contain Specification and Implementation details
> ---
>
> Key: MSOURCES-36
> URL: http://jira.codehaus.org/browse/MSOURCES-36
> Project: Maven 2.x Source Plugin
> Issue Type: Bug
>Reporter: SebbASF
>Priority: Minor
>
> The javadoc jar manifest should contain Specification and Implementation
> details, e.g.:
> Implementation-Title: Commons SCXML
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Vendor-Id: org.apache
> Implementation-Version: 0.8
> Specification-Title: Commons SCXML
> Specification-Vendor: The Apache Software Foundation
> Specification-Version: 0.8
--
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-187) Javadoc jar manifest should contain Specification and Implementation details
[
http://jira.codehaus.org/browse/MJAVADOC-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135864#action_135864
]
Vincent Siveton commented on MJAVADOC-187:
--
We need to use MavenArchiveConfiguration similar to
[http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java]
This, the configuration will be:
{noformat}
true
true
{noformat}
> Javadoc jar manifest should contain Specification and Implementation details
>
>
> Key: MJAVADOC-187
> URL: http://jira.codehaus.org/browse/MJAVADOC-187
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Reporter: SebbASF
>Priority: Minor
>
> The javadoc jar manifest should contain Specification and Implementation
> details, e.g.:
> Implementation-Title: Commons SCXML
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Vendor-Id: org.apache
> Implementation-Version: 0.8
> Specification-Title: Commons SCXML
> Specification-Vendor: The Apache Software Foundation
> Specification-Version: 0.8
--
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: (MAVENUPLOAD-1968) JDom 1.1 is out
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MAVENUPLOAD-1968: --- Attachment: pom-relocation.xml jdom-1.1-bundle.jar Next try ;-) I started off with the existing POM for JDOM 1.0, updated dependencies and added missing bits. Still missing is the license info. According to the [JDOM FAQ|http://www.jdom.org/docs/faq.html#a0030], it's an "Apache-style" license but I couldn't find a browsable URL for it so not sure how to get that into the POM. Also, I propose to relocate the artifact from the group "jdom" to "org.jdom" to better match our conventions. The loose POM should provide appropriate relocation info. > JDom 1.1 is out > --- > > Key: MAVENUPLOAD-1968 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Mirko Steinle >Assignee: Carlos Sanchez > Attachments: jdom-1.1-bundle.jar, pom-relocation.xml > > > Hello! > JDom has released a major version (1.1) last november. Could you please > upload it? > All files can be found at http://www.jdom.org/ > Thank you very much. > Mirko > P.S. I am only a user of JDom, but I guess the team won't have anything > against seeing their latest release uploaded... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-329) infinite build loop during site generation
infinite build loop during site generation -- Key: MSITE-329 URL: http://jira.codehaus.org/browse/MSITE-329 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.9; Sun JDK 1.6.0_06; Linux Ubuntu 8.04 Reporter: Alessio Pace My multi module project can be correctly built from the top most parent module with a simple mvn -DskipTests clean install, but trying instead to perform a mvn -DskipTests clean site causes an infinite loop in the build process, where the overall build and site generation is performed all and all over again. -- 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-1968) JDom 1.1 is out
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MAVENUPLOAD-1968: > JDom 1.1 is out > --- > > Key: MAVENUPLOAD-1968 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Mirko Steinle >Assignee: Carlos Sanchez > Attachments: jdom-1.1-bundle.jar, pom-relocation.xml > > > Hello! > JDom has released a major version (1.1) last november. Could you please > upload it? > All files can be found at http://www.jdom.org/ > Thank you very much. > Mirko > P.S. I am only a user of JDom, but I guess the team won't have anything > against seeing their latest release uploaded... -- 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: (MEAR-51) Exploded (unpacked) ear
[ http://jira.codehaus.org/browse/MEAR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135867#action_135867 ] Chandra Poluru commented on MEAR-51: Hi Any progress on implementing the new goal like you did for war. it seems to be a problem for many with no solution. I am here after googling everywhere to find this. > Exploded (unpacked) ear > --- > > Key: MEAR-51 > URL: http://jira.codehaus.org/browse/MEAR-51 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Maurice Zeijen >Assignee: Stephane Nicoll > > It is great that you can unpack the modules within the ear. But it would be > also be great if the ear itself could also be delivered unpacked. At this > moment I could use the working directory but it doesn't get the Manifest 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] Commented: (MSITE-329) infinite build loop during site generation
[ http://jira.codehaus.org/browse/MSITE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135868#action_135868 ] Maria Odea Ching commented on MSITE-329: This was also experienced in Archiva, see http://www.nabble.com/Trunk-has-a-build-loop---td16075681.html > infinite build loop during site generation > -- > > Key: MSITE-329 > URL: http://jira.codehaus.org/browse/MSITE-329 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Maven 2.0.9; Sun JDK 1.6.0_06; Linux Ubuntu 8.04 >Reporter: Alessio Pace > > My multi module project can be correctly built from the top most parent > module with a simple mvn -DskipTests clean install, but trying instead to > perform a mvn -DskipTests clean site causes an infinite loop in the build > process, where the overall build and site generation is performed all and all > over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-329) infinite build loop during site generation
[ http://jira.codehaus.org/browse/MSITE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135869#action_135869 ] Valerio Schiavoni commented on MSITE-329: - Same on Mac OSX 10.5.2 and java 1.5.0_13 > infinite build loop during site generation > -- > > Key: MSITE-329 > URL: http://jira.codehaus.org/browse/MSITE-329 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Maven 2.0.9; Sun JDK 1.6.0_06; Linux Ubuntu 8.04 >Reporter: Alessio Pace > > My multi module project can be correctly built from the top most parent > module with a simple mvn -DskipTests clean install, but trying instead to > perform a mvn -DskipTests clean site causes an infinite loop in the build > process, where the overall build and site generation is performed all and all > over again. -- 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: (MSITE-329) infinite build loop during site generation
[ http://jira.codehaus.org/browse/MSITE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Pace closed MSITE-329. -- Resolution: Fixed Fix Version/s: 2.0-beta-6 Apparently using the 2.0-beta-6 version of the maven-site-plugin the infinite loop is not encountered. > infinite build loop during site generation > -- > > Key: MSITE-329 > URL: http://jira.codehaus.org/browse/MSITE-329 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Maven 2.0.9; Sun JDK 1.6.0_06; Linux Ubuntu 8.04 >Reporter: Alessio Pace > Fix For: 2.0-beta-6 > > > My multi module project can be correctly built from the top most parent > module with a simple mvn -DskipTests clean install, but trying instead to > perform a mvn -DskipTests clean site causes an infinite loop in the build > process, where the overall build and site generation is performed all and all > over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-221) XML header missing in modified POM after release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MRELEASE-221: --- Fix Version/s: (was: 2.0-beta-5) > XML header missing in modified POM after release:prepare > > > Key: MRELEASE-221 > URL: http://jira.codehaus.org/browse/MRELEASE-221 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Windows XP, CVSNT, Eclipse >Reporter: Alain Coetmeur > > When release plugin modifies the POM to prepare a new release, > the new file does not containt the XML header > > it cause problems with XML editors who ignore the encoding and breaks all > unusual characters. > some XML tools also don't accept XML files without headers... -- 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: (MRELEASE-221) XML header missing in modified POM after release:prepare
[
http://jira.codehaus.org/browse/MRELEASE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MRELEASE-221:
This was indeed reproducible: MRELEASE-254.
The problem is that the XML declaration and anything else outside of the root
element depend on a fragile detection algo using {{indexOf()}} on the
serialized DOM. If this detection fails, the stuff is simply dropped from the
resulting POM.
> XML header missing in modified POM after release:prepare
>
>
> Key: MRELEASE-221
> URL: http://jira.codehaus.org/browse/MRELEASE-221
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: Windows XP, CVSNT, Eclipse
>Reporter: Alain Coetmeur
>
> When release plugin modifies the POM to prepare a new release,
> the new file does not containt the XML header
>
> it cause problems with XML editors who ignore the encoding and breaks all
> unusual characters.
> some XML tools also don't accept XML files without headers...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-93) maven-antrun-plugin must depend on ant v1.7.0
maven-antrun-plugin must depend on ant v1.7.0 - Key: MANTRUN-93 URL: http://jira.codehaus.org/browse/MANTRUN-93 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Graham Leggett Priority: Critical The most recent version of maven-antrun-plugin (1.1) has a hard dependency on ant v1.6.5. A version of maven-antrun-plugin needs to be released depending on ant v1.7.0, so that ant v1.7.0 features are available to maven users. This issue has been raised before (MNG-3083), though no clear reason was given for marking this as "wont fix". -- 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: (MARTIFACT-17) Add generics details to collections
[ http://jira.codehaus.org/browse/MARTIFACT-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reopened MARTIFACT-17: --- Reopening for another patch > Add generics details to collections > --- > > Key: MARTIFACT-17 > URL: http://jira.codehaus.org/browse/MARTIFACT-17 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Jason Dillon >Assignee: Jason van Zyl > Attachments: MARTIFACT-17-2.diff, MARTIFACT-17.diff > > > Also adds some use of java5 for bits and such. -- 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: (MARTIFACT-17) Add generics details to collections
[ http://jira.codehaus.org/browse/MARTIFACT-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated MARTIFACT-17: -- Attachment: MARTIFACT-17-3.diff Adding *-3 patch which does more of the same for some stuff I missed before. I think after this, only significant untyped collections are related to managed versions map, still not sure what types that guy holds. Also some tests still need to be updated with types, but I'm not too concerned about those atm. > Add generics details to collections > --- > > Key: MARTIFACT-17 > URL: http://jira.codehaus.org/browse/MARTIFACT-17 > Project: Maven Artifact > Issue Type: Improvement >Reporter: Jason Dillon >Assignee: Jason van Zyl > Attachments: MARTIFACT-17-2.diff, MARTIFACT-17-3.diff, > MARTIFACT-17.diff > > > Also adds some use of java5 for bits and such. -- 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: (MEAR-51) Exploded (unpacked) ear
[ http://jira.codehaus.org/browse/MEAR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135900#action_135900 ] Stephane Nicoll commented on MEAR-51: - I have zero time for this at the moment, sorry. > Exploded (unpacked) ear > --- > > Key: MEAR-51 > URL: http://jira.codehaus.org/browse/MEAR-51 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Maurice Zeijen >Assignee: Stephane Nicoll > > It is great that you can unpack the modules within the ear. But it would be > also be great if the ear itself could also be delivered unpacked. At this > moment I could use the working directory but it doesn't get the Manifest 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: (MRELEASE-285) Unresolved test-jar dependency during release
[ http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened MRELEASE-285: > Unresolved test-jar dependency during release > - > > Key: MRELEASE-285 > URL: http://jira.codehaus.org/browse/MRELEASE-285 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Rod Coffin > Fix For: 2.0 > > Attachments: example.jar > > > I have a multi-module project where one project produces a normal jar and a > test-jar > (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). > Another submodule has a test scoped dependency on the test-jar from the first > submodule. For example, this is the structure and produced artifacts for a > small sample (attached) I built to reproduce this behavior: > release-test-jar (parent project) > project-with-test-jar (submodule) > => project-with-test-jar-1.0.jar > => project-with-test-jar-1.0-tests.jar > project-using-test-jar (submodule) > => project-user-test-jar-1.0.jar > When I run a 'clean install' the build succeeds. However, when I run a > 'release:prepare' the build fails with the following error: > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.rfc:project-using-test-jar:jar:1.1 > 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 > -- > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > Judging from the stack trace this problem seems to occu
[jira] Created: (ARCHETYPE-176) Cannot use "-DarchetypeRepository" if you have * in your settings.xml file
Cannot use "-DarchetypeRepository" if you have * in your settings.xml file Key: ARCHETYPE-176 URL: http://jira.codehaus.org/browse/ARCHETYPE-176 Project: Maven Archetype Issue Type: Bug Components: Creator, Generator Affects Versions: 2.0-alpha-3 Environment: Java 6 Maven 2.0.9 Reporter: Jeff Campbell I'm using the following command to create a new project from a custom archetype from a 3rd party Maven repo (only the relevant portion of the command is below): mvn archetype:generate -DarchetypeRepository=http://somehost.com/mvnrepo .(other -D params for thecustom archetype)... But, because I have the following in my settings.xml file, I cannot access the repository specified by the "-DarchetypeRepository": my.nexus Nexus Mirror http://somehost:8081/nexus/content/groups/public * Work around(s): 1. Don't use section all together in the settings.xml file. 2. List every single possible maven repo site mirror, in Nexus, that I can possibly think of to hopefully cover every possible custom archetype that will ever be used? (yikes!) -- 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: (MRELEASE-221) XML header missing in modified POM after release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MRELEASE-221. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.0-beta-8 Fixed in [r659603|http://svn.apache.org/viewvc?view=rev&revision=659603]. > XML header missing in modified POM after release:prepare > > > Key: MRELEASE-221 > URL: http://jira.codehaus.org/browse/MRELEASE-221 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Windows XP, CVSNT, Eclipse >Reporter: Alain Coetmeur >Assignee: Benjamin Bentmann > Fix For: 2.0-beta-8 > > > When release plugin modifies the POM to prepare a new release, > the new file does not containt the XML header > > it cause problems with XML editors who ignore the encoding and breaks all > unusual characters. > some XML tools also don't accept XML files without headers... -- 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: (MRELEASE-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MRELEASE-255. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.0-beta-8 Fixed in [r659603|http://svn.apache.org/viewvc?view=rev&revision=659603]. bq. A very simple approach would be to use an xslt stylesheet for this: it can match on the elements to change and just copy everything else. This seems like a major rewrite of the plugin. If you would go for it, we would be happy to review it ;-) > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny >Assignee: Benjamin Bentmann > Fix For: 2.0-beta-8 > > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-223) Generated pom.xml has invalid chars (does not correctly handle xml entities)
[
http://jira.codehaus.org/browse/MRELEASE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MRELEASE-223.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.0-beta-8
This is basically fixed by MRELEASE-87, i.e. the POM is now written using the
encoding given by the XML declaration.
As for the entities themselves: These will keep to be expanded, I see no
(feasible) way of preserving them, also considering that they have little use:
simply specify your desired charset in the XML declaration and edit the POM
right away.
> Generated pom.xml has invalid chars (does not correctly handle xml entities)
>
>
> Key: MRELEASE-223
> URL: http://jira.codehaus.org/browse/MRELEASE-223
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Stefano Bagnara
>Assignee: Benjamin Bentmann
> Fix For: 2.0-beta-8
>
>
> In our main pom we have this entry:
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
> in the resulting pom.xml the entity is converted to the real value, and the
> next time I try to use the pom it results in invalid output.
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
--
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: (MPH-41) help:effective-pom should optionally output an XML document wihout the non-XML header and footer
help:effective-pom should optionally output an XML document wihout the non-XML header and footer Key: MPH-41 URL: http://jira.codehaus.org/browse/MPH-41 Project: Maven 2.x Help Plugin Issue Type: Improvement Reporter: Ben Tomasini I am looking to read in the pom with an ant script using xmlproperty after running mvn -Doutput=mypom.xml help:effective-pom. This would be easier if the output file was simply XML without the comment header and footer. -- 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: (MRELEASE-201) Deployed POM is not valid XML
[ http://jira.codehaus.org/browse/MRELEASE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MRELEASE-201. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.0-beta-8 Fixed by MRELEASE-87. While the entities are still expanded by the Release Plugin, they are now properly encoded as given by the XML declaration (which is kept now). > Deployed POM is not valid XML > - > > Key: MRELEASE-201 > URL: http://jira.codehaus.org/browse/MRELEASE-201 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Joerg Schaible >Assignee: Benjamin Bentmann > Fix For: 2.0-beta-8 > > Attachments: MNG-2362.zip > > > If the POM has utf-8 encoding and you make usage of entities to support > extended characters, these characters are no longer encoded as entities in > the repository (well, the effect is already visible in > target/effective-pom.xml). This is not a rule of general, POMs with packaging > "pom" are installed and deployed correctly. > Multi module example. The attached archive contains a parent POM and a POM > for a jar. Both UTF-8 encoded POMs contain a developer with a name using an > entitiy. Releasing the POMs they are written with the expanded entitiy making > the XML invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-223) Generated pom.xml has invalid chars (does not correctly handle xml entities)
[
http://jira.codehaus.org/browse/MRELEASE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135953#action_135953
]
Stefano Bagnara commented on MRELEASE-223:
--
I'm not sure I understand the "specify your desired charset in the XML
declartion" suggestion:
How can I use chinese and sweden chars to specify the name of a sweden
committer and a chinese committer working on the project team ?
> Generated pom.xml has invalid chars (does not correctly handle xml entities)
>
>
> Key: MRELEASE-223
> URL: http://jira.codehaus.org/browse/MRELEASE-223
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Stefano Bagnara
>Assignee: Benjamin Bentmann
> Fix For: 2.0-beta-8
>
>
> In our main pom we have this entry:
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
> in the resulting pom.xml the entity is converted to the real value, and the
> next time I try to use the pom it results in invalid output.
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-223) Generated pom.xml has invalid chars (does not correctly handle xml entities)
[
http://jira.codehaus.org/browse/MRELEASE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135954#action_135954
]
Benjamin Bentmann commented on MRELEASE-223:
You would use UTF-8 as the encoding since it can handle quite any character
around. The rest is merely a matter of your text editor helping to type in the
characters you need.
> Generated pom.xml has invalid chars (does not correctly handle xml entities)
>
>
> Key: MRELEASE-223
> URL: http://jira.codehaus.org/browse/MRELEASE-223
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Stefano Bagnara
>Assignee: Benjamin Bentmann
> Fix For: 2.0-beta-8
>
>
> In our main pom we have this entry:
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
> in the resulting pom.xml the entity is converted to the real value, and the
> next time I try to use the pom it results in invalid output.
> {code:xml}
>
> hilmer
> Søren Hilmer
> sh at widetrail.dk
>
>
> Developer
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-245) Manifest configuration does not work properly
[ http://jira.codehaus.org/browse/MASSEMBLY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135957#action_135957 ] Ying Dong commented on MASSEMBLY-245: - I have the same issue. My config is as simple as add main class to the jar taken from this plugin's docs. Now I have to use jar plugin to do it. This issue has not got any response of the committer for so long. Wonder whether this plugin is actively developed or not. > Manifest configuration does not work properly > - > > Key: MASSEMBLY-245 > URL: http://jira.codehaus.org/browse/MASSEMBLY-245 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: XP >Reporter: David Hoffer > > The documentation at > http://maven.apache.org/plugins/maven-assembly-plugin/usage.html > states..."the Assembly Plugin supports configuration of an element > which is identical to that supported by the maven-jar-plugin" > However when I add a manifestEntries section just like I have in my > maven-jar-plugin configuration, it is ignored by the assembly plugin. The > manifest section works but not manifestEntries. > I need both sections to work as documented. -- 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-345) Keep comments in rewritten elements
Keep comments in rewritten elements
---
Key: MRELEASE-345
URL: http://jira.codehaus.org/browse/MRELEASE-345
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-7
Reporter: Benjamin Bentmann
Priority: Minor
Something like
{code:xml}
1.0-SNAPSHOT
{code}
will be rewritten as
{code:xml}
1.0
{code}
Though the comment could be placed elsewhere, it should be kept.
--
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: (MRELEASE-345) Keep comments in rewritten elements
[
http://jira.codehaus.org/browse/MRELEASE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MRELEASE-345.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.0-beta-8
Done in [r659639|http://svn.apache.org/viewvc?view=rev&revision=659639].
> Keep comments in rewritten elements
> ---
>
> Key: MRELEASE-345
> URL: http://jira.codehaus.org/browse/MRELEASE-345
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.0-beta-7
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.0-beta-8
>
>
> Something like
> {code:xml}
>
> 1.0-SNAPSHOT
>
> {code}
> will be rewritten as
> {code:xml}
> 1.0
> {code}
> Though the comment could be placed elsewhere, it should be kept.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-368. Resolution: Fixed Done. > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-374) maven-scm-providers-git is missing some testdata
[ http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135967#action_135967 ] Emmanuel Venisse commented on SCM-374: -- All git diff test resources files are missing > maven-scm-providers-git is missing some testdata > > > Key: SCM-374 > URL: http://jira.codehaus.org/browse/SCM-374 > Project: Maven SCM > Issue Type: Bug >Affects Versions: 1.1 > Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 >Reporter: mark struberg >Assignee: Jason van Zyl > Fix For: 1.1 > > Attachments: maven-scm-providers-git-testdata.patch > > > It seems that something has gone missing by moving the > maven-scm-providers-git plugin from git to SVN. > I checked out the SVN version and compared it to my git repo. > It seems that the test/resource/git/ ... /*.log files have been ignored. > This files contain the testdata for testing the various commandline output > consumers for the git executable. > The appending patch does contain all missing files plus a small change in the > way the base command is constructed. > Tests and TCK successfully passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2739) Repository entries are not validated and NPE will occur
[ http://jira.codehaus.org/browse/MNG-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2739. --- Resolution: Fixed Fix Version/s: 2.1-alpha-1 added logic to ProjectUtils and MavenTools implementations to validate that repo ID and URL are present before constructing an ArtifactRepository instance. > Repository entries are not validated and NPE will occur > --- > > Key: MNG-2739 > URL: http://jira.codehaus.org/browse/MNG-2739 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Jason van Zyl >Assignee: John Casey > Fix For: 2.0.10, 2.1-alpha-1 > > > Using something like the following has no id and an incorrect file url: > > cbuilds > > > > /Users/jvanzyl/js/org/codehaus/mojo/trunk/mojo/mojo-sandbox/c-builds/test-cpkg/m2-repo > > > > java.lang.NullPointerException > at > org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:239) > at java.util.HashMap.hash(HashMap.java:264) > at java.util.HashMap.put(HashMap.java:382) > at java.util.HashSet.add(HashSet.java:194) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:665) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135977#action_135977 ] Olivier Lamy commented on SCM-368: -- Tested and works fine. Thanks! > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- 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-2070) rsync_ssh request for caelum-stella.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cauê Haucke Porta Guerra reopened MAVENUPLOAD-2070: --- Sorry again Besides the fact that I am hosted at sourceforge, my groupId is br.com.caelum.stella (there is some examples at maven site that showed it should be net.sf.myprojectname. so, my line is "br.com.caelum.stella","[EMAIL PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, Thanks > rsync_ssh request for caelum-stella.sourceforge.net > --- > > Key: MAVENUPLOAD-2070 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2070 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Cauê Haucke Porta Guerra >Assignee: Carlos Sanchez > > "net.sf.caelum-stella","[EMAIL > PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/m2repo","rsync_ssh","Caue > Guerra","[EMAIL PROTECTED]",, > Project page generated by maven hosted at project domain: > http://stella.caelum.com.br/dev/team-list.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] Reopened: (MAVENUPLOAD-2071) rsync_ssh request for seleniumdsl.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cauê Haucke Porta Guerra reopened MAVENUPLOAD-2071: --- Sorry again Besides the fact that I am hosted at sourceforge, my groupId is br.com.caelum.seleniumdsl (there is some examples at maven site that showed it should be net.sf.myprojectname. so, my line is "br.com.caelum.seleniumdsl","[EMAIL PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/maven","rsync_ssh","Caue Guerra","[EMAIL PROTECTED]",, Thanks > rsync_ssh request for seleniumdsl.sourceforge.net > - > > Key: MAVENUPLOAD-2071 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2071 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Cauê Haucke Porta Guerra >Assignee: Carlos Sanchez > > "net.sf.seleniumdsl","[EMAIL > PROTECTED]:/home/groups/s/se/seleniumdsl/htdocs/m2repo","rsync_ssh","Caue > Guerra","[EMAIL PROTECTED]",, > Project page generated by maven hosted at project domain: > http://seleniumdsl.sourceforge.net/team-list.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
