[jira] Commented: (MCHANGES-202) Enhance action-tag with a type attribute
[ http://jira.codehaus.org/browse/MCHANGES-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225414#action_225414 ] Michael Wenig commented on MCHANGES-202: There is a difference between the type of a change and the type of an issue. The existing type attribute is limited to 'add', 'update', 'fix' and 'remove' and expresses the kind of change at the source level. When you compare the sample changes report with the sample jira report ( http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html vs. http://maven.apache.org/plugins/maven-changes-plugin/jira-report.html) you can see that on the jira report for every change the type of issue is mentioned (Bug, New Feature, ...). The changes-report is only showing an image about the type and the possible types are predefined. SO there is no possibility to mention the type of the issue (like a UserStory) except entering it in the description. If you try to achieve a report like the jira-report using the changes.xml there is a missing issueType which is entered as text in the report (and perhaps the report is grouped by the issueType): Something like |[type-image]|UserStory|TEST-123|bla bla bla||micha|| Enhance action-tag with a type attribute Key: MCHANGES-202 URL: http://jira.codehaus.org/browse/MCHANGES-202 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: changes-report Affects Versions: 2.3 Reporter: Michael Wenig When using the manual created report there is only the possibility to set an issue id. it would be nice if there were also an attribute issueType (e.g. UserStory, Bug, ...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPIR-189) Allow configuration of mailing list header text.
[ http://jira.codehaus.org/browse/MPIR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPIR-189. -- Resolution: Fixed Please do not re-open issues that have been marked as fixed in released versions. Open a new issue instead. Allow configuration of mailing list header text. Key: MPIR-189 URL: http://jira.codehaus.org/browse/MPIR-189 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: mailing-list Reporter: SebbASF Assignee: Olivier Lamy Fix For: 2.2 The generated mailing list report has a header which provides basic info on the page. However, in some cases this information is not enough. For example, some lists may not allow posting; it would be useful to be able to explain why. In the case of Apache Commons, the lists are shared, so users need to add a prefix to the subject line. There are no doubt other use cases. It would be useful to be able to override the introduction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHANGES-201) Release-Notes
[
http://jira.codehaus.org/browse/MCHANGES-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225416#action_225416
]
Michael Wenig commented on MCHANGES-201:
A Release-Notes-Text should be rendered above the table with the changes. Using
a 'dummy action' (I call it dummy as it is no action directly related to an
issue or code-change but a ontainer for 'anything that has to do with this
release') the text would be rendered as a table row and is therefore not
popular enough. Additionally this would semantically be incorrect as an action
is defined as 'A single action done on the project, during this release' and is
not suitable for something the deployer has to keep in mind.
I would like to have a report like
* Release 123.*
Notes:
Be careful to run the migrationJob xyz after installing it!
An Update of the admins profile data is needed for this release. So
Changes:
|TEST-1|invent a new look and feel|
|TEST-2|Download of xyz is not possible|
...
I hope it is clear now.
Release-Notes
-
Key: MCHANGES-201
URL: http://jira.codehaus.org/browse/MCHANGES-201
Project: Maven 2.x Changes Plugin
Issue Type: Improvement
Components: changes-report
Affects Versions: 2.3
Reporter: Michael Wenig
Currently there is no ability to add some free text release notes for a
release (except than creating a dummy action).
It would be nice if there would be a possibility to add a further tag beyond
a release ('notes') which would be rendered in top of the list (perhaps using
WIKI-Syntax?)
Or provide a possibility to add a link to an apt-page.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-4710) Command line option to use dependency repositories
[ http://jira.codehaus.org/browse/MNG-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225418#action_225418 ] Carlo de Wolf commented on MNG-4710: Ideally the repositories introduced should be scoped to that artifact and its dependencies. Most likely this is too complex and turning it off is a reasonable alternative. Command line option to use dependency repositories -- Key: MNG-4710 URL: http://jira.codehaus.org/browse/MNG-4710 Project: Maven 2 3 Issue Type: New Feature Components: Artifacts and Repositories Reporter: Paul Gier Currently Maven allows dependency POMs to introduce repositories into the build. It would be better if this behaviour was turned off by default. Instead Maven could provide a command line option to enable dependencies to add repositories to the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-486) Site navigation not generated for submodules of multimodule project when site.xml defined in the parent
[ http://jira.codehaus.org/browse/MSITE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225432#action_225432 ] Matthias Wegerhoff commented on MSITE-486: -- Got a similar problem. When defining a site.xml in a seperate Project that is referenzed as parent in a second project everything (skin, breadcrumbs,...) gets inherited, except the menu ref=modules / entry which results in missing links to submodules. By adding a site.xml to every Project everything works fine, but trying to define a site-decriptor only for the parent results in the described problem. Site navigation not generated for submodules of multimodule project when site.xml defined in the parent --- Key: MSITE-486 URL: http://jira.codehaus.org/browse/MSITE-486 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.1, 2.1.1 Environment: Windows XP SP2, Sun/Oracle JDK 1.6, Maven 2.2.1 Reporter: Grzegorz Slowikowski Attachments: MSITE-486.zip Bug that manifests itself like http://jira.codehaus.org/browse/MSITE-456 but in different configuration. If you define src/site/site.xml file for the root module the navigation left menu in submodule is completely empty. After deleting this site.xml file everything works (maybe something has recently changed in this file content/structure requirements). Everything works without problems for 2.0.1 version of Maven site plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-141) Exception thrown when src/main/java directory does not exist
Exception thrown when src/main/java directory does not exist Key: MCHECKSTYLE-141 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-141 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.5 Environment: maven 2.2.1 Reporter: Joachim Van der Auwera Attachments: checkstyle-src.patch An exception is thrown when the src directory does not exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHECKSTYLE-142) add access to maven properties
add access to maven properties
--
Key: MCHECKSTYLE-142
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-142
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joachim Van der Auwera
Attachments: checkstyle-prop.patch
At least, access to ${basedir} inside the configuration files would be very
useful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-398) release:prepare: endlessly asking for the next development version on a multi-module project when not entering the expected value
[
http://jira.codehaus.org/browse/MRELEASE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225466#action_225466
]
Cliff Evans commented on MRELEASE-398:
--
This bug is still in version 2.0. What does it take to get things fixed around
here? Thorsten has supplied a patch, is it not good enough? Are there issues
with it? Is something more needed? I have no idea because there's no feedback
or activity on stuff around here.
release:prepare: endlessly asking for the next development version on a
multi-module project when not entering the expected value
-
Key: MRELEASE-398
URL: http://jira.codehaus.org/browse/MRELEASE-398
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-8
Environment: Maven 2.0.9
Windows XP SP3
JDK 1.6.0_11
Reporter: Thorsten Heit
Attachments: release-prepare-patch.txt
I'm working on a multi-module project that has dependencies to other modules
which were released recently. When trying to release my project,
release:prepare doesn't stop asking me for a dependency's next development
version as long as I'm entering a version string that doesn't equal the
expected one:
\\
{code}(...)
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve
them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Resolve Project Dependency Snapshots.: 'de.ukv.verbund.base:verbund-base' set
to release? (yes/no) yes: :
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
2.0.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
1.2.0-SNAPSHOT
What is the next development version? (1.2-SNAPSHOT) 1.2-SNAPSHOT: :
'de.ukv.verbund.form:verbund-form' set to release? (yes/no) yes: :
(...){code}
(see also bugs MRELEASE-158 and MRELEASE-269)
The solution for that behaviour is quite easy; see attached patch.
Note: I've seen this only when the release plugin asks for new versions of
snapshot dependencies, not when asking for the new version of the project
itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MPIR-198) introduction does not allow HTML markup
introduction does not allow HTML markup --- Key: MPIR-198 URL: http://jira.codehaus.org/browse/MPIR-198 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: mailing-list Affects Versions: 2.2 Reporter: SebbASF Further to http://jira.codehaus.org/browse/MPIR-189 the property does not seem to allow any markup. This is very limiting. HTML markup ought to be allowed, e.g. to allow a link to a page describing the e-mail etiquette etc. In particular for ASF projects there really needs to be a link to the Forum Archive Policy http://www.apache.org/foundation/public-archives.html The string can be specified with embedded markup if one uses the ![CDATA[ tag. But something in the code then escapes theso they appear as text in the generated page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (WAGON-309) NTLM for webdav behind IIS
NTLM for webdav behind IIS
--
Key: WAGON-309
URL: http://jira.codehaus.org/browse/WAGON-309
Project: Maven Wagon
Issue Type: Improvement
Components: wagon-webdav
Affects Versions: 1.0-beta-2
Environment: client: jdk1.5
server: iis 6, tomcat 5.5 and ssl
Reporter: Alessandro Gerlinger Romero
Priority: Minor
Attachments: wagon-webdav.zip
To use webdav over https with IIS 6, I changed two files to use NTCredentials.
It is compatible with basic authentication.
---
WebDavWagon.java
---
try
{
httpURL = urlToHttpURL( url );
/* - begin - before
if ( hasAuthentication )
{
String userName = authenticationInfo.getUserName();
String password = authenticationInfo.getPassword();
if ( userName != null password != null )
{
//httpURL.setUserinfo( userName, password );
webdavResource.setCredentials( new
NTCredentials(userName, password, saows1701.accenture.com, saows1701) );
}
}
- end - before
*/
CorrectedWebdavResource.setDefaultAction(
CorrectedWebdavResource.NOACTION );
webdavResource = new CorrectedWebdavResource( httpURL );
// begin - after
if ( hasAuthentication )
{
String userName = authenticationInfo.getUserName();
String password = authenticationInfo.getPassword();
if ( userName != null password != null )
{
//httpURL.setUserinfo( userName, password );
webdavResource.setCredentials( new
NTCredentials(userName, password, repository.getHost(), repository.getHost()) );
}
}
// end - after
---
CorrectedWebdavResource.java
---
/**
* FOWARD NTCREDENTIALS FOR EACH TRANSACTION
* It is compatible with basic authentication.
*
* @see
org.apache.webdav.lib.WebdavResource#generateTransactionHeader(org.apache.commons.httpclient.HttpMethod)
*/
protected void generateTransactionHeader(HttpMethod method) {
WebdavState state = (WebdavState) client.getState();
String host = null;
String realm = null;
if ( hostCredentials instanceof NTCredentials){
host = ((NTCredentials)hostCredentials).getHost();
realm = ((NTCredentials)hostCredentials).getDomain();
}
state.setCredentials(realm, host, hostCredentials);
super.generateTransactionHeader(method);
}
***
LIMITATIONS
***
Uses host as realm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-3198) ${basedir} variable makes portable builds overly difficult
[
http://jira.codehaus.org/browse/MNG-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225513#action_225513
]
Gili commented on MNG-3198:
---
Please reopen this issue!
${basedir} variable makes portable builds overly difficult
--
Key: MNG-3198
URL: http://jira.codehaus.org/browse/MNG-3198
Project: Maven 2 3
Issue Type: Bug
Components: Design, Patterns Best Practices, Logging, POM,
POM::Encoding, Profiles
Affects Versions: 2.0.7
Reporter: Andrew J. Leer
Assignee: Brett Porter
Attachments: SimpleTest21.tar, SimpleTest21.zip
Using log4j.xml I tried to use the resource filtering mechanism of Maven2 to
write log files to the directory:
${basedir}/logs
(in windows)
In the end the log files indeed do end up in the project directory, but not
the ./log directory.
Also the name of the log file becomes the path with all of the '\'
(${file.seprator}'s taken out of it:
For instance if the path to my log file was:
C:\dev\workspace\project\logs\project-1.0-dev_test.log
My log file would appear in ${basedir} and be called:
devworkspaceprojectlogsproject-1.0-dev_test.log
Thank you,
Andrew J. Leer
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2788) Remove artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225532#action_225532 ] Wendy Smoak commented on MAVENUPLOAD-2788: -- ... and we're starting to get questions about it on the Maven Users list. As Brett said, normally things are not removed from the central repo. No idea whether the maintainers will make an exception in this case, but one way forward is to release 2.0.1 with corrected poms. Remove artifacts Key: MAVENUPLOAD-2788 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2788 Project: Maven Upload Requests Issue Type: Wish Reporter: Blaine Simpson Simple directory removal request. I do not want a Maven Upload, but just to wipe some artifacts that you are already mirroring to ibiblio (so that I can fix them). I am only opening this issue under this project because there is no other relevant project to fix issues with artifacts already in place. I figure that the techs who can work Upload tickets should know how to get to the mock-ftp staging or ibiblio production servers and know where the maven2 artifacts reside there. My problem is, you already picked up, by rsync, my new resources for my new project version 2.0.0. There was a mistake in the .pom files which was discovered after your pick-up. Not a big deal with the .pom mistake-- I fixed that in 5 minutes. But your rsync pickup job refuses to modify existing hosted artifacts, very likely because of the --ignore-existing switch that you use for rsync. If you could just get on the staging or production servers as needed and wipe out all of the 2.0.0 subdirectories at the level http://repo2.maven.org/maven2/org/hsqldb/*/2.0.0/ , that should be all that is needed (there are 4 directories at the same exact level, all grandchildren of http://repo2.maven.org/maven2/org/hsqldb/). I have a lot of experience with rsync, and with UNIX and scripting generally, so let me know if I can help in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-664) Artifact in Repo without defined artifactId
Artifact in Repo without defined artifactId
---
Key: MEV-664
URL: http://jira.codehaus.org/browse/MEV-664
Project: Maven Evangelism
Issue Type: Bug
Reporter: Bryan Stopp
I was asked to post this after i sent a question on the mailing list. here's my
email to the users mailing list.
I'm experiencing a strange issue and discrepancy with Maven 2.2.1 and
the m2eclipse plugin.
This artifact:
org.hsqldb:hsqldb-j5:2.0.0:jar
has a pom in repo1.maven.org which does not have a defined artifactId.
The m2eclipse plugin successfully resolves the artifact and downloaded
it into my eclipse workspace. But when I go to build my application
using the command I get this error:
[ERROR] FATAL ERROR
[INFO]
--
--
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process.
Here is the information we do have for this artifact:
o GroupID: org.hsqldb
o ArtifactID: MISSING
o Version: 2.0.0
o Type:jar
[INFO]
--
--
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.hsqldb:null:2.0.0:jar}: The artifactId cannot be
empty.
-B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-488) useStrictFiltering in a fileSet in the assembly descriptor doesn't work
useStrictFiltering in a fileSet in the assembly descriptor doesn't work --- Key: MASSEMBLY-488 URL: http://jira.codehaus.org/browse/MASSEMBLY-488 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: Maven 2.2.1, RHEL4 Reporter: Eric Haszlakiewicz I'm trying to turn on useStrictFiltering in a fileSet in an assembly descriptor, but maven doesn't fail when the file does not exist. Here is an example of what the assembly descriptor looks like: ?xml version=1.0 encoding=UTF-8?assembly formats formattar.gz/format /formats fileSets fileSet useStrictFilteringtrue/useStrictFiltering directorysrc/main/directory includes includenonexistant.txt*/include /includes /fileSet /fileSets /assembly Running mvn package happily produces a tarball with no indication that anything is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-488) useStrictFiltering in a fileSet in the assembly descriptor doesn't work
[ http://jira.codehaus.org/browse/MASSEMBLY-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Haszlakiewicz updated MASSEMBLY-488: - Attachment: fail_strictfiltering.zip Here's a test case that demonstrates the problem. useStrictFiltering in a fileSet in the assembly descriptor doesn't work --- Key: MASSEMBLY-488 URL: http://jira.codehaus.org/browse/MASSEMBLY-488 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: Maven 2.2.1, RHEL4 Reporter: Eric Haszlakiewicz Attachments: fail_strictfiltering.zip I'm trying to turn on useStrictFiltering in a fileSet in an assembly descriptor, but maven doesn't fail when the file does not exist. Here is an example of what the assembly descriptor looks like: ?xml version=1.0 encoding=UTF-8?assembly formats formattar.gz/format /formats fileSets fileSet useStrictFilteringtrue/useStrictFiltering directorysrc/main/directory includes includenonexistant.txt*/include /includes /fileSet /fileSets /assembly Running mvn package happily produces a tarball with no indication that anything is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2788) Remove artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225540#action_225540 ] Brett Porter commented on MAVENUPLOAD-2788: --- I've removed the POMs, but not the JARs. Since the POMs were invalid, not being there is basically equivalent to Maven. When you put them in place, that does mean a change in behaviour for the people who have started using it, as Wendy pointed out. Unfortunately, the corrected artifacts are not in your repository at all. Please make sure they are uploaded as quickly as possible so that your users get consistent behaviour. Remove artifacts Key: MAVENUPLOAD-2788 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2788 Project: Maven Upload Requests Issue Type: Wish Reporter: Blaine Simpson Simple directory removal request. I do not want a Maven Upload, but just to wipe some artifacts that you are already mirroring to ibiblio (so that I can fix them). I am only opening this issue under this project because there is no other relevant project to fix issues with artifacts already in place. I figure that the techs who can work Upload tickets should know how to get to the mock-ftp staging or ibiblio production servers and know where the maven2 artifacts reside there. My problem is, you already picked up, by rsync, my new resources for my new project version 2.0.0. There was a mistake in the .pom files which was discovered after your pick-up. Not a big deal with the .pom mistake-- I fixed that in 5 minutes. But your rsync pickup job refuses to modify existing hosted artifacts, very likely because of the --ignore-existing switch that you use for rsync. If you could just get on the staging or production servers as needed and wipe out all of the 2.0.0 subdirectories at the level http://repo2.maven.org/maven2/org/hsqldb/*/2.0.0/ , that should be all that is needed (there are 4 directories at the same exact level, all grandchildren of http://repo2.maven.org/maven2/org/hsqldb/). I have a lot of experience with rsync, and with UNIX and scripting generally, so let me know if I can help in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=22#action_22 ] Peter Kreidermacher commented on MDEP-265: -- We would also like to see this implemented. There is a need to get dependencies that have a client classifier that cannot currently be gotten with the current get. Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Attachments: MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2788) Remove artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225556#action_225556 ] Blaine Simpson commented on MAVENUPLOAD-2788: - Thanks very much Brett. I cleared the bad subdirs in my pickup branch on purpose so that it would be very easy to tell when, and exactly what, gets removed on your end, either automatically or manually. I've been checking for that every day. As the POMs that were there fail absolutely, my users are in no worse shape than with no POM present. Unlike an error message about POM content, it should be easy for end users to see the cause of this problem and know that the problem is not on their side. Updating my own POMs would have had the problem fixed within 24 without Jira issues or missing items. I've just now restored my pickup branch (it was my first opportunity), so my fingers are crossed for tomorrow. Remove artifacts Key: MAVENUPLOAD-2788 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2788 Project: Maven Upload Requests Issue Type: Wish Reporter: Blaine Simpson Simple directory removal request. I do not want a Maven Upload, but just to wipe some artifacts that you are already mirroring to ibiblio (so that I can fix them). I am only opening this issue under this project because there is no other relevant project to fix issues with artifacts already in place. I figure that the techs who can work Upload tickets should know how to get to the mock-ftp staging or ibiblio production servers and know where the maven2 artifacts reside there. My problem is, you already picked up, by rsync, my new resources for my new project version 2.0.0. There was a mistake in the .pom files which was discovered after your pick-up. Not a big deal with the .pom mistake-- I fixed that in 5 minutes. But your rsync pickup job refuses to modify existing hosted artifacts, very likely because of the --ignore-existing switch that you use for rsync. If you could just get on the staging or production servers as needed and wipe out all of the 2.0.0 subdirectories at the level http://repo2.maven.org/maven2/org/hsqldb/*/2.0.0/ , that should be all that is needed (there are 4 directories at the same exact level, all grandchildren of http://repo2.maven.org/maven2/org/hsqldb/). I have a lot of experience with rsync, and with UNIX and scripting generally, so let me know if I can help in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated SCM-558: - Assignee: Maria Odea Ching Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225571#action_225571 ] Maria Odea Ching commented on SCM-558: -- Committed in trunk [-r955486|http://svn.apache.org/viewvc?revision=955486view=revision] with the following changes: * added mkdir command to scm api * implement mkdir in SVN scm provider * added unit tests and tck tests for svn mkdir command Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
