Jesse Glick (JIRA | 1 Jul 02:03 2011

[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:
(Continue reading)

Michael Osipov (JIRA | 1 Jul 09:19 2011

[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:
(Continue reading)

Michael Osipov (JIRA | 1 Jul 10:14 2011

[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

Ronald A. Bowers (JIRA | 1 Jul 17:53 2011

[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>
(Continue reading)

Jesse Glick (JIRA | 1 Jul 18:08 2011

[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.
(Continue reading)

Ronald A. Bowers (JIRA | 1 Jul 18:22 2011

[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>
(Continue reading)

r351574nc3 (JIRA | 1 Jul 23:51 2011

[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".
(Continue reading)

Robert Scholte (JIRA | 2 Jul 13:16 2011

[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
(Continue reading)

Clement Denis (JIRA | 2 Jul 15:24 2011

[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
(Continue reading)

Robert Scholte | 2 Jul 20:39 2011

RE: Vote: Promote chronos from sandbox to proper

Integration tests are always about maven-projects. The nice thing about this is that it won't have dependency-collissions, which might happen if you use the AbstractMojoTestCase (in case of java).
With ITs it's much more often possible to reproduce certain issues.
 
Why not extract the JMeter part and make a separate mojo-project of it? This might make a lot of people happy. The naming is less odd and there's an extra (JMeter) plugin with its own release cycle.
I wouldn't include some functionality of which you expect to be replaced in the (near) future.
 
-Robert
 
From: ksr <at> lakeside.dk
Date: Thu, 30 Jun 2011 15:32:46 +0200
To: dev <at> mojo.codehaus.org
Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper

I see what You mean with the structuring. I am not sure that Your suggested structure is a no-brainer, since the integrationtests are a suite of small independent maven projects, and NOT normal java based tests.
But if other project do it this way, it should of course be aligned.

The naming may be odd at first. The focus of the plugin have never been performing the tests, but rather analyzing the output from the tests, tracking historic developments, checking that goals have been met...

 I believe in the concept of "do one thing and do it well". And the name jmeter-maven-plugin should IMHO be reserved for a plugin focused on invoking jmeter. When this project was started, there was no mature jmeter plugins at all, so "by coincidense"  support for that was added as well.

Actually the name jmeter-maven-plugin is already taken by  a project hosted at googlecode (later moved to github), which is focused on the execution of JMeter. It does not seem very mature to me yet, but it actually is possible to use the jmeter-maven-plugin to invoke the performancetests, and then use chronos to analyze the results.

As soon as i find a jmeter plugin which is mature enough, the intention is to deprecate the stuf about jmeter invocation inside chronos and recommend usage of other plugins to that task.

Any comments on that?

- Kent



Den 27/06/2011 kl. 22.41 skrev Robert Scholte:

IIRC there have been some issues with the licensing of this project. Suddenly it changed from MIT to some company copyright, but it looks like this has been reverted and slightly adjusted by mentioning some donation information. I think this is okay right now.
 
The project structure looks a bit strange to me. I would have expected:
chronos-maven-plugin
 \- src
     \- main
     \- test
     \- it (here the integration tests)
If there's no particular reason for this, consider restructuring it, so it would look more like most other mojo plugins.
 
I haven't looked at the code yet, but Kents comment sounds interesting. If JMeter is the only implementation, why not call it like that.
That would also make it easier to find for wandering users looking for some JMeter Maven-plugin.
 
-Robert

> Date: Mon, 27 Jun 2011 09:10:00 -0400
> From: jieryn <at> gmail.com
> To: dev <at> mojo.codehaus.org
> Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper
> 
> Greetings,
> 
> On Mon, Jun 27, 2011 at 4:08 AM, Kent Sølvsten <ksr <at> lakeside.dk> wrote:
> > I believe now is the time to promote the plugin from the sandbox. Since the code should be in a pretty stable state, I expect to head immediately for a beta release, and then hopefully a final 1.0 release within a month or 2.
> 
> I don't have a binding vote. I find the naming of this plugin to be
> kind of misleading though, since all of the goals seem to deal with
> JMeter. Wouldn't this plugin fair better if named jmeter-maven-plugin?
> Or something else which otherwise informs the uninformed, at a glance,
> what this plugin is likely about..
> 
> -Jesse
> 
> -- 
> There are 10 types of people in this world, those
> that can read binary and those that can not.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email
> 
> 


Gmane