[continuum build - SUCCESS - checkout] Mon Nov 14 01:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051114.013000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051114.013000.txt
[jira] Updated: (SCM-72) Remove tagbase usage and use insted mecanism use in update command
[ http://jira.codehaus.org/browse/SCM-72?page=all ]
David Hawkins updated SCM-72:
-
Attachment: SCM-72-maven-scm-test.patch
SCM-72-maven.scm-provider-svn.patch
Added automatic tag resolution to SvnCheckoutCommand, SvnChangeLogCommand, and
SvnTagCommand.
On the SvnChangeLogCommand command, I changed the date format specified in the
command line.
The original format looked like: svn log -v -r {2003/09/10 GMT}:{2003/10/10
GMT}
But this format was not legal in svn version 1.2.3 on cygwin, linux, or
windows. I am not sure if a previous version supported this date format, but
the current does not.
The new date format looks like: svn log -v -r {2003-09-10 00:00:00
+}:{2003-10-10 00:00:00 +}
It is now specifying the time along with the date. The api allows a user to
pass a date, so we should probably use the time in the date as well.
I also changed ScmTestCase.getDate() to support passing time values so I could
test the changelog command creation.
As far as SvnDiffCommand goes, I didn't add branch/tag resolution to it because
the api specifies a startRevision and endRevision. While it might be
useful to be able to support tag/branch diffs, the api only specifies
revisions. This is something that can always be added at a later date if
deemed necessary.
It also seems odd to me that the StatusMojo doesn't actually print anything
out. It has a StatusScmResult with a list of changed files, but only checks
that the result was successful. Maybe I don't understand the intended use of
the action, but it basically throws away the result without ever doing anything
with it.
Remove tagbase usage and use insted mecanism use in update command
--
Key: SCM-72
URL: http://jira.codehaus.org/browse/SCM-72
Project: Maven SCM
Type: Task
Components: maven-scm-provider-svn
Versions: 1.0-beta-1
Reporter: Emmanuel Venisse
Attachments: SCM-72-maven-scm-test.patch, SCM-72-maven.scm-provider-svn.patch
David Hawkins, do you want work on it?
--
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-1488) need to set default bundleDir for all ear modules
[ http://jira.codehaus.org/browse/MNG-1488?page=comments#action_50797 ] Stephane Nicoll commented on MNG-1488: -- OK. Here is what I suggest: property: defaultJavaBundleDir which specify an URI. If it is set all Javamodules go there. If a javamodule has a bundleDir entry, this value is taken. Mike, if you have modified something useful, feel free to send a patch. need to set default bundleDir for all ear modules - Key: MNG-1488 URL: http://jira.codehaus.org/browse/MNG-1488 Project: Maven 2 Type: New Feature Components: maven-ear-plugin Reporter: Michal Stochmialek Assignee: Stephane Nicoll I need an improvement of bundleDir feature. I would like to specify common bundleDir for all modules in ear. For example: plugin artifactIdmaven-ear-plugin/artifactId configuration resourcesDirsrc/resources/resourcesDir defaultBundleDirAPP-INF/lib/defaultBundleDir modules javaModule ... /javaModule ejbModule ... /ejbModule /modules /configuration /plugin I have ear with single ejb and a bunch of jar archives. I would like them all placed in APP-INF/lib directory. Using bundleDir tag I must duplicate whole dependency list (and also transitive dependencies) in ear-plugin configuration and change bundle dir of each archive. It's very frustrating. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1542) type attribute of artifact:dependencies doesn't work for indirect dependencies
type attribute of artifact:dependencies doesn't work for indirect dependencies -- Key: MNG-1542 URL: http://jira.codehaus.org/browse/MNG-1542 Project: Maven 2 Type: Sub-task Components: maven-artifact-ant Versions: 2.0 Reporter: Tomislav Bodor It appears that the type filter doesn't work properly with indirect dependencies. It doesn't look like an issue with the TypeArtifactFilter itself, but somewhere deeper. However, it's related to this feature, so here it is... The problem manifests with transitive dependencies that are of different type, e.g. a war artefact depends on a jar library. Whatever the type in that case (jar or war), the dependency list returned by artifact:dependencies is empty. I've traced through it and here is some more information: DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. This iterates over the (dependency) node trail and applies the specified filter to each dependency in turn. If all dependencies are of the same type and the type matches the one specified in the filter, no problems. However, I've got a dependency that is a war archive and that in turn has some jar dependencies. If type is set to jar, filter fails when testing the first dependency in the trail - the war in this case and never gets to the jar. The result is that whatever the value of the type attribute, the dependency list always ends up empty for trails that contain dependencies of different types. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1488) need to set default bundleDir for all ear modules
[ http://jira.codehaus.org/browse/MNG-1488?page=all ] Stephane Nicoll closed MNG-1488: Resolution: Fixed Fix Version: 2.0.1 This is done. Added defaultJavaBundleDir proerty which specify an URI. If it is set all Javamodules go there. If a javamodule has a bundleDir entry, this value is taken. need to set default bundleDir for all ear modules - Key: MNG-1488 URL: http://jira.codehaus.org/browse/MNG-1488 Project: Maven 2 Type: New Feature Components: maven-ear-plugin Reporter: Michal Stochmialek Assignee: Stephane Nicoll Fix For: 2.0.1 I need an improvement of bundleDir feature. I would like to specify common bundleDir for all modules in ear. For example: plugin artifactIdmaven-ear-plugin/artifactId configuration resourcesDirsrc/resources/resourcesDir defaultBundleDirAPP-INF/lib/defaultBundleDir modules javaModule ... /javaModule ejbModule ... /ejbModule /modules /configuration /plugin I have ear with single ejb and a bunch of jar archives. I would like them all placed in APP-INF/lib directory. Using bundleDir tag I must duplicate whole dependency list (and also transitive dependencies) in ear-plugin configuration and change bundle dir of each archive. It's very frustrating. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Sun Nov 13 12:45:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051113.124500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051113.124500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1455) Possible NPE in DefaultArtifactResolver
[ http://jira.codehaus.org/browse/MNG-1455?page=comments#action_50800 ] Jeff Jensen commented on MNG-1455: -- Is this the same as http://jira.codehaus.org/browse/MNG-1316? Possible NPE in DefaultArtifactResolver --- Key: MNG-1455 URL: http://jira.codehaus.org/browse/MNG-1455 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0 Environment: Ubuntu /Windows 2000 Reporter: Bernd Bohmann Attachments: DefaultArtifactResolver.java.patch With mvn site:site we got a NPE at org.apache.maven.aritfact.resolver.DefaultArtifactResolver.java Line 82 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1455) Possible NPE in DefaultArtifactResolver
[ http://jira.codehaus.org/browse/MNG-1455?page=comments#action_50801 ] Bernd Bohmann commented on MNG-1455: Yes Possible NPE in DefaultArtifactResolver --- Key: MNG-1455 URL: http://jira.codehaus.org/browse/MNG-1455 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0 Environment: Ubuntu /Windows 2000 Reporter: Bernd Bohmann Attachments: DefaultArtifactResolver.java.patch With mvn site:site we got a NPE at org.apache.maven.aritfact.resolver.DefaultArtifactResolver.java Line 82 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1543) pom.xml information automatically included in META-INF during jar
pom.xml information automatically included in META-INF during jar
--
Key: MNG-1543
URL: http://jira.codehaus.org/browse/MNG-1543
Project: Maven 2
Type: Improvement
Components: maven-jar-plugin
Versions: 2.0
Reporter: Jorg Heymans
The jar plugin automatically adds a pom.xml in META-INF, which makes sense. But
this pom.xml also contains local paths ie
build
sourceDirectoryd:\src\excalibur-trunk\framework\api\src\java/sourceDirectory
scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory
testSourceDirectoryd:\src\excalibur-trunk\framework\api\src\test/testSourceDirectory
outputDirectoryd:\src\excalibur-trunk\framework\api\target\classes/outputDirectory
testOutputDirectoryd:\src\excalibur-trunk\framework\api\target\test-classes/testOutputDirectory
resources
resource
targetPathMETA-INF/targetPath
directoryd:\src\excalibur-trunk\framework\api\..\../directory
includes
includeLICENSE.txt/include
includeNOTICE.txt/include
/includes
/resource
/resources
testResources
testResource
directoryd:\src\excalibur-trunk\framework\api\src\test\resources/directory
I don't see how this information could be useful to anyone else, and i'ld
rather not have my local paths in distribution jars - call me paranoid :)
Conversation log from IRC :
jorgis there a way to tell maven not to include the pom.xml in
META-INF when creating jars ?
jesse hm, not that I know of
jesse might be a boolean to control it in there somewhere
jorgi looked at the jar plugin config .. didn't seem like it
jorgit's not a real problem, just funny that this is done by default
jesse I don't know, it makes it easier down the road to have
automated things interrogate the jar for dependencies of the things inside
trygvis yeah, you're right there jesse
jorgmmm well yes that makes sense ...
jorgthanks !
trygvis jorg: it's useful for the application itself
trygvis like reading out the version number from pom.properties
jorgtrygvis: yes, but the pom also had my local paths in it for
sourceDirectory and stuff, that's why i found it a bit strange
trygvis makes it easier making versioning-aware application and gives a
thigh integration with your project management tool (aka maven)
trygvis hm
trygvis that should possibly be changed indeed
trygvis File properties should be made relative to ${basedir} again
trygvis when writing out the pom that is
jorgi can understand about the dependencies , but the build
configuration probably shouldn't be in there
jorg
directoryd:\src\excalibur-trunk\framework\api\..\../directory
trygvis jorg: file an issue, it should be relative to ${basedir} if
there at all
trygvis IMO the build parts of a pom could be stripped from the repo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-472) multiple execution/'s with no goals not considered when running a goal directly from the CLI
[ http://jira.codehaus.org/browse/MNG-472?page=comments#action_50808 ] Jesse McConnell commented on MNG-472: - one note on this issue.. if you specify the phase in the execution it will not process multiple execution elements using the default lifecycle (ie, mvn install)...the plugin declares the phase and the plugins can't mention the phase, even if it is the same one since that causes only the first one to be executed.. multiple execution/'s with no goals not considered when running a goal directly from the CLI -- Key: MNG-472 URL: http://jira.codehaus.org/browse/MNG-472 Project: Maven 2 Type: Bug Components: maven-core Reporter: John Casey Priority: Critical assume you specify a plugin in the pom with multiple execution/ sections, each containing configurations. It should be possible to directly invoke a goal within this plugin, and have that goal run once per execution, despite the fact that the goal is not explicitly specified in the execution/. This is not the case now. Workaround: specify the goal for each execution in which you want it to run. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)
On 11/13/05, Lukas Theussl [EMAIL PROTECTED] wrote: I just committed a fix for this issue, can you check if it's ok? One thing though: in navigation.xml, you need to prepend the hrefs in the menu items by a slash, eg item name=Bean href=/tagreference-struts-bean.html/ Strange, I see no change at all. I updated from svn (and saw the change in fo-tables.xslt). Did maven plugin:install, deleted the cache, got rid of every copy of maven-pdf-plugin* that I could find, tried again with plugin:install, and after 'maven site pdf' the title is still Jakarta Maven with incorrect dates (tiles) and a build failure for duplicate ids (taglib). Assuming it works for you with Maven 1.0.2, what could I be missing? (I think adding / to those menu items would break the website, the taglib docs live one level down from the main site. But I see from the docs that you can have a separate navigation file for the pdf. No idea what's going to happen if I try to make a pdf of the entire multiproject site, though.) Thanks for all your work on this! -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-200) sslext/sslext-1.2-0 jar contains no class files (should have several)
sslext/sslext-1.2-0 jar contains no class files (should have several) - Key: MEV-200 URL: http://jira.codehaus.org/browse/MEV-200 Project: Maven Evangelism Type: Bug Reporter: Adam Hardy The jar on ibiblio has 1.8kB. The jar from the source has 23kB. For reasons unknown all the class files are missing from the ibiblio jar. http://sourceforge.net/project/showfiles.php?group_id=59967package_id=130891 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)
Wendy, My patch only fixes the id problem, not the 1.0-1.1 incompatibility (I still haven't got a clue why this happens). You have to add the slashes though, if you can't do it in navigation.xml then you should use a separate pdf_navigation.xml (I would recommend that anyway). However, according to the maven docs [1], the href elements should be absolute even for the xdoc plugin and in a multiproject setup, I think that was the case already in m1.0. -Lukas [1] http://maven.apache.org/maven-1.x/using/site.html Wendy Smoak wrote: On 11/13/05, Lukas Theussl [EMAIL PROTECTED] wrote: I just committed a fix for this issue, can you check if it's ok? One thing though: in navigation.xml, you need to prepend the hrefs in the menu items by a slash, eg item name=Bean href=/tagreference-struts-bean.html/ Strange, I see no change at all. I updated from svn (and saw the change in fo-tables.xslt). Did maven plugin:install, deleted the cache, got rid of every copy of maven-pdf-plugin* that I could find, tried again with plugin:install, and after 'maven site pdf' the title is still Jakarta Maven with incorrect dates (tiles) and a build failure for duplicate ids (taglib). Assuming it works for you with Maven 1.0.2, what could I be missing? (I think adding / to those menu items would break the website, the taglib docs live one level down from the main site. But I see from the docs that you can have a separate navigation file for the pdf. No idea what's going to happen if I try to make a pdf of the entire multiproject site, though.) Thanks for all your work on this! -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1544) Attached artefacts not handled
Attached artefacts not handled
--
Key: MNG-1544
URL: http://jira.codehaus.org/browse/MNG-1544
Project: Maven 2
Type: Bug
Components: maven-artifact-ant
Versions: 2.0
Reporter: Tomislav Bodor
The install and deploy tasks don't seem to be able to handle attached
artefacts. There appear to be two sides to the problem: first, there seems to
be no way to attach anything, and second, even if it were attached, the install
and deploy tasks don't do anything with attachments.
The latter could be solved by adding to the install (and similar to the deploy)
task something along the lines of (similar to the InstallMojo in the install
plugin):
List attachedArtifacts =
pom.getMavenProject().getAttachedArtifacts();
for (Iterator i = attachedArtifacts.iterator(); i.hasNext(); ) {
Artifact attached = (Artifact) i.next();
installer.install(attached.getFile(), attached, localRepo);
}
For the former (how to attach anything), a new task could be added (say,
'attach', taking a type, classifier and file).
This functionality is needed to handle source archives and EJB client jars.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1544) Attached artefacts not handled
[ http://jira.codehaus.org/browse/MNG-1544?page=comments#action_50810 ]
Tomislav Bodor commented on MNG-1544:
-
Alternatively, a nested fileset could be added to install and deploy tasks...
Then the attachments would not be handled the 'maven way', but more the 'ant
way'. Since maven plugins cannot be executed in this mode anyway, perhaps there
is no need to support the proper attachments.
Attached artefacts not handled
--
Key: MNG-1544
URL: http://jira.codehaus.org/browse/MNG-1544
Project: Maven 2
Type: Bug
Components: maven-artifact-ant
Versions: 2.0
Reporter: Tomislav Bodor
The install and deploy tasks don't seem to be able to handle attached
artefacts. There appear to be two sides to the problem: first, there seems to
be no way to attach anything, and second, even if it were attached, the
install and deploy tasks don't do anything with attachments.
The latter could be solved by adding to the install (and similar to the
deploy) task something along the lines of (similar to the InstallMojo in the
install plugin):
List attachedArtifacts =
pom.getMavenProject().getAttachedArtifacts();
for (Iterator i = attachedArtifacts.iterator(); i.hasNext(); ) {
Artifact attached = (Artifact) i.next();
installer.install(attached.getFile(), attached, localRepo);
}
For the former (how to attach anything), a new task could be added (say,
'attach', taking a type, classifier and file).
This functionality is needed to handle source archives and EJB client jars.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1545) some execution output not routed through default routes.
some execution output not routed through default routes. Key: MNG-1545 URL: http://jira.codehaus.org/browse/MNG-1545 Project: Maven 2 Type: Bug Components: maven-embedder Reporter: Milos Kleint Priority: Critical when running embedded maven I create an instance of EventMonitor, TransferListener and MavenEmbedderLogger. however there's still some output that is not received through these means, but rather printoed to standard output (I suppose) that's wrong because it prohibits custom handling of output. one example that I found is the surefire plugin's output.. everything prepended with [surefire] is printed out wrongly.. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1546) no way to retrieve/change plugin configuration in the POM or globally
no way to retrieve/change plugin configuration in the POM or globally - Key: MNG-1546 URL: http://jira.codehaus.org/browse/MNG-1546 Project: Maven 2 Type: Bug Components: maven-embedder Reporter: Milos Kleint Priority: Critical there is not way to figure the configuration of a given plugin in the pom. usecase: have the surefire plugin with test includes/excludes. in the UI mark the included/excluded. allow changing these settings.. another usecase: figure if a plugin is added to the pom that generates some sources.. another usecase: dynamically allow to run a single test from the IDE, requires me to manipulate the surefire's includes/excluse or test pattern property.. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Sun Nov 13 18:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051113.18.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051113.18.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPDIST-27) Zip archives should use CRLF line endings on txt files
[ http://jira.codehaus.org/browse/MPDIST-27?page=comments#action_50817 ] Phil Steitz commented on MPDIST-27: --- Is there a problem with this patch? Is there a better way to do this? It would be great to get a fix for this committed. Zip archives should use CRLF line endings on txt files -- Key: MPDIST-27 URL: http://jira.codehaus.org/browse/MPDIST-27 Project: maven-dist-plugin Type: Improvement Environment: Windows Reporter: Phil Steitz Attachments: dist-plugin-crlf.patch Adding CRLF line endings to text files in zip archives will make these files easier to read on Windows platforms. The attached patch fixes the line endings before creating the zips. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPDIST-27) Zip archives should use CRLF line endings on txt files
[ http://jira.codehaus.org/browse/MPDIST-27?page=all ] Lukas Theussl closed MPDIST-27: --- Resolution: Fixed Fix Version: 1.7 Zip archives should use CRLF line endings on txt files -- Key: MPDIST-27 URL: http://jira.codehaus.org/browse/MPDIST-27 Project: maven-dist-plugin Type: Improvement Environment: Windows Reporter: Phil Steitz Fix For: 1.7 Attachments: dist-plugin-crlf.patch Adding CRLF line endings to text files in zip archives will make these files easier to read on Windows platforms. The attached patch fixes the line endings before creating the zips. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPDIST-13) Allow distribution of artifact types other than jar
[ http://jira.codehaus.org/browse/MPDIST-13?page=all ] Lukas Theussl reopened MPDIST-13: - Reopen to change fix version Allow distribution of artifact types other than jar --- Key: MPDIST-13 URL: http://jira.codehaus.org/browse/MPDIST-13 Project: maven-dist-plugin Type: New Feature Reporter: Carlos Sanchez Assignee: Carlos Sanchez Fix For: 1.7 Attachments: patch.txt The plugin depends on jar goals, like multiproject it should allow choosing the artifact type (jar, war, ...) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPDIST-13) Allow distribution of artifact types other than jar
[ http://jira.codehaus.org/browse/MPDIST-13?page=all ] Lukas Theussl closed MPDIST-13: --- Resolution: Fixed Fix Version: 1.7 Allow distribution of artifact types other than jar --- Key: MPDIST-13 URL: http://jira.codehaus.org/browse/MPDIST-13 Project: maven-dist-plugin Type: New Feature Reporter: Carlos Sanchez Assignee: Carlos Sanchez Fix For: 1.7 Attachments: patch.txt The plugin depends on jar goals, like multiproject it should allow choosing the artifact type (jar, war, ...) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPDIST-18) maven.dist.tar.executable and maven.dist.gunzip.executable props in plugin.properties are never used, and so should be removed
[ http://jira.codehaus.org/browse/MPDIST-18?page=all ] Lukas Theussl closed MPDIST-18: --- Resolution: Fixed Fix Version: 1.7 Fixed long time ago maven.dist.tar.executable and maven.dist.gunzip.executable props in plugin.properties are never used, and so should be removed -- Key: MPDIST-18 URL: http://jira.codehaus.org/browse/MPDIST-18 Project: maven-dist-plugin Type: Bug Environment: n/a Reporter: Ian Springer Priority: Trivial Fix For: 1.7 These two props aren't used at all by plugin.jelly and so should be removed from plugin.properties. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPDIST-25) Goal dist:prepare-src-filesystem should also include build.properties in source distribution.
[ http://jira.codehaus.org/browse/MPDIST-25?page=all ]
Lukas Theussl closed MPDIST-25:
---
Resolution: Won't Fix
Goal dist:prepare-src-filesystem should also include build.properties in
source distribution.
-
Key: MPDIST-25
URL: http://jira.codehaus.org/browse/MPDIST-25
Project: maven-dist-plugin
Type: Improvement
Environment: Not of importance.
Reporter: Davy Toch
Original Estimate: 2 hours
Remaining: 2 hours
The following target call
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=.
ant:include name=README.txt/
ant:include name=LICENSE*/
ant:include name=project.properties/
ant:include name=maven.xml/
ant:include name=project.xml/
/ant:fileset
/ant:copy
in the goal dist:prepare-src-filesystem should also include the file
build.properties. Normally this file only includes user-specific settings.
When this file is not included in the source distribution, the developer
receiving the source distribution doesn't know which user-specific properties
to set.
On the other hand it would be useful to add a section at
http://maven.apache.org/reference/plugins/dist/ that indicates that if more
files from the project root need to be added in the source distribution, then
a postGoal for the above goal needs to be created in a custom maven.xml, for
example something like:
!--
Maven dist plugin doesn't copy build.properties (contains user-specific
settings) to source distribution. Additionally, it is sometimes
interesting
to also have the POM xsd in the project root and have it included as well
in the source distribution.
--
postGoal name=dist:prepare-src-filesystem
copy todir=${maven.dist.src.assembly.dir}
fileset dir=${basedir}
include name=build.properties/
include name=project.xsd/
/fileset
/copy
/postGoal
Regards,
Davy Toch
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPDIST-24) dist:prepare-src-filesystem doesn't recognize maven.ant.generatebuild.file
[ http://jira.codehaus.org/browse/MPDIST-24?page=all ]
Lukas Theussl closed MPDIST-24:
---
Resolution: Fixed
Fix Version: 1.7
dist:prepare-src-filesystem doesn't recognize maven.ant.generatebuild.file
--
Key: MPDIST-24
URL: http://jira.codehaus.org/browse/MPDIST-24
Project: maven-dist-plugin
Type: Bug
Environment: Windows XP
Reporter: Steve McMee
Fix For: 1.7
Original Estimate: 15 minutes
Remaining: 15 minutes
I have encountered a bug in goal
dist:prepare-src-filesystem:
attainGoal name=ant:generate-build/
ant:move
file=${basedir}/build.xml
tofile=${maven.dist.src.assembly.dir}/build.xml/
this target fails if you have specified the property
maven.ant.generatebuild.file to another file than build.xml
${basedir}/build.xml should be replaced by ${maven.ant.generatebuild.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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Sun Nov 13 21:45:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051113.214500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051113.214500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPDIST-9) Add fixcrlf step
[ http://jira.codehaus.org/browse/MPDIST-9?page=all ]
Lukas Theussl updated MPDIST-9:
---
Assign To: Lukas Theussl (was: Jason van Zyl)
Description:
It would be good to have the following:
1. FIXCRLF distribution directory before creating zip using 1st rule-set
(windows)
2. then ZIP
3. FIXCRLF distribution directory before creating tar.gz using 2nd rule set
(unix)
4. then TAR.GZ
Thank you.
Below you can find my temporal workaround for FIXCRLF:
goal name=dist:build-bin
prereqs=dist:build-setup, dist:prepare-bin-filesystem
description=Build the binary distribution.
!-- fix CR/LF for unix dist --
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=lf
eof=remove
patternset refid=fixcrlf.patternset/
patternset refid=fixcrlf.unix.patternset/
/ant:fixcrlf
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=crlf
eof=remove
patternset refid=fixcrlf.win.patternset/
/ant:fixcrlf
!-- Create a tar.gz file --
ant:tar longfile=gnu
tarfile=${maven.dist.dir}/${maven.final.name}.tar
ant:tarfileset dir=${maven.dist.bin.archive.dir}/
/ant:tar
ant:gzip
zipfile=${maven.dist.dir}/${maven.final.name}.tar.gz
src=${maven.dist.dir}/${maven.final.name}.tar
/
ant:delete file=${maven.dist.dir}/${maven.final.name}.tar/
!-- fix CR/LF for win dist --
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=lf
eof=remove
patternset refid=fixcrlf.unix.patternset/
/ant:fixcrlf
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=crlf
eof=remove
patternset refid=fixcrlf.patternset/
patternset refid=fixcrlf.win.patternset/
/ant:fixcrlf
!-- Create a zip file --
ant:zip zipfile=${maven.dist.dir}/${maven.final.name}.zip
ant:zipfileset dir=${maven.dist.bin.archive.dir}/
/ant:zip
/goal
was:
It would be good to have the following:
1. FIXCRLF distribution directory before creating zip using 1st rule-set
(windows)
2. then ZIP
3. FIXCRLF distribution directory before creating tar.gz using 2nd rule set
(unix)
4. then TAR.GZ
Thank you.
Below you can find my temporal workaround for FIXCRLF:
goal name=dist:build-bin
prereqs=dist:build-setup, dist:prepare-bin-filesystem
description=Build the binary distribution.
!-- fix CR/LF for unix dist --
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=lf
eof=remove
patternset refid=fixcrlf.patternset/
patternset refid=fixcrlf.unix.patternset/
/ant:fixcrlf
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=crlf
eof=remove
patternset refid=fixcrlf.win.patternset/
/ant:fixcrlf
!-- Create a tar.gz file --
ant:tar longfile=gnu
tarfile=${maven.dist.dir}/${maven.final.name}.tar
ant:tarfileset dir=${maven.dist.bin.archive.dir}/
/ant:tar
ant:gzip
zipfile=${maven.dist.dir}/${maven.final.name}.tar.gz
src=${maven.dist.dir}/${maven.final.name}.tar
/
ant:delete file=${maven.dist.dir}/${maven.final.name}.tar/
!-- fix CR/LF for win dist --
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=lf
eof=remove
patternset refid=fixcrlf.unix.patternset/
/ant:fixcrlf
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=crlf
eof=remove
patternset refid=fixcrlf.patternset/
patternset refid=fixcrlf.win.patternset/
/ant:fixcrlf
!-- Create a zip file --
ant:zip zipfile=${maven.dist.dir}/${maven.final.name}.zip
ant:zipfileset dir=${maven.dist.bin.archive.dir}/
/ant:zip
/goal
Fix Version: 1.7
Add fixcrlf step
--
Key: MPDIST-9
URL: http://jira.codehaus.org/browse/MPDIST-9
Project: maven-dist-plugin
Type: New Feature
Environment: Any
Reporter: Dmytro Mykhaylov
Assignee: Lukas Theussl
Priority: Minor
Fix For: 1.7
It would be good to have the following:
1. FIXCRLF distribution directory before creating zip using 1st rule-set
(windows)
2. then ZIP
3. FIXCRLF distribution directory before creating tar.gz using 2nd rule set
(unix)
4. then TAR.GZ
Thank you.
Below you can find my temporal workaround for FIXCRLF:
goal name=dist:build-bin
prereqs=dist:build-setup, dist:prepare-bin-filesystem
description=Build the binary distribution.
!-- fix CR/LF for unix dist --
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir} eol=lf
eof=remove
patternset refid=fixcrlf.patternset/
patternset refid=fixcrlf.unix.patternset/
/ant:fixcrlf
ant:fixcrlf srcdir=${maven.dist.bin.assembly.dir}
[jira] Updated: (MPDIST-15) custom include list for source distribution patch (fixes missing checkstyle.xml)
[ http://jira.codehaus.org/browse/MPDIST-15?page=all ] Lukas Theussl updated MPDIST-15: Assign To: fabrizio giustina Description: Actually the dist plugin includes in source distribution only a predefined list of files. When using a custom checkstyle.xml for the checkstyle report, the source distribution should include this file, elsewhere the site generation will fail complaining for the missing file. To address the issue in a more general way I am adding a new maven.dist.src.include property which allows users to specify addictional files which should be included in source distribution. was: Actually the dist plugin includes in source distribution only a predefined list of files. When using a custom checkstyle.xml for the checkstyle report, the source distribution should include this file, elsewhere the site generation will fail complaining for the missing file. To address the issue in a more general way I am adding a new maven.dist.src.include property which allows users to specify addictional files which should be included in source distribution. Fix Version: 1.7 Environment: custom include list for source distribution patch (fixes missing checkstyle.xml) Key: MPDIST-15 URL: http://jira.codehaus.org/browse/MPDIST-15 Project: maven-dist-plugin Type: Bug Reporter: fabrizio giustina Assignee: fabrizio giustina Fix For: 1.7 Attachments: MPDIST-15.diff Original Estimate: 10 minutes Remaining: 10 minutes Actually the dist plugin includes in source distribution only a predefined list of files. When using a custom checkstyle.xml for the checkstyle report, the source distribution should include this file, elsewhere the site generation will fail complaining for the missing file. To address the issue in a more general way I am adding a new maven.dist.src.include property which allows users to specify addictional files which should be included in source distribution. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m1] [result] New Release managers for plugins
Hi all, I'm back. Sorry for the delay. Here is the list of plugins and the new release manager for each one : Abbot : To be decommissioned in sandbox ? Announcement : Lukas Ant: Arnaud Antlr : Artifact : Arnaud AspectJ: Castor : Changelog : Lukas Changes: Lukas Checkstyle : Carlos (always interested ?) Clean : Clover : Vincent M Console: Cruise Control : Dashboard : Developer Activity : Lukas Distribution : EAR: Stephan Eclipse: EJB: FAQ: Lukas File Activity : Lukas Genapp : Arnaud Gump : Hibernate : Html2XDoc : IDEA : Stephan J2EE : depended on by struts and ear, move the tag into ear Jalopy : Jar: Java : Javacc : Stephan Javadoc: Arnaud JBoss : JBuilder : To be decommissioned in sandbox ? JCoverage : JDepend: JDiff : JellyDoc : Jetty : JIRA : JNLP : JUnit Report : JXR: License: LinkCheck : MultiChanges : Multi-Project : Lukas Native : NSIS : PDF: Arnaud Plugin : Lukas PMD: POM: Lukas RAR: Stephan Release: moved used functionality to SCM plugin Repository : not being maintained (move upload-bundle to artifact plugin) SCM: Simian : Site : Lukas Tasklist : Test : Uberjar: WAR: XDoc : Arnaud For plugins without RM we'll share the work in the team. Any of us will be able to propose a release when he'll think it will be needed. New RMs are invited to update the poms and Jira. You can also help me to remove RM roles in plugins which doesn't have one. For Jira I don't think it is possible to don't have a owner for a project :-( (We could create a generic user for the maven team ?). If someone else want to take some others plugins (Felipe, Fabrizio ? For example ;-) ) let us know. I'll try to take some others if I have a little free time but I prefer to focus to the core from now to release ASAP the 1.1 beta 3. If some plugins are stable don't hesitate to begin to launch votes. We have a lot of plugins (almost all) to release before the 1.1 beta 3. Don't forget also to publish as often as possible new snapshots to allo wusers to test them. Thanks. Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 26 octobre 2005 22:28 À : 'Maven Developers List' Objet : RE: [m1] New Release managers for plugins Good eyes Lukas, I forgot this thread. Thanks Arnaud Is there some others plugins that should be moved to the sandbox ? This is what Brett noted when he last called for a vote to demote m1 plugins ( http://www.nabble.com/-vote-demote-plugins-t66370.html ): === Not to be removed now, but to get merged and removed by the final 1.1 release: - repository - not being maintained (move upload-bundle to artifact plugin) - release - moved used functionality to SCM plugin - j2ee - depended on by struts and ear, move the tag into ear Borderline (not included in this vote, but likely to be culled in future if they don't get fixed and nobody volunteers): - jbuilder (not of same level as other IDE plugins) - jcoverage (replaced by Corbetura) - jira - not working, no maintainer? - simian - not being maintained - jdiff - not being maintained === I think this should be considered now. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: standard form for commit messages
Hi, Can it be documented somewhere in m1/m2 sites ? Committers, can you try to follow it ? :-) I took a look at recent commits and it's not really used !! Arnaud Hi, I've noticed a few things going into commit messages, for which I usually use a standard form (that matches a template that used to exist in Apache's CVS). Basically, wehere applicable: PR: issue1, issue2 (using issue keys from JIRA, not URLs) Submitted by: (when it was a patch, put that persons name there) Reviewed by: (not sure if this is useful, but was in the template - who reviewed it) comment What do folks think of using this? I just find it a bit easier to parse when scanning, and also as we move to get JIRA including all our commits linked in issues the first part is especially helpful. Just a thought... don't know if we can have a template for SVN commit messages like CVS though. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-587) openutils-log4j 1.0
openutils-log4j 1.0 --- Key: MAVENUPLOAD-587 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-587 Project: maven-upload-requests Type: Task Reporter: fabrizio giustina -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)
Hi, I'll try to test it this week. I hope this not due to an incompability between jelly versions. Arnaud -Message d'origine- De : Lukas Theussl [mailto:[EMAIL PROTECTED] Envoyé : dimanche 13 novembre 2005 17:44 À : Maven Developers List Objet : Re: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together) Wendy, My patch only fixes the id problem, not the 1.0-1.1 incompatibility (I still haven't got a clue why this happens). You have to add the slashes though, if you can't do it in navigation.xml then you should use a separate pdf_navigation.xml (I would recommend that anyway). However, according to the maven docs [1], the href elements should be absolute even for the xdoc plugin and in a multiproject setup, I think that was the case already in m1.0. -Lukas [1] http://maven.apache.org/maven-1.x/using/site.html Wendy Smoak wrote: On 11/13/05, Lukas Theussl [EMAIL PROTECTED] wrote: I just committed a fix for this issue, can you check if it's ok? One thing though: in navigation.xml, you need to prepend the hrefs in the menu items by a slash, eg item name=Bean href=/tagreference-struts-bean.html/ Strange, I see no change at all. I updated from svn (and saw the change in fo-tables.xslt). Did maven plugin:install, deleted the cache, got rid of every copy of maven-pdf-plugin* that I could find, tried again with plugin:install, and after 'maven site pdf' the title is still Jakarta Maven with incorrect dates (tiles) and a build failure for duplicate ids (taglib). Assuming it works for you with Maven 1.0.2, what could I be missing? (I think adding / to those menu items would break the website, the taglib docs live one level down from the main site. But I see from the docs that you can have a separate navigation file for the pdf. No idea what's going to happen if I try to make a pdf of the entire multiproject site, though.) Thanks for all your work on this! -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1547) maven-one-plugin needs a configurable repositoryId
maven-one-plugin needs a configurable repositoryId -- Key: MNG-1547 URL: http://jira.codehaus.org/browse/MNG-1547 Project: Maven 2 Type: Bug Reporter: Brett Porter this would allow configurability of server settings -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1548) file/directory permissions and configuration should be configurable on a deployment repository in distributionManagement of POM
file/directory permissions and configuration should be configurable on a deployment repository in distributionManagement of POM --- Key: MNG-1548 URL: http://jira.codehaus.org/browse/MNG-1548 Project: Maven 2 Type: Improvement Components: maven-model Reporter: Brett Porter Fix For: 2.1 while it can be overridden from the settings.xml version, I think this should be configurable in 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Deleted: (MNG-1547) maven-one-plugin needs a configurable repositoryId
[ http://jira.codehaus.org/browse/MNG-1547?page=all ] Brett Porter deleted MNG-1547: -- maven-one-plugin needs a configurable repositoryId -- Key: MNG-1547 URL: http://jira.codehaus.org/browse/MNG-1547 Project: Maven 2 Type: Bug Reporter: Brett Porter this would allow configurability of server settings -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: standard form for commit messages
Yes, its already under the guide for contributing. - Brett Arnaud HERITIER wrote: Hi, Can it be documented somewhere in m1/m2 sites ? Committers, can you try to follow it ? :-) I took a look at recent commits and it's not really used !! Arnaud Hi, I've noticed a few things going into commit messages, for which I usually use a standard form (that matches a template that used to exist in Apache's CVS). Basically, wehere applicable: PR: issue1, issue2 (using issue keys from JIRA, not URLs) Submitted by: (when it was a patch, put that persons name there) Reviewed by: (not sure if this is useful, but was in the template - who reviewed it) comment What do folks think of using this? I just find it a bit easier to parse when scanning, and also as we move to get JIRA including all our commits linked in issues the first part is especially helpful. Just a thought... don't know if we can have a template for SVN commit messages like CVS though. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] [result] New Release managers for plugins
On 11/13/05, Arnaud HERITIER [EMAIL PROTECTED] wrote: If someone else want to take some others plugins (Felipe, Fabrizio ? For example ;-) ) let us know. you can add my name to the Eclipse plugin as a start, I will check if I can take other ones... fabrizio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1316) Dependency report breaks on systemPath artifacts
[ http://jira.codehaus.org/browse/MNG-1316?page=all ]
Brett Porter closed MNG-1316:
-
Assign To: Brett Porter
Resolution: Duplicate
Dependency report breaks on systemPath artifacts
Key: MNG-1316
URL: http://jira.codehaus.org/browse/MNG-1316
Project: Maven 2
Type: Bug
Components: maven-project-info-reports-plugin
Versions: 2.0
Reporter: Wilfred Springer
Assignee: Brett Porter
My project refers to several artifacts that have a systemPath element,
refering to jar files in the ${basedir}/lib directory. The projects builds
fine, but the dependency reports breaks when it starts processing these
dependencies.
java.lang.NullPointerException
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:380)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:346)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.getMavenProjectFromRepository(DependenciesReport.java:362)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:242)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:157)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:789)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1543) pom.xml information automatically included in META-INF during jar
[ http://jira.codehaus.org/browse/MNG-1543?page=all ]
Brett Porter updated MNG-1543:
--
Fix Version: 2.0.1
I thought this was fixed already - its related to the same issue in hte release
plugin.
pom.xml information automatically included in META-INF during jar
--
Key: MNG-1543
URL: http://jira.codehaus.org/browse/MNG-1543
Project: Maven 2
Type: Improvement
Components: maven-jar-plugin
Versions: 2.0
Reporter: Jorg Heymans
Fix For: 2.0.1
The jar plugin automatically adds a pom.xml in META-INF, which makes sense.
But this pom.xml also contains local paths ie
build
sourceDirectoryd:\src\excalibur-trunk\framework\api\src\java/sourceDirectory
scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory
testSourceDirectoryd:\src\excalibur-trunk\framework\api\src\test/testSourceDirectory
outputDirectoryd:\src\excalibur-trunk\framework\api\target\classes/outputDirectory
testOutputDirectoryd:\src\excalibur-trunk\framework\api\target\test-classes/testOutputDirectory
resources
resource
targetPathMETA-INF/targetPath
directoryd:\src\excalibur-trunk\framework\api\..\../directory
includes
includeLICENSE.txt/include
includeNOTICE.txt/include
/includes
/resource
/resources
testResources
testResource
directoryd:\src\excalibur-trunk\framework\api\src\test\resources/directory
I don't see how this information could be useful to anyone else, and i'ld
rather not have my local paths in distribution jars - call me paranoid :)
Conversation log from IRC :
jorgis there a way to tell maven not to include the pom.xml in
META-INF when creating jars ?
jesse hm, not that I know of
jesse might be a boolean to control it in there somewhere
jorgi looked at the jar plugin config .. didn't seem like it
jorgit's not a real problem, just funny that this is done by default
jesse I don't know, it makes it easier down the road to have
automated things interrogate the jar for dependencies of the things inside
trygvis yeah, you're right there jesse
jorgmmm well yes that makes sense ...
jorgthanks !
trygvis jorg: it's useful for the application itself
trygvis like reading out the version number from pom.properties
jorgtrygvis: yes, but the pom also had my local paths in it for
sourceDirectory and stuff, that's why i found it a bit strange
trygvis makes it easier making versioning-aware application and gives a
thigh integration with your project management tool (aka maven)
trygvis hm
trygvis that should possibly be changed indeed
trygvis File properties should be made relative to ${basedir} again
trygvis when writing out the pom that is
jorgi can understand about the dependencies , but the build
configuration probably shouldn't be in there
jorg
directoryd:\src\excalibur-trunk\framework\api\..\../directory
trygvis jorg: file an issue, it should be relative to ${basedir} if
there at all
trygvis IMO the build parts of a pom could be stripped from the repo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: standard form for commit messages
Ok, Thanks Brett, Arnaud -Message d'origine- De : Brett Porter [mailto:[EMAIL PROTECTED] Envoyé : lundi 14 novembre 2005 00:09 À : Maven Developers List Objet : Re: standard form for commit messages Yes, its already under the guide for contributing. - Brett Arnaud HERITIER wrote: Hi, Can it be documented somewhere in m1/m2 sites ? Committers, can you try to follow it ? :-) I took a look at recent commits and it's not really used !! Arnaud Hi, I've noticed a few things going into commit messages, for which I usually use a standard form (that matches a template that used to exist in Apache's CVS). Basically, wehere applicable: PR: issue1, issue2 (using issue keys from JIRA, not URLs) Submitted by: (when it was a patch, put that persons name there) Reviewed by: (not sure if this is useful, but was in the template - who reviewed it) comment What do folks think of using this? I just find it a bit easier to parse when scanning, and also as we move to get JIRA including all our commits linked in issues the first part is especially helpful. Just a thought... don't know if we can have a template for SVN commit messages like CVS though. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-472) multiple execution/'s with no goals not considered when running a goal directly from the CLI
[ http://jira.codehaus.org/browse/MNG-472?page=comments#action_50828 ] Brett Porter commented on MNG-472: -- Jesse - is that a bug or something that needs to be documented? It'll get lost in this closed issue, so please either file a new issue or create a doc (with an example, as I have no idea what you are talking about here pre-coffee :) multiple execution/'s with no goals not considered when running a goal directly from the CLI -- Key: MNG-472 URL: http://jira.codehaus.org/browse/MNG-472 Project: Maven 2 Type: Bug Components: maven-core Reporter: John Casey Priority: Critical assume you specify a plugin in the pom with multiple execution/ sections, each containing configurations. It should be possible to directly invoke a goal within this plugin, and have that goal run once per execution, despite the fact that the goal is not explicitly specified in the execution/. This is not the case now. Workaround: specify the goal for each execution in which you want it to run. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m1] [result] New Release managers for plugins
Fabrizio added for the eclipse plugin. Arnaud Hi all, I'm back. Sorry for the delay. Here is the list of plugins and the new release manager for each one : Abbot : To be decommissioned in sandbox ? Announcement : Lukas Ant: Arnaud Antlr : Artifact : Arnaud AspectJ: Castor : Changelog : Lukas Changes: Lukas Checkstyle : Carlos (always interested ?) Clean : Clover : Vincent M Console: Cruise Control : Dashboard : Developer Activity : Lukas Distribution : EAR: Stephan Eclipse: Fabrizio EJB: FAQ: Lukas File Activity : Lukas Genapp : Arnaud Gump : Hibernate : Html2XDoc : IDEA : Stephan J2EE : depended on by struts and ear, move the tag into ear Jalopy : Jar: Java : Javacc : Stephan Javadoc: Arnaud JBoss : JBuilder : To be decommissioned in sandbox ? JCoverage : JDepend: JDiff : JellyDoc : Jetty : JIRA : JNLP : JUnit Report : JXR: License: LinkCheck : MultiChanges : Multi-Project : Lukas Native : NSIS : PDF: Arnaud Plugin : Lukas PMD: POM: Lukas RAR: Stephan Release: moved used functionality to SCM plugin Repository : not being maintained (move upload-bundle to artifact plugin) SCM: Simian : Site : Lukas Tasklist : Test : Uberjar: WAR: XDoc : Arnaud For plugins without RM we'll share the work in the team. Any of us will be able to propose a release when he'll think it will be needed. New RMs are invited to update the poms and Jira. You can also help me to remove RM roles in plugins which doesn't have one. For Jira I don't think it is possible to don't have a owner for a project :-( (We could create a generic user for the maven team ?). If someone else want to take some others plugins (Felipe, Fabrizio ? For example ;-) ) let us know. I'll try to take some others if I have a little free time but I prefer to focus to the core from now to release ASAP the 1.1 beta 3. If some plugins are stable don't hesitate to begin to launch votes. We have a lot of plugins (almost all) to release before the 1.1 beta 3. Don't forget also to publish as often as possible new snapshots to allo wusers to test them. Thanks. Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 26 octobre 2005 22:28 À : 'Maven Developers List' Objet : RE: [m1] New Release managers for plugins Good eyes Lukas, I forgot this thread. Thanks Arnaud Is there some others plugins that should be moved to the sandbox ? This is what Brett noted when he last called for a vote to demote m1 plugins ( http://www.nabble.com/-vote-demote-plugins-t66370.html ): === Not to be removed now, but to get merged and removed by the final 1.1 release: - repository - not being maintained (move upload-bundle to artifact plugin) - release - moved used functionality to SCM plugin - j2ee - depended on by struts and ear, move the tag into ear Borderline (not included in this vote, but likely to be culled in future if they don't get fixed and nobody volunteers): - jbuilder (not of same level as other IDE plugins) - jcoverage (replaced by Corbetura) - jira - not working, no maintainer? - simian - not being maintained - jdiff - not being maintained === I think this should be considered now. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJIRA-4) issueTrackingUrl must contain an id attribute
[ http://jira.codehaus.org/browse/MPJIRA-4?page=all ] fabrizio giustina closed MPJIRA-4: -- Assign To: fabrizio giustina (was: Emmanuel Venisse) Resolution: Fixed Fix Version: 1.2 Fixed by downloading the project page and extracting a project id from it issueTrackingUrl must contain an id attribute - Key: MPJIRA-4 URL: http://jira.codehaus.org/browse/MPJIRA-4 Project: maven-jira-plugin Type: Bug Versions: 1.1 Reporter: Paul Spencer Assignee: fabrizio giustina Fix For: 1.2 Although the following URLs are equivelement, only the one containing the id attribute will work with the JIRA plugin. http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10492 http://nagoya.apache.org/jira/browse/JS2 When using http://nagoya.apache.org/jira/browse/JS2; for the issueTrackerUrl the following error is received. Notice the pid attribute on the url. Downloading http://nagoya.apache.org/jira/browse/secure/IssueNavigator.jspa?view=rsspid=p://nagoya.apache.org/jira/browse/JS2sorter/field=issuekeysorter/order=DESCsorter/field=statussorter/order=DESCtempMax=1000reset=true Received: [404] for http://nagoya.apache.org/jira/browse/secure/IssueNavigator.jspa?view=rsspid=p://nagoya.apache.org/jira/browse/JS2sorter/field=issuekeysorter/order=DESCsorter/field=statussorter/order=DESCtempMax=1000reset=true Received: [404] for http://nagoya.apache.org/jira/browse/secure/IssueNavigator.jspa?view=rsspid=p://nagoya.apache.org/jira/browse/JS2sorter/field=issuekeysorter/order=DESCsorter/field=statussorter/order=DESCtempMax=1000reset=true BUILD FAILED File.. c:\maven_repo\1.0-rc4\cache\maven-xdoc-plugin-1.7.2\plugin.jelly Element... x:parse Line.. 119 Column 48 Error on line 27 of document file:/C:/cvs_apache/jakarta-jetspeed-2/target/jira/jira-results.xml : The element type link must be terminated by the matching end-tag /link. Nested exception: The element type link must be terminated by the matching end-tag /link. Total time: 4 seconds Finished at: Sat Jul 10 05:31:54 EDT 2004 C:\cvs_apache\jakarta-jetspeed-2 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1] [result] New Release managers for plugins
Can this go on the wiki somewhere? - Brett Arnaud HERITIER wrote: Fabrizio added for the eclipse plugin. Arnaud Hi all, I'm back. Sorry for the delay. Here is the list of plugins and the new release manager for each one : Abbot : To be decommissioned in sandbox ? Announcement : Lukas Ant: Arnaud Antlr : Artifact : Arnaud AspectJ: Castor : Changelog : Lukas Changes: Lukas Checkstyle : Carlos (always interested ?) Clean : Clover : Vincent M Console: Cruise Control : Dashboard : Developer Activity : Lukas Distribution : EAR: Stephan Eclipse: Fabrizio EJB: FAQ: Lukas File Activity : Lukas Genapp : Arnaud Gump : Hibernate : Html2XDoc : IDEA : Stephan J2EE : depended on by struts and ear, move the tag into ear Jalopy : Jar: Java : Javacc : Stephan Javadoc: Arnaud JBoss : JBuilder : To be decommissioned in sandbox ? JCoverage : JDepend: JDiff : JellyDoc : Jetty : JIRA : JNLP : JUnit Report : JXR: License: LinkCheck : MultiChanges : Multi-Project : Lukas Native : NSIS : PDF: Arnaud Plugin : Lukas PMD: POM: Lukas RAR: Stephan Release: moved used functionality to SCM plugin Repository : not being maintained (move upload-bundle to artifact plugin) SCM: Simian : Site : Lukas Tasklist : Test : Uberjar: WAR: XDoc : Arnaud For plugins without RM we'll share the work in the team. Any of us will be able to propose a release when he'll think it will be needed. New RMs are invited to update the poms and Jira. You can also help me to remove RM roles in plugins which doesn't have one. For Jira I don't think it is possible to don't have a owner for a project :-( (We could create a generic user for the maven team ?). If someone else want to take some others plugins (Felipe, Fabrizio ? For example ;-) ) let us know. I'll try to take some others if I have a little free time but I prefer to focus to the core from now to release ASAP the 1.1 beta 3. If some plugins are stable don't hesitate to begin to launch votes. We have a lot of plugins (almost all) to release before the 1.1 beta 3. Don't forget also to publish as often as possible new snapshots to allo wusers to test them. Thanks. Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 26 octobre 2005 22:28 À : 'Maven Developers List' Objet : RE: [m1] New Release managers for plugins Good eyes Lukas, I forgot this thread. Thanks Arnaud Is there some others plugins that should be moved to the sandbox ? This is what Brett noted when he last called for a vote to demote m1 plugins ( http://www.nabble.com/-vote-demote-plugins-t66370.html ): === Not to be removed now, but to get merged and removed by the final 1.1 release: - repository - not being maintained (move upload-bundle to artifact plugin) - release - moved used functionality to SCM plugin - j2ee - depended on by struts and ear, move the tag into ear Borderline (not included in this vote, but likely to be culled in future if they don't get fixed and nobody volunteers): - jbuilder (not of same level as other IDE plugins) - jcoverage (replaced by Corbetura) - jira - not working, no maintainer? - simian - not being maintained - jdiff - not being maintained === I think this should be considered now. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
making behaviour of ide plugins consistent
Hi, Can we discuss how to make the ide plugins behave consistently? It appears that, in particular, there are a lot of discussions about Eclipse and direct project references, and as I'm not a user I don't really follow them - but I'm concerned that they might be arriving at a different solution to what is already in place for the idea plugin. So, could folks provide feedback on this strategy, and if there are any other places that might differ (eg source/javadoc binding), please comment on that. For project references: the idea plugin uses a reference if and only if the project exists in the reactor - ie, you run it from the root and it creates all the files and the single project file. If run from a subdirectory later, it will not create a link, but use the JAR from the repository. I think I'd want to enhance that to use a reference if it is found in the USD/workspace - but that's not there just yet as there isn't an API for the USD, it's only used in finding parent POMs. Thoughts? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1549) metadata needs different policy to releases
metadata needs different policy to releases - Key: MNG-1549 URL: http://jira.codehaus.org/browse/MNG-1549 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Fix For: 2.0.1 currently, metadata is looked for updates on the same interval as releases. However, if that is never (which is valid if you want a purely snapshot repository), then finding out the available snapshot versions is impossible. The metadata update policy probably should not be individually configurable, as that would be confusing, but instead should be the more frequent of snapshots and releases, and the more permissive of thetwo checksum policies. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPSCM-68) Update maven-scm deps to latest (alpha-4)
[ http://jira.codehaus.org/browse/MPSCM-68?page=comments#action_50831 ] Arnaud Heritier commented on MPSCM-68: -- These jars aren't available in maven 1 repo : http://www.ibiblio.org/maven/org.apache.maven.scm/jars/ Update maven-scm deps to latest (alpha-4) - Key: MPSCM-68 URL: http://jira.codehaus.org/browse/MPSCM-68 Project: maven-scm-plugin Type: Task Reporter: Emmanuel Venisse Fix For: 1.6 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1550) save checksum in local repository
save checksum in local repository - Key: MNG-1550 URL: http://jira.codehaus.org/browse/MNG-1550 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Fix For: 2.0.1 when a file is downloaded, the checksum is verified, but not saved in the local repository. It should also be copied when the download was valid and the checksum succeeded. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - checkout] Mon Nov 14 00:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051114.001500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051114.001500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1551) create a deploy:deploy-file goal
create a deploy:deploy-file goal Key: MNG-1551 URL: http://jira.codehaus.org/browse/MNG-1551 Project: Maven 2 Type: Improvement Components: maven-deploy-plugin Reporter: Brett Porter Fix For: 2.0.1 this should partner the install:install-file goal, but deploy to a remote repository. It will be very similar to the goal in the maven-one-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPSCM-69) Remove scmurl page and use http://maven.apache.org/scm/scm-url-format.html instead
[ http://jira.codehaus.org/browse/MPSCM-69?page=all ] Arnaud Heritier closed MPSCM-69: Assign To: Arnaud Heritier Resolution: Fixed done. Remove scmurl page and use http://maven.apache.org/scm/scm-url-format.html instead -- Key: MPSCM-69 URL: http://jira.codehaus.org/browse/MPSCM-69 Project: maven-scm-plugin Type: Task Reporter: Emmanuel Venisse Assignee: Arnaud Heritier Fix For: 1.6 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-201) should have dependency on org.relaxngdatatype.relaxngDatatype
should have dependency on org.relaxngdatatype.relaxngDatatype - Key: MEV-201 URL: http://jira.codehaus.org/browse/MEV-201 Project: Maven Evangelism Type: Bug Reporter: Adam Hardy org.relaxng is actually org.relaxngdatatype -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-202) dependency wrong
dependency wrong Key: MEV-202 URL: http://jira.codehaus.org/browse/MEV-202 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Adam Hardy javax.xml.namespace doesn't exist on ibiblio and javax.xml.xsdlib is xsdlib.xsdlib -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r333087 - /maven/maven-1/plugins/trunk/site/plugin.jelly
Hi Fabrizio,
Can you note it in the changes file
Thx
Arnaud
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 13 novembre 2005 19:33
À : commits@maven.apache.org
Objet : svn commit: r333087 -
/maven/maven-1/plugins/trunk/site/plugin.jelly
Author: fgiust
Date: Sun Nov 13 10:33:13 2005
New Revision: 333087
URL: http://svn.apache.org/viewcvs?rev=333087view=rev
Log:
don't change permissions on the home dir but only on
contained files/directories.
The home dir is not created/overwritten by the site deploy so
its permissions should not be changed (the build failed if
the users couldn't change permissions on this directory)
Modified:
maven/maven-1/plugins/trunk/site/plugin.jelly
Modified: maven/maven-1/plugins/trunk/site/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/site
/plugin.jelly?rev=333087r1=333086r2=333087view=diff
==
--- maven/maven-1/plugins/trunk/site/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/site/plugin.jelly Sun Nov 13 10:33:13
+++ 2005
@@ -143,10 +143,10 @@
remotedir=${siteDirectory}/
ftp server=${siteAddress}
depends=true
- userid=${siteUsername}
- password=${maven.password}
- remotedir=${siteDirectory}
- chmod=${maven.site.chmod.mode}
+ userid=${siteUsername}
+ password=${maven.password}
+ remotedir=${siteDirectory}
+ chmod=${maven.site.chmod.mode}
fileset dir=${docsDest} includes=**/*.*/
/ftp
@@ -193,7 +193,7 @@
/exec
echoUpdating files modes on the remote host/echo
exec dir=. executable=${maven.ssh.executable}
failonerror=${maven.site.failonerror}
- arg line=${maven.ssh.args} -l ${siteUsername}
${siteAddress} 'cd ${maven.homepage} amp;amp; chmod
${maven.site.chmod.options} ${maven.site.chmod.mode} * .'/
+ arg line=${maven.ssh.args} -l ${siteUsername} ${siteAddress}
+ 'cd ${maven.homepage} amp;amp; chmod ${maven.site.chmod.options}
+ ${maven.site.chmod.mode} * ./*'/
/exec
echoDeleting remote archive/echo
exec dir=. executable=${maven.ssh.executable}
failonerror=${maven.site.failonerror}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r331014 - /maven/maven-1/plugins/trunk/eclipse/plugin.jelly
Hi Fabrizio,
Can you update the changes file and the goals documentation please ?
Arnaud
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : samedi 5 novembre 2005 19:44
À : commits@maven.apache.org
Objet : svn commit: r331014 -
/maven/maven-1/plugins/trunk/eclipse/plugin.jelly
Author: fgiust
Date: Sat Nov 5 10:44:25 2005
New Revision: 331014
URL: http://svn.apache.org/viewcvs?rev=331014view=rev
Log:
adding an eclipse:eclipse alias for the eclipse goal
(same name as mvn).
Reformatting the whole file - sorry for all these
modifications in the diff but the formatting was wrong and
manually adjusted, now the file can be formatted automatically
Modified:
maven/maven-1/plugins/trunk/eclipse/plugin.jelly
Modified: maven/maven-1/plugins/trunk/eclipse/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/ecli
pse/plugin.jelly?rev=331014r1=331013r2=331014view=diff
==
--- maven/maven-1/plugins/trunk/eclipse/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/eclipse/plugin.jelly Sat Nov
5 10:44:25
+++ 2005
@@ -1,183 +1,158 @@
?xml version=1.0?
!--
-/*
- * Copyright 2001-2004 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the License);
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in
writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
- * See the License for the specific language governing
permissions and
- * limitations under the License.
- */
- --
-
-
-project
- xmlns:j=jelly:core
- xmlns:ant=jelly:ant
- xmlns:test=test
- xmlns:util=jelly:util
- xmlns:define=jelly:define
- xmlns:maven=jelly:maven
-
-
+ /*
+ * Copyright 2001-2005 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in
writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
+ * See the License for the specific language governing
permissions and
+ * limitations under the License.
+ */
+--
+project xmlns:j=jelly:core xmlns:ant=jelly:ant
xmlns:test=test xmlns:util=jelly:util
+ xmlns:define=jelly:define xmlns:maven=jelly:maven
define:taglib uri=eclipse
define:tag name=write-classpath-entry
- maven:param-check value=${groupId} fail=true
message='groupId' must be specified/
- maven:param-check value=${artifactId} fail=true
message='artifactId' must be specified/
- maven:param-check value=${version} fail=false
message='version' should be specified for artifact
${groupId}.${artifactId}/
+ maven:param-check value=${groupId} fail=true
message='groupId' must be specified /
+ maven:param-check value=${artifactId} fail=true
message='artifactId' must be specified /
+ maven:param-check value=${version} fail=false
+message='version' should be specified for artifact
+ ${groupId}.${artifactId} /
!-- relativePath is optional, used for jar override --
-
j:set var=relativePathCheck value=${relativePath}X /
j:if test='${relativePathCheck == X}'
- j:set var=relativePath
value=${groupId}/jars/${artifactId}-${version}.jar /
+j:set var=relativePath
+ value=${groupId}/jars/${artifactId}-${version}.jar /
/j:if
-
!--
- should be (m1 repo layout):
-
${groupId}/java-sources/${artifactId}-${version}-sources.jar
- --
+should be (m1 repo layout):
+${groupId}/java-sources/${artifactId}-${version}-sources.jar
+ --
!-- deprecated: check it first and use it if
available, elsewhere set the new path --
- j:set var=mappedsrc
value=${groupId}/src/${artifactId}-${version}.${maven.eclipse
.src.extension}/
-
- util:file var=srcFile
name=${maven.repo.local}/${mappedsrc}/
+ j:set var=mappedsrc
value=${groupId}/src/${artifactId}-${version}.${maven.eclipse
.src.extension} /
+ util:file var=srcFile
name=${maven.repo.local}/${mappedsrc}
+ /
j:choose
j:when test=${srcFile.exists()}
- ant:echodeprecated: java sources for
${artifactId} found at MAVEN_REPO/${mappedsrc}, please use
the path
MAVEN_REPO/${groupId}/java-sources/${artifactId}-${version}-so
Re: making behaviour of ide plugins consistent
In my opinion, giving the choise to the individual developer would be the best solution. When plugins tries to get too smart they often fail, and a lot of discussions appear. It should not be the responsibility of the plugin writer to tell people how they must manage their IDE's projects. Rather the plugin writers should provide good default behaviour and then allow the users of the plugin to change that behaviour if it does not suit their needs. Lets take a project i am in as an example: We have currently 22 modules/projects in our reactor, and our developers works on one or possible 2 or 3 concurrently. Due to how the eclipse plugin currently works each developer needs to have their workspace cluttered with 20 projects they are not working on, and really don't care about. As the one respopnsible of introducing maven to the team, I do come short of explaining to them why they have to have all the projects open. And if some of you out there could come up with the answer here, then honestly you are not really listening to what they are saying. And as i am sayning in the issue http://jira.codehaus.org/browse/MNG-955 Why do we really need to make this so difficult. So to make a long story short. My opinion is: Yes it would be a good idea to have the plugins behave consistenly, they perhaps could share a configuration object that holds the common settings. Then supply good default behaviour (where i really do think the current eclipseplugin does a good job). And finally let the users choose how they want to use it. On 14/11/05, Brett Porter [EMAIL PROTECTED] wrote: Hi, Can we discuss how to make the ide plugins behave consistently? It appears that, in particular, there are a lot of discussions about Eclipse and direct project references, and as I'm not a user I don't really follow them - but I'm concerned that they might be arriving at a different solution to what is already in place for the idea plugin. So, could folks provide feedback on this strategy, and if there are any other places that might differ (eg source/javadoc binding), please comment on that. For project references: the idea plugin uses a reference if and only if the project exists in the reactor - ie, you run it from the root and it creates all the files and the single project file. If run from a subdirectory later, it will not create a link, but use the JAR from the repository. I think I'd want to enhance that to use a reference if it is found in the USD/workspace - but that's not there just yet as there isn't an API for the USD, it's only used in finding parent POMs. Thoughts? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
Yes, I definitely agree with that. This discussion should be about the default, but be configurable. So, you say the eclipse plugin does well - is it the same or different to the idea plugin as I described it? - Brett Kaare Nilsen wrote: Then supply good default behaviour (where i really do think the current eclipseplugin does a good job). And finally let the users choose how they want to use it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m1] [result] New Release managers for plugins
I began this page. http://docs.codehaus.org/display/MAVEN/Maven+1.X+plugins You (maven-developers) can edit it if needed. Thx Arnaud -Message d'origine- De : Brett Porter [mailto:[EMAIL PROTECTED] Envoyé : lundi 14 novembre 2005 00:55 À : Maven Developers List Objet : Re: [m1] [result] New Release managers for plugins Can this go on the wiki somewhere? - Brett Arnaud HERITIER wrote: Fabrizio added for the eclipse plugin. Arnaud Hi all, I'm back. Sorry for the delay. Here is the list of plugins and the new release manager for each one : Abbot : To be decommissioned in sandbox ? Announcement : Lukas Ant: Arnaud Antlr : Artifact : Arnaud AspectJ: Castor : Changelog : Lukas Changes: Lukas Checkstyle : Carlos (always interested ?) Clean : Clover : Vincent M Console: Cruise Control : Dashboard : Developer Activity : Lukas Distribution : EAR: Stephan Eclipse: Fabrizio EJB: FAQ: Lukas File Activity : Lukas Genapp : Arnaud Gump : Hibernate : Html2XDoc : IDEA : Stephan J2EE : depended on by struts and ear, move the tag into ear Jalopy : Jar: Java : Javacc : Stephan Javadoc: Arnaud JBoss : JBuilder : To be decommissioned in sandbox ? JCoverage : JDepend: JDiff : JellyDoc : Jetty : JIRA : JNLP : JUnit Report : JXR: License: LinkCheck : MultiChanges : Multi-Project : Lukas Native : NSIS : PDF: Arnaud Plugin : Lukas PMD: POM: Lukas RAR: Stephan Release: moved used functionality to SCM plugin Repository : not being maintained (move upload-bundle to artifact plugin) SCM: Simian : Site : Lukas Tasklist : Test : Uberjar: WAR: XDoc : Arnaud For plugins without RM we'll share the work in the team. Any of us will be able to propose a release when he'll think it will be needed. New RMs are invited to update the poms and Jira. You can also help me to remove RM roles in plugins which doesn't have one. For Jira I don't think it is possible to don't have a owner for a project :-( (We could create a generic user for the maven team ?). If someone else want to take some others plugins (Felipe, Fabrizio ? For example ;-) ) let us know. I'll try to take some others if I have a little free time but I prefer to focus to the core from now to release ASAP the 1.1 beta 3. If some plugins are stable don't hesitate to begin to launch votes. We have a lot of plugins (almost all) to release before the 1.1 beta 3. Don't forget also to publish as often as possible new snapshots to allo wusers to test them. Thanks. Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 26 octobre 2005 22:28 À : 'Maven Developers List' Objet : RE: [m1] New Release managers for plugins Good eyes Lukas, I forgot this thread. Thanks Arnaud Is there some others plugins that should be moved to the sandbox ? This is what Brett noted when he last called for a vote to demote m1 plugins ( http://www.nabble.com/-vote-demote-plugins-t66370.html ): === Not to be removed now, but to get merged and removed by the final 1.1 release: - repository - not being maintained (move upload-bundle to artifact plugin) - release - moved used functionality to SCM plugin - j2ee - depended on by struts and ear, move the tag into ear Borderline (not included in this vote, but likely to be culled in future if they don't get fixed and nobody volunteers): - jbuilder (not of same level as other IDE plugins) - jcoverage (replaced by Corbetura) - jira - not working, no maintainer? - simian - not being maintained - jdiff - not being maintained === I think this should be considered now. -Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
Re: making behaviour of ide plugins consistent
Well, no.. I think that what you are describing is somewhat to magical for me ;) You say that the idea plugin creates different projects depending on where you run the command, i personally finds that very confusing. In my opinion a plugin after configured in the module pom (or a parent) should behave consistently, and create equivalent projects on every run, not depending on where the command is executed. The eclipse plugin creates project references if they share the same parent pom (i have seen there are ppl out there struggeling with that, but in my experience it works) no matter if you run the plugin from the root or in a subdirectory. Personally i find this to be a more consise solution. hehe, i litteraly can se my self trying to explain it to a coworker. Oh.. yeah.. by the way. please do remember to check where your run your project generation. The result may vary, and then i can imagine the look of confusion i would get back ;) So If an IDE project is generated for a module in a multimodule project, it should always by default use project references. But then again. perhaps the notion of project generation strategy would be a cool common setting. like this (using one of the values inside[] ) ... configuration projectReferenceStrategy [direct,directIfSameVersion,repsitory,snapshot-repository] /projectReferenceStrategy ... On 14/11/05, Brett Porter [EMAIL PROTECTED] wrote: Yes, I definitely agree with that. This discussion should be about the default, but be configurable. So, you say the eclipse plugin does well - is it the same or different to the idea plugin as I described it? - Brett Kaare Nilsen wrote: Then supply good default behaviour (where i really do think the current eclipseplugin does a good job). And finally let the users choose how they want to use it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1552) finish introduction to pom
finish introduction to pom -- Key: MNG-1552 URL: http://jira.codehaus.org/browse/MNG-1552 Project: Maven 2 Type: Task Components: documentation - introductions Reporter: Brett Porter http://maven.apache.org/guides/introduction/introduction-to-the-pom.html seems to be a placeholder -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-986) add configurable powered by logo
[ http://jira.codehaus.org/browse/MNG-986?page=all ] Johnny R. Ruiz III updated MNG-986: --- Attachment: MNG-986-maven-site-plugin-2.patch Here's another patch, this may be patch or just the first one. - The difference on the first patch is it follows the Maven 1 Xdoc Plugin convention mentioned by Lukas. powered-by item name=Powered By Bulldozer href=http://www.bulldozer.net; img=maven-bulldozer.png/ /powered-by Please apply whatever is more suitable. Thanks. add configurable powered by logo Key: MNG-986 URL: http://jira.codehaus.org/browse/MNG-986 Project: Maven 2 Type: Improvement Components: maven-site-plugin Reporter: Brett Porter Assignee: Johnny R. Ruiz III Priority: Minor Fix For: 2.0.1 Attachments: MNG-986-maven-site-plugin-2.patch, MNG-986-maven-site-plugin.patch -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1553) ability to retreive starteam username/password from settings.xml in maven-release-plugin
ability to retreive starteam username/password from settings.xml in maven-release-plugin Key: MNG-1553 URL: http://jira.codehaus.org/browse/MNG-1553 Project: Maven 2 Type: Improvement Components: maven-release-plugin Environment: staream, xp Reporter: Dan Tran Fix For: 2.0.1 Attachments: patch.diff Per discussion with Brett, we should strive to make this happen. Basically, in the prepare mojo, instead of call getScm() in the abstract base class, getPrepareScm is call which does a special check to load username/password using startteam's host:port as the key. Feed back on this is greatly appreciated Sorry I am not able to do the same for SVN untill SvnRepository provide a way for me to retreive a unique host address -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1550) save checksum in local repository
[ http://jira.codehaus.org/browse/MNG-1550?page=all ] Edwin Punzalan updated MNG-1550: Attachment: MNG-1550-maven-artifact-manager.patch save checksum in local repository - Key: MNG-1550 URL: http://jira.codehaus.org/browse/MNG-1550 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1550-maven-artifact-manager.patch when a file is downloaded, the checksum is verified, but not saved in the local repository. It should also be copied when the download was valid and the checksum succeeded. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1489) test repository connection first time (get a file at / ?) for better error reporting
[ http://jira.codehaus.org/browse/MNG-1489?page=all ] Edwin Punzalan updated MNG-1489: Attachment: MNG-1489-maven-artifact.patch test repository connection first time (get a file at / ?) for better error reporting Key: MNG-1489 URL: http://jira.codehaus.org/browse/MNG-1489 Project: Maven 2 Type: Improvement Reporter: Brett Porter Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1489-maven-artifact-manager.patch, MNG-1489-maven-artifact.patch if a particular remote repository is being used to download from for the first time, test the retrieval of a known file so that missing proxies/unreachable repo can be better diagnosed (this may be possible to do as part of the first request instead). Currently, users receive the error that a particular plugin can't be found. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1489) test repository connection first time (get a file at / ?) for better error reporting
[ http://jira.codehaus.org/browse/MNG-1489?page=all ] Edwin Punzalan updated MNG-1489: Attachment: MNG-1489-maven-artifact-manager.patch test repository connection first time (get a file at / ?) for better error reporting Key: MNG-1489 URL: http://jira.codehaus.org/browse/MNG-1489 Project: Maven 2 Type: Improvement Reporter: Brett Porter Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1489-maven-artifact-manager.patch, MNG-1489-maven-artifact.patch if a particular remote repository is being used to download from for the first time, test the retrieval of a known file so that missing proxies/unreachable repo can be better diagnosed (this may be possible to do as part of the first request instead). Currently, users receive the error that a particular plugin can't be found. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1553) ability to retreive starteam username/password from settings.xml in maven-release-plugin
[ http://jira.codehaus.org/browse/MNG-1553?page=all ] Dan Tran updated MNG-1553: -- Attachment: MNG-1553.patch Please discard the last patch, it has another patch i am working on that is not supposed to be included with this specific improment ability to retreive starteam username/password from settings.xml in maven-release-plugin Key: MNG-1553 URL: http://jira.codehaus.org/browse/MNG-1553 Project: Maven 2 Type: Improvement Components: maven-release-plugin Environment: staream, xp Reporter: Dan Tran Fix For: 2.0.1 Attachments: MNG-1553.patch, patch.diff Per discussion with Brett, we should strive to make this happen. Basically, in the prepare mojo, instead of call getScm() in the abstract base class, getPrepareScm is call which does a special check to load username/password using startteam's host:port as the key. Feed back on this is greatly appreciated Sorry I am not able to do the same for SVN untill SvnRepository provide a way for me to retreive a unique host address -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1553) ability to retreive starteam username/password from settings.xml in maven-release-plugin
[ http://jira.codehaus.org/browse/MNG-1553?page=comments#action_50852 ] Dan Tran commented on MNG-1553: --- MNG-1533.patch is the correct one ability to retreive starteam username/password from settings.xml in maven-release-plugin Key: MNG-1553 URL: http://jira.codehaus.org/browse/MNG-1553 Project: Maven 2 Type: Improvement Components: maven-release-plugin Environment: staream, xp Reporter: Dan Tran Fix For: 2.0.1 Attachments: MNG-1553.patch, patch.diff Per discussion with Brett, we should strive to make this happen. Basically, in the prepare mojo, instead of call getScm() in the abstract base class, getPrepareScm is call which does a special check to load username/password using startteam's host:port as the key. Feed back on this is greatly appreciated Sorry I am not able to do the same for SVN untill SvnRepository provide a way for me to retreive a unique host address -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-464) confusing error reported when using a non writable local directory
[ http://jira.codehaus.org/browse/MNG-464?page=all ] Edwin Punzalan updated MNG-464: --- Attachment: MNG-464-maven-artifact-manager.patch confusing error reported when using a non writable local directory -- Key: MNG-464 URL: http://jira.codehaus.org/browse/MNG-464 Project: Maven 2 Type: Improvement Components: maven-artifact Versions: 2.0-alpha-3 Reporter: Jerome Lacoste Assignee: Edwin Punzalan Priority: Minor Fix For: 2.0.1 Attachments: MNG-464-maven-artifact-manager.patch I was trying to share a repository between 2 users, and tried to do so before setting the repository permissions correctly. user1 created the repository user2 tried to do a build without having write access to repository the build failed with a confusing error. Something like: Caused by: java.io.FileNotFoundException: /usr/local/tools/share/m2/org/codehaus/cargo/cargo/0.6-SNAPSHOT/cargo-0.6-SNAPSHOT.version.txt (No such file or directory) (I don't have the exact log unfortunately, but it shouldn't be too hard to reproduce) I think a previous failure (e.g. couldn't write in a directory) was silently discarded. That error if treated appropriately could help better diagnose the issue. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-203) Add postgresql-8.1-404.jdbc3.jar to Maven 2 Repository
Add postgresql-8.1-404.jdbc3.jar to Maven 2 Repository -- Key: MEV-203 URL: http://jira.codehaus.org/browse/MEV-203 Project: Maven Evangelism Type: Wish Components: Dependencies Reporter: Matt Raible The latest version of PostgreSQL (8.0.4) does not work with the latest driver (8.0-312) in Maven's repository. Please upload the latest JDBC Driver so it's possible to use M2+PostgreSQL's latest database. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-204) Change jWebUnit's POM to depend on httpunit 1.6 since 1.5.4 throws errors
Change jWebUnit's POM to depend on httpunit 1.6 since 1.5.4 throws errors - Key: MEV-204 URL: http://jira.codehaus.org/browse/MEV-204 Project: Maven Evangelism Type: Wish Components: Invalid POM Reporter: Matt Raible Having 1.6 as the default will allow me to simplify and not have to specificy the upgraded HTTPUnit. My jWebUnit tests don't pass if I use the default HttpUnit, but do if I upgrade to 1.6. dependency artifactIdjwebunit/artifactId groupIdjwebunit/groupId version1.2/version scopetest/scope exclusions exclusion artifactIdservletapi/artifactId groupIdservletapi/groupId /exclusion /exclusions /dependency dependency groupIdhttpunit/groupId artifactIdhttpunit/artifactId version1.6/version scopetest/scope exclusions exclusion groupIdrhino/groupId artifactIdjs/artifactId /exclusion /exclusions /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-442) plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes
plexus.sh overwrites PLEXUS_OPTS, doesn't delegate processes Key: CONTINUUM-442 URL: http://jira.codehaus.org/browse/CONTINUUM-442 Project: Continuum Type: Bug Reporter: Brett Porter Fix For: 1.0.1 (if you can get it into 1.0.1) Make the following changes: PLEXUS_OPTS=$PLEXUS_OPTS -Xmx128m (to pass on plexus opts) ... exec $JAVACMD \ (to delegate process) This is required to get it running as a service from the plexus script. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-205) Upload iBATIS 2.1.6 to iBiblio
Upload iBATIS 2.1.6 to iBiblio -- Key: MEV-205 URL: http://jira.codehaus.org/browse/MEV-205 Project: Maven Evangelism Type: Improvement Reporter: Matt Raible http://ibatis.apache.org/downloads.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
