[jira] Created: (MOUNCE-7) Invalid character in plugin.xml

Invalid character in plugin.xml
-------------------------------

                 Key: MOUNCE-7
                 URL: https://jira.codehaus.org/browse/MOUNCE-7
             Project: Maven 2.x Ounce Plugin
          Issue Type: Bug
         Environment: JDK 6u25, Ubuntu
            Reporter: Jesse Glick

While running a parser on {{META-INF/maven/plugin.xml}} in
{{~/.m2/repository/org/codehaus/mojo/ounce-maven-plugin/1.2/ounce-maven-plugin-1.2.jar}} I got:

{noformat}
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of
2-byte UTF-8 sequence.
	at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(UTF8Reader.java:684)
	at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:369)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1742)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(XMLEntityScanner.java:487)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2687)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:235)
	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284){noformat}

Inspecting the XML file, I saw the problem at line 215:

[jira] Commented: (MAPPASM-121) Generated script should be set executable (or allow for a umask to be defined).

    [
https://jira.codehaus.org/browse/MAPPASM-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271992#comment-271992
] 

Michael Osipov commented on MAPPASM-121:
----------------------------------------

Won't work on Windows. I'd rather set this in the assembly plugin.

> Generated script should be set executable (or allow for a umask to be defined).
> -------------------------------------------------------------------------------
>
>                 Key: MAPPASM-121
>                 URL: https://jira.codehaus.org/browse/MAPPASM-121
>             Project: Mojo AppAssembler Plugin
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>         Environment: ubuntu x86
>            Reporter: David J. M. Karlsen
>
> The generated shell script should be have the executable bit set by default.
> It would be even better if an filemask could be set by the end user in configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

[jira] Created: (MAPPASM-123) Make %JAVA_OPTS% name customizable

Make %JAVA_OPTS% name customizable
----------------------------------

                 Key: MAPPASM-123
                 URL: https://jira.codehaus.org/browse/MAPPASM-123
             Project: Mojo AppAssembler Plugin
          Issue Type: New Feature
    Affects Versions: 1.1.1
         Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_07
Java home: /usr/local/diablo-jdk1.6.0/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "freebsd" version: "8.2-stable" arch: "i386" Family: "unix"
            Reporter: Michael Osipov

I'd like to configure the name of JAVA_OPTS which will be passed to the VM.

I'd prefer %APP_NAME_OPTS% just as Maven does with %MAVEN_OPTS%.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jira] Created: (MNBMODULE-144) Build fails due to problem opening zip file under "mvn test" and "mvn package" but succeeds under "mvn install"

Build fails due to problem opening zip file under "mvn test"  and "mvn package" but succeeds under "mvn install"
----------------------------------------------------------------------------------------------------------------

                 Key: MNBMODULE-144
                 URL: https://jira.codehaus.org/browse/MNBMODULE-144
             Project: Maven NetBeans Module Plugin
          Issue Type: Bug
    Affects Versions: 3.5
         Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Java version: 1.6.0_20, vendor: Sun Microsystems Inc.
OS name: "linux", version: "2.6.18-238.12.1.el5.arl", arch: "amd64", family: "unix"

Netbeans 7.0 RCP
            Reporter: Ronald A. Bowers
            Assignee: Jesse Glick

First off, I understand that this issue was supposedly fixed in 3.5, however I'm still getting it.

Here's the pom.

<build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>nbm-maven-plugin</artifactId>
                <version>3.5</version>                
                <configuration>
                    <publicPackages>
                        <publicPackage>xxx.gui.fs.importer.excelFile</publicPackage>
                        <publicPackage>xxx.gui.fs.importer.funcunits.bad</publicPackage>

[jira] Closed: (MNBMODULE-144) Build fails due to problem opening zip file under "mvn test" and "mvn package" but succeeds under "mvn install"

     [
https://jira.codehaus.org/browse/MNBMODULE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse Glick closed MNBMODULE-144.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.6

Perhaps fixed in revision 14242. Since you offered no test case to reproduce, I cannot say for sure. (I
understand that you have confidential source code, but that just means you need to narrow down the problem
to a generic minimal test case, which would be a good idea anyway.) It looks like some nbm-packaging
project has a dependency on a jar-packaging project in the same reactor tree but it is hard to tell.

I have deployed a snapshot version of the plugin with the attempted fix to
https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/nbm-maven-plugin/3.6-SNAPSHOT/nbm-maven-plugin-3.6-20110701.160517-1.jar
so if you want to try to declare this snapshot repository and request this version of the plugin in your root
pom you would be able to verify using your project.

> Build fails due to problem opening zip file under "mvn test"  and "mvn package" but succeeds under "mvn install"
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: MNBMODULE-144
>                 URL: https://jira.codehaus.org/browse/MNBMODULE-144
>             Project: Maven NetBeans Module Plugin
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Java version: 1.6.0_20, vendor: Sun Microsystems Inc.

[jira] Commented: (MNBMODULE-144) Build fails due to problem opening zip file under "mvn test" and "mvn package" but succeeds under "mvn install"

    [
https://jira.codehaus.org/browse/MNBMODULE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272067#comment-272067
] 

Ronald A. Bowers commented on MNBMODULE-144:
--------------------------------------------

Thanks Jesse! 3.6 SNAPSHOT fixes the issue. Thanks for the super-quick response.

> Build fails due to problem opening zip file under "mvn test"  and "mvn package" but succeeds under "mvn install"
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: MNBMODULE-144
>                 URL: https://jira.codehaus.org/browse/MNBMODULE-144
>             Project: Maven NetBeans Module Plugin
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Java version: 1.6.0_20, vendor: Sun Microsystems Inc.
> OS name: "linux", version: "2.6.18-238.12.1.el5.arl", arch: "amd64", family: "unix"
> Netbeans 7.0 RCP
>            Reporter: Ronald A. Bowers
>            Assignee: Jesse Glick
>             Fix For: 3.6
>
>
> First off, I understand that this issue was supposedly fixed in 3.5, however I'm still getting it.
> Here's the pom.
> <build>

[jira] Commented: (MTOMCAT-6) tomcat:run goal failing

    [
https://jira.codehaus.org/browse/MTOMCAT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272098#comment-272098
] 

r351574nc3 commented on MTOMCAT-6:
----------------------------------

Is this the same problem as I am experiencing? This is what my log is spitting out? Looks like it says delegate
is 'false'. I thought this is 'true' by default. I tried explicitly setting to 'true'. that doesn't help.
Looks like it's having trouble mixing sun.misc.Launcher$AppClassLoader <at> 61e63e3d and
WebappClassLoader. Is this a new issue or the same as this one?

Jul 1, 2011 2:47:06 PM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Jul 1, 2011 2:47:06 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
"org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by 
log4j:ERROR [ClassRealm[plugin>org.codehaus.mojo:tomcat-maven-plugin:1.1, parent:
sun.misc.Launcher$AppClassLoader <at> 61e63e3d]] whereas object of type 
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by [WebappClassLoader
  context: /kfs-dev
  delegate: false
  repositories:
----------> Parent Classloader:
ClassRealm[plugin>org.codehaus.mojo:tomcat-maven-plugin:1.1, parent: sun.misc.Launcher$AppClassLoader <at> 61e63e3d]
].
log4j:ERROR Could not instantiate appender named "CONSOLE".

[jira] Closed: (MASPECTJ-9) Add support for weaving classes in folders instead of jars

     [
https://jira.codehaus.org/browse/MASPECTJ-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Scholte closed MASPECTJ-9.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 1.4

Somehow it took 1040 days to apply this patch.
It's an old patch, so I had to adjust it here and there.
With this feature I think I can close some other issues too.
This feature will require some more code, like there should be an option to (un)set the sourcespaths
(related to MASPECTJ-95), make them optional (related to MASPECTJ-99).
At least the AspectJ option is now exposed.

Fixed in [rev.4243|http://fisheye.codehaus.org/changelog/mojo/?cs=14243]

> Add support for weaving classes in folders instead of jars
> ----------------------------------------------------------
>
>                 Key: MASPECTJ-9
>                 URL: https://jira.codehaus.org/browse/MASPECTJ-9
>             Project: Mojo AspectJ Plugin
>          Issue Type: New Feature
>    Affects Versions: 1.0
>            Reporter: Torsten Juergeleit
>            Assignee: Robert Scholte
>             Fix For: 1.4

[jira] Created: (MVERSIONS-155) display-property-updates goal displays the updated versions twice

display-property-updates goal displays the updated versions twice
-----------------------------------------------------------------

                 Key: MVERSIONS-155
                 URL: https://jira.codehaus.org/browse/MVERSIONS-155
             Project: Maven 2.x Versions Plugin
          Issue Type: Bug
    Affects Versions: 1.2
         Environment: Maven 3.0.3
Java 1.6
            Reporter: Clement Denis

When I run the display-property-updates goal, I get the updated version properties twice instead of
getting the up-to-date versions first.

{code}
[INFO] The following version properties are referencing the newest available version:
[INFO]   ${spring.batch.version} .............. 2.0.4.RELEASE -> 2.1.8.RELEASE
[INFO]   ${version.commons-logging} ............. 1.1.1 -> 99.0-does-not-exist
[INFO]   ${version.intellij-annotations} ...................... 7.0.3 -> 9.0.4
[INFO]   ${version.jackson} ................................... 1.7.4 -> 1.8.2
[INFO]   ${version.commons-codec} ................................. 1.4 -> 1.5
[INFO]   ${spring.framework.version} ............... 3.0.3.RELEASE -> 3.1.0.M2
[INFO]   ${version.perf4j} .................................. 0.9.13 -> 0.9.14
[INFO]   ${version.commons-digester} .............................. 1.8 -> 2.1
[INFO]   ${version.jsf} .................................. 1.2_14 -> 2.0.2-FCS
[INFO]   ${version.commons-vfs} ........................ 1.0 -> 20050307052300
[INFO]   ${version.antlr} .................................. 2.7.6 -> 20030911
[INFO]   ${version.hibernate-ehcache} ................ 3.3.1.GA -> 4.0.0.Beta2
[INFO]   ${version.commons-httpclient} ....................... 3.1 -> 3.1-osgi

RE: Vote: Promote chronos from sandbox to proper