[jira] Updated: (MRM-479) metadata files in artifactId/version level are not updated during repository purge
[ http://jira.codehaus.org/browse/MRM-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-479: - Fix Version/s: 1.0-beta-3 > metadata files in artifactId/version level are not updated during repository > purge > -- > > Key: MRM-479 > URL: http://jira.codehaus.org/browse/MRM-479 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Maria Odea Ching > Fix For: 1.0-beta-3 > > -- 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: (MRM-479) metadata files in artifactId/version level are not updated during repository purge
metadata files in artifactId/version level are not updated during repository purge -- Key: MRM-479 URL: http://jira.codehaus.org/browse/MRM-479 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: 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: (SUREFIRE-180) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/SUREFIRE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104886 ] Peter Anning commented on SUREFIRE-180: --- I don't want to patch core maven I've done this before and it leads to a maintenance headache. For now I am running Junit via the ant plugin but this is not the point of maven. Please can we get this into the core asap. Cheers Peter > Ability to add additions to classpath > - > > Key: SUREFIRE-180 > URL: http://jira.codehaus.org/browse/SUREFIRE-180 > Project: Maven Surefire > Issue Type: Improvement > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: fabrizio giustina > Fix For: 2.4 > > Attachments: MSUREFIRE-153-maven-surefire-plugin.patch, > SurefirePlugin.java-diff > > > There should be a possibility to add arbritary resources to the classpath > while executing the tests. These resources would only be available while > executing the tests, so they won't be added in the archive. > i suggest a configuration element > > some/path > /some/other/path > > This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / > ability to exclude/include filtering in archiver/jar-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-118) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/SUREFIRE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104885 ] Peter Anning commented on SUREFIRE-118: --- I don't want to patch core maven I've done this before and it leads to a maintenance headache. For now I am running Junit via the ant plugin but this is not the point of maven. Please can we get this into the core asap. Cheers Peter > Cannot override read-only parameter: classpathElements > -- > > Key: SUREFIRE-118 > URL: http://jira.codehaus.org/browse/SUREFIRE-118 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 1.5.2 (2.1.2 plugin), 2.0 (2.2 plugin) >Reporter: Jesper Zedlitz >Priority: Minor > Fix For: 2.4 > > Attachments: additionalClasspaths.patch > > > When calling "mvn site" on a multi-module project the goal "surefire:test" > fails for the second project: > Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason: > ERROR: Cannot override read-only parameter: classpathElements in goal: > surefire:test > "mvn test" works and runs the tests on all modules. -- 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-3149) install:install-file plugin to use file naming convention in place of most parameters
install:install-file plugin to use file naming convention in place of most parameters - Key: MNG-3149 URL: http://jira.codehaus.org/browse/MNG-3149 Project: Maven 2 Issue Type: Improvement Components: Command Line, Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: James Drucza It would be really nice to have the install:install-file plugin support a file naming convention instead of specifying all the parameters (and thus maven support i.e. ignore the extra info in the file name). eg: instead of: mvn install:install-file -DgroupId=MSSQLDriver -DartifactId=sqljdbc -Dversion=1.1.1501.101 -Dpackaging=jar -Dfile=sqljdbc.jar use: mvn install:install-file -Dfile=MSSQLDriver-sqljdbc-1.1.1501.101.jar or some similar convention. -- 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: (MRM-463) Metadata merging doesn't work.
[ http://jira.codehaus.org/browse/MRM-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104880 ] Joakim Erdfelt commented on MRM-463: Even though this is assigned to me, please feel free to work on it, if you feel you can contribute. ;-) > Metadata merging doesn't work. > -- > > Key: MRM-463 > URL: http://jira.codehaus.org/browse/MRM-463 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-2 > > > When dealing with metadata.xml files and proxying the merging of metadata is > not performed correctly. > Often ending up with a metadata.xml file with no versions specified. > Tasks > 1) Re-enabled metadata tests in the archiva-proxy module. > 2) Fix the proxy code (and possibly the tests) to ensure metadata.xml files > are merged correctly. > 3) Create tests for 1 managed to multiple remote repos all with metadata.xml > for the same groupId:artifactId > 4) Create tests for versionless and versioned metadata.xml files. > Note: Consider using the VersionComparator to obtain a unique list of sorted > (by version) -- 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: (MRM-478) Automatic Reassign of POM embedded repositories.
[ http://jira.codehaus.org/browse/MRM-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-478: --- Fix Version/s: Future Setting to a Future fix version. > Automatic Reassign of POM embedded repositories. > > > Key: MRM-478 > URL: http://jira.codehaus.org/browse/MRM-478 > Project: Archiva > Issue Type: New Feature > Components: remote proxy >Affects Versions: Future >Reporter: Joakim Erdfelt > Fix For: Future > > > This is discussed at: > http://www.nabble.com/Re%3A-MRM-462%3A-configuring-different-types-of-repositories-differently-p12154720.html > Example: > 1) Pull up a report of all remote repositories defined in the poms. > 2) Select one of them, and a managed repository, hit 'reassign repo' button. > 3) A remote repository is added to the archiva configuration. > 4) A proxy connector is added between the selected managed repo and the new > remote repository. > 5) Then all embedded references to that remote repository now point to the > managed archiva repository URL. > 6) A reference is added to the auto-convert consumer that all new occurrences > of this repository are converted. -- 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: (MRM-478) Automatic Reassign of POM embedded repositories.
Automatic Reassign of POM embedded repositories. Key: MRM-478 URL: http://jira.codehaus.org/browse/MRM-478 Project: Archiva Issue Type: New Feature Components: remote proxy Affects Versions: Future Reporter: Joakim Erdfelt Fix For: Future This is discussed at: http://www.nabble.com/Re%3A-MRM-462%3A-configuring-different-types-of-repositories-differently-p12154720.html Example: 1) Pull up a report of all remote repositories defined in the poms. 2) Select one of them, and a managed repository, hit 'reassign repo' button. 3) A remote repository is added to the archiva configuration. 4) A proxy connector is added between the selected managed repo and the new remote repository. 5) Then all embedded references to that remote repository now point to the managed archiva repository URL. 6) A reference is added to the auto-convert consumer that all new occurrences of this repository are converted. -- 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: (MRM-477) Missing ability to manage proxy order.
[ http://jira.codehaus.org/browse/MRM-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-477: --- Fix Version/s: 1.0-beta-3 > Missing ability to manage proxy order. > -- > > Key: MRM-477 > URL: http://jira.codehaus.org/browse/MRM-477 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Dan Tran brought up a good point about Proxy Connectors and search order. > Reference: http://www.nabble.com/The-order-to-proxy-connectors-p12138354.html > --(snip)-- > Hello, I would like to setup archiva to search for java.net first then > repo1.maven.org. And archive user interface does not seem to support this > option. > Can some one confirm? > this is a work around for http://jira.codehaus.org/browse/MEV-498 > Thanks > --(snip)-- -- 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: (MRM-477) Missing ability to manage proxy order.
Missing ability to manage proxy order. -- Key: MRM-477 URL: http://jira.codehaus.org/browse/MRM-477 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt Dan Tran brought up a good point about Proxy Connectors and search order. Reference: http://www.nabble.com/The-order-to-proxy-connectors-p12138354.html --(snip)-- Hello, I would like to setup archiva to search for java.net first then repo1.maven.org. And archive user interface does not seem to support this option. Can some one confirm? this is a work around for http://jira.codehaus.org/browse/MEV-498 Thanks --(snip)-- -- 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: (MRM-462) separate configuration of managed repositories from remote repositories
[ http://jira.codehaus.org/browse/MRM-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104876 ] Joakim Erdfelt commented on MRM-462: Discussion on this JIRA is in progress in archiva-dev mailing list. See http://www.nabble.com/MRM-462%3A-configuring-different-types-of-repositories-differently-tf4259505.html > separate configuration of managed repositories from remote repositories > --- > > Key: MRM-462 > URL: http://jira.codehaus.org/browse/MRM-462 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-2 > > > the fancy footwork to make a managed repository use all the same > configuration screens as a remote repository is causing both subtle bugs > (particularly in the URL handling), and a confusing user experience (settings > appearing that are irrelevant to remote repositories in the edit form). > 1) separate the forms/actions (or at least exclude the fields that are not > relevant when editing the remote repos) > 2) treat the URL (remote) as a URL and the location (managed) as a path. > Don't munge anything. > 3) I think we should consider separating them into different lists in the > configuration again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-463) Metadata merging doesn't work.
[ http://jira.codehaus.org/browse/MRM-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104877 ] Joakim Erdfelt commented on MRM-463: Discussion on this jira has been started in archiva-dev mailing list. See http://www.nabble.com/MRM-463---metadata-handling---merging-tf4270417.html > Metadata merging doesn't work. > -- > > Key: MRM-463 > URL: http://jira.codehaus.org/browse/MRM-463 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-2 > > > When dealing with metadata.xml files and proxying the merging of metadata is > not performed correctly. > Often ending up with a metadata.xml file with no versions specified. > Tasks > 1) Re-enabled metadata tests in the archiva-proxy module. > 2) Fix the proxy code (and possibly the tests) to ensure metadata.xml files > are merged correctly. > 3) Create tests for 1 managed to multiple remote repos all with metadata.xml > for the same groupId:artifactId > 4) Create tests for versionless and versioned metadata.xml files. > Note: Consider using the VersionComparator to obtain a unique list of sorted > (by version) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104871 ] Brian Fox commented on MECLIPSE-213: Hi Rich, I sent you this email several weeks ago but perhaps it was blocked: Hi Ritchie, I tried applying your patch. Unfortunately, svn doesn't handle newly added files in patches very well, especially binary ones. Can you do the following? Remove all files from the tree that are not new, leaving behind just the tree of new files, and zip it up? Then attach it or email it to me. I'll take this zip and unpack it over the eclipse folder and apply the rest of your patch. I can then submit it to a branch where we can review it and tweak if needed before merging. Thanks, Brian > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch, maven-eclipse-plugin.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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-1672) Request to upload MyDas Distributed Annotation Server core jar.
Request to upload MyDas Distributed Annotation Server core jar. --- Key: MAVENUPLOAD-1672 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1672 Project: maven-upload-requests Issue Type: Wish Reporter: Philip Jones http://code.google.com/p/mydas/ Developers: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=471 http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=479 MyDas is a new DAS (Distributed Annotation System) Server API, written in Java. It is built using Maven 2 and the template project also uses Maven 2, so having this jar uploaded to the public Maven repository would be very useful! It is now stable - a publicly available example implementation of this server can be viewed at http://www.ebi.ac.uk/das-srv/uniprot/das Best regards, Phil. -- 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: (MECLIPSE-302) resolveVersionRanges crashes on system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Beermann updated MECLIPSE-302:
--
Attachment: MECLIPSE-302-maven-eclipse-plugin.patch
Updated patch, add test cases
> resolveVersionRanges crashes on system.bundle
> -
>
> Key: MECLIPSE-302
> URL: http://jira.codehaus.org/browse/MECLIPSE-302
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Matthew Beermann
> Fix For: 2.5
>
> Attachments: MECLIPSE-302-maven-eclipse-plugin.patch,
> MECLIPSE-302-maven-eclipse-plugin.patch
>
>
> When running eclipse:make-artifacts with -DresolveVersionRanges=true, it dies
> with the following error:
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system.bundle, artifactId=system.bundle, version=[0,), type=jar} in
> project org.apache.xml.org.apache.xml.resolver
> It turns out that "system.bundle" is a keyword in OSGi that (broadly
> speaking) refers to the JRE itself, and thus need not/should not be included
> in the POM as a dependency. I've got a patch for this coming up in a moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2961) DefaultArtifact getBaseVersion is changed to "xxxx-SNAPSHOT" only if you first call isSnapshot()
[
http://jira.codehaus.org/browse/MNG-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2961.
---
Assignee: John Casey (was: Brian Fox)
Resolution: Fixed
Fix Version/s: 2.1-alpha-1
Applied, and added my own unit test to verify the fix. Thanks, Brian!
> DefaultArtifact getBaseVersion is changed to "-SNAPSHOT" only if you
> first call isSnapshot()
>
>
> Key: MNG-2961
> URL: http://jira.codehaus.org/browse/MNG-2961
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7
>Reporter: Brian Fox
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.0.8, 2.1-alpha-1
>
> Attachments: MNG-2961.diff
>
>
> calling isSnapshot() actually modifies the baseVersion:
> public boolean isSnapshot()
> {
> if ( version != null || baseVersion != null )
> {
> Matcher m = VERSION_FILE_PATTERN.matcher( getBaseVersion() );
> if ( m.matches() )
> {
> setBaseVersion( m.group( 1 ) + "-" + SNAPSHOT_VERSION );
> return true;
> }
> else
> {
> return getBaseVersion().endsWith( SNAPSHOT_VERSION ) ||
> getBaseVersion().equals( LATEST_VERSION );
> }
> }
> else
> {
> return 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] Commented: (MSITE-243) Czech translation
[ http://jira.codehaus.org/browse/MSITE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104862 ] Petr Ferschmann commented on MSITE-243: --- If I download the file (using browser) it is correctly readable. But in the SVN there is not properly set contentType. It should be text/plain; charset=utf-8 It is not problem for translation users. You just ask about the subversion properties. Thank you > Czech translation > - > > Key: MSITE-243 > URL: http://jira.codehaus.org/browse/MSITE-243 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Petr Ferschmann >Assignee: John Casey > Fix For: 2.0-beta-6 > > Attachments: project-info-report_cs.properties, > project-info-report_cs.properties, site-plugin_cs.properties, > site-plugin_cs.properties > > > We have translated Maven site plugin to czech language. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-314) PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure
[ http://jira.codehaus.org/browse/MECLIPSE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104861 ] John Casey commented on MECLIPSE-314: - Can you please add some tests to verify this fix? > PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure > -- > > Key: MECLIPSE-314 > URL: http://jira.codehaus.org/browse/MECLIPSE-314 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.4 > Environment: java version "1.5.0_11" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) >Reporter: Graham Leggett > Attachments: pde-reactor-fix-2.patch, pde-reactor-fix.patch > > > When the eclipse:eclipse goal synchronises MANIFEST.MF during PDE builds, all > reactor projects are accidently left off the dependency list that gets > written to Bundle-Classpath. > This causes the PDE build to fail. > The attached patch fixes this issue by inserting the missing reactor > dependencies when writing the Bundle-Classpath. -- 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: (MDEPLOY-56) Parent version ignored when deploying file with existing pom
[ http://jira.codehaus.org/browse/MDEPLOY-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MDEPLOY-56. - Assignee: John Casey Resolution: Fixed Fix Version/s: 2.4 Applied. Thanks. > Parent version ignored when deploying file with existing pom > > > Key: MDEPLOY-56 > URL: http://jira.codehaus.org/browse/MDEPLOY-56 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Tuomas Kiviaho >Assignee: John Casey > Fix For: 2.4 > > Attachments: maven-deploy-plugin.rev553111.patch > > > Pom parent version is not used as source for version in deploy-file although > deploy allows versionless deployment. -- 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: (MECLIPSE-281) Documentation patch for PDE support
[ http://jira.codehaus.org/browse/MECLIPSE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MECLIPSE-281. --- Assignee: John Casey Resolution: Fixed Applied, thanks! > Documentation patch for PDE support > --- > > Key: MECLIPSE-281 > URL: http://jira.codehaus.org/browse/MECLIPSE-281 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: Graham Leggett >Assignee: John Casey > Fix For: 2.5 > > Attachments: pde-docs.diff > > > The attached patch documents the PDE feature of maven-eclipse-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-284) Transitive dependencies with scope provided should not be part of .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104858 ] John Casey commented on MECLIPSE-284: - Can you please provide any changes as a unified diff, so we can isolate the changed lines? This works much better as these files age, and gives us a much more focused idea of what you've done. Also, please provide some sort of test case that will fail prior to your fix, and pass afterwards. > Transitive dependencies with scope provided should not be part of .classpath > file > - > > Key: MECLIPSE-284 > URL: http://jira.codehaus.org/browse/MECLIPSE-284 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.3 > Environment: Windows XP >Reporter: Jan Dieckmann > Attachments: AbstractIdeSupportMojo.java > > > We are using the maven eclipse plugin and it does a very good job for us. > Úsing the plugin we now have the pom's as the sole source for all .classpath > and .project files in our multi module project. We really appreciate this > solution. The maven eclipse plugin does a lot for us .. actually it does too > much. > Some of our dependencies have a scope of "provided". The default maven > behaviour is to ignore those items when transitive dependencies are resolved. > The plugin's behaviour is different and there is no configuration to switch > to the default behaviour. At least we did not find one. As a result our > .classpath files have a lot of unnecessary references to jar files. > We changed the class AbstractIdeSupportMojo.java to get rid of dispensable > jars. The inner class IVUScopeFilter does the job. This class is used in the > method call artifactCollector.collect(). > Is there something we missed or should the plugin be changed in a way we did? > best regards > Jan Dieckmann -- 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: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[
http://jira.codehaus.org/browse/MJAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MJAR-75.
--
Resolution: Fixed
Fix Version/s: 2.2
Applied, thanks.
> [PATCH] Wrong artifact type attached to the project by the test-jar goal
> -
>
> Key: MJAR-75
> URL: http://jira.codehaus.org/browse/MJAR-75
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1, 2.2
> Environment: All
>Reporter: Piotr Tabor
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.2
>
> Attachments: maven-jar-plugin-MJAR-75.diff,
> MJAR-75-core-integration-testing.diff
>
>
> The test-jar goal attaches to the project
> "org.apache.maven.its.it0121:model:jar" such a artifact:
> - org.apache.maven.its.it0121:model:*jar*:tests
> It should attach such an artifact:
> - org.apache.maven.its.it0121:model:*test-jar*:tests
> The wrong artifacts "naming" leads to MNG-2871 problem:
> The code does not work (because the strings are different:
> --MavenProject:
> replaceWithActiveArtifact(...)-
>
> Iterator itr = ref.getAttachedArtifacts().iterator();
> while(itr.hasNext()) {
> Artifact attached = (Artifact) itr.next();
> if(
> attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
> ) {
> ... (resolve as active's project) ...
>}
> ...
> ---
> pluginArtifact.getDependencyConflictId() is :
> org.apache.maven.its.it0121:model:*test-jar*:tests
> attached.getDependencyConflictId() is :
> org.apache.maven.its.it0121:model:*jar*:tests
> For test-case: look at test (it121) attached to:
> http://jira.codehaus.org/browse/MNG-2871
--
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-243) Czech translation
[ http://jira.codehaus.org/browse/MSITE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104855 ] John Casey commented on MSITE-243: -- Sorry, that second URL is meant to be: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_cs.properties > Czech translation > - > > Key: MSITE-243 > URL: http://jira.codehaus.org/browse/MSITE-243 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Petr Ferschmann >Assignee: John Casey > Fix For: 2.0-beta-6 > > Attachments: project-info-report_cs.properties, > project-info-report_cs.properties, site-plugin_cs.properties, > site-plugin_cs.properties > > > We have translated Maven site plugin to czech language. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-243) Czech translation
[ http://jira.codehaus.org/browse/MSITE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MSITE-243. Resolution: Fixed Fix Version/s: 2.0-beta-6 I've applied these patches. Can you please have a look at: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_cs.properties http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-reports_cs.properties and make sure I've got all the Subversion properties, etc. correct? Thanks! > Czech translation > - > > Key: MSITE-243 > URL: http://jira.codehaus.org/browse/MSITE-243 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Petr Ferschmann >Assignee: John Casey > Fix For: 2.0-beta-6 > > Attachments: project-info-report_cs.properties, > project-info-report_cs.properties, site-plugin_cs.properties, > site-plugin_cs.properties > > > We have translated Maven site plugin to czech language. -- 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-3106) Multiple profile activation conditions broken
[ http://jira.codehaus.org/browse/MNG-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104853 ] Bryan Kate commented on MNG-3106: - This bug is severely limiting, especially since the online documentation indicates an AND operation. > Multiple profile activation conditions broken > - > > Key: MNG-3106 > URL: http://jira.codehaus.org/browse/MNG-3106 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.4 >Reporter: Andy Bryant > > Having multiple profile activation conditions behaves in an unexpected > manner. It doesn't cause a build failure, but the actual algorithm for > activating a profile is very different from expected. My expectation was that > if you include multiple conditions, they are ANDed together. However what > appears to happen is that the conditions overwrite each other. > If an condition is added, it overrides any or > conditions regardless of their results. > If a condition is added, it overrides any condition > regardless of results > The following table gives a sample of conditions matched, and whether the > profile was activated as a result: > Property File OS Result Expected > T T - TT > T F - FF > F T - TF > F F - FF > T - T TT > T - F FF > F - T TF > F - F FF > F F T TF > T T FFF -- 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: (MRM-476) ability to use file protocol using UNC path for Managed repository
[ http://jira.codehaus.org/browse/MRM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-476: --- Affects Version/s: 1.0-beta-1 Fix Version/s: 1.0-beta-3 > ability to use file protocol using UNC path for Managed repository > -- > > Key: MRM-476 > URL: http://jira.codehaus.org/browse/MRM-476 > Project: Archiva > Issue Type: New Feature > Components: WebDAV interface >Affects Versions: 1.0-beta-1 > Environment: window NT, apache tomcat 5.5, >Reporter: Patrick Gallagher > Fix For: 1.0-beta-3 > > > Currently, if I try to use a network share with a UNC path when creating a > Managed Repository, the path is replaced with a newly created directory on > the system root. For example, using the path of > file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. > I have tried a combination of strings for the url but have not been able to > connect to a network share. -- 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: (MRM-476) ability to use file protocol using UNC path for Managed repository
[ http://jira.codehaus.org/browse/MRM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104852 ] Joakim Erdfelt commented on MRM-476: Sounds like a wonderful idea. Do you have any examples on how to access a UNC/Windows share via java? > ability to use file protocol using UNC path for Managed repository > -- > > Key: MRM-476 > URL: http://jira.codehaus.org/browse/MRM-476 > Project: Archiva > Issue Type: New Feature > Components: WebDAV interface >Affects Versions: 1.0-beta-1 > Environment: window NT, apache tomcat 5.5, >Reporter: Patrick Gallagher > Fix For: 1.0-beta-3 > > > Currently, if I try to use a network share with a UNC path when creating a > Managed Repository, the path is replaced with a newly created directory on > the system root. For example, using the path of > file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. > I have tried a combination of strings for the url but have not been able to > connect to a network share. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2188) Report mojos should check canGenerateReport() when called directly
[
http://jira.codehaus.org/browse/MNG-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2188.
---
Resolution: Fixed
Fix Version/s: (was: 2.0.x)
2.0.8
I added this logic to the generate() method, since the execute method seems to
disallow direct invocation at this point.
> Report mojos should check canGenerateReport() when called directly
> --
>
> Key: MNG-2188
> URL: http://jira.codehaus.org/browse/MNG-2188
> Project: Maven 2
> Issue Type: Improvement
> Components: Sites & Reporting
>Affects Versions: 2.0.3
>Reporter: Vincent Massol
>Assignee: John Casey
> Fix For: 2.0.8
>
> Attachments: AbstractMavenReport-canGenerateReport-check.patch
>
>
> There's a canGenerateReport() method in a ReportMojo. This method is called
> by the site phase to decide if the mojo should be called or not. This is
> cool. However the user can call directly the report mojo and in that case the
> canGenerateReport() method is not called automatically. Thus the solution for
> a plugin developer is to write:
> {code}
> public void executeReport()
> {
> if (canGenerateReport() )
> {
> [...]
> }
> }
> {code}
> Which means that the canGenerateReport method is going to be called twice
> when mvn site is executed.
--
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-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104849 ] John Casey commented on MNG-671: Brett, can you shed some light on why this issue was reopened? Are the patches solid, and is the use case worth complicating the artifact-resolution process further for the marginal gains it will provide? Which patches are even active, does anyone know? > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.x > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-728. -- Resolution: Won't Fix I'm not willing to take a chance on this code without tests, particularly when all available reports indicate that there is little or no upside effect to this patch. If we're hungry to get this stuff integrated, we need to have patches that provide full testing, i.e. comprehensive unit tests or integration tests. Also, we need a much better indication that JDK 1.6/1.7/1.whatever actually does something beneficial with this configuration. If you can provide ALL of this information, THEN reopen the issue. Otherwise, the patches that are given are insufficient. > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- 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-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104847
]
John Casey commented on MSITE-245:
--
John, do you think we could use the relativePath that you calculate at the top
in conjunction with project.getBasedir() in cases where the given basedir
points to the wrong location? This would effectively reorient that
siteDirectory to the proper basedir with the proper relative path.
I only ask because it looks like you started down this road (in the patch), but
then there's a comment about assuming a standard location...I'd like to take
advantage of any lessons you learned when making this patch.
> parent filesystem site.xml is never be found
>
>
> Key: MSITE-245
> URL: http://jira.codehaus.org/browse/MSITE-245
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: 2.0.7
>Reporter: John Allen
>Priority: Blocker
> Attachments: site-patch.txt
>
>
> The current approach used by the getSiteDescriptorFile(File, Locale) is wrong
> as the basedir passed in to it is not just the project's own basedir, it's
> potentially a parent project's basedir and thus the previous code makes no
> sense as we would need to add on the parent's site.xml site directory and
> then try and find the relative path to it and as there's no way (that I know
> of) of a) finding that out from the parent project's object model (even if we
> passed it in) and b) the current code does not append anything to the passed
> in basedir so is always looking for a site.xml in the parents root directory.
> What's more the use of a relative path here is pointless too as we simply
> read in the descriptor file, not persist it into links where relativePaths
> are useful.
> Current code:
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
>String relativePath = getRelativePath(
> siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
> File siteDescriptor = new File( relativePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( relativePath, "site.xml" );
> }
> return siteDescriptor;
> }
> {code}
> Fixed code
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
> String sitePath;
>
> if ( basedir.equals( project.getBasedir() ))
> {
> // it's this project's basedir so use our siteDirectory (allows
> this project
> // to use a custom site location)
>
> sitePath = siteDirectory.getAbsolutePath();
> }
> else
> {
> // it's not this project's basedir so it must be one of our
> parent's,
> // so we'll just have to assume they store their site.xml in the
> // standard location (src/site)
>
> sitePath = basedir.getAbsolutePath() + "/src/site";
> }
>
> File siteDescriptor = new File( sitePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( sitePath, "site.xml" );
> }
> return siteDescriptor;
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-476) ability to use file protocol using UNC path for Managed repository
ability to use file protocol using UNC path for Managed repository -- Key: MRM-476 URL: http://jira.codehaus.org/browse/MRM-476 Project: Archiva Issue Type: New Feature Components: WebDAV interface Environment: window NT, apache tomcat 5.5, Reporter: Patrick Gallagher Currently, if I try to use a network share with a UNC path when creating a Managed Repository, the path is replaced with a newly created directory on the system root. For example, using the path of file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. I have tried a combination of strings for the url but have not been able to connect to a network share. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-225) Not a v4.0.0 POM
[ http://jira.codehaus.org/browse/MASSEMBLY-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104846 ] Michael King commented on MASSEMBLY-225: Is there a work around for this issue? I saw a thread somewhere that John Casey found the problem but mentioned it won't be release for a little while. Anything available to get around this little issue? Thanks, Mike > Not a v4.0.0 POM > > > Key: MASSEMBLY-225 > URL: http://jira.codehaus.org/browse/MASSEMBLY-225 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0.1 > Environment: Linux Unbuntu, 1.5_07 jdk >Reporter: C Helck > > I have a maven 1 project that builds a jar file called pps-3.0.2.jar. > The jar (and it's pom) are moved into my legacy style repository. > I have a maven 2 project that depends on pps-3.0.2. It compiles and > tests the code fine. During the assembly it is suppose to creates a > directory of dependent jar files and it blows up with the message: > -- > Error building POM (may not be this project's POM). > Project ID: ebs:pps > POM Location: /home/chelck/.m2/repository/ebs/pps/3.0.2/pps-3.0.2.pom > Reason: Not a v4.0.0 POM. > - > In a sense the error is correct: pps-3.0.2.pom is not v4.0.0 -- it's > legacy. So why is mvn trying to build it's POM and why doesn't it > realize it's a legacy pom? > I see this with maven 2.0.4,2.0.6, and 2.0.7. > Here is a (2.0.4) stack trace: > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create > assembly: Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; > Reason: Not a v4.0.0 POM. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; > Reason: Not a v4.0.0 POM. > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:302) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error retrieving POM of module-dependency: ebs:pps:jar:3.0.2; Reason: Not a > v4.0.0 POM. > at > org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:114) > at > org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90) > at > org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54) > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278) > ... 18 more > Caused by: org.apache.maven.project.InvalidProjectModelException: Not a > v4.0.0 POM. > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder
[jira] Closed: (MPH-25) Simplify Help Plugin - Add medium describe flag
[ http://jira.codehaus.org/browse/MPH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MPH-25. - Resolution: Fixed Fix Version/s: 2.0.2 Applied. Thanks, Eric, this is a nice addition. > Simplify Help Plugin - Add medium describe flag > --- > > Key: MPH-25 > URL: http://jira.codehaus.org/browse/MPH-25 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Reporter: Eric Redmond >Assignee: John Casey > Fix For: 2.0.2 > > Attachments: maven-help-plugin-medium.diff, mylar-context.zip > > > This simplifies the help plugin "describe" goal printout in "full" mode by > removing redundant spaces to condense the overall size of the output. > This patch also adds a "medium" flag - allowing one to get a simple plugin > description with a list of available goals (no parameter data). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3064) "Building For Different Environments with Maven 2" in APT-format
[ http://jira.codehaus.org/browse/MNG-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3064. --- Resolution: Fixed Fix Version/s: Documentation Applied. Thanks! > "Building For Different Environments with Maven 2" in APT-format > > > Key: MNG-3064 > URL: http://jira.codehaus.org/browse/MNG-3064 > Project: Maven 2 > Issue Type: New Feature > Components: Documentation: Guides >Affects Versions: Documentation >Reporter: Erik Drolshammer >Assignee: John Casey >Priority: Trivial > Fix For: Documentation > > Attachments: building-for-different-environments.patch > > > http://blogs.codehaus.org/people/trygvis/archives/001296_building_for_different_environments_with_maven_2.html > in APT format. This guide is often referenced and should be included in the > official docs. It is a pure encoding of the guide. I have only correct "lt" > to "-" and commented out a dead link to TrackBack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3047) DefaultArtifactVersion compareTo inconsistent with equals
[ http://jira.codehaus.org/browse/MNG-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3047. --- Resolution: Fixed Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1-alpha-1 2.0.8 Applied. Thanks! > DefaultArtifactVersion compareTo inconsistent with equals > - > > Key: MNG-3047 > URL: http://jira.codehaus.org/browse/MNG-3047 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: David Julian >Assignee: John Casey >Priority: Minor > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: MNG-3047-maven-artifact.patch > > > Over the course of investigating MNG-3046, I discovered > DefaultArtifactVersion's implementation of Comparable.compareTo() is > inconsistent with its equals(Object). (DefaultArtifactVersion doesn't > implement equals(...); it's using the instance equals it gets from Object.) > The contract for Comparable.compareTo()[1] states, while it's not strictly > required the behavior between compareTo and equals be consistent, breaking it > should be an overt and visible decision. In the case of > DefaultArtifactVersion, there's really no reason not to implement equals and > hashCode. > I have a fix--I'll attach a patch shortly--that implements equals and > hashCode following the recipes from Bloch's "Effective Java." In fact, > equals now uses a cleaned-up compareTo, ensuring consistency across these > methods. > Since the interface ArtifactVersion extends Comparable (as opposed to > DefaultArtifactVersion implementing both ArtifactVersion and Comparable) I > assume the intent is to be able to compare different ArtifactVersions > regardless of implementation. Therefore, I added the equals and hashCode > declaration to the interface and made the equals and compareTo > implementations work with all ArtifactVersions. > Note that this work obviates the patch for MNG-3046. I made that patch small > and surgical to fix a major issue. This fix is less urgent--still important, > imho--but I wasn't sure if the interface changes were right for the whole > project, if such a big change is warranted, etc. The bottom line is: only > that patch or this one need be applied, not both. > [1] > http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html#compareTo(T) -- 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-2068) Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104832 ] Denis Pasek commented on MNG-2068: -- Same problem for me with Maven 2.0.4 and 2.0.6. Build fails if it's started on a intermediate POM (= not top level POM but also no leaf in project hierarchy). > Multiple inheritance fails to find "grand" parent in ../../pom.xml when the > groupIds differ (Test Case Attached) > > > Key: MNG-2068 > URL: http://jira.codehaus.org/browse/MNG-2068 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.4, 2.0.5, 2.0.6 >Reporter: Brian Fox >Assignee: John Casey >Priority: Critical > Fix For: 2.0.x > > Attachments: good-sample.zip, mavenbugreport.zip, sample.zip > > > I have a project that inherits from 2 (or more) parents. If the grand parent > (parent of my parent) isn't in the repository, it isn't found at ../../pom.xml > In my sample, make sure none of the artifacts are in your repository, then go > down to sample-jar and try to build from there. See it fail. > Note: If you remove the ".sub" from the second parent's group and update the > sampe-jar pom, it no longer fails and finds the grandparent. > See below for the output when the groups are different (fails) and when they > are the same (works) > Failing output: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > sp > ecification in null:sample-parent2:pom:null: > Specified: sample-project.sub:sample-parent::SNAPSHOT > Found: sample-project:sample-parent:pom:SNAPSHOT > [DEBUG] Retrieving parent-POM from the repository for project: > null:sample-paren > t2:pom:null > [DEBUG] Skipping disabled repository central > [DEBUG] sample-parent: using locally installed snapshot > [DEBUG] Trying repository sv1-int > Downloading: > http://sv1.tus.stchome.com:9998/repository/sample-project/sub/sampl > e-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository sv1-int > (http://sv1.tus.stchome > .com:9998/repository) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2//sample-project/sub/samp > le-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository Maven Snapshots > (http://snapsho > ts.maven.codehaus.org/maven2/) > [DEBUG] Skipping disabled repository central > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: sample-project.sub > ArtifactId: sample-parent > Version: SNAPSHOT > Reason: Unable to download the artifact from any repository > sample-project.sub:sample-parent:pom:SNAPSHOT > OUTPUT WITHOUT .sub: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-parent2:pom:null > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [compile] > [INFO] > - > --- > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-resour -- 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: (DOXIA-148) FmlParser emits HTML specific events
FmlParser emits HTML specific events Key: DOXIA-148 URL: http://jira.codehaus.org/browse/DOXIA-148 Project: Maven Doxia Issue Type: Bug Components: Module - Fml Affects Versions: 1.0-alpha-8 Reporter: Lukas Theussl Priority: Minor Questions/answers in an fml document may contain (almost) arbitrary html tags (eg lists, paragraphs) but the question/answer in the Faq model is defined as a simple String and questions/answers are emitted as rawText by the parser. That means that FmlParser events can only be consumed correctly by the XhtmlSink (or XmlSink). -- 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] Moved: (MRAR-17) Maven-cobertura-plugin does not work for RAR packaging projects
[
http://jira.codehaus.org/browse/MRAR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey moved MNG-3105 to MRAR-17:
-
Affects Version/s: (was: 2.0.6)
2.3
Issue Type: New Feature (was: Bug)
Key: MRAR-17 (was: MNG-3105)
Project: Maven 2.x Rar Plugin (was: Maven 2)
> Maven-cobertura-plugin does not work for RAR packaging projects
> ---
>
> Key: MRAR-17
> URL: http://jira.codehaus.org/browse/MRAR-17
> Project: Maven 2.x Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> 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] Updated: (MRAR-17) No RAR packaging (Causes Maven-cobertura-plugin to fail)
[
http://jira.codehaus.org/browse/MRAR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MRAR-17:
---
Summary: No RAR packaging (Causes Maven-cobertura-plugin to fail) (was:
Maven-cobertura-plugin does not work for RAR packaging projects)
We should consider defining an ArtifactHandler and lifecycle mapping for rar
packaging...
> No RAR packaging (Causes Maven-cobertura-plugin to fail)
>
>
> Key: MRAR-17
> URL: http://jira.codehaus.org/browse/MRAR-17
> Project: Maven 2.x Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> 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] Commented: (MNG-3147) CLONE -No component for RAR packaging projects in components.xml
[
http://jira.codehaus.org/browse/MNG-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104829
]
John Casey commented on MNG-3147:
-
As I mentioned in the linked issue, I believe this should be defined in the
maven-rar-plugin, then used via true
> CLONE -No component for RAR packaging projects in components.xml
>
>
> Key: MNG-3147
> URL: http://jira.codehaus.org/browse/MNG-3147
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> 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] Commented: (MNG-3105) Maven-cobertura-plugin does not work for RAR packaging projects
[
http://jira.codehaus.org/browse/MNG-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104826
]
John Casey commented on MNG-3105:
-
Wouldn't this artifact definition be more appropriate in the maven-rar-plugin?
That way, rar functionality could be captured in a single release cycle, rather
than waiting for new releases of Maven itself.
> Maven-cobertura-plugin does not work for RAR packaging projects
> ---
>
> Key: MNG-3105
> URL: http://jira.codehaus.org/browse/MNG-3105
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> 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] Closed: (MNG-3062) Allow access to mojoExecution from within plugin.
[ http://jira.codehaus.org/browse/MNG-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3062. --- Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.1-alpha-1 2.0.8 I applied this. It provides easy access to all sorts of information about the current mojo, execution, and plugin...including configuration and more. This will be very useful for advanced mojos and reports. > Allow access to mojoExecution from within plugin. > - > > Key: MNG-3062 > URL: http://jira.codehaus.org/browse/MNG-3062 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.6 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: PluginParameterExpressionEvaluator.patch > > > I would like to be able to access the execution ID from within a plugin. > This could be useful for example to run only certain executions. This could > be done with a small change to the plugin expression evaluator. > I created a patch that would give the plugin access to the current > MojoExecution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3046) DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
[
http://jira.codehaus.org/browse/MNG-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3046.
---
Resolution: Fixed
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
2.0.8
Applied, thanks.
> DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
> ---
>
> Key: MNG-3046
> URL: http://jira.codehaus.org/browse/MNG-3046
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.6
>Reporter: David Julian
>Assignee: John Casey
> Fix For: 2.0.8, 2.1-alpha-1
>
> Attachments: MNG-3046-maven-artifact.patch
>
>
> The implementation of Comparable.compareTo(Object) is faulty regarding the
> handling of version numbers where a build number is present but zero. Here's
> a unit test to demonstrate:
> DefaultArtifactVersion v1 = new DefaultArtifactVersion("2.0");
> DefaultArtifactVersion v2 = new DefaultArtifactVersion("2.0-0");
> DefaultArtifactVersion v3 = new DefaultArtifactVersion("2.0-alpha1");
>
> // v1 and v2 are equal
> assertTrue( v1.compareTo(v2) == 0 );
> assertTrue( v2.compareTo(v1) == 0 );
>
> // v1 is newer than v3
> assertTrue( v1.compareTo(v3) > 0 );
> assertTrue( v3.compareTo(v1) < 0 );
>
> // ergo, v2 should also be newer than v3
> assertTrue( v2.compareTo(v3) > 0 ); // FAILS!! returns 0 (equal)
> assertTrue( v3.compareTo(v1) < 0 ); // succeeds
> This test demonstrates this behavior violates symmetry and transitivity.
> Luckily, the fix is easy. A small change to the compareTo method to consider
> qualifiers before build numbers relieves this issue. I have a patch that
> I'll submit as soon as I have the issue number.
--
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-76) don't check the test code
don't check the test code
-
Key: MCHECKSTYLE-76
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-76
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: windos, standar conf projet (juste parent pom)
Reporter: kerboriou christophe
Priority: Critical
Fix For: 2.2
the parm for excute checkstyle on test code was at true. and i have this log
{panel} [DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-checkstyle-plugin:2.1:checkstyle' -->
[DEBUG] (f) cacheFile =
D:\workspaces\workspace\{sous-projet}\target/checkstyle-cachefile
[DEBUG] (f) configLocation = http://///checkstyle_config.xml
[DEBUG] (f) consoleOutput = false
[DEBUG] (f) enableFilesSummary = true
[DEBUG] (f) enableRSS = true
[DEBUG] (f) enableRulesSummary = true
[DEBUG] (f) enableSeveritySummary = true
[DEBUG] (f) failsOnError = false
[DEBUG] (f) format = sun
[DEBUG] (f) headerFile = D:\workspaces\workspace\{sous-projet}\LICENSE.txt
[DEBUG] (f) headerLocation = LICENSE.txt
[DEBUG] (f) includes = **/*.java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) outputDirectory =
D:\workspaces\workspace\{sous-projet}\target\site
[DEBUG] (f) outputFile =
D:\workspaces\workspace\{sous-projet}\target\checkstyle-result.xml
[DEBUG] (f) outputFileFormat = xml
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] {color:red} *(f) sourceDirectory =
D:\workspaces\workspace\{sous-projet}\src\main\java*{color}
[DEBUG] (f) xrefLocation =
D:\workspaces\workspace\{sous-projet}\target\site\xref
[DEBUG] -- end configuration --
[INFO] [checkstyle:checkstyle]
[DEBUG] resolveLocation(http://///checkstyle_config.xml,
checkstyle-checker.xml)
[DEBUG] Potential URL: http://///checkstyle_config.xml
[DEBUG] resolveLocation(null, checkstyle-checker.properties)
[DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt)
[DEBUG] Location is not a URL.
[DEBUG] Location is not a File.
[DEBUG] Potential Resource:
jar:file:/C:/dev/maven/bin/../lib/jsch-0.1.24.jar!/LICENSE.txt
[DEBUG] resolveLocation(null, checkstyle-packages.xml)
[DEBUG] resolveLocation(null, checkstyle-suppressions.xml)
[DEBUG] File D:\workspaces\workspace\{sous-projet}\target\site/checkstyle.rss
created...{panel}
the src/test/java wasn't use.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-247) Site generation does not inherit element from parent site.xml
Site generation does not inherit element from parent site.xml --- Key: MSITE-247 URL: http://jira.codehaus.org/browse/MSITE-247 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: WinXP-SP2, JDK 1.5.0_12, Maven 2.0.7 Reporter: Benjamin Bentmann Priority: Minor I have a parent project of a multi-module project whose site.xml contains The element is properly inherited by the site descriptors of the module POMs, but the element gets dropped so that one needs to manually add it to each site.xml for the modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3134) DefaultModelInheritence::assembleDistributionInheritence should be childPathAdjustment aware
[ http://jira.codehaus.org/browse/MNG-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3134. --- Resolution: Fixed Fix Version/s: 2.1-alpha-1 2.0.8 Applied. Thanks, John. > DefaultModelInheritence::assembleDistributionInheritence should be > childPathAdjustment aware > > > Key: MNG-3134 > URL: http://jira.codehaus.org/browse/MNG-3134 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.7 >Reporter: John Allen >Assignee: John Casey >Priority: Critical > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: patch.txt > > > In the same way that the URL, and SCM inheritance assembly is > 'childPathAdjustment' aware, so should the site distribution URL. > The childPathAdjustment value takes into account a child's relative location > to its parent, such that 'children' (modules) that are declared via > ../../foo/bar end up with paths that are accurate for their > location within the external namespaces (ie the SCM namespace or the URL > namespace). However this is not being done for the site distribution URL > which is obviously a bug as the project URL, which remember is > childPathAdjustment aware, has a direct coupling to the > distroManagement.site.URL. > Patch against maven-project 2.0.7 attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-46) Provide support for more complex filtering (Velocity, etc)
[ http://jira.codehaus.org/browse/MRESOURCES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104819 ] Brian Jackson commented on MRESOURCES-46: - Two use cases I need that are currently not supported. 1) Conditionally include/exclude sections of a file based on property. This is not possible currently 2) Inject file fragment into another file. We have a DAO framework that generates a fragment of a config file. I would like to be able to inject this generated file into a template of a full config file. These relate to managing configuration files for our application. We have many instance of our application with different config as well as differences per instance across deployment environments. Example: Football instance has 5 config files and is deployed to 4 environments, local-dev, dev, qa, prod. Baseball instance has 5 config files and is deployed to 4 environments, local-dev, dev, qa, prod. What sounds like 40 files is more since each developer has there own version of local-dev. I'd like to reduce this to maintaining 5 templates for Football and 5 templates for Baseball with the environment differences specified in a Maven profile. The config files would then be generated from the templates. > Provide support for more complex filtering (Velocity, etc) > -- > > Key: MRESOURCES-46 > URL: http://jira.codehaus.org/browse/MRESOURCES-46 > Project: Maven 2.x Resources Plugin > Issue Type: New Feature >Reporter: Brian Jackson > > My resources (ex. configuration files that have conditional blocks based on > target environment) need more complex filtering then simple token > replacement. Support for any templating language would be helpful. An > abstraction to plugin the language desired would be even better. -- 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-104) Add Analyze HTML Report
Add Analyze HTML Report --- Key: MDEP-104 URL: http://jira.codehaus.org/browse/MDEP-104 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.0-alpha-5 Reporter: Jeremy Lauture Assignee: Brian Fox Attachments: analyze-report-mojo.patch It would be nice to have a HTML analyze report (as same as the CLI analyze report) when we generate the web site project. Find in attachment our patch that provides this new feature. In order to use it, you can add this reporting section in your pom.xml: org.apache.maven.plugins maven-dependency-plugin 2.0-alpha-5-SNAPSHOT analyze-report -- 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: (CONTINUUM-1385) Foreign key konstraint violation
[
http://jira.codehaus.org/browse/CONTINUUM-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-1385.
---
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 1.1-beta-2
> Foreign key konstraint violation
>
>
> Key: CONTINUUM-1385
> URL: http://jira.codehaus.org/browse/CONTINUUM-1385
> Project: Continuum
> Issue Type: Bug
> Components: Database
>Affects Versions: 1.1-beta-2
> Environment: Linux, Tomcat 5.5.17, Derby
>Reporter: Pavel Halas
>Assignee: Emmanuel Venisse
> Fix For: 1.1-beta-2
>
>
> Hi,
> I tried to delete an ant project from a group and get the following message
> (see below). Removing all the build results helped. Nevertheless, I think
> there should be a delete cascade, not a contstraint.
> {noformat}
> javax.jdo.JDOUserException: One or more instances could not be deleted
> NestedThrowables: javax.jdo.JDODataStoreException: Delete request failed:
> DELETE FROM BUILDDEFINITION WHERE ID = ? NestedThrowables: SQL Exception:
> DELETE on table 'BUILDDEFINITION' caused a violation of foreign key
> constraint 'BUILDRESULT_FK1' for key (6). The statement has been rolled back.
> {noformat}
--
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: (MRESOURCES-46) Provide support for more complex filtering (Velocity, etc)
[ http://jira.codehaus.org/browse/MRESOURCES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104814 ] Stephane Nicoll commented on MRESOURCES-46: --- should be made available to all plugins (in a shared component). Brian, if you can refine that would be good. We can't support "everything" and "complex filtering" without valid uses cases. > Provide support for more complex filtering (Velocity, etc) > -- > > Key: MRESOURCES-46 > URL: http://jira.codehaus.org/browse/MRESOURCES-46 > Project: Maven 2.x Resources Plugin > Issue Type: New Feature >Reporter: Brian Jackson > > My resources (ex. configuration files that have conditional blocks based on > target environment) need more complex filtering then simple token > replacement. Support for any templating language would be helpful. An > abstraction to plugin the language desired would be even better. -- 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-347) regression: plexus is not properly isolated
[ http://jira.codehaus.org/browse/SUREFIRE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104813 ] Brett Porter commented on SUREFIRE-347: --- testRender(org.apache.maven.doxia.siterenderer.DefaultSiteRendererTest) Time elapsed: 0.275 sec <<< ERROR! java.lang.NoSuchMethodError: org.codehaus.plexus.component.repository.ComponentDescriptor.setSource(Ljava/lang/String;)V at org.codehaus.plexus.component.discovery.DefaultComponentDiscoverer.createComponentDescriptors(DefaultComponentDiscoverer.java:68) see: http://mail-archives.apache.org/mod_mbox/maven-dev/200708.mbox/[EMAIL PROTECTED] > regression: plexus is not properly isolated > --- > > Key: SUREFIRE-347 > URL: http://jira.codehaus.org/browse/SUREFIRE-347 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: Brett Porter > Fix For: 2.3.1 > > > Currently, if you use 2.3.1-SNAPSHOT on doxia-site-renderer, you get a test > error due to a class incompatibility in Plexus. > The same issue occurs if you use forkMode=never under 2.3 or earlier. > this could be related to, or caused by SUREFIRE-334. Fix that first and see > if this is still an issue. However, note that it works under 2.3 with > forkMode=once and useSystemClassLoader=true. -- 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: (MRM-471) Create a sample project that demonstrates how a component can be plugged into Archiva.
[ http://jira.codehaus.org/browse/MRM-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-471. Resolution: Fixed Fixed in -r565706 - Added feature for dumping the new artifacts into a file. - I also tested this component > Create a sample project that demonstrates how a component can be plugged into > Archiva. > -- > > Key: MRM-471 > URL: http://jira.codehaus.org/browse/MRM-471 > Project: Archiva > Issue Type: Wish >Affects Versions: 1.0-beta-1 >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] Closed: (MAVENUPLOAD-1671) JasperReports 2.0.0 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1671. --- Assignee: Carlos Sanchez Resolution: Fixed > JasperReports 2.0.0 upload > -- > > Key: MAVENUPLOAD-1671 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1671 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu >Assignee: Carlos Sanchez > > http://www.jasperforge.org/maven2/jasperreports-2.0.0-bundle.jar > http://sourceforge.net/projects/jasperreports > http://sourceforge.net/project/memberlist.php?group_id=36382 > Open Source Reporting Engine -- 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: (MAVENUPLOAD-1668) HtmlUnit 1.12 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1668. --- Assignee: Carlos Sanchez Resolution: Fixed > HtmlUnit 1.12 upload request > > > Key: MAVENUPLOAD-1668 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1668 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Guillemot >Assignee: Carlos Sanchez > > http://htmlunit.sourceforge.net/htmlunit-1.12-bundle.jar > Team members, including myself: > http://htmlunit.sourceforge.net/team-list.html > http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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-1666) upload vraptor 2.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104807 ] Carlos Sanchez commented on MAVENUPLOAD-1666: - you have to provide the parent pom I strongly suggest you to go through the syncing repos process http://maven.apache.org/guides/mini/guide-central-repository-upload.html > upload vraptor 2.4 > -- > > Key: MAVENUPLOAD-1666 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1666 > Project: maven-upload-requests > Issue Type: Task >Reporter: Fabio Kung > > upload vraptor 2.2 > file: http://www.vraptor.org/vraptor-2.2-bundle.jar > project: http://www.vraptor.org > team: http://www.vraptor.org/team-list.html > VRaptor 2.2 framework update with many improvements and new docs. > > VRaptor 2 is a mvc controller based on the idea (stolen) from Rails > that configuration should be minimal and conventions should be > maximized. -- 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: (MAVENUPLOAD-1669) opencsv 1.8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1669. --- Assignee: Carlos Sanchez Resolution: Fixed > opencsv 1.8 > --- > > Key: MAVENUPLOAD-1669 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1669 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina >Assignee: Carlos Sanchez > -- 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: (MEV-498) javax.xml.ws:jaxws-api:2.1 is bad
[ http://jira.codehaus.org/browse/MEV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104806 ] Carlos Sanchez commented on MEV-498: the solution was already proposed, we can host a 2.1-1 with the right pom and jar, but somebody has to prepare and request it > javax.xml.ws:jaxws-api:2.1 is bad > - > > Key: MEV-498 > URL: http://jira.codehaus.org/browse/MEV-498 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Dan Tran >Assignee: Carlos Sanchez > > Sun just released jaxws 2.1 and the jaxws-api available at repo1.maven.org is > not the same with the Sun's one (both pom and the jar ) > I am working jaxws-maven-plugin and the generate code crash due to missing > interfaces > We can either sync the sun version over, or remove it from repo1 to remove > confusion > Here is the link to java.net repo > https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.ws/ -- 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: (CONTINUUM-1357) release data-management with beta2
[ http://jira.codehaus.org/browse/CONTINUUM-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1357. --- Assignee: Emmanuel Venisse Resolution: Fixed > release data-management with beta2 > -- > > Key: CONTINUUM-1357 > URL: http://jira.codehaus.org/browse/CONTINUUM-1357 > Project: Continuum > Issue Type: Task > Components: Database >Affects Versions: 1.1-beta-1 >Reporter: Jesse McConnell >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-2 > > > we need to enable the data management with the next release of continuum -- 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: (MPMD-60) @SuppressWarnings causes maven PMD plugin to fail on building report
[
http://jira.codehaus.org/browse/MPMD-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104798
]
Holger Brands commented on MPMD-60:
---
We also get this annoying bug.
It seems to be related to issue MPMD-59, so perhaps upgrading to PMD 4.0 will
help?
> @SuppressWarnings causes maven PMD plugin to fail on building report
>
>
> Key: MPMD-60
> URL: http://jira.codehaus.org/browse/MPMD-60
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.2
> Environment: Windows XP, Java 6, Maven 2.0.6, PMD-3.9 plugin
>Reporter: Pieter Iserbyt
>
> When running mvn pmd:pmd, the plugin crashes at the time it tries to create
> the report.
> This seems to happen when violations are present that are suppressed by a
> @SuppressWarnings("PMD") or @SuppressWarnings("PMD.a_warning_name")
> annotation.
> Also, java keywords are not recognized by PMD, e.g. for
> @SuppressWarnings("unused"), violations are logged anyway.
> D:\trunk\quality>mvn pmd:check -e
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'pmd'.
> [INFO] org.apache.maven.plugins: checking for updates from doc-artifactory
> [INFO] org.codehaus.mojo: checking for updates from doc-artifactory
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'cc696ab05c9684342aa52c61bdcb7471a264b533'; remote =
> 'fd019ddf5b11fc51ce35ac7cf10c2ef5b387b0cf' - RETRYING
> [INFO] artifact org.apache.maven.plugins:maven-pmd-plugin: checking for
> updates from doc-artifactory
> [INFO]
>
> [INFO] Building Diamond Quality
> [INFO]task-segment: [pmd:check]
> [INFO]
>
> [INFO] Preparing pmd:check
> [INFO] [pmd:pmd]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error has occurred in PMD Report report generation.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred
> in PMD Report report generation.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:903)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in PMD Report report generation.
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 19 more
> Caused by: java.lang.NullPointerException
>
[jira] Created: (MAVENUPLOAD-1671) JasperReports 2.0.0 upload
JasperReports 2.0.0 upload -- Key: MAVENUPLOAD-1671 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1671 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://www.jasperforge.org/maven2/jasperreports-2.0.0-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104791
]
Vitaliy Obmanyuk commented on MJAR-69:
--
Any progress of that?
I have the same error with maven-rar-plugin on Linux (it works fine on Windows
platform only).
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1385) Foreign key konstraint violation
[
http://jira.codehaus.org/browse/CONTINUUM-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104788
]
Pavel Halas commented on CONTINUUM-1385:
Build: continuum-20070727.01.war
> Foreign key konstraint violation
>
>
> Key: CONTINUUM-1385
> URL: http://jira.codehaus.org/browse/CONTINUUM-1385
> Project: Continuum
> Issue Type: Bug
> Components: Database
>Affects Versions: 1.1-beta-2
> Environment: Linux, Tomcat 5.5.17, Derby
>Reporter: Pavel Halas
>
> Hi,
> I tried to delete an ant project from a group and get the following message
> (see below). Removing all the build results helped. Nevertheless, I think
> there should be a delete cascade, not a contstraint.
> {noformat}
> javax.jdo.JDOUserException: One or more instances could not be deleted
> NestedThrowables: javax.jdo.JDODataStoreException: Delete request failed:
> DELETE FROM BUILDDEFINITION WHERE ID = ? NestedThrowables: SQL Exception:
> DELETE on table 'BUILDDEFINITION' caused a violation of foreign key
> constraint 'BUILDRESULT_FK1' for key (6). The statement has been rolled back.
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1385) Foreign key konstraint violation
Foreign key konstraint violation
Key: CONTINUUM-1385
URL: http://jira.codehaus.org/browse/CONTINUUM-1385
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1-beta-2
Environment: Linux, Tomcat 5.5.17, Derby
Reporter: Pavel Halas
Hi,
I tried to delete an ant project from a group and get the following message
(see below). Removing all the build results helped. Nevertheless, I think there
should be a delete cascade, not a contstraint.
{noformat}
javax.jdo.JDOUserException: One or more instances could not be deleted
NestedThrowables: javax.jdo.JDODataStoreException: Delete request failed:
DELETE FROM BUILDDEFINITION WHERE ID = ? NestedThrowables: SQL Exception:
DELETE on table 'BUILDDEFINITION' caused a violation of foreign key constraint
'BUILDRESULT_FK1' for key (6). The statement has been rolled back.
{noformat}
--
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
