[jira] Updated: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=all ]
Baerrach bonDierne updated MASSEMBLY-67:
Attachment: MJAR-28-TestCases-Patch.txt
MJAR-28-Notes.txt
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-48) regression: report generation doesn't work while dealing with the header file
regression: report generation doesn't work while dealing with the header file - Key: MCHECKSTYLE-48 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-48 Project: Maven 2.x Checkstyle Plugin Type: Bug Environment: Checkstyle 2.2-SNAPSHOT rev 419829. Reporter: Jerome Lacoste Priority: Blocker Attachments: mvn.log Configured as is: org.apache.maven.plugins maven-checkstyle-plugin config/maven_checks.xml Checkstyle stopped working. I made a fresh svn update and mvn checkstyle:checkstyle fails with: [...] Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot initialize module TreeWalker - Cannot set property 'headerFile' in module RegexpHeader to '/home/jerome/Dev/OSS/perso/jar-info/target/checkstyle-header.txt': line 24 in header specification is not a regular expression at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:165) at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:209) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:729) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:490) [...] Caused by: org.apache.commons.beanutils.ConversionException: line 24 in header specification is not a regular expression at com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.initHeaderRegexps(RegexpHeaderCheck.java:116) at com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.setHeaderFile(RegexpHeaderCheck.java:85) ... 34 more Full log attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEJB-13) Add support for configuring exclusion filter for main ejb jar
[ http://jira.codehaus.org/browse/MEJB-13?page=comments#action_69168 ] Trygve Laugstol commented on MEJB-13: - I suggested that the ejb plugin had a section that it could apply to the ejb client jar. The ejb jar itself has to behave in the exact same way as the normal jar plugin. This will give you what you are asking for without breaking the normal Maven way of packaging an artifact. The bug here is that the ejb plugin applies the includes and excludes in addition to the one specified in the pom. > Add support for configuring exclusion filter for main ejb jar > - > > Key: MEJB-13 > URL: http://jira.codehaus.org/browse/MEJB-13 > Project: Maven 2.x Ejb Plugin > Type: New Feature > Versions: 2.1, 2.0 > Environment: Maven 2.0.4, maven-ejb-plugin 2.1-SNAPSHOT, JBoss 4.0.3sp1 > Reporter: Fredrik Vraalsen > Attachments: MEJB-configure-excludes.patch, > maven-ejb-plugin-configure-main-jar-excludes-2.patch, > maven-ejb-plugin-configure-main-jar-excludes.patch > > > In my ejb project I have certain files that must only be included in the > ejb-client jar and not the main ejb jar (jboss-client.xml, > application-client.xml and jndi.properties). When these files are present in > the main ejb jar, JBoss refuses to deploy my ejbs. > Thus, I need a way to configure the exclusion filter for the main ejb jar. > This is currently hardcoded in EjbMojo.java. I am attaching a patch to make > this configurable in the same way as clientExcludes. > Below is an example of the kind of configuration I am using: > > org.apache.maven.plugins > maven-ejb-plugin > 2.1-SNAPSHOT > > > > jndi.properties > > META-INF/*-client.xml > > **/interfaces/ > > **/assetrepository/Asset.class > > true > > > META-INF/ejb-jar.xml > > META-INF/jboss.xml > > **/dao/ > > **/entity/ > > **/jaxb/ > > **/session/ > > **/xmldb/ > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2424) Classpath in reactor builds differ from dependency resolution
Classpath in reactor builds differ from dependency resolution - Key: MNG-2424 URL: http://jira.codehaus.org/browse/MNG-2424 Project: Maven 2 Type: Bug Components: Reactor and workspace Versions: 2.0.4 Reporter: Joerg Schaible Priority: Blocker The classpath used to compile and test a module is wrong, if the module uses a released version of another module in the reactor build. If the module is build locally, the correct depednencies are on the classpath. This currently breaks our complete development and results makes e.g. EJBs useless (MEJB-18). -- 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-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=comments#action_69169 ] Marvin King commented on MWAR-48: - i missed the index.apt and modify the mvn: to war:. I'll remove that note about the overlay war files overwrriting the existing war files. =) the recent fix makes this obsolete. revising for draft4-1 > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > Fix For: 2.0.2 > Attachments: MWAR-48-maven-war-plugin[draft3].patch, > MWAR-48-maven-war-plugin[draft4].patch > > Time Spent: 1 day, 13 hours, 10 minutes >Remaining: 0 minutes > -- 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: (MWAR-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=all ] Marvin King updated MWAR-48: Attachment: MWAR-48-maven-war-plugin[draft4-1].patch > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > Fix For: 2.0.2 > Attachments: MWAR-48-maven-war-plugin[draft3].patch, > MWAR-48-maven-war-plugin[draft4-1].patch, > MWAR-48-maven-war-plugin[draft4].patch > > Time Spent: 1 day, 13 hours, 30 minutes >Remaining: 0 minutes > -- 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-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=comments#action_69173 ] Marvin King commented on MWAR-48: - for review draft4-1 > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > Fix For: 2.0.2 > Attachments: MWAR-48-maven-war-plugin[draft3].patch, > MWAR-48-maven-war-plugin[draft4-1].patch, > MWAR-48-maven-war-plugin[draft4].patch > > Time Spent: 1 day, 13 hours, 30 minutes >Remaining: 0 minutes > -- 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: (MWAR-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=all ] Marvin King updated MWAR-48: Attachment: (was: MWAR-48-maven-war-plugin[draft3].patch) > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > Fix For: 2.0.2 > Attachments: MWAR-48-maven-war-plugin[draft4-1].patch, > MWAR-48-maven-war-plugin[draft4].patch > > Time Spent: 1 day, 13 hours, 30 minutes >Remaining: 0 minutes > -- 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: (MNG-2424) Classpath in reactor builds differ from dependency resolution
[ http://jira.codehaus.org/browse/MNG-2424?page=all ] Joerg Schaible updated MNG-2424: Attachment: MNG-2424.zip > Classpath in reactor builds differ from dependency resolution > - > > Key: MNG-2424 > URL: http://jira.codehaus.org/browse/MNG-2424 > Project: Maven 2 > Type: Bug > Components: Reactor and workspace > Versions: 2.0.4 > Reporter: Joerg Schaible > Priority: Blocker > Attachments: MNG-2424.zip > > > The classpath used to compile and test a module is wrong, if the module uses > a released version of another module in the reactor build. If the module is > build locally, the correct depednencies are on the classpath. This currently > breaks our complete development and results makes e.g. EJBs useless (MEJB-18). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2425) Mojo parameters with no "expression" does not get added to the parameter list
Mojo parameters with no "expression" does not get added to the parameter list - Key: MNG-2425 URL: http://jira.codehaus.org/browse/MNG-2425 Project: Maven 2 Type: Bug Components: Documentation: General Reporter: Edwin Punzalan was caused by my the patch in MPLUGIN-7 -- 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: (MNG-2425) Mojo parameters with no "expression" does not get added to the parameter list
[ http://jira.codehaus.org/browse/MNG-2425?page=all ] Edwin Punzalan updated MNG-2425: Assign To: Edwin Punzalan Attachment: MNG-2425-maven-plugin-tools-api.patch Attached patch to fix this > Mojo parameters with no "expression" does not get added to the parameter list > - > > Key: MNG-2425 > URL: http://jira.codehaus.org/browse/MNG-2425 > Project: Maven 2 > Type: Bug > Components: Documentation: General > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Attachments: MNG-2425-maven-plugin-tools-api.patch > > > was caused by my the patch in MPLUGIN-7 -- 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: (MCLEAN-14) review the clean plugin documentation
[ http://jira.codehaus.org/browse/MCLEAN-14?page=comments#action_69193 ] Edwin Punzalan commented on MCLEAN-14: -- Fixes committed... please review. > review the clean plugin documentation > - > > Key: MCLEAN-14 > URL: http://jira.codehaus.org/browse/MCLEAN-14 > Project: Maven 2.x Clean Plugin > Type: Improvement > Reporter: Brett Porter > Assignee: Edwin Punzalan > Fix For: 2.1.1 > > Original Estimate: 4 hours >Time Spent: 4 hours > Remaining: 0 minutes > > please make the following changes to docs: > - add an index page (see javadoc for an example) > - rename examples.html to examples/includesExcludes or similar and put in a > submenu as the one example is of that. -- 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: (MDEPLOY-35) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MDEPLOY-35?page=comments#action_69203 ] Allan Ramirez commented on MDEPLOY-35: -- applied.. for review again.. thanks > Review Plugin Documentation > --- > > Key: MDEPLOY-35 > URL: http://jira.codehaus.org/browse/MDEPLOY-35 > Project: Maven 2.x Deploy Plugin > Type: Task > Versions: 2.2 > Reporter: Allan Ramirez > Assignee: Allan Ramirez > Fix For: 2.3 > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-759) Generate plexus-request.xml with plexus-cdc
[ http://jira.codehaus.org/browse/CONTINUUM-759?page=comments#action_69206 ] Trygve Laugstol commented on CONTINUUM-759: --- I will have to think about this. How will the CDC/Plexus Maven Plugin know to tell the difference between a application, session and request component? Isn't that just how it's looked up? Also, what's the difference between plexus-application.xml and a normal components.xml? > Generate plexus-request.xml with plexus-cdc > --- > > Key: CONTINUUM-759 > URL: http://jira.codehaus.org/browse/CONTINUUM-759 > Project: Continuum > Type: Task > Components: Web interface > Versions: 1.1 > Reporter: Emmanuel Venisse > Priority: Trivial > Fix For: 1.1 > > -- 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: (MWAR-60) Source Excludes are being applied to WAR file
Source Excludes are being applied to WAR file - Key: MWAR-60 URL: http://jira.codehaus.org/browse/MWAR-60 Project: Maven 2.x War Plugin Type: Bug Versions: 2.0.1 Environment: WinXP, jdk1.5.0_07, mvn 2.0.4 Reporter: Chuck Deal My scenario: I use Eclipse 3.1.1 to develop the web app. I run Tomcat 5.5.17 with it's docbase pointed at the source tree (/src/main/webapp). As a result, I have files that are required by Tomcat to run, but not to be included in the WAR. Specifically, I have a WEB-INF folder with a classes directory that includes classes that will actually be included in the WAR as a JAR (as well as a few other things). As you can see in the following plugin snippet, I specifically exclude the WEB-INF folder from the source tree because all of its contents will be gathered by the various stages of the build process (process-resources, etc) and included in the WAR when it is "exploded" I had been using the following plugin snippet for generating my War (war plugin 2.0) org.apache.maven.plugins maven-war-plugin 2.0 target/jspweb.xml aims **/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.* If you change the version from 2.0 to 2.0.1, you will no longer generate the same WAR file! Instead, v2.0.1 uses the source excludes and applies them to the WAR construction as well. This means that the exploded WEB-INF (the correct one) is also removed from the WAR file. I don't think that the source excludes should be applied to the WAR construction, only to the stage where the source files are "exploded" (as in v2.0) -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=all ] Mike Perham closed MPMD-36: --- Resolution: Won't Fix This is as designed. Please configure the war plugin to build your war project through the normal lifecycle and PMD will work also. > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Assignee: Mike Perham > Attachments: modulePOM.xml, parentPOM.xml, pmd-plugin_MPMD36.patch > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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-50) "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab char in pom Description
"Invalid Header" in jar's Manifest (Specification-Title attribute) when tab
char in pom Description
---
Key: MJAR-50
URL: http://jira.codehaus.org/browse/MJAR-50
Project: Maven 2.x Jar Plugin
Type: Bug
Versions: 2.0
Reporter: Mike Laurie
Priority: Trivial
I typed a element into my pom; the description spanned 2 lines,
and my text editor put a tab char at the beginning of the 2nd line.
The project built correctly, but another project depended on the resulting jar.
The compilation of the depending project failed with "invalid header" on the
jar I'd just compiled.
When I looked at the jar's manifest, I saw the Specification-Title attribute
had the tab character still in it from the element.
Replacing the tab with spaces in the pom solved the problem.
However, this was valid xml that caused a compilation problem, so I think it's
a minor bug with the jar production code.
Note that the full description is trimmed before going into the manifest, so
any
Easy to work around, but it would be nice if whitespace in the
element were consolidated into spaces before copying to the manifest.
Doesn't need any fancy layout stuff - just any multiple instances of tabs,
spaces, lf or cr should be replaced by a single space.
Try (I haven't tried to compile this!):
{code}
public String consolidateWhitespace(String input){
StringTokenizer st = new StringTokenizer(input);
StringBuffer rv = new StringBuffer();
while (st.hasMoreTokens()){
rv.append(st.nextToken() + (st.hasMoreTokens()?" ":""));
}
return rv.toString();
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-50) "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab char in pom Description
[ http://jira.codehaus.org/browse/MJAR-50?page=comments#action_69239 ]
Mike Laurie commented on MJAR-50:
-
Sorry - in the middle of that description, I meant to say:
"Note that the full description is trimmed before going into the manifest (I
think), so any leading or trailing tabs don't seem recreate the problem."
> "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab
> char in pom Description
> ---
>
> Key: MJAR-50
> URL: http://jira.codehaus.org/browse/MJAR-50
> Project: Maven 2.x Jar Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Mike Laurie
> Priority: Trivial
>
>
> I typed a element into my pom; the description spanned 2 lines,
> and my text editor put a tab char at the beginning of the 2nd line.
> The project built correctly, but another project depended on the resulting
> jar.
> The compilation of the depending project failed with "invalid header" on the
> jar I'd just compiled.
> When I looked at the jar's manifest, I saw the Specification-Title attribute
> had the tab character still in it from the element.
> Replacing the tab with spaces in the pom solved the problem.
> However, this was valid xml that caused a compilation problem, so I think
> it's a minor bug with the jar production code.
> Note that the full description is trimmed before going into the manifest, so
> any
> Easy to work around, but it would be nice if whitespace in the
> element were consolidated into spaces before copying to the manifest.
> Doesn't need any fancy layout stuff - just any multiple instances of tabs,
> spaces, lf or cr should be replaced by a single space.
> Try (I haven't tried to compile this!):
> {code}
> public String consolidateWhitespace(String input){
> StringTokenizer st = new StringTokenizer(input);
> StringBuffer rv = new StringBuffer();
> while (st.hasMoreTokens()){
> rv.append(st.nextToken() + (st.hasMoreTokens()?" ":""));
> }
> return rv.toString();
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-50) "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab char in pom Description
[ http://jira.codehaus.org/browse/MJAR-50?page=comments#action_69241 ]
Wendy Smoak commented on MJAR-50:
-
Possible duplicate of MJAR-4 and MJAR-34
> "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab
> char in pom Description
> ---
>
> Key: MJAR-50
> URL: http://jira.codehaus.org/browse/MJAR-50
> Project: Maven 2.x Jar Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Mike Laurie
> Priority: Trivial
>
>
> I typed a element into my pom; the description spanned 2 lines,
> and my text editor put a tab char at the beginning of the 2nd line.
> The project built correctly, but another project depended on the resulting
> jar.
> The compilation of the depending project failed with "invalid header" on the
> jar I'd just compiled.
> When I looked at the jar's manifest, I saw the Specification-Title attribute
> had the tab character still in it from the element.
> Replacing the tab with spaces in the pom solved the problem.
> However, this was valid xml that caused a compilation problem, so I think
> it's a minor bug with the jar production code.
> Note that the full description is trimmed before going into the manifest, so
> any
> Easy to work around, but it would be nice if whitespace in the
> element were consolidated into spaces before copying to the manifest.
> Doesn't need any fancy layout stuff - just any multiple instances of tabs,
> spaces, lf or cr should be replaced by a single space.
> Try (I haven't tried to compile this!):
> {code}
> public String consolidateWhitespace(String input){
> StringTokenizer st = new StringTokenizer(input);
> StringBuffer rv = new StringBuffer();
> while (st.hasMoreTokens()){
> rv.append(st.nextToken() + (st.hasMoreTokens()?" ":""));
> }
> return rv.toString();
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
Artifact copied to local repository with wrong file extension when using jboss-packaging plugin --- Key: MNG-2426 URL: http://jira.codehaus.org/browse/MNG-2426 Project: Maven 2 Type: Bug Components: Artifacts and Repositories, Artifacts Versions: 2.0.4 Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) Reporter: Fredrik Vraalsen When using the jboss-packaging plugin and setting to jboss-sar in my pom, the artifact is copied into the local repository with the wrong file extension (.jboss-sar instead of .sar). The jboss-packaging components.xml has set to sar. The file in the build target directory has the correct .sar extension. Here's the relevant excerpt from my pom.xml: jboss-sar ... org.codehaus.mojo jboss-packaging-maven-plugin 2.0-SNAPSHOT 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] Commented: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=comments#action_69244 ] Fredrik Vraalsen commented on MNG-2426: --- Also reported as http://jira.codehaus.org/browse/MOJO-449 Related to http://jira.codehaus.org/browse/MNG-2240 ? > Artifact copied to local repository with wrong file extension when using > jboss-packaging plugin > --- > > Key: MNG-2426 > URL: http://jira.codehaus.org/browse/MNG-2426 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories, Artifacts > Versions: 2.0.4 > Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin > 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) > Reporter: Fredrik Vraalsen > > > When using the jboss-packaging plugin and setting to jboss-sar in > my pom, the artifact is copied into the local repository with the wrong file > extension (.jboss-sar instead of .sar). The jboss-packaging components.xml > has set to sar. The file in the build target directory has the > correct .sar extension. > Here's the relevant excerpt from my pom.xml: > jboss-sar > ... > > > > org.codehaus.mojo > jboss-packaging-maven-plugin > 2.0-SNAPSHOT > 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] Commented: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=comments#action_69247 ] Sharmarke Aden commented on MPMD-36: In response to Mike Perham comments: Are you guys familiar with the assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html)? It provides an alternative way of package an application and as it stands you can't use the PMD plugin in conjunction with the assembly plugin. I believe this is an issue the PMD plugin needs to deal with. My application is packaged in fashion similar to the how Jetty is packaged (http://prdownloads.sourceforge.net/jetty/jetty-5.1.10.zip?download) . Look at their directory structure and try using war packaging to create that sort of directory structure. In response to Brett Porter comment: My patch also insures that the project has a source directory defined before proceeding. The patch basically allows the PMD continue if the follow condition is met: ((java || pom) && has source) > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Assignee: Mike Perham > Attachments: modulePOM.xml, parentPOM.xml, pmd-plugin_MPMD36.patch > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=comments#action_69253 ] Kenney Westerhof commented on MNG-2426: --- The artifact + ArtifactHandler are created before the project is scanned for plugins, and before the custom ArtifactHandler is discovered. It is never updated again after that, resulting in a default artifact handler of type 'jboss-sar', and getExtension defaults to the type. It works fine for core plugins since they're in the core components.xml which gets discovered before any maven project instance and/or artifact is created. > Artifact copied to local repository with wrong file extension when using > jboss-packaging plugin > --- > > Key: MNG-2426 > URL: http://jira.codehaus.org/browse/MNG-2426 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories, Artifacts > Versions: 2.0.4 > Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin > 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) > Reporter: Fredrik Vraalsen > > > When using the jboss-packaging plugin and setting to jboss-sar in > my pom, the artifact is copied into the local repository with the wrong file > extension (.jboss-sar instead of .sar). The jboss-packaging components.xml > has set to sar. The file in the build target directory has the > correct .sar extension. > Here's the relevant excerpt from my pom.xml: > jboss-sar > ... > > > > org.codehaus.mojo > jboss-packaging-maven-plugin > 2.0-SNAPSHOT > 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] Commented: (MNG-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=comments#action_69255 ]
Kenney Westerhof commented on MNG-2426:
---
Actually, after the extensions are processed, the artifactHandler _is_ updated
on the project,
except that the newly discovered artifact handler is not present in there.
some debug:
{noformat}
+ Error stacktraces are turned on.
Maven version: 2.1-SNAPSHOT
[INFO] Scanning for projects...
No artifact handler for type jboss-sar - using a default handler
java.lang.Throwable
at
org.apache.maven.artifact.handler.manager.DefaultArtifactHandlerManager.getArtifactHandler(DefaultArtifactHandlerManager.java:42)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:153)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:114)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:108)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createBuildArtifact(DefaultArtifactFactory.java:72)
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:903)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:754)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:425)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:194)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:580)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:512)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:412)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:338)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:171)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:689)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
EXTENSION NULL, USING TYPE: pom (classifier=null, packaging=null)
[INFO] FOUND PLUGIN COMPONENT:
org.codehaus.mojo:jboss-packaging-maven-plugin:2.0-SNAPSHOT
(org.codehaus.mojo:jboss-packaging-maven-plugin)
jar:file:/home/forge/.m2/repository/org/codehaus/mojo/jboss-packaging-maven-plugin/2.0-SNAPSHOT/jboss-packaging-maven-plugin-2.0-S
NAPSHOT.jar!/META-INF/maven/plugin.xml [KEY:
org.codehaus.mojo:jboss-packaging-maven-plugin] collector: [EMAIL PROTECTED]
[INFO] FOUND PLUGIN COMPONENT:
org.codehaus.mojo:jboss-packaging-maven-plugin:2.0-SNAPSHOT
(org.codehaus.mojo:jboss-packaging-maven-plugin)
jar:file:/home/forge/.m2/repository/org/codehaus/mojo/jboss-packaging-maven-plugin/2.0-SNAPSHOT/jboss-packaging-maven-plugin-2.0-S
NAPSHOT.jar!/META-INF/maven/plugin.xml [KEY:
org.codehaus.mojo:jboss-packaging-maven-plugin] collector: [EMAIL PROTECTED]
[INFO] Got 14 ArtifactHandlers from plugin jboss-packaging-maven-plugin
[INFO] Handler: [EMAIL PROTECTED] (packaging: javadoc classifier=javadoc
extension=jar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: jar classifier=null
extension=spring)
EXTENSION NULL, USING TYPE: jar (classifier=null, packaging=jar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: jar classifier=null
extension=jar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: ejb classifier=client
extension=jar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: jar classifier=tests
extension=jar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: java-source classifier=sources
extension=jar)
EXTENSION NULL, USING TYPE: ejb3 (classifier=null, packaging=ejb3)
[INFO] Handler: [EMAIL PROTECTED] (packaging: ejb3 classifier=null
extension=ejb3)
EXTENSION NULL, USING TYPE: ear (classifier=null, packaging=ear)
[INFO] Handler: [EMAIL PROTECTED] (packaging: ear classifier=null
extension=ear)
[INFO] Handler: [EMAIL PROTECTED] (packaging: jar classifier=null
extension=sar)
[INFO] Handler: [EMAIL PROTECTED] (packaging: ejb classifier=null
extension=jar)
EXTENSION NULL, USING TYPE: war (classifier=null, packaging=war)
[INFO] Handler: [EMAIL PROTECTED] (packaging: war classifier=null
extension=war)
EXTENSION NULL, USING TYPE: par (classifier=null, packaging
[jira] Commented: (MNG-2421) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
[ http://jira.codehaus.org/browse/MNG-2421?page=comments#action_69256 ] Dennis Lundberg commented on MNG-2421: -- This is because docck uses commons-httpclient which in turn uses commons-logging. When commons-logging tries to configure itself it does not find any configuration at all. But it does find log4j in the classpath so it tries to use it. There is no configuration for log4j so it (log4j) opts to shut down completely. I added a dependency in docck on commons-logging 1.1 which has some nice diagnostics to use in cases like this. Then I ran Maven on the webstart-plugin again like this: mvn docck:plugin -Dorg.apache.commons.logging.diagnostics.dest=STDOUT This tells commons-logging to output its diagnostics to STDOUT. The diagnostics shoes the classloading and configuration chain. This might be good in other cases as well. Doing this actually showed the results for docck, so it can be used as a workaround for the time being. I will try to see if I can tweak docck to work better. > [plugins/docck] fail to run > "org.apache.commons.logging.LogConfigurationException: Class > org.apache.commons.logging.impl.Jdk14Logger does not implement Log" > > > Key: MNG-2421 > URL: http://jira.codehaus.org/browse/MNG-2421 > Project: Maven 2 > Type: Bug > Components: Sandbox > Environment: maven 2.0.4 > Reporter: Jerome Lacoste > Attachments: mvn.log > > > This happens when I try running it on the under the > mojo/webstart-maven-plugin/plugin directory -- 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-156) site with FAQ plugin strips XML entities
site with FAQ plugin strips XML entities Key: MSITE-156 URL: http://jira.codehaus.org/browse/MSITE-156 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-5 Environment: WinXP Reporter: Ted Husted When using the FAQ plugin with site, entities lke < and > are stripped out, and the corresponding character is not injected. Apache Struts renders as a href="http://struts.apache.org"Apache Struts/a instead of http://struts.apache.org";>Apache Struts -- 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-2421) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
[ http://jira.codehaus.org/browse/MNG-2421?page=comments#action_69262 ] Dennis Lundberg commented on MNG-2421: -- I've done some digging and using commons-logging-1.0.4 produces this more usable message: "Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed." This seems to indicate a problem with the class loader hierarchy. Updating to commons-logging-1.1 solves this. That release of commons-logging had many fixes to class loading issues. Unless anyone thinks it is bad to add a dependency on commons-logging-1.1 I will commit the changes I have. Will leave it open for comments first. > [plugins/docck] fail to run > "org.apache.commons.logging.LogConfigurationException: Class > org.apache.commons.logging.impl.Jdk14Logger does not implement Log" > > > Key: MNG-2421 > URL: http://jira.codehaus.org/browse/MNG-2421 > Project: Maven 2 > Type: Bug > Components: Sandbox > Environment: maven 2.0.4 > Reporter: Jerome Lacoste > Attachments: mvn.log > > > This happens when I try running it on the under the > mojo/webstart-maven-plugin/plugin directory -- 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: (MNG-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] Fredrik Vraalsen reopened MNG-2284: --- see previous comment > Cannot specify additional classpath entries in manifest when using > addClasspath > --- > > Key: MNG-2284 > URL: http://jira.codehaus.org/browse/MNG-2284 > Project: Maven 2 > Type: Bug > Components: maven-archiver > Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 > Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK > 1.5.0_06, Windows XP > Reporter: Fredrik Vraalsen > Assignee: Mike Perham > Fix For: 2.0.5 > Attachments: MNG-archiver-classpath.patch > > > When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to > add additional classpath entries using manifestEntries, as this generates an > illegal manifest file (contains two Class-Path entries). Please see > http://jira.codehaus.org/browse/MJAR-41 > I have been looking through the code, and it seems this might need to be > resolved in MavenArchiver? I've attached a simple fix that solves the > problem for me, but a more thorough solution might be needed of course. ;-) -- 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-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=comments#action_69265 ] Fredrik Vraalsen commented on MNG-2284: --- Hi, I'm still having problems with this, but of a different sort now. If I have a configuration such as the following: true resources/ I now get the following in my manifest.mf: Class-Path: resources/ Class-Path: resources/ In other words, still two Class-Path entries in the manifest file, only this time they both have the value 'resources/', and the classpath created by addClasspath is gone. This is with latest maven-jar-plugin 2.1-SNAPSHOT (maven-archiver 2.1). I'm trying to create a JUnit test-case for maven-archiver, but I'm still trying to work out the details of how to set this up. ;-) In the meanwhile, I'll attach a simple stand-alone pom file which shows the problem. > Cannot specify additional classpath entries in manifest when using > addClasspath > --- > > Key: MNG-2284 > URL: http://jira.codehaus.org/browse/MNG-2284 > Project: Maven 2 > Type: Bug > Components: maven-archiver > Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 > Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK > 1.5.0_06, Windows XP > Reporter: Fredrik Vraalsen > Assignee: Mike Perham > Fix For: 2.0.5 > Attachments: MNG-archiver-classpath.patch > > > When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to > add additional classpath entries using manifestEntries, as this generates an > illegal manifest file (contains two Class-Path entries). Please see > http://jira.codehaus.org/browse/MJAR-41 > I have been looking through the code, and it seems this might need to be > resolved in MavenArchiver? I've attached a simple fix that solves the > problem for me, but a more thorough solution might be needed of course. ;-) -- 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: (MNG-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] Fredrik Vraalsen updated MNG-2284: -- Attachment: pom.xml > Cannot specify additional classpath entries in manifest when using > addClasspath > --- > > Key: MNG-2284 > URL: http://jira.codehaus.org/browse/MNG-2284 > Project: Maven 2 > Type: Bug > Components: maven-archiver > Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 > Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK > 1.5.0_06, Windows XP > Reporter: Fredrik Vraalsen > Assignee: Mike Perham > Fix For: 2.0.5 > Attachments: MNG-archiver-classpath.patch, pom.xml > > > When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to > add additional classpath entries using manifestEntries, as this generates an > illegal manifest file (contains two Class-Path entries). Please see > http://jira.codehaus.org/browse/MJAR-41 > I have been looking through the code, and it seems this might need to be > resolved in MavenArchiver? I've attached a simple fix that solves the > problem for me, but a more thorough solution might be needed of course. ;-) -- 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-761) Ability to delete results
Ability to delete results - Key: CONTINUUM-761 URL: http://jira.codehaus.org/browse/CONTINUUM-761 Project: Continuum Type: New Feature Components: Core system Versions: 1.0.3 Reporter: Srinivas Pavani There needs to be a way to delete old results. Especially useful when doing frequent builds and for cleaning up failed build results. -- 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-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69270 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
Woops, I've attached the comments to this bug rather than MJAR-28.
Never mind, they are related.
Request for advice sent to dev list, see
http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html
> assembling dependent jars or snapshots uses timestamp formatted version
> instead of ${version}
> -
>
> Key: MASSEMBLY-67
> URL: http://jira.codehaus.org/browse/MASSEMBLY-67
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Mark J. Titorenko
> Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
>
>
> I'm using the jar plugin to add my dependencies to the manifest. I'm also
> using the assembly plugin to package all dependencies into one archive. The
> problem is that the jar manifest adds my dependencies as "foo-SNAPHOT" and
> the archiver adds them as "foo-20041113.jar".
> This causes my snapshot classes to not be found at runtime.
--
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-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_69271 ] Baerrach bonDierne commented on MJAR-28: Woops, I've attached the comments to bug MASSEMBLY-67. Never mind, they are related. Request for advice sent to dev list, see http://www.nabble.com/MJAR-28-Advice-from-dev%3A-Mainfest.mf-Class-Path-entries-by-MavenArchiver%2C-Assembly-and-Jar-tf1908862.html > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Reporter: Mark J. Titorenko > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-759) Generate plexus-request.xml with plexus-cdc
[ http://jira.codehaus.org/browse/CONTINUUM-759?page=comments#action_69272
]
Emmanuel Venisse commented on CONTINUUM-759:
CDC/Plexus Maven Plugin don't know the difference, it generate only the file we
want :
{nofornat}
org.codehaus.plexus
plexus-maven-plugin
plexus-request.xml
true
{noformat}
plexus-application.xml is similar to component.xml or the old continuum conf
file (application.xml). In this file we add all component required by the
webwork application and not session or request objects
> Generate plexus-request.xml with plexus-cdc
> ---
>
> Key: CONTINUUM-759
> URL: http://jira.codehaus.org/browse/CONTINUUM-759
> Project: Continuum
> Type: Task
> Components: Web interface
> Versions: 1.1
> Reporter: Emmanuel Venisse
> Priority: Trivial
> Fix For: 1.1
>
>
--
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-406) XMLBeans pom is missing dependency
[ http://jira.codehaus.org/browse/MEV-406?page=comments#action_69282 ] Corridor Software Developer commented on MEV-406: - Can we take Brett's idea about a 2.0.0-1.pom to fruition and close this out? It's blocking the 2.0.1 release of the xmlbeans maven plugin. This is the last issue for the version. > XMLBeans pom is missing dependency > -- > > Key: MEV-406 > URL: http://jira.codehaus.org/browse/MEV-406 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: David Jencks > Attachments: xbean-2.0.0.pom > > > The xmlbeans 2.0.0 pom is missing the one required dependency on the stax > api. xmlbeans seems to ship a jsr-173-api jar that is of AFAICT unknown > provenance. AFAIK everyone has been using the stax-api jar with no problems > for years: certainly geronimo has. > To see that this is the single required dependency, consult > http://xmlbeans.apache.org/documentation/conInstallGuide.html and look at the > bottom of the page at the suggested classpath setup, e.g.: > export > CLASSPATH=$XMLBEANS_HOME/lib/xbean.jar:$XMLBEANS_HOME/lib/jsr173_1.0_api.jar:$CLASSPATH > Here's the pom, the instructions at > http://maven.apache.org/guides/mini/guide-maven-evangelism.html point to > invalid svn locations so I cannot check out the original and supply a patch. > The pom goes at ~/.m2/repository/xmlbeans/xbean/2.0.0/xbean-2.0.0.pom in a > local repo. I'll attach it as well. > > 4.0.0 > xmlbeans > xbean > 2.0.0 > > > stax > stax-api > 1.0 > > > -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_69283 ] Kenny Cheang commented on MSUREFIREREP-6: - I have the same issue. I am using "clean install site" and for some reason, the surefire test is executed four times. This is more than annoying. It considerably slows down the build process because I have some DAO tests against real database. I hope Maven can remove all duplicated goals within a single maven command so that people can safely execute something like "mvn clean compile test package install deploy site site-deploy". > surefire-report reruns tests > > > Key: MSUREFIREREP-6 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Environment: maven 2.0 > Reporter: Dirk Sturzebecher > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- 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-980) Upload JUG (Java UUID Generator) 2.0.0 (LGPL)
Upload JUG (Java UUID Generator) 2.0.0 (LGPL) - Key: MAVENUPLOAD-980 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-980 Project: maven-upload-requests Type: Task Reporter: Matt Whitlock Attachments: jug-lgpl-2.0.0-bundle.jar http://home.mattwhitlock.com:8080/~mattw/jug-lgpl-2.0.0-bundle.jar http://jug.safehaus.org/ JUG is a pure java UUID generator, that can be used either as a component in a bigger application, or as a standalone command line tool (a la 'uuidgen'). UUIDs are 128-bit Universally Unique IDentifiers (aka GUID, Globally Unique IDentifier used in Windows world). [see project site for more] -- 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
