[jira] Commented: (MJAR-66) Maven fails to include generated resources
[ http://jira.codehaus.org/browse/MJAR-66?page=comments#action_84698 ]
Baerrach bonDierne commented on MJAR-66:
I haven't spent any time looking into it but I would suspect that because on a
clean the resource directory
{noformat}
target/generated-sources/axistools/java2wsdl
{noformat}
does not exist that it is not included in the project model.
The second run works as expected because the directory was created on the first
run.
Why isn't the axistools-maven-plugin programatically adding in additional
resources so the user doesn't need to modify their pom?
> Maven fails to include generated resources
> --
>
> Key: MJAR-66
> URL: http://jira.codehaus.org/browse/MJAR-66
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Linux (not tested on windows)
>Reporter: Leszek Ciesielski
> Attachments: ConfigurationServerAPI.tar.gz
>
>
> My project is generating a wsdl with axistools plugin. When maven is run with
> mvn clean install (or after a checkout), the wsdl is not packaged into the
> jar, although it is present when the jar is generated and included in
> resources. On second run (mvn install) the wsdl file, is, as expected,
> included.
> A test project showing this behaviour is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-128) SCM properties being replaced during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-128?page=comments#action_83880 ]
Baerrach bonDierne commented on MRELEASE-128:
-
I'm experiencing the same problem but with ${user.name}
{noformat}
scm:cvs:pserver:[EMAIL PROTECTED]:/cvs/CVS_ROOT:PROJECT_DIR
{noformat}
where the tagged release value is correct but the transformed version for the
next snapshot is incorrect as $[user.name}
has been expanded to be the current users name.
This doesn't look like it is fixed by reading the patch attached to
MRELEASE-114.
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
> Assigned To: Jason van Zyl
> Fix For: 2.0-beta-5
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
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-187) error message "cvs server: pom.xml is locally modified" when using windows
[ http://jira.codehaus.org/browse/MRELEASE-187?page=all ] Baerrach bonDierne closed MRELEASE-187. --- Resolution: Duplicate MRELEASE-94 > error message "cvs server: pom.xml is locally modified" when using windows > -- > > Key: MRELEASE-187 > URL: http://jira.codehaus.org/browse/MRELEASE-187 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Windows XP >Reporter: Baerrach bonDierne > > For some reason the root pom.xml file is not being checked in. > I believe this is a windows timing issue, probably due to the the even > millisecond resolution. > I hope to have time at some stage to create a test case for this to show the > problem. > Workaround: > Manually check it in and the restart the release. > e.g. (You can cut and paste the most of the details from the console output) > cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/cvs/CVS_ROOT -q commit -R -m > "[maven-release-plugin] prepare release RELEASE_TAG" pom.xml > Note: > After the failure to checkin occurs and the release:perform is restarted, it > will fail because the released versions of the artifacts do not exist. The > workaround to this is to run "mvn install" (it is wise to run "mvn site" to > ensure there are no "gotchas" here for when you attempt to perform the > 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] Commented: (MRELEASE-188) release:perform is not updating some modules to the next version identifier correctly.
[ http://jira.codehaus.org/browse/MRELEASE-188?page=comments#action_83779 ]
Baerrach bonDierne commented on MRELEASE-188:
-
After modifying my pom to look like:
{noformat}
abc
abc-abcdefgh-abcdefghijklm-ancdefg
0.4-SNAPSHOT
ejb
{noformat}
the version was correctly updated to have the -SNAPSHOT removed.
> release:perform is not updating some modules to the next version identifier
> correctly.
> --
>
> Key: MRELEASE-188
> URL: http://jira.codehaus.org/browse/MRELEASE-188
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>
> For some reason the release:prepare is not correctly removing -SNAPSHOT from
> some module files, most of them have been correctly transformed only one has
> not been.
> I am manually double checking whether the tagged version of the file has been
> modified correctly prior to running release:perform.
> I hope to put together a test case for this problem. I'm not sure why it is
> occurring and without a test case it will be impossible for someone else to
> resolve.
> Work around:
> If there is an error, copy the pom.xml to a safe place.
> From the CVS History get the contents of the tagged version for release and
> then make the necessary modifications and commit them. The file then needs to
> be retagged to use the release tag.
> Now copy back the contents of the saved pom.xml, which contains the version
> id's updated to the next snapshot identifiers. Make sure to fix the same
> versions that had problems as above to the correct new snapshot value.
--
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-3) release:prepare should not require multimodule artifacts to be in the local repository
[ http://jira.codehaus.org/browse/MRELEASE-3?page=comments#action_83778 ] Baerrach bonDierne commented on MRELEASE-3: --- MRELEASE-182 (release:prepare preparationGoals should be "clean verify") may be related to this issue. I disagree with the recommendation in MRELEASE-182 as I believe that "install" needs to happen as part of release:prepare. The scenario is this: * module projects are executed with existing default goals (clean integration-test) * deployment module gets executed which has an assembly which attempts to collect all the previous module artifact's and place them into a distributable archive. The deployment module will fail since none of the artifacts are available in the local repository. According to http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html: "package" < "integration-test" < "install" and hence the deployment module will cause failures in the release process. My workaround is to manually run mvn install when the release process fails and then to restart the release. > release:prepare should not require multimodule artifacts to be in the local > repository > -- > > Key: MRELEASE-3 > URL: http://jira.codehaus.org/browse/MRELEASE-3 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: John Casey > > Currently, if you try to run release:prepare on a multimodule project after > removing any of that build's artifacts from the local repository, it will > fail. Investigate why release:prepare needs the multimodule artifacts > installed in the local repository before it can succeed. > To reproduce, comment the following line in it2002/test.sh: > mvn clean install > NOTE: This may have to do with the version resolution code, which is used to > resolve SNAPSHOT versions. -- 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-182) release:prepare preparationGoals should be "clean verify"
[ http://jira.codehaus.org/browse/MRELEASE-182?page=comments#action_83776 ] Baerrach bonDierne commented on MRELEASE-182: - MRELEASE-3 (release:prepare should not require multimodule artifacts to be in the local repository) may include this issue. > release:prepare preparationGoals should be "clean verify" > - > > Key: MRELEASE-182 > URL: http://jira.codehaus.org/browse/MRELEASE-182 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Mark Hobson >Priority: Minor > Attachments: patch.txt > > > The preparationGoals default value for release:prepare is currently "clean > integration-test", which misses out the post-integration-test phase that > cleans up after the testing, thus the default value should be "clean verify". > This also encompasses any further verification deemed necessary by the > project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=comments#action_83775 ] Baerrach bonDierne commented on MRELEASE-145: - modules are a convenience so that you can issue the one maven command and have it applied to all module projects. Once you use a module, you are saying "all these files must be released together". If this is not correct, then you should not be using a module, just use a regular project with dependencies. Therefore when you attempt to release your parent project it must be a snapshot version. Otherwise you would be overwriting an existing deployed version with the version you are about to release and this does not make sense. > release:prepare requires all modules to be SNAPSHOTS > > > Key: MRELEASE-145 > URL: http://jira.codehaus.org/browse/MRELEASE-145 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Jörg Hohwiller > > The biggest need for the maven-release-plugin is in complex projects with a > lot of modules (that may again have modules). If I do not get it wrong, the > current released version forces all modules to be snapshots and releases them > individually. This is completely useless in my situation because in the end > this forces me to release alle modules together for every change that is to > be released and more or less causes that all modules have the same version > number. When I call mvn replease:prepare on my toplevel project this is no > snapshot, it fails with this error: > The project : isn't a snapshot (). > I would expect release:prepare to leave non SNAPSHOT modules untouched (and > only verify that they do not have SNAPSHOT dependencies, what should never be > the case if the version is no snapshot). > All reactor projects that have a "-SNAPHSOT" version should be released and > theier project-internal dependencies should also be set to the acording > released version (and later be set to the new SNAPSHOT). > Additionally I want to have the complete project to be tagged as a whole > instead of each module. This could potentially be configureable (especially > which directory is actually tagged, e.g. if the toplevel project is not in > trunk/ but somewhere deeper say trunk/develop because other directories in > trunk are huge but do not need to be checked out by every developer but need > to be tagged). > I personally think that the best flexibility and final freedom would be to > split off the release:prepare goal into 3 goals: > -create release version(s) > -create tag(s) > -update to snapshot version(s) > These goals could be used individually and one could add some custom steps or > replace one with something else. > For creating the snapshot versions there is also the problem, that you do not > know right away which project will be modified when in the future. The > coolest thing would be if this would happen automatically when the first > change is commited to the module. But this is of cause not praticable in > reality (maybe if all commits would be done with maven). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-188) release:perform is not updating some modules to the next version identifier correctly.
[ http://jira.codehaus.org/browse/MRELEASE-188?page=comments#action_83774 ]
Baerrach bonDierne commented on MRELEASE-188:
-
I think it may be because of the formatting of the pom...
Here is a copy of my pom with names changed to protect the guilty...
{noformat}
abc
abc-abcdefgh-abcdefghijklm-ancdefg
0.4-SNAPSHOT
ejb
abc
abc-abcde-abcdefgh
0.4
{noformat}
The one that is multi-line is the one that always appears to have the problem.
> release:perform is not updating some modules to the next version identifier
> correctly.
> --
>
> Key: MRELEASE-188
> URL: http://jira.codehaus.org/browse/MRELEASE-188
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>
> For some reason the release:prepare is not correctly removing -SNAPSHOT from
> some module files, most of them have been correctly transformed only one has
> not been.
> I am manually double checking whether the tagged version of the file has been
> modified correctly prior to running release:perform.
> I hope to put together a test case for this problem. I'm not sure why it is
> occurring and without a test case it will be impossible for someone else to
> resolve.
> Work around:
> If there is an error, copy the pom.xml to a safe place.
> From the CVS History get the contents of the tagged version for release and
> then make the necessary modifications and commit them. The file then needs to
> be retagged to use the release tag.
> Now copy back the contents of the saved pom.xml, which contains the version
> id's updated to the next snapshot identifiers. Make sure to fix the same
> versions that had problems as above to the correct new snapshot value.
--
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-188) release:perform is not updating some modules to the next version identifier correctly.
release:perform is not updating some modules to the next version identifier correctly. -- Key: MRELEASE-188 URL: http://jira.codehaus.org/browse/MRELEASE-188 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Baerrach bonDierne For some reason the release:prepare is not correctly removing -SNAPSHOT from some module files, most of them have been correctly transformed only one has not been. I am manually double checking whether the tagged version of the file has been modified correctly prior to running release:perform. I hope to put together a test case for this problem. I'm not sure why it is occurring and without a test case it will be impossible for someone else to resolve. Work around: If there is an error, copy the pom.xml to a safe place. >From the CVS History get the contents of the tagged version for release and >then make the necessary modifications and commit them. The file then needs to >be retagged to use the release tag. Now copy back the contents of the saved pom.xml, which contains the version id's updated to the next snapshot identifiers. Make sure to fix the same versions that had problems as above to the correct new snapshot value. -- 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-187) error message "cvs server: pom.xml is locally modified" when using windows
error message "cvs server: pom.xml is locally modified" when using windows -- Key: MRELEASE-187 URL: http://jira.codehaus.org/browse/MRELEASE-187 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Windows XP Reporter: Baerrach bonDierne For some reason the root pom.xml file is not being checked in. I believe this is a windows timing issue, probably due to the the even millisecond resolution. I hope to have time at some stage to create a test case for this to show the problem. Workaround: Manually check it in and the restart the release. e.g. (You can cut and paste the most of the details from the console output) cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/cvs/CVS_ROOT -q commit -R -m "[maven-release-plugin] prepare release RELEASE_TAG" pom.xml Note: After the failure to checkin occurs and the release:perform is restarted, it will fail because the released versions of the artifacts do not exist. The workaround to this is to run "mvn install" (it is wise to run "mvn site" to ensure there are no "gotchas" here for when you attempt to perform the 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] Commented: (MASSEMBLY-170) ManifestCreationFinalizer does not close File handles causing tests to fail
[ http://jira.codehaus.org/browse/MASSEMBLY-170?page=comments#action_83413 ] Baerrach bonDierne commented on MASSEMBLY-170: -- I normally honour the formatting, if I am not it probably means the eclipse formatting rules are out of date. > ManifestCreationFinalizer does not close File handles causing tests to fail > --- > > Key: MASSEMBLY-170 > URL: http://jira.codehaus.org/browse/MASSEMBLY-170 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP >Reporter: Baerrach bonDierne > Assigned To: Brett Porter > Fix For: 2.2 > > Attachments: MASSEMBLY-170-patch.txt > > > finalizeArchiveCreation creates a FileReader but does not call close, which > causes the unit tests to fail because the manifest can not be deleted. > Patches attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2697) maven-plugin-testing-tools: ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation fails on Windows
[ http://jira.codehaus.org/browse/MNG-2697?page=comments#action_83412 ] Baerrach bonDierne commented on MNG-2697: - Unit tests based on Files would be better than string based ones, especially since the raw type being tested is a File. If the unit tests work on a Windows box I won't complain, it's just File based assertions would be more robust. > maven-plugin-testing-tools: > ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation > fails on Windows > - > > Key: MNG-2697 > URL: http://jira.codehaus.org/browse/MNG-2697 > Project: Maven 2 > Issue Type: Bug > Components: Sandbox > Environment: Windows XP >Reporter: Baerrach bonDierne > Assigned To: John Casey >Priority: Critical > Attachments: MNG-2697-patch.txt > > > File.getPath() can not be used as a comparison with a string because of the / > vs \ problem. > Attached patch, replaces this check with one against 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: (MJAVADOC-108) proxy support for plugin not complete enough
[ http://jira.codehaus.org/browse/MJAVADOC-108?page=comments#action_83207 ]
Baerrach bonDierne commented on MJAVADOC-108:
-
I would have thought this was easy, but since this plugin forks off the javadoc
command and there appears to be no way to specify username/password
authentication details via properties on the command line, I guess this issue
is stuck.
Downloading the java source to see if there is an undocumented feature
somewhere.
> proxy support for plugin not complete enough
>
>
> Key: MJAVADOC-108
> URL: http://jira.codehaus.org/browse/MJAVADOC-108
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Baerrach bonDierne
>
> AbstractJavadocMojo.java supports
> * @parameter expression="${proxyHost}"
> default-value="${settings.activeProxy.host}"
> * @parameter expression="${proxyPort}"
> default-value="${settings.activeProxy.port}"
> but does not include the full capabilities of settings.xml
> This needs extending.
> line 981:
> {code:language=java}
> if ( StringUtils.isNotEmpty( proxyHost ) && proxyPort > 0 )
> {
> cmd.createArgument().setValue( "-J-DproxyHost=" + proxyHost );
> cmd.createArgument().setValue( "-J-DproxyPort=" + proxyPort );
> }
> {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: (MJAVADOC-108) proxy support for plugin not complete enough
proxy support for plugin not complete enough
Key: MJAVADOC-108
URL: http://jira.codehaus.org/browse/MJAVADOC-108
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Baerrach bonDierne
AbstractJavadocMojo.java supports
* @parameter expression="${proxyHost}"
default-value="${settings.activeProxy.host}"
* @parameter expression="${proxyPort}"
default-value="${settings.activeProxy.port}"
but does not include the full capabilities of settings.xml
This needs extending.
line 981:
{code:language=java}
if ( StringUtils.isNotEmpty( proxyHost ) && proxyPort > 0 )
{
cmd.createArgument().setValue( "-J-DproxyHost=" + proxyHost );
cmd.createArgument().setValue( "-J-DproxyPort=" + proxyPort );
}
{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: (MECLIPSE-192) no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin
[ http://jira.codehaus.org/browse/MECLIPSE-192?page=comments#action_83084 ] Baerrach bonDierne commented on MECLIPSE-192: - Mangling occurs in ProjecTool.packageProjectArtifact(). This mangles the pom info to include the test version and then run BuiltTool.executeMaven() with the "package" phase to create the test jar. The side effect of this is to put test artifacts into D:\ide\workspace\maven\maven-eclipse-plugin\target\classes which is not good. I can see no work around for this situation except to use a different mechanism for testing. > no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin > --- > > Key: MECLIPSE-192 > URL: http://jira.codehaus.org/browse/MECLIPSE-192 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Emmanuel Lécharny >Priority: Blocker > Attachments: maven-eclipse-plugin-bug.txt, > maven-metadata-apache.snapshots.xml, maven-metadata-central.xml, > maven-metadata-snapshots.xml > > > When trying to eclipsify Apache Directory Server project (mvn install works > fine), I get an error : > ... > Reason: Unable to download the artifact from any repository > org.apache.maven.plugins:maven-eclipse-plugin:pom:test > ... > It seems that a bad snapshot version of the plugin ahas been pushed into some > repos, and it breaks the build. > We have tried to find out what was the origin of the problem with Kenney, > unlucky so far :) > I have tried with the last 2.0.5 SNAPSHOT, same result. > I also tried to remove completely the repo, no difference, except the 5 > minutes dowloads ... > Attached : the debug trace -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-192) no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin
[ http://jira.codehaus.org/browse/MECLIPSE-192?page=comments#action_83077 ]
Baerrach bonDierne commented on MECLIPSE-192:
-
Ok.
In AbstractJarMojo.java line 152:
{code:language=java}
archiver.getArchiver().addDirectory( contentDirectory, DEFAULT_INCLUDES,
DEFAULT_EXCLUDES );
{code}
where
contentDirectory =
D:\ide\workspace\maven\maven-eclipse-plugin\target\classes
This directory contains the mangled plugin.xml
D:\ide\workspace\maven\maven-eclipse-plugin\target\classes\META-INF\maven\plugin.xml
Now to work out who mangles it and how to fix it.
> no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin
> ---
>
> Key: MECLIPSE-192
> URL: http://jira.codehaus.org/browse/MECLIPSE-192
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Emmanuel Lécharny
>Priority: Blocker
> Attachments: maven-eclipse-plugin-bug.txt,
> maven-metadata-apache.snapshots.xml, maven-metadata-central.xml,
> maven-metadata-snapshots.xml
>
>
> When trying to eclipsify Apache Directory Server project (mvn install works
> fine), I get an error :
> ...
> Reason: Unable to download the artifact from any repository
> org.apache.maven.plugins:maven-eclipse-plugin:pom:test
> ...
> It seems that a bad snapshot version of the plugin ahas been pushed into some
> repos, and it breaks the build.
> We have tried to find out what was the origin of the problem with Kenney,
> unlucky so far :)
> I have tried with the last 2.0.5 SNAPSHOT, same result.
> I also tried to remove completely the repo, no difference, except the 5
> minutes dowloads ...
> Attached : the debug trace
--
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-2105) Enable remote debugging command line option (+ docs)
[ http://jira.codehaus.org/browse/MNG-2105?page=comments#action_83017 ] Baerrach bonDierne commented on MNG-2105: - For now http://docs.codehaus.org/display/MAVENUSER/Dealing+with+Eclipse-based+IDE contains notes. > Enable remote debugging command line option (+ docs) > > > Key: MNG-2105 > URL: http://jira.codehaus.org/browse/MNG-2105 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line >Affects Versions: 2.0.2 >Reporter: Geoffrey De Smet >Priority: Minor > Fix For: 2.2 > > > [dev list mailing reference: Debugging maven with breakpoints feed-back: > --jdwp + docs] > Problem: > Currently its hard to enable remote debugging for a remote debugger of your > IDE. > Basically you need to set MAVEN_OPTS something like: > export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000" > mvn ... > and unset it again. > Solution: > 1) Make it easier, choices: > A) Provide a command line option to do this (--debug is already taken for > debug logging), choices: > a) mvn --jdpa > b) mvn --jdwp > B) Provide a different script: mvnDebug > to avoid parsing command line arguments in bat and shell > C) Find a generic way to give options on the command, like -mx etc to the > java process, possibly by namespacing them? > 2) Document it in mvn --help > 3) Document it on > http://maven.apache.org/guides/development/guide-m2-development.html > like so (APT): > Debugging with breakpoints > You can attach a remote debugger of your IDE to the maven process. > This will allow you to set breakpoints (line, exception, ...). > Start maven in debugger mode on port 8000: > +-- > mvn ??? install > +-- > If you want to change any of the debugger settings, > use MAVEN_OPTS instead. > Then connect to the correct port with a remote debugger in your 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] Commented: (MECLIPSE-192) no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin
[ http://jira.codehaus.org/browse/MECLIPSE-192?page=comments#action_82929 ]
Baerrach bonDierne commented on MECLIPSE-192:
-
I am still getting this issue for the latest version on trunk, revision 488511
The culprit unit tests are these ones (I isolated them by placing excludes in
the maven-surefire-plugin configuration:
{noformat}
org/apache/maven/plugin/eclipse/EclipsePluginTest.java
org/apache/maven/plugin/eclipse/RadPluginTest.java
org/apache/maven/plugin/eclipse/EclipsePluginMasterProjectTest.java
{noformat}
They cause the META-INF\maven\plugin.xml to have an incorrect version tag.
Instead of
{noformat}
2.3-INTERNAL-r488130-pMECLIPSE-206
{noformat}
it is
{noformat}
test
{noformat}
I'm still investigating this and will provide more details later.
In the mean time, can this issue be re-opened please.
> no way to get eclipse:eclipse working since the last SNAPSHOT of the plugin
> ---
>
> Key: MECLIPSE-192
> URL: http://jira.codehaus.org/browse/MECLIPSE-192
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Emmanuel Lécharny
>Priority: Blocker
> Attachments: maven-eclipse-plugin-bug.txt,
> maven-metadata-apache.snapshots.xml, maven-metadata-central.xml,
> maven-metadata-snapshots.xml
>
>
> When trying to eclipsify Apache Directory Server project (mvn install works
> fine), I get an error :
> ...
> Reason: Unable to download the artifact from any repository
> org.apache.maven.plugins:maven-eclipse-plugin:pom:test
> ...
> It seems that a bad snapshot version of the plugin ahas been pushed into some
> repos, and it breaks the build.
> We have tried to find out what was the origin of the problem with Kenney,
> unlucky so far :)
> I have tried with the last 2.0.5 SNAPSHOT, same result.
> I also tried to remove completely the repo, no difference, except the 5
> minutes dowloads ...
> Attached : the debug trace
--
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: (MASSEMBLY-170) ManifestCreationFinalizer does not close File handles causing tests to fail
[ http://jira.codehaus.org/browse/MASSEMBLY-170?page=all ] Baerrach bonDierne updated MASSEMBLY-170: - Attachment: MASSEMBLY-170-patch.txt > ManifestCreationFinalizer does not close File handles causing tests to fail > --- > > Key: MASSEMBLY-170 > URL: http://jira.codehaus.org/browse/MASSEMBLY-170 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP >Reporter: Baerrach bonDierne > Attachments: MASSEMBLY-170-patch.txt > > > finalizeArchiveCreation creates a FileReader but does not call close, which > causes the unit tests to fail because the manifest can not be deleted. > Patches attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-170) ManifestCreationFinalizer does not close File handles causing tests to fail
ManifestCreationFinalizer does not close File handles causing tests to fail --- Key: MASSEMBLY-170 URL: http://jira.codehaus.org/browse/MASSEMBLY-170 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Windows XP Reporter: Baerrach bonDierne finalizeArchiveCreation creates a FileReader but does not call close, which causes the unit tests to fail because the manifest can not be deleted. Patches attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2705) add jar sources in repository for snapshot builds
[ http://jira.codehaus.org/browse/MNG-2705?page=comments#action_82839 ] Baerrach bonDierne commented on MNG-2705: - As per the discussion http://www.nabble.com/forum/ViewPost.jtp?post=7776225&framed=y&skin=177 this should be enabled for snapshot builds, otherwise debugging snapshots is impossible. Follow on from MNG-398 > add jar sources in repository for snapshot builds > - > > Key: MNG-2705 > URL: http://jira.codehaus.org/browse/MNG-2705 > Project: Maven 2 > Issue Type: Task >Reporter: Baerrach bonDierne > Assigned To: Brett Porter >Priority: Minor > > When using IDE like eclipse, it would be great to have dependecies sources > (optionnaly) added to repository. > This way eclipse plugin (and others) could generate a .classpath file that > set "source attachement" and allow code and javadoc consult, debuging and > inherited methods implementation with original parameters names. -- 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-2705) add jar sources in repository for snapshot builds
add jar sources in repository for snapshot builds - Key: MNG-2705 URL: http://jira.codehaus.org/browse/MNG-2705 Project: Maven 2 Issue Type: Task Reporter: Baerrach bonDierne Assigned To: Brett Porter Priority: Minor When using IDE like eclipse, it would be great to have dependecies sources (optionnaly) added to repository. This way eclipse plugin (and others) could generate a .classpath file that set "source attachement" and allow code and javadoc consult, debuging and inherited methods implementation with original parameters names. -- 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: (MASSEMBLY-166) ManifestCreationFinalizerTest fails on Windows
[ http://jira.codehaus.org/browse/MASSEMBLY-166?page=all ] Baerrach bonDierne updated MASSEMBLY-166: - Attachment: MASSEMBLY-166-patch.txt > ManifestCreationFinalizerTest fails on Windows > -- > > Key: MASSEMBLY-166 > URL: http://jira.codehaus.org/browse/MASSEMBLY-166 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP >Reporter: Baerrach bonDierne > Attachments: MASSEMBLY-166-patch.txt > > > Opening a file inside a Jar locks the file on Windows and therefore can not > be deleted as part of the tearDown(). > Patched test to workaround the issue. > // http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4823678 > ((JarURLConnection)resource.openConnection()).getJarFile().close(); > -- 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-166) ManifestCreationFinalizerTest fails on Windows
ManifestCreationFinalizerTest fails on Windows -- Key: MASSEMBLY-166 URL: http://jira.codehaus.org/browse/MASSEMBLY-166 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Windows XP Reporter: Baerrach bonDierne Attachments: MASSEMBLY-166-patch.txt Opening a file inside a Jar locks the file on Windows and therefore can not be deleted as part of the tearDown(). Patched test to workaround the issue. // http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4823678 ((JarURLConnection)resource.openConnection()).getJarFile().close(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2701) FileSetUtilsTest.operatingSystemAllowsLinking fails on windows
[ http://jira.codehaus.org/browse/MNG-2701?page=all ] Baerrach bonDierne updated MNG-2701: Attachment: MNG-2701.txt > FileSetUtilsTest.operatingSystemAllowsLinking fails on windows > -- > > Key: MNG-2701 > URL: http://jira.codehaus.org/browse/MNG-2701 > Project: Maven 2 > Issue Type: Bug > Environment: Windows XP >Reporter: Baerrach bonDierne > Attachments: MNG-2701.txt > > > operatingSystemAllowsLinking is using the system property "os.family". > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html does not > defined "os.family". > There appears to be no easy way to determine if sym links are supported and > Java doesn't seem to care. > patched unit test to attempt to invoke sym link command and assume that a > failed sym link command is because the system does not support "ln" rather > than the command failed. -- 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-2701) FileSetUtilsTest.operatingSystemAllowsLinking fails on windows
FileSetUtilsTest.operatingSystemAllowsLinking fails on windows -- Key: MNG-2701 URL: http://jira.codehaus.org/browse/MNG-2701 Project: Maven 2 Issue Type: Bug Environment: Windows XP Reporter: Baerrach bonDierne operatingSystemAllowsLinking is using the system property "os.family". http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html does not defined "os.family". There appears to be no easy way to determine if sym links are supported and Java doesn't seem to care. patched unit test to attempt to invoke sym link command and assume that a failed sym link command is because the system does not support "ln" rather than the command failed. -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=all ] Baerrach bonDierne updated MSUREFIREREP-6: -- Attachment: MSUREFIREREP-6-patch.txt Patch as requested by someone to create a "report-only" goal. Includes update to index.apt to reference the goal. Based on subversion revision 485987. Workaround until someone sorts out reactor/forked lifecycle issues. > surefire-report reruns tests > > > Key: MSUREFIREREP-6 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug > Environment: maven 2.0 >Reporter: Dirk Sturzebecher > Attachments: MSUREFIREREP-6-patch.txt > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2697) maven-plugin-testing-tools: ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation fails on Windows
[ http://jira.codehaus.org/browse/MNG-2697?page=all ] Baerrach bonDierne updated MNG-2697: Attachment: MNG-2697-patch.txt Can this issue be assigned to jdcasey please, his name appears as the author in the svn history. Thanks > maven-plugin-testing-tools: > ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation > fails on Windows > - > > Key: MNG-2697 > URL: http://jira.codehaus.org/browse/MNG-2697 > Project: Maven 2 > Issue Type: Bug > Components: Sandbox > Environment: Windows XP >Reporter: Baerrach bonDierne >Priority: Critical > Attachments: MNG-2697-patch.txt > > > File.getPath() can not be used as a comparison with a string because of the / > vs \ problem. > Attached patch, replaces this check with one against 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: (MNG-2697) maven-plugin-testing-tools: ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation fails on Windows
maven-plugin-testing-tools: ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation fails on Windows - Key: MNG-2697 URL: http://jira.codehaus.org/browse/MNG-2697 Project: Maven 2 Issue Type: Bug Components: Sandbox Environment: Windows XP Reporter: Baerrach bonDierne Priority: Critical File.getPath() can not be used as a comparison with a string because of the / vs \ problem. Attached patch, replaces this check with one against 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: (MNG-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_82415 ] Baerrach bonDierne commented on MNG-1577: - Given the long list of comments and the potential hurdles raised in them, is there any direction on the proposed solutions to the problem so far? > dependencyManagement does not work for transitive dependencies > -- > > Key: MNG-1577 > URL: http://jira.codehaus.org/browse/MNG-1577 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Joerg Schaible > Assigned To: John Casey > Fix For: 2.1 > > Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, > mng1577c.patch, mng1577d.patch, mng1577e-trunk.patch, mng1577e.patch, > mng1577trunk.patch > > > The dependencyManagement does not work for transient dependencies. The > specified version is ignored. > Use case: > Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT > and B-SNAPSHOT > Project A is child of Main and depends directly on commons-beanutils (version > inherited from Main) > Project B is child of Main and depends directly on commons-digester (version > inherited from Main) > Project C is child of Main and depends directly on A & B (versions inherited > from Main) > A is compiled and tests are run using commons-beanutils-1.7.0 > B is compiled and tests are run using commons-digester-1.6 and > commons-beanutils-1.6, since digester is dependend on this > C is compiled and tests are run using commons-beanutils-1.7.0 > Integration tests of B did not verify, that B is behaving as expected in this > scenario. B might fail with 1.7.0 and it is not even recognized. > If I add beanutils also as direct dependency to B, it works fine, but then > are transitive dependency useless. It should be possible to define at least > in the dependencyManagement, that the versions of transient dependencies also > defined in the dependencyManagement have priority. > - Jörg -- 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: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
New patch based on r471978 which does not exhibit the defect.
So the patch only includes test cases for regression purposes.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Baerrach bonDierne
> Fix For: 2.2
>
> Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt,
> MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=comments#action_79464
]
Baerrach bonDierne commented on MASSEMBLY-119:
--
Against r471978
I had some minor issues:
* pom.xml needed explicit version of 2.1 for maven-jar, for some reason this
was resolving to 2.1-SNAPSHOT and failing with unresolved method exceptions
during assembly.
{noformat}
org.apache.maven.plugins
maven-jar-plugin
2.1
{noformat}
* On windows ManifestCreationFinalizerTest fails because of the bug outlined in
the comment below.
{noformat}
URL resource = new URL( "jar:file:" + file.getAbsolutePath() +
"!/META-INF/MANIFEST.MF" );
// Fixes bug in windows for files within Jars: see
http://forum.springframework.org/archive/index.php/t-19516.html
resource.openConnection().setDefaultUseCaches( false );
BufferedReader reader = new BufferedReader( new InputStreamReader(
resource.openStream() ) );
{noformat}
But once these were resolved it works as expected.
> dir format will fail with an error because it can not install the directory
> into the repository
> ---
>
> Key: MASSEMBLY-119
> URL: http://jira.codehaus.org/browse/MASSEMBLY-119
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Baerrach bonDierne
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: MASSEMBLY-119 Format dir fails on install.zip,
> MASSEMBLY-119-patch.txt, MASSEMBLY-119-patch.txt
>
>
> See the discussion on MASSEMBLY-39 which originally created the dir format.
> I believe the dir format should never be added to the repository as it's only
> purpose is to ease the development process by providing an un-archived
> version ready for testing on disk.
> The workaround is to manually extract the archive, or to create a second
> duplicate descriptor and use that to create the directory version (do not
> bind this second one to the package phase)
> Will attach example project shortly.
> The error received is:
> [INFO] [install:install]
> [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to
> \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar
> [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to
> \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error installing artifact:
> \target\-0.0.1-SNAPSHOT-bin.dir (Acc
> ess is denied)
> When I run with -X the root cause error is:
> Caused by: java.io.FileNotFoundException:
> \target\-0.0.1-SNAPSHOT-bin.
> dir (Access is denied)
>at java.io.FileInputStream.open(Native Method)
>at java.io.FileInputStream.(FileInputStream.java:106)
>at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820)
>at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70)
--
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: (CONTINUUM-968) Tests for continuum-release fail randomly
[ http://jira.codehaus.org/browse/CONTINUUM-968?page=comments#action_79068
]
Baerrach bonDierne commented on CONTINUUM-968:
--
I'm working off HEAD (revision 470234) with a local snapshot build of
maven-release-manager.
Windows XP (no cygwin)
Trying mvn clean install from project root fails at continuum-release with the
reason that:
{noformat}
junit.framework.AssertionFailedError: Test released version
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.releaseSimpleProject(ReleaseTaskExecutorTest.java:111)
at
org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleases(ReleaseTaskExecutorTest.java:115)
{noformat}
If go into the continuum-release module and run mvn clean it will sometimes
work and sometimes fail with the same error.
Because this error is intermittent it feels like a timing issue with the
Microsoft clock not being accurate enough. If I remember rightly it is only
even milliseconds or something. This might be causing the issue with the tests.
I remember that "mvn release:prepare" had similar issues too.
> Tests for continuum-release fail randomly
> -
>
> Key: CONTINUUM-968
> URL: http://jira.codehaus.org/browse/CONTINUUM-968
> Project: Continuum
> Issue Type: Test
>Affects Versions: 1.1
> Environment: tests fail for some environments and pass for others.
> For some they fail at random
>Reporter: Philippe Faes
>Priority: Minor
> Fix For: 1.1
>
> Attachments: continuum-release.diff
>
>
> The test for continuum-release fails randomly. This is because the two test
> methods are executed in a random order (this is intended JUnit behavior), and
> the tests alter files.
> Solution is to restore files between tests (method setUp) and to force the
> order of the two tests (create one test method that calls the two other
> methods one by one).
> Patch is attached. Please verify and commit.
--
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: (CONTINUUM-968) Tests for continuum-release fail randomly
[ http://jira.codehaus.org/browse/CONTINUUM-968?page=comments#action_78993 ] Baerrach bonDierne commented on CONTINUUM-968: -- The error may be in maven-release-manager but there is no source attached when the snapshot was deployed. I've downloaded the trunk of maven-release-manager but this fails for different reasons. > Tests for continuum-release fail randomly > - > > Key: CONTINUUM-968 > URL: http://jira.codehaus.org/browse/CONTINUUM-968 > Project: Continuum > Issue Type: Test >Affects Versions: 1.1 > Environment: tests fail for some environments and pass for others. > For some they fail at random >Reporter: Philippe Faes >Priority: Minor > Fix For: 1.1 > > Attachments: continuum-release.diff > > > The test for continuum-release fails randomly. This is because the two test > methods are executed in a random order (this is intended JUnit behavior), and > the tests alter files. > Solution is to restore files between tests (method setUp) and to force the > order of the two tests (create one test method that calls the two other > methods one by one). > Patch is attached. Please verify and commit. -- 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-670) warn when local dependency scope is vetoed
[ http://jira.codehaus.org/browse/MNG-670?page=comments#action_78982 ] Baerrach bonDierne commented on MNG-670: Linked to MNG-2645 which requests better error message reporting so that warning display the cuplrit for bad scoping. > warn when local dependency scope is vetoed > -- > > Key: MNG-670 > URL: http://jira.codehaus.org/browse/MNG-670 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Brett Porter > Fix For: 2.0-beta-1 > > > currently, you might set scope = test on junit in your local POM, and it ends > up being a compile time dependency, because something you depended on > declared it that way. This is correct behaviour (avoids hiding an error), but > unintuitive when you really intended it to be test and "know better" than > your dependency did. > A big warning should be introduced here. To actually state you know better, > you must still use a dependencyManagement element. -- 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-2645) warning message for local scope test should indicate whether the problem is
warning message for local scope test should indicate whether the problem is --- Key: MNG-2645 URL: http://jira.codehaus.org/browse/MNG-2645 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Baerrach bonDierne This is the warning message you get when a pom doesn't define junit to be scoped as test (as it should) [WARNING] Artifact junit:junit:jar:3.8.1:test retains local scope 'test' overriding broader scope 'compile' given by a dependency. If this is not intended, modify or remove the local scope. The error message does not indicate where the problem originated, which would make fixing these issues up much easier. Something like: [WARNING] Artifact junit:junit:jar:3.8.1:test retains local scope 'test' overriding broader scope 'compile' given by a dependency in :::. If this is not intended, modify or remove the local 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=comments#action_75728 ] Baerrach bonDierne commented on MASSEMBLY-119: -- Sure, I have 7 days left before I go on leave for 3 weeks so I can't guarantee when I get a chance to check. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Assigned To: John Casey > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt, MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74100 ] Baerrach bonDierne commented on MJAR-28: Sorry you are right. The changes I needed to make for this are in maven-archiver in the linked issue MNG-2456 as the archiver does all the actual work, jar just invokes archiver. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74070 ] Baerrach bonDierne commented on MNG-2546: - Can you also link to your eclipse pde plugin. Some work like this is being done in the eclipse:eclipse plugin and given the small number of people wanting this specialised functionality it would be great if we could work together. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74025 ] Baerrach bonDierne commented on MJAR-28: The patch I provided does just that, for SNAPSHOTS it uses the timestamped version instead of -SNAPSHOT. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-840) jdbc2_0-stdext.jar download instructions not in README.txt
jdbc2_0-stdext.jar download instructions not in README.txt --- Key: CONTINUUM-840 URL: http://jira.codehaus.org/browse/CONTINUUM-840 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Reporter: Baerrach bonDierne Priority: Minor Attachments: patch.txt The README file does not include jdbc2_0-stdext.jar instructions. It is fairly easy to read the pom from ibiblio and work it out. (patch attached) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_72435 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
I wrote up the steps I did to roll my own:
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Mark J. Titorenko
> Assigned To: John Casey
> Fix For: 2.2
>
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=comments#action_72360 ] Baerrach bonDierne commented on MNG-2493: - When you patch it can you change the id's to codehaus.org I'm not sure what the id value should be, but maven-assembly-plugin defines it as codehaus.org. > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Assigned To: Vincent Siveton > Fix For: 2.0.5 > > Attachments: MNG-2493-patch-2.txt, MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=all ] Baerrach bonDierne updated MASSEMBLY-119: - Attachment: MASSEMBLY-119-patch.txt New patch that works with new unit test layout by John Casey. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt, MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
(patch included another patch which is now removed)
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt,
> MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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] Updated: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
New patch file working with the latest trunk code base that has created unit
tests and integration tests done by John Casey.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt, Maven
> Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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] Updated: (MNG-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=all ] Baerrach bonDierne updated MNG-2493: Attachment: MNG-2493-patch-2.txt Patch contains corrected codehaus location and also includes a repository definition (not just a plugin repo) > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Assigned To: Vincent Siveton > Fix For: 2.0.5 > > Attachments: MNG-2493-patch-2.txt, MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- 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: (MNG-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=all ] Baerrach bonDierne reopened MNG-2493: - Unfortunately the codehaus repository is at http://snapshots.repository.codehaus.org. (this is the new location for the codehaus repo after the crash) Will send in another patch. > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Assigned To: Vincent Siveton > Fix For: 2.0.5 > > Attachments: MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_72186 ]
Baerrach bonDierne commented on MJAR-28:
In MASSEMBLY-67 John Casey says
The solution here is to use an outputFileNameMapping such as this:
${artifactId}-${baseVersion}.${extension}
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming,
the plugin retains the ability to use ${version} for the timestamp-buildnumber
naming, which is useful for describing the exact library version included in
the assembly.
(This issue can be closed)
> Using the jar plugin with addClasspath and snapshots can create manifest
> classpath with incorrect jar versions
> --
>
> Key: MJAR-28
> URL: http://jira.codehaus.org/browse/MJAR-28
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Mark J. Titorenko
> Attachments: MJAR-28-patch.txt
>
>
> When the POM contains dependencies to snapshot versions of jars, and snapshot
> versions of those jars are downloaded from a remote repository, the name of
> the jar contained in the classpath added to the manifest, of the form
> artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar
> downloaded, which contains version information of the form
> artifactID-X.X-MMDD.HHmmss-V.jar.
> This does not affect snapshot versions which have been directly installed
> into a local repository and have no uploaded version within the remote
> repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar
> form.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=all ]
Baerrach bonDierne closed MNG-2456.
---
Resolution: Fixed
In MASSEMBLY-67 John Casey says
The solution here is to use an outputFileNameMapping such as this:
${artifactId}-${baseVersion}.${extension}
Using ${baseVersion} for cases where you want to preserve the -SNAPSHOT naming,
the plugin retains the ability to use ${version} for the timestamp-buildnumber
naming, which is useful for describing the exact library version included in
the assembly.
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=all ] Baerrach bonDierne updated MNG-2493: Attachment: MNG-2493-patch.txt Updated guides index to include a new file. Added a new development guide for snapshot repositories. Includes both the Maven snapshot repository at http://people.apache.org/maven-snapshot-repository and the CodeHaus snapshot repository at http://snapshots.maven.codehaus.org/maven2 > Snapshot plugin repositories should be included for reference at the Maven > site > --- > > Key: MNG-2493 > URL: http://jira.codehaus.org/browse/MNG-2493 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Reporter: Baerrach bonDierne > Attachments: MNG-2493-patch.txt > > > When developing a plugin (or patching an existing plugin), the plugin often > depends upon snapshot versions of plugins. > There is no reference material for where these snapshot plugin repositories > are located. > Luckily people respond on the list with this information, but it would help > to include it as part of the reference material on the web site. -- 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-2493) Snapshot plugin repositories should be included for reference at the Maven site
Snapshot plugin repositories should be included for reference at the Maven site --- Key: MNG-2493 URL: http://jira.codehaus.org/browse/MNG-2493 Project: Maven 2 Issue Type: Bug Components: Sites & Reporting Reporter: Baerrach bonDierne When developing a plugin (or patching an existing plugin), the plugin often depends upon snapshot versions of plugins. There is no reference material for where these snapshot plugin repositories are located. Luckily people respond on the list with this information, but it would help to include it as part of the reference material on the web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=all ]
Baerrach bonDierne updated MNG-2456:
Attachment: MNG-2456-patch.txt
Patch adds the type of the artifact to the classpath which was incorrectly left
off.
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=comments#action_71722 ]
Baerrach bonDierne commented on MNG-2456:
-
Oops. Classpath is missing file extension...
Need to update tests and repatch.
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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: (MASSEMBLY-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=all ] Baerrach bonDierne updated MASSEMBLY-130: - Attachment: MASSEMBLY-130-patch.txt Attaching again. Noticed that when I synced there was a newer index.apt. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLLY-130-patch.txt, MASSEMBLY-130-patch-2.txt, > MASSEMBLY-130-patch.txt, MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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: (MASSEMBLY-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=all ] Baerrach bonDierne updated MASSEMBLY-130: - Attachment: MASSEMBLLY-130-patch.txt Patch attaced as MASSEMBLLY-130-patch.txt (hopefully it will overwrite...) I worked out the How To's went into the example directory so have worked with that. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLLY-130-patch.txt, MASSEMBLY-130-patch-2.txt, > MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=comments#action_71126 ] Baerrach bonDierne commented on MASSEMBLY-130: -- Sure, Some files have gone missing on me like: src\site\apt\introduction.apt src\site\apt\howto.apt I'm adding them back in since I can't see what they have been replaced with. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch-2.txt, MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=comments#action_71115 ] Baerrach bonDierne commented on MASSEMBLY-130: -- You need to use the patch -p2 to apply the patches. With the latest doc changes happening on trunk applying this patch may be painful. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch-2.txt, MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_71114
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
You need to use patch -p3 to apply the patches.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=comments#action_71113 ] Baerrach bonDierne commented on MASSEMBLY-119: -- You need to use -p3 to use the patches supplied. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=comments#action_70706 ] Baerrach bonDierne commented on MASSEMBLY-130: -- It appears that using the Eclipse Team -> Create Patch command sucks. It doesn't create unified diffs very well. At least the GNU windows patch 2.5.8.6 doesn't like them. I will recreate using svn diff. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch-2.txt, MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_70705
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
It appears that using the Eclipse Team -> Create Patch command sucks.
It doesn't create unified diffs very well. At least the GNU windows patch
2.5.8.6 doesn't like them.
I will recreate using svn diff.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=comments#action_70704 ] Baerrach bonDierne commented on MASSEMBLY-119: -- It appears that using the Eclipse Team -> Create Patch command sucks. It doesn't create unified diffs very well. At least the GNU windows patch 2.5.8.6 doesn't like them. I will recreate using svn diff. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=comments#action_70686 ] Baerrach bonDierne commented on MASSEMBLY-119: -- When I was applying the patches for MASSEMBLY-119, MASSEMBLY-118, MASSEMBLY-130 locally for some reason the patching removed the includes for DefaultArtifact. I can't recall the order I applied these patches in but since the import for DefaultArtifact is in MASSEMBLY-119 I would apply that patch last. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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: (MASSEMBLY-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=all ] Baerrach bonDierne updated MASSEMBLY-130: - Attachment: MASSEMBLY-130-patch-2.txt Includes the first patch details as well as additional documentation in the how to section on using the includes/excludes elements. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch-2.txt, MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=comments#action_70680 ] Baerrach bonDierne commented on MASSEMBLY-130: -- When I tried to apply this patch I got errors because index.apt was renamed to overview.apt. I'm not sure why this is happening. Submitting patches for subversion is new to me and I was hoping Eclipse did the right thing (tm). > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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: (MCHANGELOG-38) NPE when developer section does not include an id
[ http://jira.codehaus.org/browse/MCHANGELOG-38?page=all ]
Baerrach bonDierne closed MCHANGELOG-38.
Resolution: Fixed
Fix Version/s: 2.0
Download the latest code for this plugin.
Modified the pom to include an scm section (as
org.apache.maven.plugins:maven-plugins) doesn't point to the sandbox (where
this plugin is currently located)
{noformat}
scm:svn:http://svn.apache.org/repos/asf/maven/sandbox/plugins/
scm:svn:https://svn.apache.org/repos/asf/maven/sandbox/plugins/
http://svn.apache.org/viewcvs.cgi/maven/sandbox/plugins/
{noformat}
Added in the reporting section as suggested bu Dennis
{noformat}
org.apache.maven.plugins
maven-changelog-plugin
2.0-SNAPSHOT
triple-report
changelog
dev-activity
file-activity
{noformat}
and commented out Jason's id (since his is one that appears in the reports and
is also in the developer section:
{noformat}
{noformat}
After installing the plugin and then running mvn site, I now get no npe's.
> NPE when developer section does not include an id
> -
>
> Key: MCHANGELOG-38
> URL: http://jira.codehaus.org/browse/MCHANGELOG-38
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
> Assigned To: Dennis Lundberg
>Priority: Critical
> Fix For: 2.0
>
>
> [DEBUG] Trace
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:398)
> at
> org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530)
> at
> org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541)
> at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370)
> at
> org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263)
> at
> org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218)
> at
> org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198)
> at
> org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
> This is easy to replicate, find a working "mvn site" and then remove an id
> from a developer.
> This is for plugin
> org.apache.maven.plugins
> maven-changelog-plugin
> I'd like to provide version details but this plugin isn't in my repository!
> So I am not sure how it is actually working.
> The website does't point to a repository, and I accidentally found it at
> http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins
> but this code doesn't match up with the error message.
> I couldn't find the code base from the the old codehaus repository either.
--
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: (MASSEMBLY-130) Documentation: supported formats needs updating.
[ http://jira.codehaus.org/browse/MASSEMBLY-130?page=all ] Baerrach bonDierne updated MASSEMBLY-130: - Attachment: MASSEMBLY-130-patch.txt Provides documentation updates to fix some broken links and updating the supported formats. > Documentation: supported formats needs updating. > > > Key: MASSEMBLY-130 > URL: http://jira.codehaus.org/browse/MASSEMBLY-130 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne >Priority: Minor > Attachments: MASSEMBLY-130-patch.txt > > > The documentation has drifted out of date with some of the more receent > changes. -- 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-130) Documentation: supported formats needs updating.
Documentation: supported formats needs updating. Key: MASSEMBLY-130 URL: http://jira.codehaus.org/browse/MASSEMBLY-130 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Baerrach bonDierne Priority: Minor The documentation has drifted out of date with some of the more receent changes. -- 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=all ] Baerrach bonDierne updated MASSEMBLY-119: - Attachment: MASSEMBLY-119-patch.txt This patch adds unit tests for removing the directory archiver from the attached artifacts list. > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Baerrach bonDierne > Fix For: 2.2 > > Attachments: MASSEMBLY-119 Format dir fails on install.zip, > MASSEMBLY-119-patch.txt > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Baerrach bonDierne updated MASSEMBLY-118:
-
Attachment: MASSEMBLY-118-patch.txt
Unit test with patch to fix the issue that an assembly with
includeBaseDirectory set to false fails if the outputDirectory was empty or
slash.
Removal of eclipse warnings (deleting of unused variables and import cleanups)
Cleanup of some files to conform to code format as per Maven web site.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MNG-140) refactor maven-artifact
[ http://jira.codehaus.org/browse/MNG-140?page=comments#action_70331 ] Baerrach bonDierne commented on MNG-140: This might also include common artifact naming conventions. The artifact itself should know how to generate a file name, at the moment this is duplicated across many classes and many assumptions are made about the format. maven-archiver, maven-assembly and many others fail into the category. > refactor maven-artifact > --- > > Key: MNG-140 > URL: http://jira.codehaus.org/browse/MNG-140 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.1 > > > currently, there are a few inconsistencies in the way the artifact resolution > is implemented. > ArtifactRepository objects are created from the project builder. It makes > more sense that the artifact resolver actually factory these on behalf of the > builder - currently setting any additional parameters on them requires it be > in the project, or that the project builder has knowledge of wagon. > It is also uncertain if the wagon manager is required at all and may be able > to be folded into the artifact resolver. -- 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-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_70237
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
Interestingly, it works correctly for dir format.
And I notice for both a slash and an empty outputDirectory there is an unnamed
subdirectory in the archive that contains the file (I didnt notice this before)
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_70236
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
Yes, except that outputDirectory directory of
- empty
- /
causes the file to not be added to the archive, but no warning messages.
Specifying an outputDirectory of say "docs" works fine.
I'll write some unit tests and submit a patch if needed.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Baerrach bonDierne
>Priority: Critical
> Attachments: Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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] Updated: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=all ] Baerrach bonDierne updated MJAR-28: --- Attachment: MJAR-28-patch.txt This patch includes the changes needed to support MNG-2456 and an update of the documentation to include reference to user specified classpath inclusions. It also includes a cleanup of the unit tests, moving of the unit test data from src/test/resources into src/test/unit-test-data as this was causing the build to fail by trying to compile incomplete classes in src/test/resources. Plus a cleanup of JarSignVerifyMojo to remove Eclipse problem markers > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_70228 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
I have provided refactoring, test cases and a patch to fix this bug on
MNG-2456, as it is not really a problem with the assembler.
I think the tight coupling of maven-archiver and assembler means that the use
of outputFileNameMapping in dependencySet should be deprecated as these
filenames must match.
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Mark J. Titorenko
> Fix For: 2.2
>
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=all ]
Baerrach bonDierne updated MNG-2456:
Attachment: MNG-2456-step3-fix-bug-patch.txt
Patch to fix the bug and get working unit test
(Unfortunately the patch also includes previous steps)
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=all ]
Baerrach bonDierne updated MNG-2456:
Attachment: MNG-2456-step2-add-test-cases-patch.txt
Test Cases that exercise the problems.
(Unfortunately the patch also includes previous steps)
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=all ]
Baerrach bonDierne updated MNG-2456:
Attachment: MNG-2456-step1-refactoring-patch.txt
Attached refactoring patch, with appropriate test cases, that changes Maven
Archiver to use Project.getRuntimeArtifacts instead of
Project.getRuntimeClasspathElements.
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Attachments: MNG-2456-step1-refactoring-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
snapshots
Key: MNG-2456
URL: http://jira.codehaus.org/browse/MNG-2456
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.4
Reporter: Baerrach bonDierne
See related problems MJAR-28 and MASSEMBLY-67.
Summary:
The Maven-Archiver uses the file part of the artifact's filename to create the
Class-Path entries in the Manifest.
This works fine for released artifacts and non-deployed snapshot.
The problem occurs when using a deployed snapshot as the assembly plugin will
copy the dependency as ${artifactId}-${version}-timestampedversion.jar and the
entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
thus use of java -jar will fail because of the differing names.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-92) Allow .classpath generation for plugin-development support
[ http://jira.codehaus.org/browse/MECLIPSE-92?page=comments#action_70215 ] Baerrach bonDierne commented on MECLIPSE-92: This probably isn't the place for the discussion, I can see Stephane is close to getting maven and eclipse RCP stuff working together. Has someone written up the steps they followed to do this? http://docs.codehaus.org/display/MAVEN might be a good spot for this so we can share knowledge. > Allow .classpath generation for plugin-development support > -- > > Key: MECLIPSE-92 > URL: http://jira.codehaus.org/browse/MECLIPSE-92 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.1 >Reporter: Sachin Patel > Assigned To: fabrizio giustina > Attachments: pde_patch_1.diff > > > In order to improve eclipse plugin development with maven, the configuration > of the eclipse:eclipse goal should allow a flag to be set that that given pom > is an eclipse plugin and the .classpath generated should not add .classpath > entries for dependencies declared in the POM, since plugins really just > reference other plugins in the workspace and or use the "requiredPlugins" > classpath container. At runtime plugins cannot reference external > classes/jars so having all the "var" entries isn't necessary and adds clutter. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_70120 ] Baerrach bonDierne commented on MJAR-28: Most of the comments I have made have been against MASSEMBLY-67 but the bug I believe is definitely in Maven Archiver (no bug has yet been raised for it) MNG-775 doesn't affect this because: - if the artifact is released this bug does not occur - if the artifact is not deployed (only installed) then the correct value is -SNAPSHOT so the only time this problem occurrs is when the artifact is deployed but not yet released. If the artifact is deployed it has been placed in a repository with a timestamped snapshot version (complete with build number) and hence MNG-775 does not apply. My current work around is to manually rename the assembled artifacts to -SNAPSHOT. The notes in MASSEMBLY-67 list the cause of the problem, the use of Project.getRuntimeClasspathElements() instead of using the runtime artifacts. I'm looking into test cases now and should know more by the end of the week. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69654 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
(Well it's not quite a week... but) Anyway I've found a web enabled IRC client
and asked on the maven irc channel.
#maven channel on the codehaus IRC server: irc.codehaus.org:6667
The latest code base (I was struggling to find) is at
http://svn.apache.org/repos/asf/maven/shared/trunk/maven-archiver
Also the correct place for archiver defects is in
http://jira.codehaus.org/browse/MNG using the maven-archiver component.
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69650 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
I've reposted my request for help as it has been a week and no response from
the dev list.
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_69271 ] Baerrach bonDierne commented on MJAR-28: Woops, I've attached the comments to bug MASSEMBLY-67. Never mind, they are related. Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Reporter: Mark J. Titorenko > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69270 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
Woops, I've attached the comments to this bug rather than MJAR-28.
Never mind, they are related.
Request for advice sent to dev list, see
http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=all ]
Baerrach bonDierne updated MASSEMBLY-67:
Attachment: MJAR-28-TestCases-Patch.txt
MJAR-28-Notes.txt
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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: (MJAR-47) maven-jar-plugin documentation should point to additional documentation, such as manifest guide
[ http://jira.codehaus.org/browse/MJAR-47?page=comments#action_68946 ] Baerrach bonDierne commented on MJAR-47: How To guides for things underneath the "archive" section would be great. Or links to archiver documentation so that we can work out how to configure it without trawling the mail archives. > maven-jar-plugin documentation should point to additional documentation, such > as manifest guide > --- > > Key: MJAR-47 > URL: http://jira.codehaus.org/browse/MJAR-47 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: Howard M. Lewis Ship > > > I had to appeal to the list for information on how to control the Manifest > for a JAR. The line of documentation in the maven-jar-plugin: "The maven > archiver to use." is misleading. More examples in the maven-jar-plugin > documentation would be good, as well as a link to > http://maven.apache.org/guides/mini/guide-manifest.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] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_68549 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
Ok,
I think the problem is that we are not using the archiver to assemble a jar.
We are using the archiver to assemble a binary distribution of the jar, with
all dependencies.
Therefore we need the version values in the manifest to match the versions in
the binary distribution as well.
I'm not clear if the Class-Path entry should be -SNAPSHOT or the resolved
version identifiers.
The only reason for a -SNAPSHOT would be for development purposes and so it
would be easier to just use -SNAPSHOT rather than the timestamped snapshot
versions.
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_68545 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
Brett, could you elaborate please?
I'm not familiar with the archive section of the assembly plugin, but I am not
sure how this would work anyway.
(I can't find the archive definition at
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html and there
is no information about the archive parameter at the mojo decriptions.)
The jar file needs in META-INF/MANIFEST.MF entries like:
Class-Path: etc
so that I can just run on the command line:
java -jar
So this would be part of the jar plugin.
All the assembly's task is to create the correct directory structure so that
the project's jar and all dependencies are copied to the correct locations so
that the Class-Path declaration matches the file locations.
Cheers
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-32) Allow for forcing the creation of direct project references for dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-32?page=comments#action_68206 ]
Baerrach bonDierne commented on MECLIPSE-32:
Barry, See http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html
Brett means that the configuration you require would be done inside the eclipse
plugin pluginManagement section rather than specifying it within the dependency
declaration.
Since only the eclipse plugin cares about the different types of project
references it makes sense to include it there. These values could also be
specified on the command line, rather than in a configuration, if the plugin is
designed to support this. It's all in the Better Builds With Maven book,
Section 5 Developing Custom Maven Plugins.
I've pasted the relevant section of pom.xml, it would go into the configuration
tag as Brett's snippet above shows.
{noformat}
{noformat}
> Allow for forcing the creation of direct project references for dependencies
>
>
> Key: MECLIPSE-32
> URL: http://jira.codehaus.org/browse/MECLIPSE-32
> Project: Maven 2.x Eclipse Plugin
> Type: Improvement
> Versions: 2.0
> Reporter: Barry Kaplan
>
>
> For some thirdparty dependencies, it is common (for me at least) that an
> eclipse project for that dependency does/will exist in the workspace. It
> would be nice if dependencies in eclipse projects can be forced to use a
> direct project reference. eg:
>
> backport-util-concurrent
> backport-util-concurrent
> 2.0_01_pd
> runtime
>
>
>
>
> Where can be:
> - 'project' -- always create a project reference
> - 'jar' -- always create a jar reference as in MNG-955
> - 'auto' -- the behavior prior to MNG-955
--
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: (MCHANGELOG-38) NPE when developer section does not include an id
[ http://jira.codehaus.org/browse/MCHANGELOG-38?page=comments#action_68041 ] Baerrach bonDierne commented on MCHANGELOG-38: -- id may be required, but the problem is that it does not indicate this gracefully. I used the definition from the JIRA help to assign priority levels. Critical - Crashes, loss of data, severe memory leak It's probably not the assembly plugins job to validate and enforce that id is mandatory though. > NPE when developer section does not include an id > - > > Key: MCHANGELOG-38 > URL: http://jira.codehaus.org/browse/MCHANGELOG-38 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Baerrach bonDierne > Priority: Critical > > > [DEBUG] Trace > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:398) > at > org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530) > at > org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541) > at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370) > at > org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263) > at > org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218) > at > org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198) > at > org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > This is easy to replicate, find a working "mvn site" and then remove an id > from a developer. > This is for plugin > org.apache.maven.plugins > maven-changelog-plugin > I'd like to provide version details but this plugin isn't in my repository! > So I am not sure how it is actually working. > The website does't point to a repository, and I accidentally found it at > http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins > but this code doesn't match up with the error message. > I couldn't find the code base from the the old codehaus repository either. -- 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: (MCHANGELOG-38) NPE when developer section does not include an id
[ http://jira.codehaus.org/browse/MCHANGELOG-38?page=comments#action_67904 ] Baerrach bonDierne commented on MCHANGELOG-38: -- org.codehaus.mojo changelog-maven-plugin Is the plugin I am using. I hadn't committed the changes into CVS before trying on the integration server. > NPE when developer section does not include an id > - > > Key: MCHANGELOG-38 > URL: http://jira.codehaus.org/browse/MCHANGELOG-38 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Baerrach bonDierne > Priority: Critical > > > [DEBUG] Trace > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:398) > at > org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530) > at > org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541) > at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370) > at > org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263) > at > org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218) > at > org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198) > at > org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > This is easy to replicate, find a working "mvn site" and then remove an id > from a developer. > This is for plugin > org.apache.maven.plugins > maven-changelog-plugin > I'd like to provide version details but this plugin isn't in my repository! > So I am not sure how it is actually working. > The website does't point to a repository, and I accidentally found it at > http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins > but this code doesn't match up with the error message. > I couldn't find the code base from the the old codehaus repository either. -- 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: (MCHANGELOG-38) NPE when developer section does not include an id
NPE when developer section does not include an id - Key: MCHANGELOG-38 URL: http://jira.codehaus.org/browse/MCHANGELOG-38 Project: Maven 2.x Changelog Plugin Type: Bug Reporter: Baerrach bonDierne Priority: Critical [DEBUG] Trace java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:398) at org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530) at org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541) at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370) at org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263) at org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218) at org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198) at org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) This is easy to replicate, find a working "mvn site" and then remove an id from a developer. This is for plugin org.apache.maven.plugins maven-changelog-plugin I'd like to provide version details but this plugin isn't in my repository! So I am not sure how it is actually working. The website does't point to a repository, and I accidentally found it at http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins but this code doesn't match up with the error message. I couldn't find the code base from the the old codehaus repository either. -- 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=all ] Baerrach bonDierne updated MASSEMBLY-119: - Attachment: MASSEMBLY-119 Format dir fails on install.zip > dir format will fail with an error because it can not install the directory > into the repository > --- > > Key: MASSEMBLY-119 > URL: http://jira.codehaus.org/browse/MASSEMBLY-119 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.1 > Reporter: Baerrach bonDierne > Attachments: MASSEMBLY-119 Format dir fails on install.zip > > > See the discussion on MASSEMBLY-39 which originally created the dir format. > I believe the dir format should never be added to the repository as it's only > purpose is to ease the development process by providing an un-archived > version ready for testing on disk. > The workaround is to manually extract the archive, or to create a second > duplicate descriptor and use that to create the directory version (do not > bind this second one to the package phase) > Will attach example project shortly. > The error received is: > [INFO] [install:install] > [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar > [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to > \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error installing artifact: > \target\-0.0.1-SNAPSHOT-bin.dir (Acc > ess is denied) > When I run with -X the root cause error is: > Caused by: java.io.FileNotFoundException: > \target\-0.0.1-SNAPSHOT-bin. > dir (Access is denied) >at java.io.FileInputStream.open(Native Method) >at java.io.FileInputStream.(FileInputStream.java:106) >at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) >at > org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_67781
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
Spaces in the path?
The issue is that in a reactor build the section is resolving path
names to be parent project relative instead of module relative.
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Baerrach bonDierne
> Priority: Critical
> Attachments: Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
dir format will fail with an error because it can not install the directory into the repository --- Key: MASSEMBLY-119 URL: http://jira.codehaus.org/browse/MASSEMBLY-119 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Reporter: Baerrach bonDierne See the discussion on MASSEMBLY-39 which originally created the dir format. I believe the dir format should never be added to the repository as it's only purpose is to ease the development process by providing an un-archived version ready for testing on disk. The workaround is to manually extract the archive, or to create a second duplicate descriptor and use that to create the directory version (do not bind this second one to the package phase) Will attach example project shortly. The error received is: [INFO] [install:install] [INFO] Installing \target\-0.0.1-SNAPSHOT.jar to \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT.jar [INFO] Installing \target\-0.0.1-SNAPSHOT-bin.dir to \.m2\repository\\\0.0.1-SNAPSHOT\-0.0.1-SNAPSHOT-bin.dir [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact: \target\-0.0.1-SNAPSHOT-bin.dir (Acc ess is denied) When I run with -X the root cause error is: Caused by: java.io.FileNotFoundException: \target\-0.0.1-SNAPSHOT-bin. dir (Access is denied) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- 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-87) In a multi-module build, assembly descriptor paths are not project-relative, but erraneously relative to the parent project directory
[ http://jira.codehaus.org/browse/MASSEMBLY-87?page=comments#action_6 ] Baerrach bonDierne commented on MASSEMBLY-87: - This may be a duplicate of MASSEMBLY-100. If you run mvn assembly:assembly in the parent pom, you are asking to run a plugin "outside" the normal lifecycle. If the the parent pom does not have an assembly descriptor then shouldn't this be an error? Perhaps mvn assembly:assembly should not force a reactor build? > In a multi-module build, assembly descriptor paths are not project-relative, > but erraneously relative to the parent project directory > - > > Key: MASSEMBLY-87 > URL: http://jira.codehaus.org/browse/MASSEMBLY-87 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.1, 2.0.1 > Environment: windows xp, jdk 1.5.0_06, mvn 2.0.4 > Reporter: Evgeny Kompaniets > Attachments: PomWithModule.zip > > > Bug with such summary already closed, but it is not fixed. > I have the POM packaging project with one submodule (see attachment). > The submodule contains assembly descriptor. > I run mvn assembly:assembly and got > "No assembly descriptors found." > Running the same in submodule dir (m1 in attachment) work 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] Commented: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=comments#action_67775
]
Baerrach bonDierne commented on MASSEMBLY-118:
--
This may be a duplicate of MASSEMBLY-100 which is listed as fixed in 2.2
(at this time 2.2 us unreleased.)
> assembly uses maven parent relative path and not the modules relative
> path
> --
>
> Key: MASSEMBLY-118
> URL: http://jira.codehaus.org/browse/MASSEMBLY-118
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Baerrach bonDierne
> Priority: Critical
> Attachments: Maven Assembly Bug.zip
>
>
> In mvn 2.0.4 if I have an assemly descriptor that has the following:
>
>
> src/site/apt/index.apt
>
> README.txt
>
>
> and a maven project that looks like:
> Maven Assembly Bug
> - pom.xml
> - assembly-bug-module
> - pom.xml
> - src/site/apt/index.apt
> with the assembly:assembly bound to the package phase inside
> assembly-bug-module/pom.xml as
>
>
>
> maven-assembly-plugin
>
>
> package-assembly
> package
>
> assembly
>
>
>
>
>
> src/main/assembly/bin.xml
>
>
>
>
>
>
> then when I run mvn install inside assembly-bug-module:
> assembly-bug-module> mvn install
> the command works fine
> When I run mvn install inside the "Maven Assembly Bug" directory the command
> will fail
> Maven Assembly Bug> mvn install
> [INFO] [assembly:assembly {execution: package-assembly}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\src\site\apt\index.apt isn't a file.
> Example project is attached as a zip file.
> Trying to change the descriptor to use ${project.build.sourceDirectory} does
> not work as this is not resoolved.
> [INFO] Error adding file to archive: \Maven Assembly
> Bug\assembly-bug-module\${project.build.sourceDirectory}
> \site\apt\index.apt isn't a 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: (MASSEMBLY-118) assembly uses maven parent relative path and not the modules relative path
assembly uses maven parent relative path and not the modules relative
path
--
Key: MASSEMBLY-118
URL: http://jira.codehaus.org/browse/MASSEMBLY-118
Project: Maven 2.x Assembly Plugin
Type: Bug
Reporter: Baerrach bonDierne
Priority: Critical
Attachments: Maven Assembly Bug.zip
In mvn 2.0.4 if I have an assemly descriptor that has the following:
src/site/apt/index.apt
README.txt
and a maven project that looks like:
Maven Assembly Bug
- pom.xml
- assembly-bug-module
- pom.xml
- src/site/apt/index.apt
with the assembly:assembly bound to the package phase inside
assembly-bug-module/pom.xml as
maven-assembly-plugin
package-assembly
package
assembly
src/main/assembly/bin.xml
then when I run mvn install inside assembly-bug-module:
assembly-bug-module> mvn install
the command works fine
When I run mvn install inside the "Maven Assembly Bug" directory the command
will fail
Maven Assembly Bug> mvn install
[INFO] [assembly:assembly {execution: package-assembly}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error adding file to archive: \Maven Assembly
Bug\src\site\apt\index.apt isn't a file.
Example project is attached as a zip file.
Trying to change the descriptor to use ${project.build.sourceDirectory} does
not work as this is not resoolved.
[INFO] Error adding file to archive: \Maven Assembly
Bug\assembly-bug-module\${project.build.sourceDirectory}
\site\apt\index.apt isn't a 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
