[jira] Created: (MNG-2953) Wrong link on http://docs.codehaus.org/display/MAVEN/How+To+Help
Wrong link on http://docs.codehaus.org/display/MAVEN/How+To+Help - Key: MNG-2953 URL: http://jira.codehaus.org/browse/MNG-2953 Project: Maven 2 Issue Type: Bug Components: Documentation: Guides Reporter: Mario Hochreiter Priority: Minor There is an incorrect link on the http://docs.codehaus.org/display/MAVEN/How+To+Help wiki site to http://maven.apache.org/maven2/development/development-guide.html which seems no longer to exist. I think the correct link should be: http://maven.apache.org/guides/development/guide-m2-development.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-142) Starteam tree stale
[ http://jira.codehaus.org/browse/SCM-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93205 ] Jan Edelbroek commented on SCM-142: --- Does anybody have a solution yet for this problem? I have the same problem too and it seems that starteam has sometimes troubles with updating the status of the files. Maybe this can be solved by using the update-status command (stcmd update-status ...) first before doing the checkout from starteam. I think this will solve most of the problems. Starteam tree stale --- Key: SCM-142 URL: http://jira.codehaus.org/browse/SCM-142 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-starteam Environment: continuum-1.0.2 Reporter: Bob Herrmann Fix For: future It only takes a few changes to starteam for the checked out filesystem to become hopelessly stale. The only recovery option is to completely remove all files and startover. Either the code checking out is not handing the timestamps correctly, or starteam command line has problems keeping a checked out tree in sync (this more likely - as we also see this problem with AntHill when using it's incremental builder.) Possible fixes might be to detect 'unknown' status's and flush the checked out tree. Or try using the 2005 bco command instead of stcmd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-83) Typo in How to prepare your dependencies before updating to Maven 2.0.6
Typo in How to prepare your dependencies before updating to Maven 2.0.6 - Key: MDEP-83 URL: http://jira.codehaus.org/browse/MDEP-83 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Dominique Jean-Prost Assignee: Brian Fox On the site, you can read this at http://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared I think we should read this : You should also pay particular attention to the Used Undeclared dependencies because this is showing that you are using something that isn't declared Shouldn't we ? Although it's just a typo (I guess), it can be error prone as it says quite the contrary of what should be -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-84) usage of -DstripVersion=true doesn't work
usage of -DstripVersion=true doesn't work - Key: MDEP-84 URL: http://jira.codehaus.org/browse/MDEP-84 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0-alpha-4 Reporter: Dominique Jean-Prost Assignee: Brian Fox Priority: Minor using mvn dependency:copy-dependencies -DstripVersion=true doesn't work : the version number are still there -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-287) Regression: org.testng.xml.Praser#parse() signature changed
[ http://jira.codehaus.org/browse/SUREFIRE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93263 ] Bernhard Neuhauser commented on SUREFIRE-287: - Tried TestNG 5.5 + surefire 2.4-SNAPSHOT = Works as expected. Regression: org.testng.xml.Praser#parse() signature changed --- Key: SUREFIRE-287 URL: http://jira.codehaus.org/browse/SUREFIRE-287 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.0 (2.2 plugin), 2.3 Reporter: Bernhard Neuhauser Priority: Critical Fix For: 2.4 TestNG 5.3, 5.4 and 5.5 dont work with Surefire. TestNG 5.2 runs fine. Reference to the TestNG Issue: http://jira.opensymphony.com/browse/TESTNG-122 org.apache.maven.surefire.booter.SurefireExecutionException: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite;; nested exception is java.lang.NoSuchMethodError: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; java.lang.NoSuchMethodError: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; at org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:129) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java:108) 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:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:816) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-85) excludeScope=test doesn't work
excludeScope=test doesn't work -- Key: MDEP-85 URL: http://jira.codehaus.org/browse/MDEP-85 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0-alpha-4 Reporter: Dominique Jean-Prost Assignee: Brian Fox mvn dependency:copy-dependencies -DexcludeScope=test doesn't seem to work correctly : I get a [INFO] [dependency:copy-dependencies] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Can't exclude Test scope, this will exclude everything. [INFO] If I use mvn dependency:copy-dependencies -DincludeScope=provided, I do get only provided scope artifact, that is the test scope is exluded indeed. --- To my mind, excludeScope=test should work then. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1488) rxtx. upload : java serial and parallel I/O API
rxtx. upload : java serial and parallel I/O API --- Key: MAVENUPLOAD-1488 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1488 Project: maven-upload-requests Issue Type: Task Reporter: Julien Vermillard RXTX is a native lib providing serial and parallel communication for the Java Development Toolkit (JDK). All deliverables are under the gnu LGPL license. I upload it because I need it for apache MINA (for more info : [EMAIL PROTECTED]), I'm not an RXTX developer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2806) Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle
[ http://jira.codehaus.org/browse/MNG-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93279 ] Aaron Digulla commented on MNG-2806: In the AROS project, we have implemented such a system and it works pretty well. See my comment on http://docs.codehaus.org/display/MAVEN/Lifecycle+and+Plugin+Handling for more details. Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle -- Key: MNG-2806 URL: http://jira.codehaus.org/browse/MNG-2806 Project: Maven 2 Issue Type: New Feature Components: POM Affects Versions: 2.0.4 Reporter: John Casey Fix For: 2.1-alpha-1 Lifecycle phase-bindings that are inherited from parent POMs or packaging-mappings are invisible to the user, without sometimes extensive research into the POM lineage and/or the extension artifact source that brings in the packaging-mapping. For end users in a large development environment, it should be possible to replace an inherited mojo binding with one specified in the local POM, without needing to know what phase that binding is attached to. It is possible to see the full mojo ID and execution ID for a replacement target in the debug output of a build, but phase transitions are not logged...which makes researching the phase-location of a mojo binding quite difficult. Replacement should be available at either the execution level, or the mojo level within a specified execution. If replacing a mojo in the lifecycle mapping given by the project's packaging, the executionId for the replacement should be 'default'. This feature should be accompanied by a new mojo in the help plugin which can print out the effective build steps in that project's lifecycle, to help with debugging replacements, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCOMPILER-52) Need a way to specify the debug level
Need a way to specify the debug level
-
Key: MCOMPILER-52
URL: http://jira.codehaus.org/browse/MCOMPILER-52
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Thomas Krammer
Currently there is no way to specify the debug level for the Java compiler
(-g:{lines,vars,source}). We only want to include line number information in
our jars to get line numbers in stack traces without bloating the jars.
I also tried
configuration
source${jdk.version}/source
target${jdk.version}/target
forktrue/fork
maxmem512m/maxmem
compilerArgument-g:lines/compilerArgument
/configuration
but that configuration doesn't include any debug information in the jar for
some reason.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MASSEMBLY-199) 2.2-beta-1 is still marked as unreleased in JIRA
[ http://jira.codehaus.org/browse/MASSEMBLY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MASSEMBLY-199. - Assignee: Stephane Nicoll Resolution: Fixed Done. 2.2-beta-1 is still marked as unreleased in JIRA -- Key: MASSEMBLY-199 URL: http://jira.codehaus.org/browse/MASSEMBLY-199 Project: Maven 2.x Assembly Plugin Issue Type: Task Reporter: Graham Leggett Assignee: Stephane Nicoll As I recall, v2.2-beta-1 of the assembly plugin was released recently. JIRA still lists 2.2-beta-1 was unreleased. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-198) Published docs on website out of date
[ http://jira.codehaus.org/browse/MASSEMBLY-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MASSEMBLY-198: -- Affects Version/s: (was: 2.2-beta-1) Issue Type: Task (was: Bug) Published docs on website out of date - Key: MASSEMBLY-198 URL: http://jira.codehaus.org/browse/MASSEMBLY-198 Project: Maven 2.x Assembly Plugin Issue Type: Task Reporter: Graham Leggett Assignee: Stephane Nicoll The published docs at http://maven.apache.org/plugins/maven-assembly-plugin/ are from a snapshot of v2.2, rather than the released v2.2-beta-1. The fix is to deploy the docs with the release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-199) 2.2-beta-1 is still marked as unreleased in JIRA
[ http://jira.codehaus.org/browse/MASSEMBLY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MASSEMBLY-199: -- Affects Version/s: (was: 2.2-beta-1) Issue Type: Task (was: Bug) 2.2-beta-1 is still marked as unreleased in JIRA -- Key: MASSEMBLY-199 URL: http://jira.codehaus.org/browse/MASSEMBLY-199 Project: Maven 2.x Assembly Plugin Issue Type: Task Reporter: Graham Leggett As I recall, v2.2-beta-1 of the assembly plugin was released recently. JIRA still lists 2.2-beta-1 was unreleased. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93309
]
Hans Dockter commented on MNG-2446:
---
I think this is an major issue.
We have a complex build where we have poms that declare the modules and other
poms that are used for inheritance.
- api
-- pom.xml (Module declaration)
-- apibasepomDir
--- api-base-pom
-- someprojectDir
--- pom -- api-base-pom
-- servicesDir
--- pom.xml (Further module declaration)
--- servicesbasepom
services-base-pom -- api-base-pom
--- someServiceDir
pom -- services-base-pom
We want one and only one definition of the version.
We do this via properties. In the api-base-pom, which is the parent of every
project except the poms declaring the modules, we set a property:
{code:xml}
properties
krugle.api.version1.0-SNAPSHOT/krugle.api.version
/properties
{code}
This property is available for all projects that inherit from api-base-pom as
well as for api-base-pom itself.
So we can use something like:
{code:xml}
parent
groupIdx/groupId
artifactIdapi-base-pom/artifactId
version${api.version}/version
/parent
{code}
The problem is that the pom declaring the modules don't inherit from the
api-base-pom. It would be anyway more intuitive to set the version property in
the pom of the api folder, as this is the first one parsed for a build. But if
we set the property there, it is only applicable within this pom. So we end up
with a situation where we have to define the version property 3 times. We have
to separate the pom's declaring the modules from the base-poms used for
inheritance, to avoid cyclic references and to trigger certain packaging
instructions at the right phase of the build.
What works is to set the version property via mvn install -D...
But the version property should be part of the pom, no question about this.
Basically I want to be able to declare a property that is available for all
poms within the module build, regardless of inheritance relationships.
parent Pom properties not resolved for module dependencies
---
Key: MNG-2446
URL: http://jira.codehaus.org/browse/MNG-2446
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Environment: WindowsXP/Linux - JDK 1.4 last version
Reporter: Jeremie Poutrin
Priority: Minor
root-project -- root-pom.xml with version${my.version}/version
|---proj1 parentversion${my.version}/version/parent
|---proj2 parentversion${my.version}/version/parent
| |
| |-proj1 dependency
|---proj3 parentversion${my.version}/version/parent
if I compile from the root-project directory, all compile fine.
if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
resolve proj1-${my.version}
but tries to resolve the parent version root-project-${my.version} but this
is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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] Work started: (MASSEMBLY-200) AssemblyInterpolatorTest.testShouldResolveEnvarHOMEValueInDependencySetOutputDirectory fails on Windows XP
[
http://jira.codehaus.org/browse/MASSEMBLY-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MASSEMBLY-200 started by Barrie Treloar.
AssemblyInterpolatorTest.testShouldResolveEnvarHOMEValueInDependencySetOutputDirectory
fails on Windows XP
--
Key: MASSEMBLY-200
URL: http://jira.codehaus.org/browse/MASSEMBLY-200
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Environment: Windows XP
Reporter: Barrie Treloar
Assignee: Barrie Treloar
AssemblyInterpolatorTest.testShouldResolveEnvarHOMEValueInDependencySetOutputDirectory
fails with
expected:lt;${env.PATH}gt; but was:lt;REAL PATH DELETEDgt;
This is because AssemblyInterpolatorTest is using
import org.codehaus.plexus.util.cli.CommandLineUtils;
instead of
import org.apache.maven.plugin.assembly.utils.CommandLineUtils;
and the call to get the envars should be
Properties envars = CommandLineUtils.getSystemEnvVars( false );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-86) Non-unique-version snapshots not updated
Non-unique-version snapshots not updated Key: MDEP-86 URL: http://jira.codehaus.org/browse/MDEP-86 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-4 Reporter: Pavel Halas Assignee: Brian Fox Please see http://jira.codehaus.org/browse/MNG-2839. PS: I've reported a bug into Maven project (without being spotted) but it rather belongs to this section. To me it seems like a really major issue so I decided to spam the tracker a bit. Sorry. I felt it could speed things up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-86) Non-unique-version snapshots not updated
[ http://jira.codehaus.org/browse/MDEP-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-86. - Resolution: Won't Fix Your original issue is in the correct location. Non-unique-version snapshots not updated Key: MDEP-86 URL: http://jira.codehaus.org/browse/MDEP-86 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-4 Reporter: Pavel Halas Assignee: Brian Fox Please see http://jira.codehaus.org/browse/MNG-2839. PS: I've reported a bug into Maven project (without being spotted) but it rather belongs to this section. To me it seems like a really major issue so I decided to spam the tracker a bit. Sorry. I felt it could speed things up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2839) Non-unique-version snapshots not updated
[ http://jira.codehaus.org/browse/MNG-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93311 ] Brian Fox commented on MNG-2839: Not sure I understand. You're saying that you changed the file in your local repo and then you expect it to update again from the repo? Non-unique-version snapshots not updated Key: MNG-2839 URL: http://jira.codehaus.org/browse/MNG-2839 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5 Reporter: Pavel Halas Test case: - let's have a repository with[uniqueVersion]false[/uniqueVersion]. - let your project download any snapshot dependency (with non-unique version) (like abc-1.0-SNAPSHOT.jar). - go to your local repository and change the file content. You can also remove all the metadata. - run mvn -U on your project - you get [INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from YOUR-REPOSITORY - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated. The same (I think) bug has been reported (and closed) several times before (MNG-1908 etc.) but it still appears in 2.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-116) Wrong SCM info put by the release plugin for modules
[ http://jira.codehaus.org/browse/MRELEASE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-116. - Assignee: Emmanuel Venisse (was: Jason van Zyl) Resolution: Fixed Wrong SCM info put by the release plugin for modules Key: MRELEASE-116 URL: http://jira.codehaus.org/browse/MRELEASE-116 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: Sun JDK 1.5, M2 2.0.3-SNAPSHOT (2006-01-30), Subversion SCM Reporter: Arik Kfir Assignee: Emmanuel Venisse Fix For: 2.0-beta-5 Attachments: patch.txt, patch.txt Hi, I have a project with several modules in it. The entire project is stored in one SVN repository, in the following layout: myproject | +-- module A | +-- module B | +-- . The root pom has a scm url like http://svn.myserver/.../trunk/;, and each sub module also has its own scm tag with a url such as http://svn.myserver/.../trunk/moduleA;, etc. When running release:prepare, the URL encoded back into the modules' POMs (the back-to-trunk pom, not the released one) is the same URL as the root POM, rather than the original module's SCM url. So module A's scm urls would be http://svn.myserver/.../trunk/; without the moduleA directory appended to it (as it was before releasing). Carlos has pointed out to me that the best practice for this use case is not specifying the scm tag for the modules' POMs at all. He did, however, also noted that it's still a bug - hence this JIRA ;-) Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2839) Non-unique-version snapshots not updated
[ http://jira.codehaus.org/browse/MNG-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93312 ] Pavel Halas commented on MNG-2839: -- Yes. It's the hardcore use case. Nevertheless, it fails to update it in regular update cycle (based on settings.xml) too. Non-unique-version snapshots not updated Key: MNG-2839 URL: http://jira.codehaus.org/browse/MNG-2839 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5 Reporter: Pavel Halas Test case: - let's have a repository with[uniqueVersion]false[/uniqueVersion]. - let your project download any snapshot dependency (with non-unique version) (like abc-1.0-SNAPSHOT.jar). - go to your local repository and change the file content. You can also remove all the metadata. - run mvn -U on your project - you get [INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from YOUR-REPOSITORY - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated. The same (I think) bug has been reported (and closed) several times before (MNG-1908 etc.) but it still appears in 2.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2839) Non-unique-version snapshots not updated
[ http://jira.codehaus.org/browse/MNG-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93312 ] Pavel Halas edited comment on MNG-2839 at 4/18/07 9:13 AM: --- Yes. It's the hardcore use case. Nevertheless, it fails to update it (without such manual changes) in regular update cycle (based on settings.xml) too. was: Yes. It's the hardcore use case. Nevertheless, it fails to update it in regular update cycle (based on settings.xml) too. Non-unique-version snapshots not updated Key: MNG-2839 URL: http://jira.codehaus.org/browse/MNG-2839 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5 Reporter: Pavel Halas Test case: - let's have a repository with[uniqueVersion]false[/uniqueVersion]. - let your project download any snapshot dependency (with non-unique version) (like abc-1.0-SNAPSHOT.jar). - go to your local repository and change the file content. You can also remove all the metadata. - run mvn -U on your project - you get [INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from YOUR-REPOSITORY - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated. The same (I think) bug has been reported (and closed) several times before (MNG-1908 etc.) but it still appears in 2.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93315 ] Bryan Cooper commented on MNG-1412: --- Perhaps an ordering attribute on the dependency itself would help in ordering. By default, the attribute doesn't need to be specified in the pom, but, be used by the module responsible for ordering the dependencies to store the default pom order of dependencies. This would also enable a simple sort via the Collections.sort utility. dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope classpathOrder1/classpathOrder-- New attribute /dependency The attribute should be respected for building classpaths and even for adding a classpath to a manifest file. Also, transitive dependencies shoud be included directly prior to their first occurrance, but, not before. Hope to see some news on this issue soon. dependency sorting in classpath --- Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina Fix For: 2.1.x Attachments: artifact-order_maven-artifact-manager.txt, artifact-order_maven-artifact.txt, artifact-order_maven-project.txt, MNG-1412-maven-2.0.x-r507746.patch The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEP-85) excludeScope=test doesn't work
[
http://jira.codehaus.org/browse/MDEP-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-85.
-
Resolution: Won't Fix
The dependency plugin uses the same code as Maven itself to determine scope. As
you can see by the code listed below, test scope includes everything.
public ScopeArtifactFilter( String scope )
{
if ( DefaultArtifact.SCOPE_COMPILE.equals( scope ) )
{
systemScope = true;
providedScope = true;
compileScope = true;
runtimeScope = false;
testScope = false;
}
else if ( DefaultArtifact.SCOPE_RUNTIME.equals( scope ) )
{
systemScope = false;
providedScope = false;
compileScope = true;
runtimeScope = true;
testScope = false;
}
else if ( DefaultArtifact.SCOPE_TEST.equals( scope ) )
{
systemScope = true;
providedScope = true;
compileScope = true;
runtimeScope = true;
testScope = true;
}
else
{
systemScope = false;
providedScope = false;
compileScope = false;
runtimeScope = false;
testScope = false;
}
}
If you want something else, maybe you can just include the scope you want. The
code above will help you figure out which one.
excludeScope=test doesn't work
--
Key: MDEP-85
URL: http://jira.codehaus.org/browse/MDEP-85
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.0-alpha-4
Reporter: Dominique Jean-Prost
Assignee: Brian Fox
mvn dependency:copy-dependencies -DexcludeScope=test doesn't seem to work
correctly : I get a
[INFO] [dependency:copy-dependencies]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Can't exclude Test scope, this will exclude everything.
[INFO]
If I use mvn dependency:copy-dependencies -DincludeScope=provided, I do get
only provided scope artifact, that is the test scope is exluded indeed.
--- To my mind, excludeScope=test should work then.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-90) Exception if version is SNAPSHOT
[ http://jira.codehaus.org/browse/MRELEASE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-90. Assignee: Emmanuel Venisse (was: Jason van Zyl) Resolution: Fixed Exception if version is SNAPSHOT Key: MRELEASE-90 URL: http://jira.codehaus.org/browse/MRELEASE-90 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-3, 2.0-beta-4 Reporter: Joerg Schaible Assignee: Emmanuel Venisse Fix For: 2.0-beta-5 Attachments: MNG-90-maven-release-plugin.patch If the project has a very simple version scheme (i.e. only a simple number) and has therefore set the verstion tag to SNAPSHOT, the plugin fails with a StringIndexOutOfRange exception: [INFO] [release:prepare] [INFO] Verifying there are no local modifications ... [INFO] Checking lineage for snapshots ... [INFO] Checking dependencies for snapshots ... [INFO] Checking plugins for snapshots ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1444) at org.apache.maven.plugins.release.helpers.ProjectVersionResolver.resolveVersion(ProjectVersionResolver.java:61) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:219) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java: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) [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[ http://jira.codehaus.org/browse/MRELEASE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-91. Assignee: Emmanuel Venisse (was: Jason van Zyl) Resolution: Fixed Already fixed. Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs Key: MRELEASE-91 URL: http://jira.codehaus.org/browse/MRELEASE-91 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: maven 2.0.4, win XP Reporter: Marcel Schutte Assignee: Emmanuel Venisse Fix For: 2.0-beta-5 Attachments: changes.xml, depmgnt.zip, MRELEASE-91.patch, MRELEASE-91.patch-2, release.patch, rewriting-dev-phase.apt, snapshots-reactor-in-dependencies.tar, snapshots-reactor-in-dependency-management.tar The mechanism in release:prepare for creating the new development version of POM's handles snapshots that are part of the current reactor build differently for dependencyManagement and for dependencies. A snapshot version in a dependencies section will be updated to the next development version whereas one in dependencyManagement won't. The attached patch will change this behavior. It will update a snapshot version under dependencyManagement if and only if it is part of the current reactor build. Note that dependencies cannot contain snapshot versions that are not part of the current reactor, but dependencyManagement can. I suggest to forbid this too. A second suggestion is to introduce a parameter to control the updating of snapshot dependencies in both dependencyManagement and dependencies sections. Either leave them at the released version or update them to the new development version. This touches on the discussion in MRELEASE-36 about the developer having to knowingly choose to use a new development version. I would be fine with using a parameter to select the behavior as obtained with my patch. My central point is that dependencyManagement and dependencies snapshots should behave the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-107) scm.url gets translated incorrectly during release
[ http://jira.codehaus.org/browse/MRELEASE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-107. - Resolution: Fixed Fix Version/s: 2.0-beta-5 Already fixed with a test scm.url gets translated incorrectly during release -- Key: MRELEASE-107 URL: http://jira.codehaus.org/browse/MRELEASE-107 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Reporter: Brian Fox Assignee: Emmanuel Venisse Fix For: 2.0-beta-5 Testing release 2.0-beta4. My original scm urls are like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/release-branches/dsms-2.1/developerConnection urlhttp://sv1.tus.stchome.com/viewvc/stc/products/dsms/release-branches/dsms-2.1/url /scm after the prepare, they end up like this: scm connectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/connection developerConnectionscm:svn:http://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/developerConnection urlhttp://sv1.tus.stchome.com/svn/training/products/dsms/build-tags/t5/url /scm Notice the url lost the viewvc reference and ended up with a direct svn url. After a release:perform, the url ends up back to viewvc so only the tag is modified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2954) Docu incomplete: Guide to uploading artifacts to the Central Repository: Jira project not specified, Attachment usage unclear
Docu incomplete: Guide to uploading artifacts to the Central Repository: Jira project not specified, Attachment usage unclear Key: MNG-2954 URL: http://jira.codehaus.org/browse/MNG-2954 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Reporter: Stefan Prange Priority: Minor Hi, 1) the Guide to uploading artifacts to the Central Repository (http://maven.apache.org/guides/mini/guide-central-repository-upload.html) says, that upload requests have to be made as Jira issues using the URL http://jira.codehaus.org/secure/CreateIssue.jspa?pid=10367amp;issuetype=3. Under this URL one has to choose a Project and an Issue Type. It would be great if the guide could say which project and issue type to choose. I suppose that project is maven-upload-requests and issue type is wish, but I'm not sure. 2) the guide says that new bundles have to be downloadable via a URL which has to be entered into the Jira issue. But Jira also offers the possibility to add an attachment to the issue (up to 10MB). It would be nice, if the guide could clarify on this possibilty, either that using attachments is equal to download urls (then the url doesn't have to be a mandatory field any more) or that attachments added to the issue will be ignored. Kind regards, Stefan Prange -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-318) Fails to run build on Windows Server 2003
Fails to run build on Windows Server 2003 - Key: SUREFIRE-318 URL: http://jira.codehaus.org/browse/SUREFIRE-318 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.3 Environment: Maven 2.0.5 or 2.0.6 , Windows Server 2003, Java 1.5 or 1.6 Reporter: Vlad Skarzhevskyy Attachments: build-log.txt After Upgrade to Surefire 2.3 our build server fails to run tests on any project. Get the message: [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] All works fine on Linux, WinXP and Win2000. But when I try to build on any Windows Server 2003 build will fail. See the log mvn -X test build-log.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-60) Improve support for skinny war files
[ http://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93326 ] Heinrich Nirschl commented on MEAR-60: -- I don't think that a boolean configuration option is flexible enough. There are situations where you want most of your jars in the ear, but still some of them in the war (for example, if they contain a tag library - the jsp compiler does not find the tag library if it is in the ear). Improve support for skinny war files Key: MEAR-60 URL: http://jira.codehaus.org/browse/MEAR-60 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: mvn 2.0.5 Reporter: Marcel Schutte Priority: Critical Provide a boolean configuration option for webModules to include the war's transitive dependencies. As described on http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it is very common in a J2EE environment to use so called skinny wars. Here the war's WEB-INF/lib will not contain the dependent jars, but instead they are packaged inside the EAR. The war references them through its META-INF/MANIFEST.MF This option could be used to avoid the 'painful part' mentioned in the above web page. The war's dependencies wouldn't have to be duplicated alongside the ear's. I also found an old issue (MEAR-14) which has asked for the current default behavior of not including the transitive dependencies. It suggests a property to include specific dependencies of the war. As far as I can tell this has never been implemented and this is also not what I am asking for. My proposal is an all of nothing kind of option for each war module in the ear. On a side note, for me this is the part where removal of the old maven 1 style properties per dependency is missed the most. With them it was possible to decide for each single dependency whether to put it in WEB-INF/lib or reference it through the manifest classpath. But of course, then we didn't have the transitive dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-517) incomplete maven-scm-plugin 1.0-rc1
incomplete maven-scm-plugin 1.0-rc1 --- Key: MEV-517 URL: http://jira.codehaus.org/browse/MEV-517 Project: Maven Evangelism Issue Type: Bug Components: Missing POM Reporter: Tomasz Pik there's only jar file for maven-scm-plugin 1.0-rc1, there's no pom file and maven-metadata do not list 1.0-rc1. it looks that sync from http://people.apache.org/~evenisse/stage/repo/org/apache/maven/plugins/maven-scm-plugin/ is incomplete -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-175) Svn commit fails due to large number of poms on windows
[ http://jira.codehaus.org/browse/MRELEASE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93332 ] Emmanuel Venisse commented on MRELEASE-175: --- no, we can't because I'm sure some SCM need a files list but for svn we can use --targets argument on svn commit. I'll fix it in Maven-SCM Svn commit fails due to large number of poms on windows --- Key: MRELEASE-175 URL: http://jira.codehaus.org/browse/MRELEASE-175 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: windows Reporter: Dan Tran Fix For: 2.0-beta-5 I have so many projects under one source tree that release:prepare fails when trying to commit the changed pom files ( ie svn command is too long) Can we just issue svn commit ? This problem hits all scm types on windows platform -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-198) Published docs on website out of date
[ http://jira.codehaus.org/browse/MASSEMBLY-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MASSEMBLY-198. - Resolution: Fixed Deployed; will be published in the next synch. Published docs on website out of date - Key: MASSEMBLY-198 URL: http://jira.codehaus.org/browse/MASSEMBLY-198 Project: Maven 2.x Assembly Plugin Issue Type: Task Reporter: Graham Leggett Assignee: Stephane Nicoll The published docs at http://maven.apache.org/plugins/maven-assembly-plugin/ are from a snapshot of v2.2, rather than the released v2.2-beta-1. The fix is to deploy the docs with the release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1489) com.jgoodies-binding-1.4.0 upload request
com.jgoodies-binding-1.4.0 upload request - Key: MAVENUPLOAD-1489 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1489 Project: maven-upload-requests Issue Type: Wish Reporter: Stefan Prange I'm sending this request on behalf of Karsten Lentzsch, the author of this library. He asked for help on uploading this maven bundle on the mailing list [EMAIL PROTECTED] on April 18, 2007 (see https://binding.dev.java.net/servlets/SummarizeList?listName=users) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1842) Upgrade maven-developer-activity-plugin to v 1.6.1
[ http://jira.codehaus.org/browse/MAVEN-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1842. -- Resolution: Fixed Fix Version/s: 1.1-rc1 Done Upgrade maven-developer-activity-plugin to v 1.6.1 -- Key: MAVEN-1842 URL: http://jira.codehaus.org/browse/MAVEN-1842 Project: Maven 1.x Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier Fix For: 1.1-rc1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1829) Upgrade maven-site-plugin to v 1.7.2
[ http://jira.codehaus.org/browse/MAVEN-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1829. -- Resolution: Fixed Done Upgrade maven-site-plugin to v 1.7.2 Key: MAVEN-1829 URL: http://jira.codehaus.org/browse/MAVEN-1829 Project: Maven 1.x Issue Type: Sub-task Affects Versions: 1.1-beta-3 Reporter: Lukas Theussl Assignee: Arnaud Heritier Fix For: 1.1-rc1 http://jira.codehaus.org/browse/MPSITE?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1839) Add maven-modello-plugin v 1.0
[ http://jira.codehaus.org/browse/MAVEN-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1839. -- Resolution: Fixed Fix Version/s: 1.1-rc1 Done Add maven-modello-plugin v 1.0 -- Key: MAVEN-1839 URL: http://jira.codehaus.org/browse/MAVEN-1839 Project: Maven 1.x Issue Type: Sub-task Reporter: Arnaud Heritier Assignee: Arnaud Heritier Fix For: 1.1-rc1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1472) OpenID4Java is an OpenID implementation for Java. Please upload!
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93374 ] Wendy Smoak commented on MAVENUPLOAD-1472: -- The pom for this seems to be invalid, though it looks okay to me (and JEdit): Downloading: http://repo1.maven.org/maven2/org/openid4java/openid4java/0.9.2/openid4java-0.9.2.pom 7K downloaded [WARNING] POM for 'org.openid4java:openid4java:pom:0.9.2:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM Downloading: http://repo1.maven.org/maven2/org/openid4java/openid4java/0.9.2/openid4java-0.9.2.jar 254K downloaded OpenID4Java is an OpenID implementation for Java. Please upload! Key: MAVENUPLOAD-1472 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1472 Project: maven-upload-requests Issue Type: Bug Reporter: zhoushuqun Assignee: Carlos Sanchez http://openid4java.googlecode.com/files/openid4java-0.9.2-bundle.jar http://openid4java.org/ http://code.google.com/p/openid4java/ OpenID4Java is an OpenID implementation for Java. Please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1472) OpenID4Java is an OpenID implementation for Java. Please upload!
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93376
]
zhoushuqun commented on MAVENUPLOAD-1472:
-
Use the following instead please as
http://jira.codehaus.org/browse/MAVENUPLOAD-1487:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdorg.openid4java/groupId
artifactIdopenid4java/artifactId
packagingjar/packaging
version0.9.2/version
build
directorybuild/directory
outputDirectorybuild/classes/outputDirectory
testOutputDirectorybuild/test-classes/testOutputDirectory
sourceDirectorysrc/sourceDirectory
resources
resource
directorysrc/directory
/resource
/resources
testSourceDirectorytest/src/testSourceDirectory
testResources
testResource
directorytest/src/directory
/testResource
/testResources
plugins
plugin
!-- NOTE: We don't need a groupId
specification because the group is
org.apache.maven.plugins ...which is
assumed by default.
--
artifactIdmaven-surefire-plugin/artifactId
configuration
skiptrue/skip
systemProperties
property
nameYADIS_TEST_DATA/name
value${basedir}/test/yadisdata/value
/property
property
nameSERVLET_PORT/name
value8989/value
/property
property
nameTEST_DATA/name
value
${basedir}/test/src/org/openid4java/
/value
/property
/systemProperties
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptorRefs
descriptorRefsrc/descriptorRef
descriptorRefbin/descriptorRef
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/plugin
/plugins
/build
reporting
outputDirectorybuild/site/outputDirectory
plugins
plugin
artifactIdmaven-site-plugin/artifactId
configuration
inputEncodingUTF-8/inputEncoding
outputEncodingUTF-8/outputEncoding
/configuration
/plugin
plugin
artifactIdmaven-javadoc-plugin/artifactId
configuration
encodingUTF-8/encoding
docencodingUTF-8/docencoding
charsetUTF-8/charset
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
/plugin
/plugins
/reporting
nameOpenID4Java/name
