[jira] Work started: (MECLIPSE-56) Generated .project-file misses encoding declaration
[ http://jira.codehaus.org/browse/MECLIPSE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MECLIPSE-56 started by Herve Boutemy. > Generated .project-file misses encoding declaration > --- > > Key: MECLIPSE-56 > URL: http://jira.codehaus.org/browse/MECLIPSE-56 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Workspace settings >Affects Versions: 2.0 >Reporter: Stefan Hübner >Assignee: Herve Boutemy > Attachments: MECLIPSE-56-maven-eclipse-plugin.patch1, > MECLIPSE-56-maven-eclipse-plugin.patch2, > MECLIPSE-56-resourcesForAdditionalTestcaseszip > > > Hi, > I'm experiencing problems creating eclipse project files, if the project's > description in pom.xml contains special characters like german umlauts (like > "öüä"). Refreshing the eclipse workspace after running eclipse:eclipse > results in the following message from eclipse: > "Errors occurred while refreshing resources with the local file system. > Failed to read the project description file (.project) for > comworld-eventlisteners. The file has been changed on disk, and it now > contains invalid information. The project will not function properly until > the description file is restored to a valid state." > This is caused by the content of the .project's generated comment-tag > containing the exact same description as in pom.xml. But the .project-file is > generated without stating an encoding parser should use to read it. So, if I > prepend the line > > eclipse is able to read the file just fine. > Regards, > Stefan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1834) jdk 1.4 compatible version for pmd 4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Le Vourch reopened MAVENUPLOAD-1834: --- There seems to be an issue with the pom version as when I tried to use the new artifact for the maven-pmd-plugin in http://jira.codehaus.org/browse/MPMD-66, I get an error. [WARNING] POM for 'pmd:pmd-jdk14:pom:4.1:compile' is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for project pmd:pmd-jdk14 at /home/xlv/.m2/repository/pmd/pmd-jdk14/4.1/pmd-jdk14-4.1.pom It worked when I imported the jar files locally. I don't understand why the generated pom is not similar to the one from the pmd:pmd bundle as I've based the new project.xml in the pmd:pmd-jdk14 bundle on the pmd:pmd version so I expected the pom files to be similar too. The differences in the project.xml files are pasted below. Thanks for any info you can provide so that future versions can be generated automatically in the correct format Xavier = 5c5 < pmd --- > pmd-jdk14 273c273,283 < 4.4 --- > 3.8.2 > > > backport-util-concurrent > backport-util-concurrent > 3.1 > > > net.sourceforge.retroweaver > retroweaver-rt > 2.0.2 = > jdk 1.4 compatible version for pmd 4.1 > -- > > Key: MAVENUPLOAD-1834 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1834 > Project: maven-upload-requests > Issue Type: Task >Reporter: Xavier Le Vourch >Assignee: Carlos Sanchez > > this create a new jdk1.4 based artifact pmd:pmd-jdk14 that may be needed for > core pmd 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] Updated: (MSHADE-9) failure to shade/relocate plexus-archiver (interfaces not properly relocated)
[
http://jira.codehaus.org/browse/MSHADE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated MSHADE-9:
--
Attachment: mshade9-repro.diff
You should be able to apply this patch to surefire trunk revision 602310 to
reproduce the problem.
> failure to shade/relocate plexus-archiver (interfaces not properly relocated)
> -
>
> Key: MSHADE-9
> URL: http://jira.codehaus.org/browse/MSHADE-9
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Reporter: Dan Fabulich
>Priority: Blocker
> Attachments: mshade9-repro.diff
>
>
> I tried using the shade plugin with surefire, to shade/relocate
> plexus-archiver. I'm trying to relocate its package to be
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver. It took
> several tries due to MSHADE-5, but even when it finally "worked", it failed
> to modify plexus-archiver correctly.
> org.codehaus.plexus.archiver.zip.AsiExtraField implements
> org.codehaus.plexus.archiver.zip.ZipExtraField. But when I try to run
> p-archiver after shading it, I get this exception:
> java.lang.ExceptionInInitializerError
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipEntry.getCentralDirectoryExtra(ZipEntry.java:386)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.writeCentralFileHeader(ZipOutputStream.java:769)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.finish(ZipOutputStream.java:320)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.close(ZipOutputStream.java:542)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:378)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
> at
> org.apache.maven.surefire.booter.ForkConfiguration.createJar(ForkConfiguration.java:264)
> [snip]
> Caused by: java.lang.RuntimeException: class
> org.codehaus.plexus.archiver.zip.AsiExtraField doesn't implement ZipExtraField
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:63)
> at
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> ... 31 more
> My decompiler (DJ) shows that the interfaces were partially but not entirely
> shaded correctly:
> package org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip;
> import java.util.zip.CRC32;
> import java.util.zip.ZipException;
> import org.codehaus.plexus.archiver.UnixStat;
> import org.codehaus.plexus.archiver.zip.ZipExtraField;
> import org.codehaus.plexus.archiver.zip.ZipLong;
> import org.codehaus.plexus.archiver.zip.ZipShort;
> // Referenced classes of package
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip:
> //ZipExtraField, ZipShort, ZipLong
> public class AsiExtraField
> implements
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipExtraField,
> org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.UnixStat,
> Cloneable
> {
> [...]
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSHADE-5) 50% of the time I run the shade plugin, it's unable to replace the original jar
[ http://jira.codehaus.org/browse/MSHADE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MSHADE-5. - Resolution: Fixed Yup, that fixed it. > 50% of the time I run the shade plugin, it's unable to replace the original > jar > --- > > Key: MSHADE-5 > URL: http://jira.codehaus.org/browse/MSHADE-5 > Project: Maven 2.x Shade Plugin > Issue Type: Bug > Environment: Windows XP SP2, Java 1.5.0_12 >Reporter: Dan Fabulich >Priority: Blocker > > I tried to wire up the shade plugin in surefire trunk. About 50% of the time > I run the shade plugin I get a "[WARNING] Could not replace original artifact > with shaded artifact!" IMO that should halt the build, because it goes on to > use the stripped POM without using the shaded jar; hilarity ensues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHADE-8) Shade plugin will cheerfully relocate your own classes
[ http://jira.codehaus.org/browse/MSHADE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MSHADE-8: -- Description: My relocation patterns were initially too relaxed, and so they wound up relocating my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got relocated, it broke the plugin metadata... definitely not what I wanted. was: My relocation patterns were initially too relaxed, and so they wound up shading my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got shaded, it broke the plugin metadata... definitely not what I wanted. Summary: Shade plugin will cheerfully relocate your own classes (was: Shade plugin will cheerfully shade your own classes) > Shade plugin will cheerfully relocate your own classes > -- > > Key: MSHADE-8 > URL: http://jira.codehaus.org/browse/MSHADE-8 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Reporter: Dan Fabulich > > My relocation patterns were initially too relaxed, and so they wound up > relocating my own classes, rather than just the classes I depend on. > I could imagine somebody wanting to do this, but I think there should > probably be a safety check or something to try to help you not do it by > accident; it's probably not what you want. (After all, if you wanted your > code to be in a different package, wouldn't you have just written it that way > to begin with?) > In my case I was working on a Maven plugin; when its classes got relocated, > it broke the plugin metadata... definitely not what I wanted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHADE-9) failure to shade/relocate plexus-archiver (interfaces not properly relocated)
[
http://jira.codehaus.org/browse/MSHADE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated MSHADE-9:
--
Description:
I tried using the shade plugin with surefire, to shade/relocate
plexus-archiver. I'm trying to relocate its package to be
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver. It took several
tries due to MSHADE-5, but even when it finally "worked", it failed to modify
plexus-archiver correctly.
org.codehaus.plexus.archiver.zip.AsiExtraField implements
org.codehaus.plexus.archiver.zip.ZipExtraField. But when I try to run
p-archiver after shading it, I get this exception:
java.lang.ExceptionInInitializerError
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipEntry.getCentralDirectoryExtra(ZipEntry.java:386)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.writeCentralFileHeader(ZipOutputStream.java:769)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.finish(ZipOutputStream.java:320)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.close(ZipOutputStream.java:542)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:378)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
at
org.apache.maven.surefire.booter.ForkConfiguration.createJar(ForkConfiguration.java:264)
[snip]
Caused by: java.lang.RuntimeException: class
org.codehaus.plexus.archiver.zip.AsiExtraField doesn't implement ZipExtraField
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:63)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
... 31 more
My decompiler (DJ) shows that the interfaces were partially but not entirely
shaded correctly:
package org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip;
import java.util.zip.CRC32;
import java.util.zip.ZipException;
import org.codehaus.plexus.archiver.UnixStat;
import org.codehaus.plexus.archiver.zip.ZipExtraField;
import org.codehaus.plexus.archiver.zip.ZipLong;
import org.codehaus.plexus.archiver.zip.ZipShort;
// Referenced classes of package
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip:
//ZipExtraField, ZipShort, ZipLong
public class AsiExtraField
implements
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipExtraField,
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.UnixStat,
Cloneable
{
[...]
}
was:
I tried using the shade plugin with surefire, to shade plexus-archiver. It
took several tries due to MSHADE-5, but even when it finally "worked", it
failed to shade plexus-archiver correctly.
org.codehaus.plexus.archiver.zip.AsiExtraField implements
org.codehaus.plexus.archiver.zip.ZipExtraField. But when I try to run
p-archiver after shading it, I get this exception:
java.lang.ExceptionInInitializerError
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipEntry.getCentralDirectoryExtra(ZipEntry.java:386)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.writeCentralFileHeader(ZipOutputStream.java:769)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.finish(ZipOutputStream.java:320)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.close(ZipOutputStream.java:542)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:378)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
at
org.apache.maven.surefire.booter.ForkConfiguration.createJar(ForkConfiguration.java:264)
[snip]
Caused by: java.lang.RuntimeException: class
org.codehaus.plexus.archiver.zip.AsiExtraField doesn't implement ZipExtraField
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:63)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
... 31 more
My decompiler (DJ) shows that the interfaces were partially but not entirely
shaded correctly:
package org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip;
import java.util.zip.CRC32;
import java.util.zip.ZipException;
import org.codehaus.plexus.archiver.UnixStat;
import org.codehaus.plexus.archiver.zip.ZipExtraField;
import org.codehaus.plexus.archiver.zip.ZipLong;
import org.
[jira] Commented: (MSHADE-5) 50% of the time I run the shade plugin, it's unable to replace the original jar
[ http://jira.codehaus.org/browse/MSHADE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116228 ] Daniel Kulp commented on MSHADE-5: -- I have no way of testing this (no windows boxes), but looking at the code, we never called jarFile.close on the jars we were reading. Thus, the file was probably locked. I fixed that. I'd appreciate it if you could see if that helps. > 50% of the time I run the shade plugin, it's unable to replace the original > jar > --- > > Key: MSHADE-5 > URL: http://jira.codehaus.org/browse/MSHADE-5 > Project: Maven 2.x Shade Plugin > Issue Type: Bug > Environment: Windows XP SP2, Java 1.5.0_12 >Reporter: Dan Fabulich >Priority: Blocker > > I tried to wire up the shade plugin in surefire trunk. About 50% of the time > I run the shade plugin I get a "[WARNING] Could not replace original artifact > with shaded artifact!" IMO that should halt the build, because it goes on to > use the stripped POM without using the shaded jar; hilarity ensues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-554) POM for joda-time-hibernate 1.0 is invalid
[ http://jira.codehaus.org/browse/MEV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116225 ] Carlos Sanchez commented on MEV-554: you have to contact Stephen Colebourne so they fix it for next releases, he's the one requesting the upload > POM for joda-time-hibernate 1.0 is invalid > -- > > Key: MEV-554 > URL: http://jira.codehaus.org/browse/MEV-554 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies, Invalid POM >Reporter: Sergey Koshcheyev > > The POM for joda-time-hibernate 1.0 release uploaded in MAVENUPLOAD-1753 is > invalid. Can it be fixed in the same way as the one for 0.8 (MEV-302)? Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1841) Upload of jasypt 1.4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1841. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload of jasypt 1.4.1 > -- > > Key: MAVENUPLOAD-1841 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1841 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Fernández >Assignee: Carlos Sanchez > > http://www.jasypt.org/jasypt-1.4.1-bundle.jar > http://www.jasypt.org > http://www.jasypt.org/team.html > Jasypt (Java Simplified Encryption) is a java library which allows the > developer to add basic encryption capabilities to his/her projects with > minimum effort, and without the need of having deep knowledge on how > cryptography works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1834) jdk 1.4 compatible version for pmd 4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1834. --- Assignee: Carlos Sanchez Resolution: Fixed > jdk 1.4 compatible version for pmd 4.1 > -- > > Key: MAVENUPLOAD-1834 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1834 > Project: maven-upload-requests > Issue Type: Task >Reporter: Xavier Le Vourch >Assignee: Carlos Sanchez > > this create a new jdk1.4 based artifact pmd:pmd-jdk14 that may be needed for > core pmd 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] Closed: (MAVENUPLOAD-1839) Upload Unitils 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1839. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Unitils 1.0 > -- > > Key: MAVENUPLOAD-1839 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1839 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tim Ducheyne >Assignee: Carlos Sanchez > > Hi, > a new release of Unitils is available. > Could you please upload the new version in the repository. > Thank you and best regards, > Tim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1838) Upload FreeMarker 2.3.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1838. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload FreeMarker 2.3.10 > > > Key: MAVENUPLOAD-1838 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1838 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato >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: (MAVENUPLOAD-1837) OpenFAST Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116221 ] Jacob Northey commented on MAVENUPLOAD-1837: Since we've updated the web site using Maven site generation, the contributor URL has changed to http://www.openfast.org/team-list.html. > OpenFAST Upload Request > --- > > Key: MAVENUPLOAD-1837 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1837 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jacob Northey > Attachments: org.openfast.sh > > > OpenFAST is a 100% Java implementation of the FAST Protocol (FIX Adapted for > STreaming). The FAST protocol is used to optimize communications in the > electronic exchange of financial data. OpenFAST is flexible and extensible > through high volume - low latency transmissions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-60) Adding directories to manifest classpath entry is not possible
[
http://jira.codehaus.org/browse/MJAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MJAR-60.
Assignee: Olivier Lamy
Resolution: Cannot Reproduce
I have just tested on cygwin an no problem
{noformat}
$ uname
CYGWIN_NT-5.1
{noformat}
I have added an it for this case with the attached project (svn rev 602276).
If you have the issue again reopen and please provide an it test.
Thanks.
> Adding directories to manifest classpath entry is not possible
> --
>
> Key: MJAR-60
> URL: http://jira.codehaus.org/browse/MJAR-60
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXP SP2, cygwin
>Reporter: Bugittaa Pahasti
>Assignee: Olivier Lamy
> Fix For: 2.2
>
> Attachments: MJAR-60.zip
>
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> main.Class
> true
> lib
>
>
> config/
>
>
>
>
> Manifest specification requires directories to include slash at the end, but
> if that is added the build will fail. WIth config
> the build works fine (but resources aren't found as the slash is missing).
> The error is:
> [INFO] Building jar: xxx-1.0-SNAPSHOT.jar
> [DEBUG] adding directory META-INF/
> [DEBUG] adding entry META-INF/MANIFEST.MF
> ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling JAR
> Embedded error: Problem creating jar: c:\main\java\module\target\classes
> (Access is denied)
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR
> 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(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> 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: Error assembling
> JAR
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:162)
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:174)
> 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.codehaus.plexus.archiver.ArchiverException: Problem creating
> jar: c:\main\java\module\target\classes (Access is denied)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:424)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:402)
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:155)
> ... 19 more
> Caused by: java.io.FileNotFoundException: c:\main\java\module\target\classes
> (Access is denied)
> at java.io.RandomAccessFile.open(Native Method)
> at java.io.RandomAccessFile.(Unknown Source)
> at
[jira] Created: (MSHADE-9) failure to shade plexus-archiver (interfaces not properly shaded)
failure to shade plexus-archiver (interfaces not properly shaded)
-
Key: MSHADE-9
URL: http://jira.codehaus.org/browse/MSHADE-9
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Reporter: Dan Fabulich
Priority: Blocker
I tried using the shade plugin with surefire, to shade plexus-archiver. It
took several tries due to MSHADE-5, but even when it finally "worked", it
failed to shade plexus-archiver correctly.
org.codehaus.plexus.archiver.zip.AsiExtraField implements
org.codehaus.plexus.archiver.zip.ZipExtraField. But when I try to run
p-archiver after shading it, I get this exception:
java.lang.ExceptionInInitializerError
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipEntry.getCentralDirectoryExtra(ZipEntry.java:386)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.writeCentralFileHeader(ZipOutputStream.java:769)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.finish(ZipOutputStream.java:320)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipOutputStream.close(ZipOutputStream.java:542)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:378)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
at
org.apache.maven.surefire.booter.ForkConfiguration.createJar(ForkConfiguration.java:264)
[snip]
Caused by: java.lang.RuntimeException: class
org.codehaus.plexus.archiver.zip.AsiExtraField doesn't implement ZipExtraField
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:63)
at
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
... 31 more
My decompiler (DJ) shows that the interfaces were partially but not entirely
shaded correctly:
package org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip;
import java.util.zip.CRC32;
import java.util.zip.ZipException;
import org.codehaus.plexus.archiver.UnixStat;
import org.codehaus.plexus.archiver.zip.ZipExtraField;
import org.codehaus.plexus.archiver.zip.ZipLong;
import org.codehaus.plexus.archiver.zip.ZipShort;
// Referenced classes of package
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip:
//ZipExtraField, ZipShort, ZipLong
public class AsiExtraField
implements
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.zip.ZipExtraField,
org.apache.maven.surefire.shaded.org.codehaus.plexus.archiver.UnixStat,
Cloneable
{
[...]
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSHADE-8) Shade plugin will cheerfully shade your own classes
Shade plugin will cheerfully shade your own classes --- Key: MSHADE-8 URL: http://jira.codehaus.org/browse/MSHADE-8 Project: Maven 2.x Shade Plugin Issue Type: Improvement Reporter: Dan Fabulich My relocation patterns were initially too relaxed, and so they wound up shading my own classes, rather than just the classes I depend on. I could imagine somebody wanting to do this, but I think there should probably be a safety check or something to try to help you not do it by accident; it's probably not what you want. (After all, if you wanted your code to be in a different package, wouldn't you have just written it that way to begin with?) In my case I was working on a Maven plugin; when its classes got shaded, it broke the plugin metadata... definitely not what I wanted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAR-49. Resolution: Fixed fixed in rev 602261. snapshot deployed maven-jar-plugin 2.2-20071207.230654-4. If any trouble reopen the issue. > Jarsigner fails on windows due to spaces in pathnames > - > > Key: MJAR-49 > URL: http://jira.codehaus.org/browse/MJAR-49 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1 > Environment: Windows XP >Reporter: Jon Tayler >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: pathproblem.txt > > > This is a problem uncovered while running the latest (1.0-20060307.100605-1) > version of the webstart plugin, which uses the jar plugin to sign jars. > During the signing stage maven fails with > [debug] jarsigner executable=[C:\Program > Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] > [debug] Signing JAR in-place (overwritting original JAR). > [warn] 'C:\Program' is not recognized as an internal or external command, > [warn] operable program or batch file. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Result of "C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe" > -verbose -keystore "C:\Documents and Settings\jdt\.keystore" -storepass > ** -keypass ** > E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar > roe execution is: '1'. > [INFO] > > (full trace is attached). > It looks as though the plexus utils classes are tokenizing the path to the > jarsigner executable wrongly due to it containing spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHADE-7) Shade should generate code, not replace the jar
Shade should generate code, not replace the jar --- Key: MSHADE-7 URL: http://jira.codehaus.org/browse/MSHADE-7 Project: Maven 2.x Shade Plugin Issue Type: Improvement Reporter: Dan Fabulich I frequently get errors replacing the output jar. (That's MSHADE-5.) It seems to me that it would be better if shade operated during the generate-sources phase, dropping the generated dependencies into a target/generated-sources directory. That way I could write my code directly against the shaded classes (rather than requiring shade do do the extra work of shading me as well). That would have the benefit of not needing to replace the artifact at package time, knocking out MSHADE-5, and making MSHADE-6 irrelevant as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-88) use maven-invoker-plugin instead of maven-embedder for it tests
[ http://jira.codehaus.org/browse/MJAR-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAR-88. Resolution: Fixed fixed in rev 602261. > use maven-invoker-plugin instead of maven-embedder for it tests > --- > > Key: MJAR-88 > URL: http://jira.codehaus.org/browse/MJAR-88 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0, 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-6) Replacement failures should halt the build
Replacement failures should halt the build -- Key: MSHADE-6 URL: http://jira.codehaus.org/browse/MSHADE-6 Project: Maven 2.x Shade Plugin Issue Type: Bug Reporter: Dan Fabulich I frequently get "Could not replace original artifact with shaded artifact!" warnings. (That's MSHADE-5.) Replacement errors should halt the build, because it goes on to use the stripped POM without using the shaded jar; hilarity ensues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHADE-5) 50% of the time I run the shade plugin, it's unable to replace the original jar
50% of the time I run the shade plugin, it's unable to replace the original jar --- Key: MSHADE-5 URL: http://jira.codehaus.org/browse/MSHADE-5 Project: Maven 2.x Shade Plugin Issue Type: Bug Environment: Windows XP SP2, Java 1.5.0_12 Reporter: Dan Fabulich Priority: Blocker I tried to wire up the shade plugin in surefire trunk. About 50% of the time I run the shade plugin I get a "[WARNING] Could not replace original artifact with shaded artifact!" IMO that should halt the build, because it goes on to use the stripped POM without using the shaded jar; hilarity ensues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Resolved: (MSHADE-4) Extraneous directories and unneeded files included after shading
[ http://jira.codehaus.org/browse/MSHADE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved MSHADE-4. -- Assignee: Daniel Kulp (was: Mauro Talevi) Resolution: Fixed > Extraneous directories and unneeded files included after shading > > > Key: MSHADE-4 > URL: http://jira.codehaus.org/browse/MSHADE-4 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Paul Hammant >Assignee: Daniel Kulp > > Refer build of > https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/pom.xml > Makes a jar that containes ... > 0 Fri Oct 05 09:32:28 PDT 2007 META-INF/ >123 Fri Oct 05 09:32:28 PDT 2007 META-INF/MANIFEST.MF > 0 Fri Oct 05 09:32:28 PDT 2007 org/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/containers/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/injectors/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/lifecycle/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/monitors/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/parameters/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/references/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/security/ > 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/visitors/ > 3766 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/adapters/AbstractAdapter.class > 4113 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/adapters/InstanceAdapter.class >391 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Cache.class >408 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Inject.class >387 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/Behavior.class >689 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/BehaviorFactory.class > 4770 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/AbstractBehavior.class > 3737 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/AbstractBehaviorFactory.class > 5132 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/AdaptiveBehavior.class >745 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Automated.class > 1742 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Automatic.class > 1024 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Behaviors.class > 1037 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Cached.class > 2685 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Caching.class > 1344 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/HiddenImplementation$1.class > 4079 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/HiddenImplementation.class > 1862 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/ImplementationHiding.class >457 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Intercepted$Controller.class > 1360 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Intercepted$ControllerImpl.class > 1933 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Intercepted$ControllerWrapper.class >686 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Intercepted$InterceptorThreadLocal.class > 3617 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Intercepted.class > 1507 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/Interception.class > 1143 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locked.class > 1687 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locking.class > 1797 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/OptInCaching.class > 1130 Fri Oct 05 09:32:28 PDT 2007 > org/picocontainer/behaviors/PropertyApplicator$1.class > 10001 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/PropertyApplicator.class > 2436 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/PropertyApplying.class > 3011 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Stored.class >562 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/Storing$StoreThreadLocal.class >814 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/Storing$StoreWrapper.class > 4043 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing.class >842 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/Synchronized.class > 1660 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/Synchronizing.class > 1013 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/behaviors/ThreadCached.class > 1806 Fri Oct 05 09:32:30 PDT 2007 > org/picocontainer/beha
[jira] Commented: (MSHADE-1) Need to fix the license processor to take literal pointers to license/notice files for uber jars.
[ http://jira.codehaus.org/browse/MSHADE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116211 ] Daniel Kulp commented on MSHADE-1: -- I've added to additional transformers to explicitly allow filtering out of resources by name or forcing the inclusion of a specific file with a specific name in the jar. > Need to fix the license processor to take literal pointers to license/notice > files for uber jars. > - > > Key: MSHADE-1 > URL: http://jira.codehaus.org/browse/MSHADE-1 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Reporter: Jason van Zyl >Assignee: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVENUPLOAD-1842) script for synching openhms public repository with ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james ahlborn updated MAVENUPLOAD-1842: --- Attachment: com.healthmarketscience.sh this got missed somehow. > script for synching openhms public repository with ibiblio > -- > > Key: MAVENUPLOAD-1842 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1842 > Project: maven-upload-requests > Issue Type: Task >Reporter: james ahlborn > Attachments: com.healthmarketscience.sh > > > the OpenHMS project, sponsored by Health Market Science, now has a public > maven release repository which we wish to have included in the ibiblio > repository. the relevant script is attached. > the openhms groupId is "com.healthmarketscience". my email address is at > hmsonline.com. both healthmarketscience.com and hmsonline.com are owned by > Health Market Science. note that the opemhms project on sourceforge, of > which i am an admin, is also controlled by Health Market Science. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1842) script for synching openhms public repository with ibiblio
script for synching openhms public repository with ibiblio -- Key: MAVENUPLOAD-1842 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1842 Project: maven-upload-requests Issue Type: Task Reporter: james ahlborn the OpenHMS project, sponsored by Health Market Science, now has a public maven release repository which we wish to have included in the ibiblio repository. the relevant script is attached. the openhms groupId is "com.healthmarketscience". my email address is at hmsonline.com. both healthmarketscience.com and hmsonline.com are owned by Health Market Science. note that the opemhms project on sourceforge, of which i am an admin, is also controlled by Health Market Science. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-53) In pom with packaging "war" the generated jar will be installed in repo instead of the war
[
http://jira.codehaus.org/browse/MJAR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116197
]
Dennis Lundberg commented on MJAR-53:
-
Martin, I'm not sure I understand what it is you want the jar-plugin to do for
you.
The way I see it, the jar-plugin shouldn't handle war files at all. That is the
responsibility of another plugin.
What should the jar-plugin do for projects that have packaging!=jar ?
Should it simply check that the project has packaging==jar before doing
anything?
> In pom with packaging "war" the generated jar will be installed in repo
> instead of the war
> --
>
> Key: MJAR-53
> URL: http://jira.codehaus.org/browse/MJAR-53
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXp
>Reporter: Martin Zeltner
>Priority: Blocker
> Attachments: patch_jar-maven2-allow-override-project-artifact.txt
>
>
> In pom with packaging "war" the generated jar will be installed in repo
> instead of the war! To solve this just do not set the file of project's
> artifact if it is already set and attach the jar artifact to the project's
> artifact. Here's the patch:
> {code}
> Index:
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> ===
> ---
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> (revision 425019)
> +++
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> (working copy)
> @@ -166,7 +166,8 @@
> File jarFile = createArchive();
>
> String classifier = getClassifier();
> -if ( classifier != null )
> +if ( classifier != null
> +|| getProject().getArtifact().getFile() != null )
> {
> projectHelper.attachArtifact( getProject(), "jar", classifier,
> jarFile );
> }
> {code}
> I could also imagine to use a boolean property "allowOverrideProjectArtifact"
> which is true by default (current case).
> Cheers,
> Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-53) In pom with packaging "war" the generated jar will be installed in repo instead of the war
[
http://jira.codehaus.org/browse/MJAR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJAR-53:
Description:
In pom with packaging "war" the generated jar will be installed in repo instead
of the war! To solve this just do not set the file of project's artifact if it
is already set and attach the jar artifact to the project's artifact. Here's
the patch:
{code}
Index:
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
===
---
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
(revision 425019)
+++
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
(working copy)
@@ -166,7 +166,8 @@
File jarFile = createArchive();
String classifier = getClassifier();
-if ( classifier != null )
+if ( classifier != null
+|| getProject().getArtifact().getFile() != null )
{
projectHelper.attachArtifact( getProject(), "jar", classifier,
jarFile );
}
{code}
I could also imagine to use a boolean property "allowOverrideProjectArtifact"
which is true by default (current case).
Cheers,
Martin
was:
In pom with packaging "war" the generated jar will be installed in repo instead
of the war! To solve this just do not set the file of project's artifact if it
is already set and attach the jar artifact to the project's artifact. Here's
the patch:
Index:
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
===
---
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
(revision 425019)
+++
D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
(working copy)
@@ -166,7 +166,8 @@
File jarFile = createArchive();
String classifier = getClassifier();
-if ( classifier != null )
+if ( classifier != null
+|| getProject().getArtifact().getFile() != null )
{
projectHelper.attachArtifact( getProject(), "jar", classifier,
jarFile );
}
I could also imagine to use a boolean property "allowOverrideProjectArtifact"
which is true by default (current case).
Cheers,
Martin
> In pom with packaging "war" the generated jar will be installed in repo
> instead of the war
> --
>
> Key: MJAR-53
> URL: http://jira.codehaus.org/browse/MJAR-53
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXp
>Reporter: Martin Zeltner
>Priority: Blocker
> Attachments: patch_jar-maven2-allow-override-project-artifact.txt
>
>
> In pom with packaging "war" the generated jar will be installed in repo
> instead of the war! To solve this just do not set the file of project's
> artifact if it is already set and attach the jar artifact to the project's
> artifact. Here's the patch:
> {code}
> Index:
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> ===
> ---
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> (revision 425019)
> +++
> D:/Programs/Maven2/maven/plugins/maven-jar-plugin/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java
> (working copy)
> @@ -166,7 +166,8 @@
> File jarFile = createArchive();
>
> String classifier = getClassifier();
> -if ( classifier != null )
> +if ( classifier != null
> +|| getProject().getArtifact().getFile() != null )
> {
> projectHelper.attachArtifact( getProject(), "jar", classifier,
> jarFile );
> }
> {code}
> I could also imagine to use a boolean property "allowOverrideProjectArtifact"
> which is true by default (current case).
> Cheers,
> Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-65) Mismatch with dependency name when using goal test-jar
[ http://jira.codehaus.org/browse/MJAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MJAR-65. --- Resolution: Won't Fix This seems to be due to an error in the configuration. > Mismatch with dependency name when using goal test-jar > -- > > Key: MJAR-65 > URL: http://jira.codehaus.org/browse/MJAR-65 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: maven 2.0.4 and 2.1 of the jar plugin >Reporter: Julian Payne >Priority: Blocker > > I am trying to do what is described on the wiki to deploy the test jar of a > project: > http://maven.apache.org/guides/mini/guide-attached-tests.html > When I do this and I deploy it deploys the following file in the directory > SNAPSHOT (along with the checksums and the metadata): > jviews-chart-20070105.141546-1-tests.jar > I then have a second project that has the following dependency: > > jviews > jviews-chart > test > tests.jar > SNAPSHOT > > However when I run mvn on this project I get the following error: > Downloading: > http://jviewstest.ilog.fr/jviews-m2/jviews/jviews-chart/SNAPSHOT/jviews-chart-20070105.141546-1.tests.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) jviews:jviews-chart:tests.jar:SNAPSHOT > NOTE: it is trying to download the file > "jviews-chart-20070105.141546-1.tests.jar" whereas the file that was deployed > is called "jviews-chart-20070105.141546-1-tests.jar". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-60) Adding directories to manifest classpath entry is not possible
[
http://jira.codehaus.org/browse/MJAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJAR-60:
Attachment: MJAR-60.zip
Here is an example project that uses the configuration mentioned in this issue.
When I run 'mvn package' with Maven 2.0.7 on Windows XP a jar file is produced
that contains the following MANIFEST.MF:
{code}
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: dlg01
Build-Jdk: 1.4.2_16
Main-Class: myproject.HelloWorld
Class-Path: config/
{code}
That seem correct to me. Your problems might be related to cygwin.
> Adding directories to manifest classpath entry is not possible
> --
>
> Key: MJAR-60
> URL: http://jira.codehaus.org/browse/MJAR-60
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXP SP2, cygwin
>Reporter: Bugittaa Pahasti
> Fix For: 2.2
>
> Attachments: MJAR-60.zip
>
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> main.Class
> true
> lib
>
>
> config/
>
>
>
>
> Manifest specification requires directories to include slash at the end, but
> if that is added the build will fail. WIth config
> the build works fine (but resources aren't found as the slash is missing).
> The error is:
> [INFO] Building jar: xxx-1.0-SNAPSHOT.jar
> [DEBUG] adding directory META-INF/
> [DEBUG] adding entry META-INF/MANIFEST.MF
> ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling JAR
> Embedded error: Problem creating jar: c:\main\java\module\target\classes
> (Access is denied)
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR
> 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(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> 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: Error assembling
> JAR
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:162)
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:174)
> 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.codehaus.plexus.archiver.ArchiverException: Problem creating
> jar: c:\main\java\module\target\classes (Access is denied)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:424)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:402)
> at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:155)
> ... 19 more
> Caused by: java.io.FileNotFoundException: c:\main\java\module\target\cl
[jira] Created: (MPMD-67) Using JDK 1.6 causes ParseException: Can't use generics unless running in JDK 1.5 mode!
Using JDK 1.6 causes ParseException: Can't use generics unless running in JDK 1.5 mode! --- Key: MPMD-67 URL: http://jira.codehaus.org/browse/MPMD-67 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.2 Environment: Maven 2.0.8 JDK 1.6 Reporter: Will Hoover While using Maven PMD plugin with: org.apache.maven.plugins maven-pmd-plugin 2.2 true utf-8 100 1.6 **/generated/*.java I get the following error even though JDK is 1.6: [WARNING] Failure executing PMD for: SomeGenericJavaClass.java net.sourceforge.pmd.PMDException: Error while parsing SomeGenericJavaClass.java at net.sourceforge.pmd.PMD.processFile(PMD.java:104) at net.sourceforge.pmd.PMD.processFile(PMD.java:64) at net.sourceforge.pmd.PMD.processFile(PMD.java:150) at org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:228) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 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:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) 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: net.sourceforge.pmd.ast.ParseException: Can't use generics unless running in JDK 1.5 mode! at net.sourceforge.pmd.ast.JavaParser.checkForBadGenericsUsage(JavaParser.java:32) at net.sourceforge.pmd.ast.JavaParser.TypeArguments(JavaParser.java:1962) at net.sourceforge.pmd.ast.JavaParser.ClassOrInterfaceType(JavaParser.java:1911) at net.sourceforge.pmd.ast.JavaParser.ReferenceType(JavaParser.java:1862) at net.sourceforge.pmd.ast.JavaParser.Type(JavaParser.java:1793) at net.sourceforge.pmd.ast.JavaParser.ResultType(JavaParser.java:2182) at net.sourceforge.pmd.ast.JavaParser.MethodDeclaration(JavaParser.java:1382) at net.sourceforge.pmd.ast.JavaParser.ClassOrInterfaceBodyDeclaration(JavaParser.java:1064) at net.sourceforge.pmd.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:983) at net.sourceforge.pmd.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:494) at net.sourceforge.pmd.ast.JavaParser.TypeDeclaration(JavaParser.java:386) at net.sourceforge.pmd.ast.JavaParser.CompilationUnit(JavaParser.java:
[jira] Commented: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[ http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116180 ] Aaron Zeckoski commented on MNG-3314: - It is also critical for people who are in countries with poor or very expensive internet access This is still an issue in maven 2.0.8 azeckoski:test-runner azeckoski$ mvn -v Maven version: 2.0.8 Java version: 1.5.0_13 OS name: "mac os x" version: "10.5.1" arch: "i386" Family: "unix" azeckoski:test-runner azeckoski$ mvn -o clean install [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Sakai TestRunner [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.sakaiproject.maven.plugins ArtifactId: sakai Version: SNAPSHOT Reason: System is offline. org.sakaiproject.maven.plugins:sakai:pom:SNAPSHOT NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Fri Dec 07 09:28:15 PST 2007 [INFO] Final Memory: 2M/254M [INFO] > offline build not running, when having SNAPSHOT dependencies > > > Key: MNG-3314 > URL: http://jira.codehaus.org/browse/MNG-3314 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.7 >Reporter: Matthias Weßendorf >Priority: Critical > > am having troubles with > mvn ... -o > (with maven 2.0.7) > says not able to download (but, really, the file is in my local repo) > The dependency is a -SNAPSHOT (for what's worth) > Luckily, when traveling by train, I had maven 2.0.4 on my box as well. > A change to use 2.0.4 works fine. > So, is this an already know bug in 2.0.7 ? > To my understanding it is a bug, since offline just shouldn't try to get a > newer > SNAPSHOT, perhaps I am wrong. > I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect > just not checking for new stuff. > and... for some reasons, sometimes, > it just downloads a new SNAPSHOT. > That is a pain, when you are "maintaining" the same snapshot on your > box, but the build just goes ahead and actually downloads a 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] Created: (CONTINUUM-1593) Requires Javamail 1.5? Should be 1.4?
Requires Javamail 1.5? Should be 1.4? - Key: CONTINUUM-1593 URL: http://jira.codehaus.org/browse/CONTINUUM-1593 Project: Continuum Issue Type: Bug Components: Documentation Affects Versions: 1.1 Reporter: creyle In this doc, http://maven.apache.org/continuum/documentation/1_1/installation/tomcat.html#The_Javamail__Activation_JAR_files the war deployment guide for Tomcat requires Javamail version 1.5 (or later), isn't the version number a typo? Currently I can only find JavaMail 1.4.1 at Sun's official JavaMail site http://java.sun.com/products/javamail/, meanwhile, in that doc just a few lines below, the link to JavaMail 1.4 is provided. BTW, on Sun's site, the spell is "JavaMail" not "Javamail", better to follow? Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (CONTINUUM-1573) not able to download files from working directory in any format other than html
[ http://jira.codehaus.org/browse/CONTINUUM-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Roberts updated CONTINUUM-1573: Attachment: screenshot-1.jpg What's happening is that I click on the StructuredDocGuide.pdf to download it and instead of being prompted to save/open the file, it displays the pdf as text in the iframe below. I have tried to access it using IE 6 and Firefox 2.0.0.11. I am using Continuum 1.1 Final > not able to download files from working directory in any format other than > html > --- > > Key: CONTINUUM-1573 > URL: http://jira.codehaus.org/browse/CONTINUUM-1573 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-4 > Environment: window >Reporter: pallavi satish > Attachments: screenshot-1.jpg > > > after building a project if it is creating any tar/war/jar file it can not be > downloaded from working copy in any formats other than html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1573) not able to download files from working directory in any format other than html
[ http://jira.codehaus.org/browse/CONTINUUM-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116174 ] esroberts edited comment on CONTINUUM-1573 at 12/7/07 10:11 AM: --- What's happening is that I click on the StructuredDocGuide.pdf to download it and instead of being prompted to save/open the file, it displays the pdf as text in the iframe below (see screenshot-1.jpg attached) I have tried to access it using IE 6 and Firefox 2.0.0.11. I am using Continuum 1.1 Final was (Author: esroberts): What's happening is that I click on the StructuredDocGuide.pdf to download it and instead of being prompted to save/open the file, it displays the pdf as text in the iframe below. I have tried to access it using IE 6 and Firefox 2.0.0.11. I am using Continuum 1.1 Final > not able to download files from working directory in any format other than > html > --- > > Key: CONTINUUM-1573 > URL: http://jira.codehaus.org/browse/CONTINUUM-1573 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-4 > Environment: window >Reporter: pallavi satish > Attachments: screenshot-1.jpg > > > after building a project if it is creating any tar/war/jar file it can not be > downloaded from working copy in any formats other than html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-88) use maven-invoker-plugin instead of maven-embedder for it tests
use maven-invoker-plugin instead of maven-embedder for it tests --- Key: MJAR-88 URL: http://jira.codehaus.org/browse/MJAR-88 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1, 2.0 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 2.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-277) site:deploy possibility to choose directory tree when using sub-modules
site:deploy possibility to choose directory tree when using sub-modules --- Key: MSITE-277 URL: http://jira.codehaus.org/browse/MSITE-277 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: site:deploy Affects Versions: 2.0-beta-6 Reporter: Guimiot Isabelle Priority: Minor I use Eclipse and my modules (root and submodules) are all at the same level in the directory tree : [eclipse_workspace]/root [eclipse_workspace]/sub1 [eclipse_workspace]/sub2 Until the 2.0-beta-5 of the maven site plugin, when I deployed my site, I obtained this tree : [publish]/root [publish]/root/sub1 [publish]/root/sub2 I installed the beta-6 version, and the default behaviour has changed, I now have every module at the same level : [publish]/root [publish]/sub1 [publish]/sub2 So I just wondered if it was possible to have an option to choose whether we prefer to publish the submodules inside the root directory, or at the same level... ? thx Isabelle -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-247) versions of included dependencies in multi-module projects are not deterministic
[ http://jira.codehaus.org/browse/MASSEMBLY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116152 ] Tarek El-Sibay commented on MASSEMBLY-247: -- hello! no comments, no hints, no solving. Nobody interested in the bug? did i made something wrong with this bug report? What can i do? Tarek > versions of included dependencies in multi-module projects are not > deterministic > > > Key: MASSEMBLY-247 > URL: http://jira.codehaus.org/browse/MASSEMBLY-247 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2-beta-1, 2.2-beta-2 > Environment: Maven 2.0.4 an assembly plugin 2.2-SNAPSHOT >Reporter: Tarek El-Sibay > Attachments: assembly-dependency-problem.zip > > > There is a problem with including dependency jars in an assembly. The > resoultion of the version of the dependencies is not deterministic. The > attached zipfile contains three projects, assembly, module-One and modue-Two. > the assembly project is the aggregator of module-One and module-Two. > module-One has a dep to junit 3.8.1, module-Two to junit 4.0. The assembly > project contains a DependencyManagement with a dependency to junit 4.0. > After executing 'mvn clean package ' in the assembly project the resulting > zip file assembly-1.0-SNAPSHOT-luna.zip contains junit 3.8.1, after 'mvn > clean install' it contains junit 4.0. > Sometimes its the other way around, but playing with both commands shows that > the resulting version of junit is not deterministic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116146 ] Olivier Lamy commented on MJAR-49: -- if we upgrade to p-u 1.4.8 we had to add a prerequisites to 2.0.6. I have started to work on that but this upgrade causes some failures on the it tests. Some tests use MavenEmbedder which causes some failures here. This means some its tests need to be rewritte with using maven-invoker-plugin. > Jarsigner fails on windows due to spaces in pathnames > - > > Key: MJAR-49 > URL: http://jira.codehaus.org/browse/MJAR-49 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1 > Environment: Windows XP >Reporter: Jon Tayler >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: pathproblem.txt > > > This is a problem uncovered while running the latest (1.0-20060307.100605-1) > version of the webstart plugin, which uses the jar plugin to sign jars. > During the signing stage maven fails with > [debug] jarsigner executable=[C:\Program > Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] > [debug] Signing JAR in-place (overwritting original JAR). > [warn] 'C:\Program' is not recognized as an internal or external command, > [warn] operable program or batch file. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Result of "C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe" > -verbose -keystore "C:\Documents and Settings\jdt\.keystore" -storepass > ** -keypass ** > E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar > roe execution is: '1'. > [INFO] > > (full trace is attached). > It looks as though the plexus utils classes are tokenizing the path to the > jarsigner executable wrongly due to it containing spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-49) Jarsigner fails on windows due to spaces in pathnames
[ http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116144 ] Jerome Lacoste commented on MJAR-49: Olivier, according to my users, upgrading to 1.4.8 fixed their problems. > Jarsigner fails on windows due to spaces in pathnames > - > > Key: MJAR-49 > URL: http://jira.codehaus.org/browse/MJAR-49 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1 > Environment: Windows XP >Reporter: Jon Tayler >Assignee: Olivier Lamy > Fix For: 2.2 > > Attachments: pathproblem.txt > > > This is a problem uncovered while running the latest (1.0-20060307.100605-1) > version of the webstart plugin, which uses the jar plugin to sign jars. > During the signing stage maven fails with > [debug] jarsigner executable=[C:\Program > Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe] > [debug] Signing JAR in-place (overwritting original JAR). > [warn] 'C:\Program' is not recognized as an internal or external command, > [warn] operable program or batch file. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Result of "C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe" > -verbose -keystore "C:\Documents and Settings\jdt\.keystore" -storepass > ** -keypass ** > E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar > roe execution is: '1'. > [INFO] > > (full trace is attached). > It looks as though the plexus utils classes are tokenizing the path to the > jarsigner executable wrongly due to it containing spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116142 ] KlaasJan Elzinga commented on MNG-3118: --- Henri, Thanks, I was wondering if it were just the classes or the classes and the resources. So its both, I'll just revert to 2.0.7 and wait for the surefire. > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116129 ] Henri Tremblay commented on MNG-3118: - KlassJan, read the other comments. It seems the problem is coming from Surefire. So you can wait for the fix to be released or build the plugin yourself (if you do so, I would be interested in knowing if it worked) > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MWAR-134) ClasscastException when turning filtering on the web resources
[ http://jira.codehaus.org/browse/MWAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116128 ] Ludovic Claude commented on MWAR-134: - Update: I had this filtering issue because some developer put png images in the src/main/webapp folder. Once they are removed, then the filtering kind of works, if it were not for the issue mentioned above. Ludovic. > ClasscastException when turning filtering on the web resources > -- > > Key: MWAR-134 > URL: http://jira.codehaus.org/browse/MWAR-134 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Maven 2.0.8, Win XP >Reporter: Ludovic Claude > > Hello, > I have configured the maven-war-plugin to filter my files in src/main/webapp, > in particular web.xml. > > org.apache.maven.plugins > maven-war-plugin > > > > false > > > > > true > > src/main/webapp > > > **/* > > > > > > But when I run Maven, I get the following error: > [INFO] Copy webapp webResources to [...]\client-framework-webapp-0.2-SNAPSHOT > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.project.MavenProject > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.project.MavenProject > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) > at java.io.Reader.read(Reader.java:100) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > 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:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > Any idea? > Thanks, > Ludov
[jira] Issue Comment Edited: (MSITE-270) site.xml: menus inherited that should not
[ http://jira.codehaus.org/browse/MSITE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116127 ] iguimiot edited comment on MSITE-270 at 12/7/07 4:49 AM: - I have a problem that seems to be linked to this one (beta-6) : I have a root module and some sub-modules. The root site.xml contains : and each sub-module site.xml contains : When I launch the site goal, I obtain this menu : - in the root site (correct) : Modules Project 1 Project 2 Menu Root Doc - in the sub-modules site (completely wrong) : Menu Root Doc ...instead of stuff like that : Parent Parent Project Reports Report 1 Report 2 Report 3 ... Menu Foo If I understand, it seems that the submodule site.xml is totally ignored, and replaced by an inherited site.xml from the root module. I also tried to put some "inherit" attributes everywhere in both files (root and submodule) but it didn't change anything... This issue is very important, I have to keep my beta-5 version until it's resolved. thanx Isabelle was (Author: iguimiot): I have a problem that seems to be linked to this one (beta-6) : I have a root module and some sub-modules. The root site.xml contains : and each sub-module site.xml contains : When I launch the site goal, I obtain this menu : - in the root site (correct) : Modules Project 1 Project 2 Menu Root Doc - in the sub-modules site (completely wrong) : Menu Root Doc ...instead of stuff like that : Parent Parent Project Reports Report 1 Report 2 Report 3 ... Menu Foo If I understand, it seems that the submodule site.xml is totally ignored, and replaced by an inherited site.xml from the root module. I also tried to put some "inherit" attributes everywhere in both files (root and submodule) but it didn't change anything... This issue is very important, I have to keep my beta-5 version until it's resolved. thanx Isabelle > site.xml: menus inherited that should not > - > > Key: MSITE-270 > URL: http://jira.codehaus.org/browse/MSITE-270 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Jörg Hohwiller > Attachments: site-inherit-bug.zip > > > I have a project with multiple levels of modules. > In the toplevel project I declare a site-descriptor with some general menu's > that have no inherit attribute (I also tried inherit='none') together with > > > > Now a module of the toplevel project that itself has modules declares a > site-descriptor with an additional regular menu that is inherited. > However the site of that module contains the menus from the toplevel project > that are NOT declared to be inherited. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116126 ] KlaasJan Elzinga commented on MNG-3118: --- I am seeing the following: in mvn 2.0.7 the test resources are put before the main-resources (src/main/resources) as expected. in mvn 2.0.8 the main resources are put before the test-resources (src/test/resources). Is this correct? I wouldnt expect it to happen. This caused my build to fail (connections made to a real environment ie stubs). Is this related to this 'feature'? > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: 2.0.8, 2.1-alpha-1 > > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-270) site.xml: menus inherited that should not
[ http://jira.codehaus.org/browse/MSITE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116127 ] Guimiot Isabelle commented on MSITE-270: I have a problem that seems to be linked to this one (beta-6) : I have a root module and some sub-modules. The root site.xml contains : and each sub-module site.xml contains : When I launch the site goal, I obtain this menu : - in the root site (correct) : Modules Project 1 Project 2 Menu Root Doc - in the sub-modules site (completely wrong) : Menu Root Doc ...instead of stuff like that : Parent Parent Project Reports Report 1 Report 2 Report 3 ... Menu Foo If I understand, it seems that the submodule site.xml is totally ignored, and replaced by an inherited site.xml from the root module. I also tried to put some "inherit" attributes everywhere in both files (root and submodule) but it didn't change anything... This issue is very important, I have to keep my beta-5 version until it's resolved. thanx Isabelle > site.xml: menus inherited that should not > - > > Key: MSITE-270 > URL: http://jira.codehaus.org/browse/MSITE-270 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Jörg Hohwiller > Attachments: site-inherit-bug.zip > > > I have a project with multiple levels of modules. > In the toplevel project I declare a site-descriptor with some general menu's > that have no inherit attribute (I also tried inherit='none') together with > > > > Now a module of the toplevel project that itself has modules declares a > site-descriptor with an additional regular menu that is inherited. > However the site of that module contains the menus from the toplevel project > that are NOT declared to be inherited. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MWAR-134) ClasscastException when turning filtering on the web resources
[
http://jira.codehaus.org/browse/MWAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116123
]
Ludovic Claude commented on MWAR-134:
-
Hello Olivier,
I'm using version 2.0.2 of the war plugin. If I upgrade to 2.1-alpha-1, then
the build doesn't fail any more, but it still doesn't do what I want:
I have the following line in my web.xml file:
Myapp version ${app.version} - Login module
In a paren POM, app.version is set to 7, while the current project version is
0.2-snapshot. Now the filter replaces ${app.version} with the value of
${version} or ${project.version}...
Myapp version 0.2-SNAPSHOT - Login module
So it looks like I'm hitting now the MWAR-133 issue...
Thanks for your help,
Ludovic
> ClasscastException when turning filtering on the web resources
> --
>
> Key: MWAR-134
> URL: http://jira.codehaus.org/browse/MWAR-134
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Maven 2.0.8, Win XP
>Reporter: Ludovic Claude
>
> Hello,
> I have configured the maven-war-plugin to filter my files in src/main/webapp,
> in particular web.xml.
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
>
> false
>
>
>
>
> true
>
> src/main/webapp
>
>
> **/*
>
>
>
>
>
> But when I run Maven, I get the following error:
> [INFO] Copy webapp webResources to [...]\client-framework-webapp-0.2-SNAPSHOT
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] org.apache.maven.project.MavenProject
> [INFO]
>
> [INFO] Trace
> java.lang.ClassCastException: org.apache.maven.project.MavenProject
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
> at java.io.Reader.read(Reader.java:100)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> 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:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(La
[jira] Commented: (MEV-554) POM for joda-time-hibernate 1.0 is invalid
[ http://jira.codehaus.org/browse/MEV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116118 ] Daniel Mutch commented on MEV-554: -- It seems the maven compiler complains but the assembly plugin just falls over. This is a real problem for Netbeans users as their run / debug mechanism for maven plugin is based on the assembly plugin > POM for joda-time-hibernate 1.0 is invalid > -- > > Key: MEV-554 > URL: http://jira.codehaus.org/browse/MEV-554 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies, Invalid POM >Reporter: Sergey Koshcheyev > > The POM for joda-time-hibernate 1.0 release uploaded in MAVENUPLOAD-1753 is > invalid. Can it be fixed in the same way as the one for 0.8 (MEV-302)? Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SCM-359) scm:update goals link not working (update) on Overview -> Introduction
scm:update goals link not working (update) on Overview -> Introduction -- Key: SCM-359 URL: http://jira.codehaus.org/browse/SCM-359 Project: Maven SCM Issue Type: Improvement Components: documentation Reporter: Ville Hartikainen Priority: Minor http://maven.apache.org/scm/plugins/index.html Apparently should be: http://maven.apache.org/scm/plugins/update-mojo instead of current: http://maven.apache.org/scm/plugins/index.html#update-mojo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-347) regression: plexus is not properly isolated
[ http://jira.codehaus.org/browse/SUREFIRE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated SUREFIRE-347: -- Fix Version/s: (was: 2.3.2) 2.3.1 > 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 >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] Created: (MECLIPSE-361) eclipse plugin and WTP generating warnings in Europa
eclipse plugin and WTP generating warnings in Europa - Key: MECLIPSE-361 URL: http://jira.codehaus.org/browse/MECLIPSE-361 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5 Environment: Eclipse 3.3.1.1 and WTP 2.0.1 Using Maven 2.0.7 and the last maven-eclipse-plugin 2.5-SNAPSHOT Reporter: Yann Priority: Minor Attachments: wtpTest.zip The issue is regarding warnings in Europa and WTP: "Classpath entry M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar will not be exported or published. Runtime ClassNotFoundExceptions may result." 1) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.5-SNAPSHOT => I get the same behaviour in EUROPA (WARNINGS) 2) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.4 => I get the same behaviour in EUROPA (WARNINGS) 3) I then try using Eclipse 3.2.2 with WTP 1.5.3 (instead of Eclipse 3.3.1.1 and WTP 2.0.1) with maven-eclipse-plugin version 2.4 or 2.5-SNAPSHOT => Everything is perfect, no more warnings I create a simple test in order to reproduce the issue. This test is a multi module application composed of 1 Ejb module and 1 Ear module. So at the top level Just run "mvn install eclipse:eclipse" And then in an europa workspace import the projetcs and you should see the warnings on the EJB module. It will behave the same way if it exists other modules. I notice that, in the case you update parameters on the eclipse plugin you will need to remove projects from workspace and import them again. otherwise some old parameter will stay in the eclipse cache... let me know if you need other tests Yann. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
