[jira] [Commented] (DOXIA-569) add Markdown Sink, to be able to convert anything to Markdown
[ https://issues.apache.org/jira/browse/DOXIA-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495952#comment-17495952 ] Jochen Wiedmann commented on DOXIA-569: --- [~michael-o] I understand the reasoning. On the other hand, the request is reasonable, just as well. Perhaps, we could compromise on something like: # There is no Markdown Sink. # There is, however, the possibility to convert the generated HTML documentation into a PDF document. If that is implemented with "pandoc": So, be it. > add Markdown Sink, to be able to convert anything to Markdown > - > > Key: DOXIA-569 > URL: https://issues.apache.org/jira/browse/DOXIA-569 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Markdown >Affects Versions: 1.8 >Reporter: Herve Boutemy >Priority: Major > Labels: intern > Fix For: wontfix-candidate > > > Markdown is well known: having Markdown Sink would help people transform > existing content to Markdown -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-409) ServicesResourceTransformer ignores relocations
[ https://issues.apache.org/jira/browse/MSHADE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486548#comment-17486548 ] Jochen Wiedmann commented on MSHADE-409: Close, please. Created accidentally. > ServicesResourceTransformer ignores relocations > --- > > Key: MSHADE-409 > URL: https://issues.apache.org/jira/browse/MSHADE-409 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.4 >Reporter: Jochen Wiedmann >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MSHADE-409) ServicesResourceTransformer ignores relocations
Jochen Wiedmann created MSHADE-409: -- Summary: ServicesResourceTransformer ignores relocations Key: MSHADE-409 URL: https://issues.apache.org/jira/browse/MSHADE-409 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.2.4 Reporter: Jochen Wiedmann -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MCOMPILER-453) Support null-analysis configuration in the Maven POM
Jochen Wiedmann created MCOMPILER-453: - Summary: Support null-analysis configuration in the Maven POM Key: MCOMPILER-453 URL: https://issues.apache.org/jira/browse/MCOMPILER-453 Project: Maven Compiler Plugin Issue Type: Wish Affects Versions: 3.8.1 Reporter: Jochen Wiedmann The commons-lang project intends to start using the @Nullable, and @NonNull annotations, both as a guidance for static code analysis, and for the purpose of documentation. Experience shows, that IDE's are already supporting these kind of things. (See, for example, [https://wiki.eclipse.org/JDT_Core/Null_Analysis|[http://example.com].)|http://example.com].%29/] Ideally, an IDE importing the commons-lang should be able to detect a) the fact, that the Maven project is using Null Analysis, and b) It does so using the namespace "javax.annotation" (and not, for example, "edu.umd.cs.findbugs.annotations", or "com.github.spotbugs.annotation). For that to happen, there are two obvious choices: 1.) We start adding IDE specific configuration files to the project. (Not desirable, for any number of reasons.) 2.) We teach the IDE's to read this information from the Maven POM. For example, have the following in the Compile goal: @Parameter(property="compiler:nullAnalysisEnabled", default="false") private boolean nullAnalysisEnabled; @Parameter(property="compiler:nullAnalysisNullableAnnotation", default="javax.annotation.Nullable") private String nullAnalysisNullableAnnotation; @Parameter(property="compiler:nullAnalysisNonNullAnnotation", default="javax.annotation.NonNull") private String nullAnalysisNonNullAnnotation; If we had that, then we could teach the IDE specific Maven adapter (like M2E) to recognize these parameters, and behave accordingly. *Note:* At least initially, these parameters could very well be no-ops. It is completely sufficient to have them for documentation purposes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5926) Allow for comment elements inside POM
[ https://issues.apache.org/jira/browse/MNG-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15724745#comment-15724745 ] Jochen Wiedmann commented on MNG-5926: -- Sorry, but I don't get, why XML comments aren't sufficient for you. What's the problem with those? > Allow for comment elements inside POM > - > > Key: MNG-5926 > URL: https://issues.apache.org/jira/browse/MNG-5926 > Project: Maven > Issue Type: Improvement > Components: POM >Reporter: James Green >Priority: Trivial > Fix For: Issues to be reviewed for 4.x > > > I have spent hours tracking down why something exists as it does within a > company POM. On multiple occasions. > All because there is no obvious documentation for things like dependencies. > Yes, we could use XML comments but these will not show in the results of any > documentation tools. > What I am asking for is a element to be permitted within a > , , and probably a few other areas but those are real > immediate areas of need. > This was discussed briefly on the -users mailing list many months ago and was > generally met with approval. I can't remember adding it here though... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-6108) Maven selects wrong JVM
[
https://issues.apache.org/jira/browse/MNG-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann closed MNG-6108.
Resolution: Cannot Reproduce
Fix Version/s: 3.3.9
After installing JDK 1.8.0_112, this issue is gone, strangely.
Sorry for the noise!
> Maven selects wrong JVM
> ---
>
> Key: MNG-6108
> URL: https://issues.apache.org/jira/browse/MNG-6108
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.9
> Environment: Windows 7, Java 8
>Reporter: Jochen Wiedmann
>Priority: Minor
> Fix For: 3.3.9
>
>
> Hi,
> I am using Mavn 3.3.9:
> {noformat}$ which mvn
> /d/opt/apache-maven-3.3.9/bin/mvn{noformat}
> I intend to use an installed SDK 1.8.0_102:
> {noformat}$ which mvn
> /d/opt/apache-maven-3.3.9/bin/mvn
> $ echo $JAVA_HOME
> d:/opt/jdk1.8.0_102
> $ which java
> /d/opt/jdk1.8.0_102/bin/java{noformat}
> Nevertheless, Maven is constantly using Java 1.8.0_111. Which is a problem,
> because that is a JRE, and not an SDK:
> {noformat}$ mvn -Pjenkins -U clean install
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Ant Plugin 1.5-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.6:clean (default-clean) @ ant ---
> [INFO] Deleting D:\Users\JochenWiedmann\git\jenkins\ant-plugin\target
> [INFO]
> [INFO] --- maven-hpi-plugin:1.120:validate (default-validate) @ ant ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:display-info (display-info) @ ant ---
> [INFO] Maven Version: 3.3.9
> [INFO] JDK Version: 1.8.0_111 normalized as: 1.8.0-111
> $ java -version
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode){noformat}
> The problem is perhaps understandable, if you look at this:
> {noformat}$ /d/opt/jdk1.8.0_102/bin/java -version
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode){noformat}
> But, anyways: How can I lock down the JVM, that Maven is using?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6108) Maven selects wrong JVM
Jochen Wiedmann created MNG-6108: Summary: Maven selects wrong JVM Key: MNG-6108 URL: https://issues.apache.org/jira/browse/MNG-6108 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.3.9 Environment: Windows 7, Java 8 Reporter: Jochen Wiedmann Priority: Minor Hi, I am using Mavn 3.3.9: $ which mvn /d/opt/apache-maven-3.3.9/bin/mvn I intend to use an installed SDK 1.8.0_102: $ which mvn /d/opt/apache-maven-3.3.9/bin/mvn $ echo $JAVA_HOME d:/opt/jdk1.8.0_102 $ which java /d/opt/jdk1.8.0_102/bin/java Nevertheless, Maven is constantly using Java 1.8.0_111. Which is a problem, because that is a JRE, and not an SDK: $ mvn -Pjenkins -U clean install [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Ant Plugin 1.5-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.6:clean (default-clean) @ ant --- [INFO] Deleting D:\Users\JochenWiedmann\git\jenkins\ant-plugin\target [INFO] [INFO] --- maven-hpi-plugin:1.120:validate (default-validate) @ ant --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:display-info (display-info) @ ant --- [INFO] Maven Version: 3.3.9 [INFO] JDK Version: 1.8.0_111 normalized as: 1.8.0-111 $ java -version java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode) The problem is perhaps understandable, if you look at this: $ /d/opt/jdk1.8.0_102/bin/java -version java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode) But, anyways: How can I lock down the JVM, that Maven is using? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MDEP-522) Support different output types for list, or resolve
[ https://issues.apache.org/jira/browse/MDEP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MDEP-522: - Attachment: MDEP-522.patch Proposed patch, complete version. > Support different output types for list, or resolve > --- > > Key: MDEP-522 > URL: https://issues.apache.org/jira/browse/MDEP-522 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.10 >Reporter: Jochen Wiedmann >Priority: Minor > Attachments: MDEP-522.patch, MDEP-522.patch > > > Right now, the goals list, and resolve, generate a human readably output > file. This is unsuitable for machine based processing, although a dependency > list is very likely to be of use for downstream applications. > Suggestion: Introduce a new parameter outputFormat with values like "text" > (current format, default), or "properties". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MDEP-522) Support different output types for list, or resolve
[ https://issues.apache.org/jira/browse/MDEP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MDEP-522: - Attachment: MDEP-522.patch Proposed patch > Support different output types for list, or resolve > --- > > Key: MDEP-522 > URL: https://issues.apache.org/jira/browse/MDEP-522 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.10 >Reporter: Jochen Wiedmann >Priority: Minor > Attachments: MDEP-522.patch > > > Right now, the goals list, and resolve, generate a human readably output > file. This is unsuitable for machine based processing, although a dependency > list is very likely to be of use for downstream applications. > Suggestion: Introduce a new parameter outputFormat with values like "text" > (current format, default), or "properties". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MDEP-522) Support different output types for list, or resolve
[ https://issues.apache.org/jira/browse/MDEP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MDEP-522: - Priority: Minor (was: Major) Description: Right now, the goals list, and resolve, generate a human readably output file. This is unsuitable for machine based processing, although a dependency list is very likely to be of use for downstream applications. Suggestion: Introduce a new parameter outputFormat with values like "text" (current format, default), or "properties". was: Right now, the goals list, and resolve, generate a human readably output file. This is unsuitable for machine based processing, although a dependency list is very likely to be of use for downstream applications. Suggestion: Introduce a new parameter outputFormat with values like "text" (current format, default), or "properties". Issue Type: New Feature (was: Bug) > Support different output types for list, or resolve > --- > > Key: MDEP-522 > URL: https://issues.apache.org/jira/browse/MDEP-522 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.10 >Reporter: Jochen Wiedmann >Priority: Minor > > Right now, the goals list, and resolve, generate a human readably output > file. This is unsuitable for machine based processing, although a dependency > list is very likely to be of use for downstream applications. > Suggestion: Introduce a new parameter outputFormat with values like "text" > (current format, default), or "properties". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MDEP-522) Support different output types for list, or resolve
Jochen Wiedmann created MDEP-522: Summary: Support different output types for list, or resolve Key: MDEP-522 URL: https://issues.apache.org/jira/browse/MDEP-522 Project: Maven Dependency Plugin Issue Type: Bug Components: resolve Affects Versions: 2.10 Reporter: Jochen Wiedmann Right now, the goals list, and resolve, generate a human readably output file. This is unsuitable for machine based processing, although a dependency list is very likely to be of use for downstream applications. Suggestion: Introduce a new parameter outputFormat with values like "text" (current format, default), or "properties". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPDF-73) Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive.
[ https://issues.apache.org/jira/browse/MPDF-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704787#comment-14704787 ] Jochen Wiedmann commented on MPDF-73: - I don't get your question, Herve? > Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive. > -- > > Key: MPDF-73 > URL: https://issues.apache.org/jira/browse/MPDF-73 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: $ mvn --version > Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; > 2015-03-13T21:10:27+01:00) > Maven home: C:\opt\apache-maven-3.3.1 > Java version: 1.7.0_76, vendor: Oracle Corporation > Java home: C:\opt\jdk1.7.0_76\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Jochen Wiedmann > Attachments: test-pdf-generation.tar.gz > > > The attached project contains three content pages: index.html, test-apt.html, > and test-md.html, two of which are written using the APT format, and one > using Markdown. > Now, everything works fine when generating the HTML site. In particular, all > three HTML pages are created, and appear in the menu. > However, only the APT pages are present in the generated PDF document. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPDF-73) Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive.
[ https://issues.apache.org/jira/browse/MPDF-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MPDF-73: Attachment: test-pdf-generation.tar.gz Demo project, use "mvn clean install site" to reproduce. > Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive. > -- > > Key: MPDF-73 > URL: https://issues.apache.org/jira/browse/MPDF-73 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: $ mvn --version > Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; > 2015-03-13T21:10:27+01:00) > Maven home: C:\opt\apache-maven-3.3.1 > Java version: 1.7.0_76, vendor: Oracle Corporation > Java home: C:\opt\jdk1.7.0_76\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Jochen Wiedmann > Attachments: test-pdf-generation.tar.gz > > > The attached project contains three content pages: index.html, test-apt.html, > and test-md.html, two of which are written using the APT format, and one > using Markdown. > Now, everything works fine when generating the HTML site. In particular, all > three HTML pages are created, and appear in the menu. > However, only the APT pages are present in the generated PDF document. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPDF-73) Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive.
Jochen Wiedmann created MPDF-73: --- Summary: Maven-pdf-plugin and Doxia-markdown-module are mutually exclusive. Key: MPDF-73 URL: https://issues.apache.org/jira/browse/MPDF-73 Project: Maven PDF Plugin Issue Type: Bug Affects Versions: 1.3 Environment: $ mvn --version Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; 2015-03-13T21:10:27+01:00) Maven home: C:\opt\apache-maven-3.3.1 Java version: 1.7.0_76, vendor: Oracle Corporation Java home: C:\opt\jdk1.7.0_76\jre Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Reporter: Jochen Wiedmann The attached project contains three content pages: index.html, test-apt.html, and test-md.html, two of which are written using the APT format, and one using Markdown. Now, everything works fine when generating the HTML site. In particular, all three HTML pages are created, and appear in the menu. However, only the APT pages are present in the generated PDF document. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5801) Unable to set webappDirectory
[
https://issues.apache.org/jira/browse/MNG-5801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-5801:
-
Attachment: demoCleanInstall.log
demo.tar.gz
The attached file demo.tar.gz contains the project, that reproduces the problem
for me.
The attached log file demonstrates, that the problem is not within the
maven-war-fille, because it is invoked with the wrong default value for
webappDirectory, and my configured value is ignored:
[DEBUG] Goal: org.apache.maven.plugins:maven-war-plugin:2.2:war (defaul
t-war)
[DEBUG] Style: Regular
[DEBUG] Configuration:
...
> Unable to set webappDirectory
> -
>
> Key: MNG-5801
> URL: https://issues.apache.org/jira/browse/MNG-5801
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.1
> Environment: Windows 7, Java 1.7.0_76
>Reporter: Jochen Wiedmann
> Attachments: demo.tar.gz, demoCleanInstall.log
>
>
> I've got a war project (see attached zip file), which contains the
> configuration snippet below. As a consequence, I'd expect the assembled
> webapp to be in target/my-webapp. However, it is in
> target/demo-0.0.1-SNAPSHOT.
>
>
>
> org.apache.maven.plugin
> maven-war-plugin
> 2.2
>
>
> ${project.build.directory}/my-webapp
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5801) Unable to set webappDirectory
Jochen Wiedmann created MNG-5801:
Summary: Unable to set webappDirectory
Key: MNG-5801
URL: https://issues.apache.org/jira/browse/MNG-5801
Project: Maven
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.3.1
Environment: Windows 7, Java 1.7.0_76
Reporter: Jochen Wiedmann
I've got a war project (see attached zip file), which contains the
configuration snippet below. As a consequence, I'd expect the assembled webapp
to be in target/my-webapp. However, it is in target/demo-0.0.1-SNAPSHOT.
org.apache.maven.plugin
maven-war-plugin
2.2
${project.build.directory}/my-webapp
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MSHARED-179) FilteringUtils.escapeWindowsPath only works if the Windows path is at the beginning of a property
[
https://jira.codehaus.org/browse/MSHARED-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304538#comment-304538
]
Jochen Wiedmann commented on MSHARED-179:
-
Recommended workaround: Use property files in XML format and replace
Properties.load with Properties.loadFromXML.
See http://www.ibm.com/developerworks/java/library/j-tiger02254/index.html
> FilteringUtils.escapeWindowsPath only works if the Windows path is at the
> beginning of a property
> -
>
> Key: MSHARED-179
> URL: https://jira.codehaus.org/browse/MSHARED-179
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-4
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: maven-filtering-1.0
>
> Attachments: MSHARED-179.patch, MSHARED-179.zip
>
>
> If the Windows path is in the middle, like in a JDBC URL escaping is not
> done. Here's the code from FilteringUtils.java that causes it:
> {code:java}
> public static final String escapeWindowsPath( String val )
> {
> if ( !StringUtils.isEmpty( val ) && val.indexOf( ":\\" ) == 1 )
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-111) escapeWindowsPath doesn't work when applying properties
[
https://jira.codehaus.org/browse/MRESOURCES-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304537#comment-304537
]
Jochen Wiedmann commented on MRESOURCES-111:
Recommended workaround: Use property files in XML format and replace
Properties.load with Properties.loadFromXML.
See http://www.ibm.com/developerworks/java/library/j-tiger02254/index.html
> escapeWindowsPath doesn't work when applying properties
> ---
>
> Key: MRESOURCES-111
> URL: https://jira.codehaus.org/browse/MRESOURCES-111
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Jochen Wiedmann
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: mydemo.zip
>
>
> The attached project contains a property file
> "src/test/main/hibernate.properties". I'd like to inject the projects build
> path into that file. More precisely, I have a property "jdbc.url" in my
> pom.xml, which looks like this:
>
> jdbc:derby:${project.build.directory}/derby-db;create=true
> In hibernate.properties, I have
> hibernate.connection.url=${jdbc.url}
> Which resolves to
>
> hibernate.connection.url=jdbc:derby:C:\workspace\mydemo\target/derby-db;create=true
> which is invalid, because the backslashes aren't escaped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-128) Add deploy-dir goal
[
http://jira.codehaus.org/browse/MDEPLOY-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann closed MDEPLOY-128.
---
Resolution: Won't Fix
Thanks for the suggestion, Dan. I did not know the wagon-maven-plugin, but the
following snippet does exactly what I had in mind:
org.codehaus.mojo
wagon-maven-plugin
1.0-beta-3
deploy-update-site
deploy
upload
${project.build.directory}/site
sftp://web.sourceforge.net/home/groups/m/mo/mongrel/htdocs/updates
mongrel.sf.net
I am therefore closing this issue.
> Add deploy-dir goal
> ---
>
> Key: MDEPLOY-128
> URL: http://jira.codehaus.org/browse/MDEPLOY-128
> Project: Maven 2.x Deploy Plugin
> Issue Type: New Feature
>Affects Versions: 2.6
>Reporter: Jochen Wiedmann
> Attachments: deploy-dir-mojo.patch
>
>
> The attached patch introduces a deploy-dir Mojo, which basically works just
> like the site plugins site-deploy mojo, except that it is configured manually
> (like deploy-file) and not from within the POM.
> My personal use case is as follows: I've got an Eclipse update site, which is
> built with Tycho. However, Tycho doesn't allow me to deploy the created
> update site. Deploying this update site currently requires the antrun plugin,
> or similar mechanisms, which completely circumvent Wagon and all these
> things, which are already built into Maven. In particular, I can't use the
> authentication, which is configured anyways, because the host carrying my
> update site is (surprise!) the same host, which carries my repository and my
> deployed site and everything is deployed using SFTP anyways.
> Rather than building this into Tycho, I choosed a more generic approach, as I
> believe that my requirement might be useful for other purposes as well.
> The patch includes a test case based on the plugin-testing-harness.
> The patch borrows heavily from site:site-deploy. I won't comment, whether
> this makes sense or not. I am ready to refactor the patch, should that be
> required. However, I'd like to have something like a basic "Ok", before doing
> this additional work.
--
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: (MDEPLOY-128) Add deploy-dir goal
Add deploy-dir goal --- Key: MDEPLOY-128 URL: http://jira.codehaus.org/browse/MDEPLOY-128 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Affects Versions: 2.6 Reporter: Jochen Wiedmann Attachments: deploy-dir-mojo.patch The attached patch introduces a deploy-dir Mojo, which basically works just like the site plugins site-deploy mojo, except that it is configured manually (like deploy-file) and not from within the POM. My personal use case is as follows: I've got an Eclipse update site, which is built with Tycho. However, Tycho doesn't allow me to deploy the created update site. Deploying this update site currently requires the antrun plugin, or similar mechanisms, which completely circumvent Wagon and all these things, which are already built into Maven. In particular, I can't use the authentication, which is configured anyways, because the host carrying my update site is (surprise!) the same host, which carries my repository and my deployed site and everything is deployed using SFTP anyways. Rather than building this into Tycho, I choosed a more generic approach, as I believe that my requirement might be useful for other purposes as well. The patch includes a test case based on the plugin-testing-harness. The patch borrows heavily from site:site-deploy. I won't comment, whether this makes sense or not. I am ready to refactor the patch, should that be required. However, I'd like to have something like a basic "Ok", before doing this additional work. -- 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: (MRESOURCES-111) escapeWindowsPath doesn't work when applying properties
escapeWindowsPath doesn't work when applying properties
---
Key: MRESOURCES-111
URL: http://jira.codehaus.org/browse/MRESOURCES-111
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Jochen Wiedmann
Attachments: mydemo.zip
The attached project contains a property file
"src/test/main/hibernate.properties". I'd like to inject the projects build
path into that file. More precisely, I have a property "jdbc.url" in my
pom.xml, which looks like this:
jdbc:derby:${project.build.directory}/derby-db;create=true
In hibernate.properties, I have
hibernate.connection.url=${jdbc.url}
Which resolves to
hibernate.connection.url=jdbc:derby:C:\workspace\mydemo\target/derby-db;create=true
which is invalid, because the backslashes aren't escaped.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-208) Implicit dependencies are not resolved when using make-artifacts with stripQualifier=false
[ http://jira.codehaus.org/browse/MECLIPSE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186784#action_186784 ] Jochen Wiedmann commented on MECLIPSE-208: -- Workaround: Use the -DstripQualifier=true parameter. Maps the version numbers from 3.5.0-vSomething to 3.5.0. > Implicit dependencies are not resolved when using make-artifacts with > stripQualifier=false > -- > > Key: MECLIPSE-208 > URL: http://jira.codehaus.org/browse/MECLIPSE-208 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 > Environment: Windows XP, Eclipse 3.3 M4 >Reporter: Chad Moats > Attachments: MECLIPSE-208-maven-eclipse-plugin.patch, > MECLIPSE-208-maven-eclipse-plugin.patch > > > When using qualifiers with the make-artifacts goal, implict dependencies > cannot be resolved because they fall outside the version range used. This > issue was found when trying to deploy Eclipse 3.3 M4 to my local repository > while retaining the qualifier. For example, the org.eclipse.core.runtime pom > that is gernerated states that it depends on org.eclipse.equinox.app using > the range of [1.0.0,2.0.0). The actual version number of the > org.eclipse.equinox.app is 1.0.0-v. Using a qualifier means that the > version actually falls before the 1.0.0-2.0.0 range. The following error is > logged: > Couldn't find a version in [1.0.0-v20061208] to match range [1.0.0,2.0.0) > org.eclipse.equinox:org.eclipse.equinox.app:jar:null -- 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: (MANTRUN-91) Cannot run javac from tasks
[ http://jira.codehaus.org/browse/MANTRUN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161653#action_161653 ] Jochen Wiedmann commented on MANTRUN-91: Carlos, I disagree with your diagnosis. The antrun plugin should try to mimick the behaviour of Ant as much as possible. Autodetecting the javac compiler is an important part of that behaviour. The requirement to specify dependencies via plugin configuration makes sense in the case of custom tasks: With native Ant, one would have to specify -lib options or do something similar, so its okay to require configuration. With tools.jar, the case is different. > Cannot run javac from tasks > --- > > Key: MANTRUN-91 > URL: http://jira.codehaus.org/browse/MANTRUN-91 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Reporter: Thomas Diesler >Assignee: Carlos Sanchez > > Embedded error: The following error occurred while executing this line: > /home/tdiesler/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/scripts/antrun-wstools.xml:65: > Unable to find a javac compiler; > com.sun.tools.javac.Main is not on the classpath. > Perhaps JAVA_HOME does not point to the JDK -- 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: (MASSEMBLY-261) Use plexus-archiver 1.0-alpha-10
Use plexus-archiver 1.0-alpha-10 Key: MASSEMBLY-261 URL: http://jira.codehaus.org/browse/MASSEMBLY-261 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Attachments: maven-assembly-plugin-resources.patch Quoting PLXCOMP-88: The handling of ArchivedFileSet is currently extremely slow: The archive is extracted to a temporary directory where the usual archiver logic is being applied. A considerable speed improvement could be achieved by replacing the FileSet internally with the PlexusIoResourceCollection. This would allow to select files (aka resources) within the archive file. Additionally, this setup would allow to include content filters and file name mappers (see the respective Ant types), thus modifying the archive contents on the fly. -- 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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated WAGON-82: - Attachment: 0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch Updated patch for the artifact manager to use the wagon ProxyInfoProvider. Note, that it is possibly to apply this patch later on. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Assignee: Brett Porter >Priority: Blocker > Attachments: > 0001-Added-the-ProxyInfoProvider-interface-in-order-to-fi.patch, > 0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch, > WAGON-82-maven-artifact-manager.patch, > WAGON-82-tested-maven-artifact-manager.patch, WAGON-82-tested-wagon.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- 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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated WAGON-82: - Attachment: 0001-Added-the-ProxyInfoProvider-interface-in-order-to-fi.patch Updated patch for WAGON, created using git. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Assignee: Brett Porter >Priority: Blocker > Attachments: > 0001-Added-the-ProxyInfoProvider-interface-in-order-to-fi.patch, > WAGON-82-maven-artifact-manager.patch, > WAGON-82-tested-maven-artifact-manager.patch, WAGON-82-tested-wagon.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- 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-89) filtering ${something.url} ignores my property value and writes http://maven.apache.org/something
[
http://jira.codehaus.org/browse/MWAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MWAR-89:
Attachment: MWAR-89.patch
Your wish is my command, Stephen. :-)
> filtering ${something.url} ignores my property value and writes
> http://maven.apache.org/something
> -
>
> Key: MWAR-89
> URL: http://jira.codehaus.org/browse/MWAR-89
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.1-alpha-1
>Reporter: Paul Jungwirth
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: example.zip, MWAR-89.patch
>
>
> I have a multimodule build, and one of the modules is a war. That module has
> an artifactId of "aardvark." This is aardvark's pom:
>
> ...
>
> http://anywhere.com/
> whatever
>
> ...
>
>
>
> maven-war-plugin
>
>
>
>${basedir}/src/main/resources
>true
>
>
>
>
>
>
>
> Inside src/main/resources, I have a file that includes both ${something.url}
> and ${another.property}. But when I run maven, ${another.property} is
> filtered correctly, while ${something.url} becomes
> "http://maven.apache.org/aardvark."; It ignores my value and writes a URL to
> apache.org instead, appending the artifactId. Weird, huh? This seems to
> happen with any property that ends in ".url." Is this supposed to be a
> feature? I've never seen it documented anywhere.
> Thanks,
> Paul
--
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-3198) ${basedir} variable makes portable builds overly difficult
[
http://jira.codehaus.org/browse/MNG-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106950
]
Jochen Wiedmann commented on MNG-3198:
--
Note, that you can safely use C:/dev/workspace/... even on Windows. In other
words, the requirement to distinguish between / and \\ will most likely only
be present when running an external batch script or something like that.
However, if you do that, then you are platform dependent anyways and should use
platform specific profiles, in which case file.separator would simply make the
POM unreadable.
> ${basedir} variable makes portable builds overly difficult
> --
>
> Key: MNG-3198
> URL: http://jira.codehaus.org/browse/MNG-3198
> Project: Maven 2
> Issue Type: Bug
> Components: Design, Patterns & Best Practices, Logging, POM,
> POM::Encoding, Profiles
>Affects Versions: 2.0.7
>Reporter: Andrew J. Leer
> Attachments: SimpleTest21.tar, SimpleTest21.zip
>
>
> Using log4j.xml I tried to use the resource filtering mechanism of Maven2 to
> write log files to the directory:
> ${basedir}/logs
> (in windows)
> In the end the log files indeed do end up in the project directory, but not
> the ./log directory.
> Also the name of the log file becomes the path with all of the '\'
> (${file.seprator}'s taken out of it:
> For instance if the path to my log file was:
> "C:\dev\workspace\project\logs\project-1.0-dev_test.log"
> My log file would appear in ${basedir} and be called:
> "devworkspaceprojectlogsproject-1.0-dev_test.log"
> Thank you,
> Andrew J. Leer
--
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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106894 ] Jochen Wiedmann commented on WAGON-82: -- > Firstly, I can't get that change into Maven trunk/branch until wagon would be > released with it's changes. Agreed, but I do not have any idea, how to solve the problem without any API changes. The current API depends on the assumptions that a) there is exactly one protocol being used by the wagon provider and b) the Wagon user is responsible to know which protocol that is. Both assumptions are, IMO, plainly wrong, as the webdav provider obviously demonstrates. > However, the upshot of the patch is that the webdav wagon ignores the proxy > that is passed in. I can't follow you here. The old proxy configuration is still in place and the patch should take care that the old proxy configuration is used, if no ProxyInfo is present. > I think it would be better to take the earlier solution provided by Jochen > where: > a) we fix the wagon manager to pass the correct proxy in (presumably it's > giving dav instead of http - surely we can figure that out), or otherwise You refer to the solution proposed by Joakim, not Jochen? It is up to you to determine whether such an ugly workaround should be installed. My strategy would clearly be to push out a wagon release ASAP (perhaps even a version 1.0-beta-2.1, which could be identical to 1.0-beta-2, apart from this patch) and use that in the Maven core, if 1.0-beta-3-SNAPSHOT is undesirable. > b) pass in all the proxies and let the wagon decide which to use. That is, IMO, exactly, what the ProxyInfo does. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Assignee: Brett Porter >Priority: Blocker > Attachments: WAGON-82-maven-artifact-manager.patch, > WAGON-82-tested-maven-artifact-manager.patch, WAGON-82-tested-wagon.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- 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-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106584 ] Jochen Wiedmann commented on MNG-1682: -- Confirmed, Brett. My test project works fine with 2.0.7. > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows NT; JDK 1.5 >Reporter: Nigel Magnay > Fix For: 2.1 > > Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- 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-1697) Upload freemarker-2.3.10
Upload freemarker-2.3.10 Key: MAVENUPLOAD-1697 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1697 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann FreeMarker is a "template engine"; a generic tool to generate text output based on templates. -- 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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100428 ] Jochen Wiedmann commented on WAGON-82: -- I've got updated versions of the patches ready, which work for me. After testing, I actually wonder whether anyone got dav via proxy working at all, because I found another bug. Even if the proxy is set on the webdavResource, it isn't used, because the resources internal instance of HttpClient isn't updated. I have added a call to webdavResource.closeSession(). I also noticed, that I receive a lot of warnings like WARNING: Default credentials for httpprox.hq.sag not available WARNING: Preemptive proxy authentication failed I would assume that these are related to a superfluous call to setAuthorizationPreemptive() within the webdav library. I didn't bother to track this down, because the warning is nasty, but ignorable. I have attempted to add the updated patches to Jira. Unfortunately, this is currently not possible for me, because I receive an error message whenever I try to attach a file, Please contact me, if you are interested in the updated files. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Priority: Blocker > Attachments: WAGON-82-maven-artifact-manager.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- 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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated WAGON-82: - Attachment: WAGON-82-wagon.patch WAGON-82-maven-artifact-manager.patch Proposed alternative patch. Has yet to be tested. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Priority: Blocker > Attachments: WAGON-82-maven-artifact-manager.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- 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: (WAGON-82) wagon-webdav does not set http-proxy correctly
[
http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99276
]
Jochen Wiedmann commented on WAGON-82:
--
I strongly disagree with the solutions discussed so far. IMO, they are all
basically hacks.
IMO, the actual problem is, that not the wagon provider itself decides on the
use of proxies, but the DefaultWagonManager. It does so, based on the
"protocol". A far better solution would be, either
- to give the proxy settings to the wagon provider and let him decide, whether
to use them or not, or.
The best way to do this would be a new interface, for example
package org.apache.maven.wagon;
public interface ProxyProvider {
/* Returns a proxy for the given protocol, if available, or null.
*/
public ProxyInfo getProxyForProtocol(String protocol);
}
The proxy provider might have a setter for ProxyProvider, which the
DefaultWagonManager might invoke.
- to introduce a new method (for example isProxyInfoRequired(String url)),
which the DefaultWagonManager
uses to query the wagon provider, whether it wants proxy settings or not.
> wagon-webdav does not set http-proxy correctly
> --
>
> Key: WAGON-82
> URL: http://jira.codehaus.org/browse/WAGON-82
> Project: wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 1.0-beta-2
> Environment: any system
>Reporter: Marc Wilhelm
>Priority: Blocker
> Attachments: wagon-webdav.patch
>
>
> Webdav connections through a http-proxy are currently not possible.
> The webdav provider opens first a connection to the target system and checks
> after this, if a proxy should be used.
> To fix this in the method
> "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the
> call "webdavResource = new CorrectedWebdavResource( httpURL );" must be
> changed into "webdavResource = new CorrectedWebdavResource( );" and after
> configuring the http-proxy the method call
> "webdavResource.setHttpURL(httpURL);" must be added.
--
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-2934) Cannot Deploy Using Webdav due to DependencyManagement
[ http://jira.codehaus.org/browse/MNG-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99179 ] Jochen Wiedmann commented on MNG-2934: -- Ok, confirmed, 2.0.7-SNAPSHOT works. I didn't have declared wagon-webdav as an extension. > Cannot Deploy Using Webdav due to DependencyManagement > -- > > Key: MNG-2934 > URL: http://jira.codehaus.org/browse/MNG-2934 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Deployment >Affects Versions: 2.0.6 >Reporter: Stephen Duncan Jr >Assignee: Jason van Zyl > Fix For: 2.0.7 > > Attachments: pom.xml > > > The webdav wagon requires commons-httpclient-2.0.2.jar. If I have a > dependencyManagement section that specifies commons-httpclient 3.0.1, then > deployment fails. > The resulting output is: > [EMAIL PROTECTED] webdavtest]$ mvn deploy > [INFO] Scanning for projects... > [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates > from ce-releases > - > this realm = app0.child-container[extensions] > urls[0] = > file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar > urls[2] = > file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > urls[3] = > file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[4] = > file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > urls[5] = > file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[6] = > file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[7] = > file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar > urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > Number of imports: 0 > this realm = plexus.core > urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar > Number of imports: 0 > - > [INFO] > > [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [site:attach-descriptor] > [INFO] [install:install] > [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to > /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom > [INFO] [deploy:deploy] > altDeploymentRepository = null > [INFO] Retrieving previous build number from snapshots > [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' > could not be retrieved from repository: snapshots due to an error: > Unsupported Protocol: 'dav': Cannot find wagon which supports the requested > protocol: dav > [INFO] Repository 'snapshots' will be blacklisted > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find > wagon which supports the requested protocol: dav > Component descriptor cannot be found in the component repository: > org.apache.maven.wagon.Wagondav. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007 > [INFO] Final Memory: 6M/10M > [INFO] > -- 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-2934) Cannot Deploy Using Webdav due to DependencyManagement
[ http://jira.codehaus.org/browse/MNG-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99174 ] Jochen Wiedmann commented on MNG-2934: -- Is this actually fixed? I still do have the same problem, with 2.0.7-SNAPSHOT as available from Jason's home on people.apache.org with a date of 10-June-2007. > Cannot Deploy Using Webdav due to DependencyManagement > -- > > Key: MNG-2934 > URL: http://jira.codehaus.org/browse/MNG-2934 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Deployment >Affects Versions: 2.0.6 >Reporter: Stephen Duncan Jr >Assignee: Jason van Zyl > Fix For: 2.0.7 > > Attachments: pom.xml > > > The webdav wagon requires commons-httpclient-2.0.2.jar. If I have a > dependencyManagement section that specifies commons-httpclient 3.0.1, then > deployment fails. > The resulting output is: > [EMAIL PROTECTED] webdavtest]$ mvn deploy > [INFO] Scanning for projects... > [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates > from ce-releases > - > this realm = app0.child-container[extensions] > urls[0] = > file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar > urls[2] = > file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > urls[3] = > file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[4] = > file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > urls[5] = > file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[6] = > file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[7] = > file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar > urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > Number of imports: 0 > this realm = plexus.core > urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar > Number of imports: 0 > - > [INFO] > > [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [site:attach-descriptor] > [INFO] [install:install] > [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to > /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom > [INFO] [deploy:deploy] > altDeploymentRepository = null > [INFO] Retrieving previous build number from snapshots > [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' > could not be retrieved from repository: snapshots due to an error: > Unsupported Protocol: 'dav': Cannot find wagon which supports the requested > protocol: dav > [INFO] Repository 'snapshots' will be blacklisted > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find > wagon which supports the requested protocol: dav > Component descriptor cannot be found in the component repository: > org.apache.maven.wagon.Wagondav. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007 > [INFO] Final Memory: 6M/10M > [INFO] > -- 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-2934) Cannot Deploy Using Webdav due to DependencyManagement
[ http://jira.codehaus.org/browse/MNG-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99171 ] Jochen Wiedmann commented on MNG-2934: -- Is this actually fixed? I've got the same problem with 2.0.7-SNAPSHOT, as picked from prople.apache.org/~jvanzyl some minutes ago. > Cannot Deploy Using Webdav due to DependencyManagement > -- > > Key: MNG-2934 > URL: http://jira.codehaus.org/browse/MNG-2934 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Deployment >Affects Versions: 2.0.6 >Reporter: Stephen Duncan Jr >Assignee: Jason van Zyl > Fix For: 2.0.7 > > Attachments: pom.xml > > > The webdav wagon requires commons-httpclient-2.0.2.jar. If I have a > dependencyManagement section that specifies commons-httpclient 3.0.1, then > deployment fails. > The resulting output is: > [EMAIL PROTECTED] webdavtest]$ mvn deploy > [INFO] Scanning for projects... > [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates > from ce-releases > - > this realm = app0.child-container[extensions] > urls[0] = > file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar > urls[2] = > file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > urls[3] = > file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[4] = > file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > urls[5] = > file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[6] = > file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[7] = > file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar > urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > Number of imports: 0 > this realm = plexus.core > urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar > Number of imports: 0 > - > [INFO] > > [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [site:attach-descriptor] > [INFO] [install:install] > [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to > /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom > [INFO] [deploy:deploy] > altDeploymentRepository = null > [INFO] Retrieving previous build number from snapshots > [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' > could not be retrieved from repository: snapshots due to an error: > Unsupported Protocol: 'dav': Cannot find wagon which supports the requested > protocol: dav > [INFO] Repository 'snapshots' will be blacklisted > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find > wagon which supports the requested protocol: dav > Component descriptor cannot be found in the component repository: > org.apache.maven.wagon.Wagondav. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007 > [INFO] Final Memory: 6M/10M > [INFO] > -- 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-1581) Upload rat-lib-0.5
Upload rat-lib-0.5 -- Key: MAVENUPLOAD-1581 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1581 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Release Audit Tool (RAT) is a tool to improve accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. It's reports require interpretation. In response to demands from project quality tool developers, RAT is available as a library suitable for inclusion in tools. This POM describes that library. Note that binary compatibility is not gauranteed between 0.x releases. -- 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-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98096 ] Jochen Wiedmann commented on MNG-728: - Jason, I *have* provided patches to this issue. If you don't like them, that's fine. Simply closing this issue with the lack of patches as a reason doesn't seem sensible to me. > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98020 ] Jochen Wiedmann commented on MNG-728: - I disagree with Jason's decision to close this issue. Let's have a look at Steve's points: 1.) "This setting appears to do nothing on Linux." While this may be so, there is no reason to assume that this won't change. Both Gnome (or maybe GTK, I do not know the details) and KDE offer to configure a proxy. I'd surely hope that the JRE will be able to pick up this settings at some point. 2.) "It is not needed on mac". May be, but if it isn't: Who cares if the property is set? The situation won't get worse? 3.) "It does something on windows, but we do not know what." That's a poor excuse for not using it. I may even go as far as accepting that it shouldn't be switched on by default. But why won't you give me at least the change to try whether it works or not and turn it on for me, if it does? My experiences with the feature are quite converse to Steve's. "Regarding (3), build files that used to work fail with connections using Oracle's JDBC driver hanging. " Sounds questionable to me, but again, this is at most an argument for not turning the feature on by defauilt. "While automatic synchronization between jvm proxy settings and the OS would be a good thing, I am not convinced what is in 1.5.0x is a workable solution. Instead it creates a different set of support calls." Who's talking about 1.5? We already are at 1.6, 1.7 is approaching fast, and we're beginning to see alternative JRE's (Harmony), where "workable solutions" (whatever they are) are more than likely. Again, I am quite happy with using that feature. "Perhaps a better solution would be a commons-proxy-setup project that did proxy configuration properly." And the first task of such a project, IMO, would be to use "useSystemSettings". > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-74) Upgrade maven-archiver dependency to 2.3-SNAPSHOT
Upgrade maven-archiver dependency to 2.3-SNAPSHOT - Key: MJAR-74 URL: http://jira.codehaus.org/browse/MJAR-74 Project: Maven 2.x Jar Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Making use of MNG-2854 should increase the plugins performance. -- 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-56) maven-jar-plugin: Update site documentation from sources
[ http://jira.codehaus.org/browse/MJAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95982 ] Jochen Wiedmann commented on MJAR-56: - The site was updated at 2006-Nov-15. This issue can most likely be closed. > maven-jar-plugin: Update site documentation from sources > > > Key: MJAR-56 > URL: http://jira.codehaus.org/browse/MJAR-56 > Project: Maven 2.x Jar Plugin > Issue Type: Task >Reporter: Marcel May >Priority: Minor > > Please update the maven plugin documentation at > http://maven.apache.org/plugins/maven-jar-plugin/ for the maven jar plugin, > it's quire out of date (Last Published: Sun Oct 16 04:42:06 EST 2005). > Currently contains dead links, too (eg Project Info/Source Repository/Web > Access). > Possibly applies to many other plugins, too. > Sorry if this is not the correct way to trigger a plugin site update ... ? > Thx alot! -- 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-102) Upgrade maven-archiver dependency to 2.3-SNAPSHOT
Upgrade maven-archiver dependency to 2.3-SNAPSHOT - Key: MWAR-102 URL: http://jira.codehaus.org/browse/MWAR-102 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Jochen Wiedmann Making use of MNG-2854 should increase the plugins performance. -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-2854:
-
Attachment: maven-archiver-MNG2854-4.patch
Done.
> Recreating pom.properties always breaks the archivers uptodate check
>
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.5
>Reporter: Jochen Wiedmann
> Attachments: maven-archiver-MNG2854-4.patch,
> maven-archiver-properties-2.patch, maven-archiver-properties-3.patch,
> maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation.
> (Unless the flag "addMavenDescriptor" is set to false, which few people do.)
> This forced recreation makes the uptodate check fail. In other words, jar
> files are always recreated, regardless whether anything was recompiled.
> Obviously, this makes the uptodate check of war files etc. fail as well,
> because the included jar files are always changed.. This is a major drawback,
> because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch
> does:
> - It is obviously bad, that the generated pom.properties file is in the
> projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which
> seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create
> multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the
> pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
> unique.
> - Finally, the patch makes the maven-archiver check, whether the
> pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version
> have changed.)
> It does so, by writing the file to an internal buffer and comparing the
> file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version
> haven't changed, the pom.properties file remains unchanged. In particular,
> the jar file doesn't need to be recreated.
--
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-1523) Upload rome-0.9
Upload rome-0.9 --- Key: MAVENUPLOAD-1523 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1523 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann All Roads Lead to ROME. ROME is a set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats. Today it accepts all flavors of RSS (0.90, 0.91, 0.92, 0.93, 0.94, 1.0 and 2.0) and Atom 0.3 feeds. Rome includes a set of parsers and generators for the various flavors of feeds, as well as converters to convert from one format to another. The parsers can give you back Java objects that are either specific for the format you want to work with, or a generic normalized SyndFeed object that lets you work on with the data without bothering about the underlying format. -- 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-1522) Upload krysalis-barcode 1.0beta
Upload krysalis-barcode 1.0beta --- Key: MAVENUPLOAD-1522 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1522 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Krysalis Barcode is an open source project for generating barcodes with FOP, Xalan, or similar libraries. The upload bundle consists of two files: The above jar file with the krysalis-barcode core and the http://people.apache.org/~jochen/krysalis-barcode-fop-ext-0.20.5-1.0beta-upload.jar Btw, I suggest to complete the guide-ibiblio-upload.html with an instruction of how to upload multiple jar files. The current guide suggests the name pom.xml, which is obviously not suited for uploading multiple files. -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-2854:
-
Attachment: maven-archiver-properties-3.patch
Done.
Thanks for the hint regarding Properties.equals(...). One learns all the time.
Of course, this simplifies the code drastically.
> Recreating pom.properties always breaks the archivers uptodate check
>
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.5
>Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch,
> maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation.
> (Unless the flag "addMavenDescriptor" is set to false, which few people do.)
> This forced recreation makes the uptodate check fail. In other words, jar
> files are always recreated, regardless whether anything was recompiled.
> Obviously, this makes the uptodate check of war files etc. fail as well,
> because the included jar files are always changed.. This is a major drawback,
> because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch
> does:
> - It is obviously bad, that the generated pom.properties file is in the
> projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which
> seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create
> multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the
> pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
> unique.
> - Finally, the patch makes the maven-archiver check, whether the
> pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version
> have changed.)
> It does so, by writing the file to an internal buffer and comparing the
> file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version
> haven't changed, the pom.properties file remains unchanged. In particular,
> the jar file doesn't need to be recreated.
--
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: (MSOURCES-14) Replace maven-verifier with maven-plugin-testing-harness
Replace maven-verifier with maven-plugin-testing-harness Key: MSOURCES-14 URL: http://jira.codehaus.org/browse/MSOURCES-14 Project: Maven 2.x Sources Plugin Issue Type: Bug Affects Versions: 2.0.3 Reporter: Jochen Wiedmann Attachments: maven-source-plugin-harness.patch The test suite of the maven-sources-plugin is currently based on the maven-verifier. This has the undesirable consequence, that the test uses the *installed* version of the maven-sources-plugin, as opposed to the local version. The attached patch replaces the maven-verifier with the maven-plugin-testing-harness, which doesn't suffer from the same problem. Additionally, the speed of the test suite is drastically improved. For reviewers: When considering the patches quality, keep in mind that the actual Mojo classes and the concrete test classes are almost unchanged. (For the latter, there is the required addition of a protected method getGoal().) For reviewers: Note the following comment in AbstractSourcePluginTestCase: * I don't know, why revision 518116 of this class had the parameters * "properties" and "expectNoErrors". The following checks demonstrate, * that the parameters aren't actually used and may safely be removed. * This should be done by the patch reviewer. I recommend that the reviewer follows my suggestion by applying a refactoring method after applying my patch. -- 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-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MNG-1889: - Attachment: maven-no-plugin-descriptors.patch Here's an updated version. Please note, that I had to catch the new exception in the test suite at some point. It mighe be better to remove the final check for size() == 0 in that test. > Plugins without descriptors > --- > > Key: MNG-1889 > URL: http://jira.codehaus.org/browse/MNG-1889 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann >Priority: Minor > Fix For: 2.0.x > > Attachments: maven-no-plugin-descriptors.patch, > numMojoDescriptors.patch > > > The attached patch throws an exception, if no Mojos are found in a plugin. > Background: If such a plugin is installed, then an NPE is caused in the > DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo > descriptors. Obviously, the actual error is in the plugin itself, where it > should be exposed. It took me some hours to find this actual reason. (I still > do not know, why the Mojos aren't found in my plugin, but that's another > story.) The patch should be able to save the same number of hours for other > plugin developers. > Note: The InvalidPluginDescriptorException, which is triggered by the patch, > is possibly not proper. I choosed it, because it allowed to leave the method > signature unchanged and keep the patch simple. It is up to the reviewer to > choose another exception. -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-2854:
-
Attachment: maven-archiver-properties-2.patch
Ok, here's an updated version of the patch. Note, that it contains a test case
(MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed
created when invoked for the first time, but isn't for the second time.
> Recreating pom.properties always breaks the archivers uptodate check
>
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.5
>Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch,
> maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation.
> (Unless the flag "addMavenDescriptor" is set to false, which few people do.)
> This forced recreation makes the uptodate check fail. In other words, jar
> files are always recreated, regardless whether anything was recompiled.
> Obviously, this makes the uptodate check of war files etc. fail as well,
> because the included jar files are always changed.. This is a major drawback,
> because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch
> does:
> - It is obviously bad, that the generated pom.properties file is in the
> projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which
> seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create
> multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the
> pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
> unique.
> - Finally, the patch makes the maven-archiver check, whether the
> pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version
> have changed.)
> It does so, by writing the file to an internal buffer and comparing the
> file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version
> haven't changed, the pom.properties file remains unchanged. In particular,
> the jar file doesn't need to be recreated.
--
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-69) Secondary artifacts aren't being attached
[
http://jira.codehaus.org/browse/MWAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90347
]
Jochen Wiedmann commented on MWAR-69:
-
The source has changed and it seems that the change has cured the issue. I can
no longer reproduce the problem. (No, I didn't use a classifier.)
> Secondary artifacts aren't being attached
> -
>
> Key: MWAR-69
> URL: http://jira.codehaus.org/browse/MWAR-69
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Reporter: Jochen Wiedmann
> Assigned To: Stephane Nicoll
> Attachments: maven-secondary-artifact.patch
>
>
> If I do configure the maven-war-plugin to create a secondary artifact, then
> that artifact isn't attached. I do believe, this is because the following
> code snippet is missing:
> Index: src/main/java/org/apache/maven/plugin/war/WarMojo.java
> ===
> --- src/main/java/org/apache/maven/plugin/war/WarMojo.java (revision
> 433193)
> +++ src/main/java/org/apache/maven/plugin/war/WarMojo.java (working copy)
> @@ -192,6 +192,10 @@
> {
> artifact.setFile( warFile );
> }
> +else
> +{
> + projectHelper.attachArtifact( getProject(). "war", warFile );
> +}
> }
> }
> }
--
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-89) filtering ${something.url} ignores my property value and writes http://maven.apache.org/something
[
http://jira.codehaus.org/browse/MWAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90345
]
Jochen Wiedmann commented on MWAR-89:
-
The problem is by no means related to using src/main/resources. I observe this
in src/main/filtered-webapp.
> filtering ${something.url} ignores my property value and writes
> http://maven.apache.org/something
> -
>
> Key: MWAR-89
> URL: http://jira.codehaus.org/browse/MWAR-89
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Paul Jungwirth
> Assigned To: Stephane Nicoll
>Priority: Minor
>
> I have a multimodule build, and one of the modules is a war. That module has
> an artifactId of "aardvark." This is aardvark's pom:
>
> ...
>
> http://anywhere.com/
> whatever
>
> ...
>
>
>
> maven-war-plugin
>
>
>
>${basedir}/src/main/resources
>true
>
>
>
>
>
>
>
> Inside src/main/resources, I have a file that includes both ${something.url}
> and ${another.property}. But when I run maven, ${another.property} is
> filtered correctly, while ${something.url} becomes
> "http://maven.apache.org/aardvark."; It ignores my value and writes a URL to
> apache.org instead, appending the artifactId. Weird, huh? This seems to
> happen with any property that ends in ".url." Is this supposed to be a
> feature? I've never seen it documented anywhere.
> Thanks,
> Paul
--
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-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89094 ] Jochen Wiedmann commented on MNG-2301: -- Please note MNG-2854 (I have created a new bug report, because my issue is the failing uptodate check, which isn't necessarily the same problem than here. Additionally, the suggested solutions are quite different. Nevertheless, it should be possible to close either MNG-2854 (this issue) or MNG-2301 as a duplicate of the other. > Maven Archiver deleteing already existing pom.properties file. > -- > > Key: MNG-2301 > URL: http://jira.codehaus.org/browse/MNG-2301 > Project: Maven 2 > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.0.4 >Reporter: Sharmarke Aden > Fix For: 2.0.x > > Attachments: maven-archiver_pomDelete.patch > > > My project has it's own pom.properties file and it seems that maven archiver > is deleting it right after packaging the application. Any particular reason > why it's doing this? It seems to me the archiver shouldn't be deleting the > file if it already exists. It should delete the file if it doesn't exists > otherwise it should add the necessary information (version, groupId, etc) to > the file and leave it be. I have attached a patch that fixes the issue. > Also note that this patch adds the "builtOn" property to the pom.properties > which is satisfy the following enhancement request: > http://jira.codehaus.org/browse/MNG-1830 -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
Recreating pom.properties always breaks the archivers uptodate check
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation.
(Unless the flag "addMavenDescriptor" is set to false, which few people do.)
This forced recreation makes the uptodate check fail. In other words, jar files
are always recreated, regardless whether anything was recompiled. Obviously,
this makes the uptodate check of war files etc. fail as well, because the
included jar files are always changed.. This is a major drawback, because it
makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch
does:
- It is obviously bad, that the generated pom.properties file is in the
projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which
seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create multiple
artifacts. In other
words, it isn't good to have a single file. The patch renames the
pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
unique.
- Finally, the patch makes the maven-archiver check, whether the pom.properties
file has
actually changed. (In other words, whether groupId, artifactId, or version
have changed.)
It does so, by writing the file to an internal buffer and comparing the file
on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version
haven't changed, the pom.properties file remains unchanged. In particular, the
jar file doesn't need to be recreated.
--
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-89) filtering ${something.url} ignores my property value and writes http://maven.apache.org/something
[
http://jira.codehaus.org/browse/MWAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88141
]
Jochen Wiedmann commented on MWAR-89:
-
That looks like a very nice simplification. :-)
> filtering ${something.url} ignores my property value and writes
> http://maven.apache.org/something
> -
>
> Key: MWAR-89
> URL: http://jira.codehaus.org/browse/MWAR-89
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Paul Jungwirth
>Priority: Minor
>
> I have a multimodule build, and one of the modules is a war. That module has
> an artifactId of "aardvark." This is aardvark's pom:
>
> ...
>
> http://anywhere.com/
> whatever
>
> ...
>
>
>
> maven-war-plugin
>
>
>
>${basedir}/src/main/resources
>true
>
>
>
>
>
>
>
> Inside src/main/resources, I have a file that includes both ${something.url}
> and ${another.property}. But when I run maven, ${another.property} is
> filtered correctly, while ${something.url} becomes
> "http://maven.apache.org/aardvark."; It ignores my value and writes a URL to
> apache.org instead, appending the artifactId. Weird, huh? This seems to
> happen with any property that ends in ".url." Is this supposed to be a
> feature? I've never seen it documented anywhere.
> Thanks,
> Paul
--
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-89) filtering ${something.url} ignores my property value and writes http://maven.apache.org/something
[
http://jira.codehaus.org/browse/MWAR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88128
]
Jochen Wiedmann commented on MWAR-89:
-
The reason for this bug is in the use of the "CompositeMap" for filtering. The
"CompositeMap" is basically a special Map, which works like this:
- Query the Project in a "magic" way for the property. If something non-null is
returned, that's the result value.
- Otherwise, query the projects properties and return the result.
The "magic" way is implemented by a utility class called
ReflectionValueExtractor. The first thing this class does is removing any part
of the property name until and including a dot. In other words, the lookup for
"something.url" becomes a lookup for "url". That's of course a valid value. In
other words, a possible workaround is to change your property name to
"something_url" and everything should work fine.
I find the behaviour of ReflectionValueExtractor (or the use of it) quite
questionable. Basically this means that ${whatever.foo} becomes ${project.foo}.
In other words, the use of the dot (which is quite common if not recommended in
property names) becomes almost imopssible.
I'd recommend to
- change the implementation of CompositeMap so that it accepts an array of
Maps, rather than two Maps.
- Instantiate the CompositeMap with the following values, in that order:
project.getProperties()
ReflectionMap(project)
System.getProperties()
I am ready to provide a patch, should I know that my suggestion will be
accepted.
my re
> filtering ${something.url} ignores my property value and writes
> http://maven.apache.org/something
> -
>
> Key: MWAR-89
> URL: http://jira.codehaus.org/browse/MWAR-89
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Paul Jungwirth
>Priority: Minor
>
> I have a multimodule build, and one of the modules is a war. That module has
> an artifactId of "aardvark." This is aardvark's pom:
>
> ...
>
> http://anywhere.com/
> whatever
>
> ...
>
>
>
> maven-war-plugin
>
>
>
>${basedir}/src/main/resources
>true
>
>
>
>
>
>
>
> Inside src/main/resources, I have a file that includes both ${something.url}
> and ${another.property}. But when I run maven, ${another.property} is
> filtered correctly, while ${something.url} becomes
> "http://maven.apache.org/aardvark."; It ignores my value and writes a URL to
> apache.org instead, appending the artifactId. Weird, huh? This seems to
> happen with any property that ends in ".url." Is this supposed to be a
> feature? I've never seen it documented anywhere.
> Thanks,
> Paul
--
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-1341) Upload rat-lib-0.4.1
Upload rat-lib-0.4.1 Key: MAVENUPLOAD-1341 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1341 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann Public release of RAT, the Release Audit Tool -- 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-1315) Upload antlr-3.0b5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1315?page=comments#action_84905 ] Jochen Wiedmann commented on MAVENUPLOAD-1315: -- Sorry! Fixed. > Upload antlr-3.0b5 > -- > > Key: MAVENUPLOAD-1315 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1315 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > > The AntLR Parser Generator, version 3.0b5 > Note: No dependencies, standalone jar file. > Note: Using the "org.antlr" groupId, which is in use for version 3, although > version 2 used "antlr". -- 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-1314) Upload antlr-2.7.7
Upload antlr-2.7.7 -- Key: MAVENUPLOAD-1314 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1314 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann The AntLR Parser Generator, version 2.7.7 Note: No dependencies, standalone jar file. Note: Using the "antlr" groupId, which has been used for all jar files of version 2. Will use "org.antlr" for version 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1315) Upload antlr-3.0b5
Upload antlr-3.0b5 -- Key: MAVENUPLOAD-1315 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1315 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann The AntLR Parser Generator, version 3.0b5 Note: No dependencies, standalone jar file. Note: Using the "org.antlr" groupId, which is in use for version 3, although version 2 used "antlr". -- 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-1313) Upload stringtemplates-3.0
Upload stringtemplates-3.0 -- Key: MAVENUPLOAD-1313 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1313 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann Stringtemplate is a template library based on and using the AntLR project. -- 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-1158) WSDL4J 1.6.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1158?page=comments#action_78021 ] Jochen Wiedmann commented on MAVENUPLOAD-1158: -- Please consider using http://people.apache.org/~jochen/wsdl4j-1.6.1-upload.jar instead. It contains the POM from 1.5.3, the sources and the javadoc jar as well. > WSDL4J 1.6.1 > > > Key: MAVENUPLOAD-1158 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1158 > Project: maven-upload-requests > Issue Type: Task >Reporter: maomaode > > http://people.apache.org/~ningjiang/m2/repository/wsdl4j/1.6.1/wsdl4j-1.6.1-bundle.jar > http://wsdl4j.sourceforge.net > http://sourceforge.net/project/memberlist.php?group_id=128811 > The Web Services Description Language for Java Toolkit (WSDL4J) allows the > creation, representation, and manipulation of WSDL documents. Is the > reference implementation for JSR110 'JWSDL' (jcp.org). Post questions/bugs to > [EMAIL PROTECTED] Please upload. -- 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-1159) WSDL4J-QNAME 1.6.1 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1159?page=comments#action_78020 ] Jochen Wiedmann commented on MAVENUPLOAD-1159: -- Please consider using http://people.apache.org/~jochen/wsdl4j-qname-1.6.1-upload.jar instead. It contains the POM from 1.5.3 and a the sources. > WSDL4J-QNAME 1.6.1 upload > - > > Key: MAVENUPLOAD-1159 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1159 > Project: maven-upload-requests > Issue Type: Sub-task >Reporter: maomaode > > http://people.apache.org/~ningjiang/m2/repository/wsdl4j/1.6.1/wsdl4j-qname-1.6.1-bundle.jar > > http://wsdl4j.sourceforge.net > http://sourceforge.net/project/memberlist.php?group_id=128811 > The Web Services Description Language for Java Toolkit (WSDL4J) allows the > creation, representation, and manipulation of WSDL documents. Is the > reference implementation for JSR110 'JWSDL' (jcp.org). Post questions/bugs to > [EMAIL PROTECTED] Please upload. -- 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-1133) Upload wsdl4j-1.5.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1133?page=comments#action_75320 ] Jochen Wiedmann commented on MAVENUPLOAD-1133: -- The -qname is yet another implementation of javax.xml.QName, like numerous others. As of Java 5, this class is part of the J2SE. I could list it as a dependency, but my personal feeling is "scope=provided", so I won't. If you insist, I change the POM of wsdl4j in that sense. > Upload wsdl4j-1.5.3 > --- > > Key: MAVENUPLOAD-1133 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1133 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Jochen Wiedmann > > Please upload > http://people.apache.org/~jochen/wsdl4j-1.5.3-upload.jar > http://people.apache.org/~jochen/wsdl4j-qname-1.5.3-upload.jar > (Note the second upload bundle!) -- 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-1133) Upload wsdl4j-1.5.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1133?page=comments#action_75027 ] Jochen Wiedmann commented on MAVENUPLOAD-1133: -- A JAXP compliant XML parser, which is nothing I'd list as a dependency. > Upload wsdl4j-1.5.3 > --- > > Key: MAVENUPLOAD-1133 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1133 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Jochen Wiedmann > > Please upload > http://people.apache.org/~jochen/wsdl4j-1.5.3-upload.jar > http://people.apache.org/~jochen/wsdl4j-qname-1.5.3-upload.jar > (Note the second upload bundle!) -- 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-1133) Upload wsdl4j-1.5.3
Upload wsdl4j-1.5.3 --- Key: MAVENUPLOAD-1133 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1133 Project: maven-upload-requests Issue Type: Wish Reporter: Jochen Wiedmann Please upload http://people.apache.org/~jochen/wsdl4j-1.5.3-upload.jar http://people.apache.org/~jochen/wsdl4j-qname-1.5.3-upload.jar (Note the second upload bundle!) -- 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: (MCHANGES-57) How does the plugin know what issues were fixed in this version?
[ http://jira.codehaus.org/browse/MCHANGES-57?page=all ] Jochen Wiedmann updated MCHANGES-57: Attachment: MCHANGES-57.patch Suggested patch. Note, that I have changed the plugins default behaviour: For non-snapshot versions the parameter "fixfor" is now being set to the projects version. For snapshot versions it is left unchanged. This default behaviour is, of course, discussable. > How does the plugin know what issues were fixed in this version? > > > Key: MCHANGES-57 > URL: http://jira.codehaus.org/browse/MCHANGES-57 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Reporter: Dennis Lundberg > Attachments: MCHANGES-57.patch > > > From the user-list: > I was able to configure the maven-changes plugin for JIRA, but how to > generate a report. > My basic question is: how does maven/svn know what issues got fixes as part > of checkin? Does the developer need to mention this data in some xml file. > I have read somewhere that if you configure JIRA as the issue > management tool, it should pull automatically... I don't get that. Any > clues? -- 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-179) Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml or xdoc/x.xml).
[ http://jira.codehaus.org/browse/MSITE-179?page=comments#action_74001 ] Jochen Wiedmann commented on MSITE-179: --- A small sample project demonstrating the problem would be helpful. > Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml > or xdoc/x.xml). > --- > > Key: MSITE-179 > URL: http://jira.codehaus.org/browse/MSITE-179 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Bernhard Wellhöfer > > Each XML document defines the used encoding. The maven-site-plugin ignores > this encoding and always uses the value of the inputEncoding configuration > value. The inputEncoding value should only be used for the non XML site files. -- 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-1035) POM for wstx-asl-2.9.3 is missing
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1035?page=all ] Jochen Wiedmann updated MAVENUPLOAD-1035: - Attachment: wstx-asl-2.9.3.jar Uploading a new POM with license and dependency informations. > POM for wstx-asl-2.9.3 is missing > - > > Key: MAVENUPLOAD-1035 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1035 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Jochen Wiedmann > Attachments: wstx-asl-2.9.3.jar > > > The directory > http://repo1.maven.org/maven2/woodstox/wstx-asl/2.9.3 > does not contain a POM. This jar file is referenced by popular applications > like Axis2-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: (MWAR-57) Unable to add custom manifest entries to war file via the pom.xml
[ http://jira.codehaus.org/browse/MWAR-57?page=comments#action_72997 ]
Jochen Wiedmann commented on MWAR-57:
-
I do believe, that this issue may be closed: See patch
http://jira.codehaus.org/secure/attachment/21061/MJAR-38.patch to issue MJAR-38
. (Note, that this patch is against the maven archiver, which is used
internally by the maven-war-plugin. Also note, that the svn version of the
maven-war-plugin is indeed using the maven-archiver version 2.1.)
> Unable to add custom manifest entries to war file via the pom.xml
> -
>
> Key: MWAR-57
> URL: http://jira.codehaus.org/browse/MWAR-57
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Windows XP SP2
> Sun JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
> Fix For: 2.0.2
>
>
> Configure custom manifest entries as in
> http://maven.apache.org/guides/mini/guide-manifest.html:
>
> maven-war-plugin
> 2.0.1
>
>
>
> development
> ${pom.url}
>
>
>
>
> Get error in build:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling WAR
> Embedded error: The attribute "mode" may not occur more than once in the same
> section
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling
> WAR
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:135)
> 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.jar.ManifestException: The attribute
> "mode" may not occur more than once in the same section
> at
> org.codehaus.plexus.archiver.jar.Manifest$Section.addAttributeAndCheck(Manifest.java:727)
> at
> org.codehaus.plexus.archiver.jar.Manifest$Section.addConfiguredAttribute(Manifest.java:658)
> at
> org.codehaus.plexus.archiver.jar.Manifest.addConfiguredAttribute(Manifest.java:1000)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:354)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:177)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:127)
> ... 18 more
> The same duplicate attribute exception occurs regardless of the name of the
> manifest entry.
> Works OK in 2.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/softwar
[jira] Updated: (MJAR-7) jar plugin recreates jar files all the time
[ http://jira.codehaus.org/browse/MJAR-7?page=all ] Jochen Wiedmann updated MJAR-7: --- Attachment: maven-jar-plugin-20060821.patch maven-archiver-20060821-2.patch Suggested patches to introduce a parameter "forced" into the maven-jar-plugin, which is configurable through a property "maven.build.forced". > jar plugin recreates jar files all the time > --- > > Key: MJAR-7 > URL: http://jira.codehaus.org/browse/MJAR-7 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Reporter: Jochen Wiedmann > Attachments: maven-archiver-20060821-2.patch, > maven-archiver-20060821.patch, maven-jar-plugin-20060821.patch, > plexus-archiver-up2date.patch > > > The jar plugin doesn't seem to check, whether rebuilding a jar file is > actually required. For daily work, it would be faster to do what Ant's "jar" > task does: Compare the timestamps of the input files with the timestamp of > the target file. > While this approach has the obvious advantage of being safe (and thus > possibly well choosen as a default), it is not appropriate for large > projects, where a single build requires a real lot of jar files being > rebuilt, even if only a single source file has been changed. This applies, in > particular, because comparable plugins like the war, ear, and assembly plugin > are forced to behave in the same manner. > Suggestion: > - Introduce a new property, for example "maven.build.force". The main idea of > the property would > be, that other plugins (install, war, assembly, ...) would listen to the > same property. While they > would possible ignore it initially, one could add support later on. > - The default property value would be true. > - If the property value is set to false, then the jar plugin compares the > timestamps of the input files with > the timestamp of the output file. If the latter is newer than the input > timestamps, then the jar file isn't > being rebuilt. > I am ready to provide a patch, if my suggestion should find interest. -- 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-7) jar plugin recreates jar files all the time
[ http://jira.codehaus.org/browse/MJAR-7?page=all ] Jochen Wiedmann updated MJAR-7: --- Attachment: maven-archiver-20060821.patch Suggested patch for the maven-archiver, depends on PLX-226. > jar plugin recreates jar files all the time > --- > > Key: MJAR-7 > URL: http://jira.codehaus.org/browse/MJAR-7 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Reporter: Jochen Wiedmann > Attachments: maven-archiver-20060821.patch, > plexus-archiver-up2date.patch > > > The jar plugin doesn't seem to check, whether rebuilding a jar file is > actually required. For daily work, it would be faster to do what Ant's "jar" > task does: Compare the timestamps of the input files with the timestamp of > the target file. > While this approach has the obvious advantage of being safe (and thus > possibly well choosen as a default), it is not appropriate for large > projects, where a single build requires a real lot of jar files being > rebuilt, even if only a single source file has been changed. This applies, in > particular, because comparable plugins like the war, ear, and assembly plugin > are forced to behave in the same manner. > Suggestion: > - Introduce a new property, for example "maven.build.force". The main idea of > the property would > be, that other plugins (install, war, assembly, ...) would listen to the > same property. While they > would possible ignore it initially, one could add support later on. > - The default property value would be true. > - If the property value is set to false, then the jar plugin compares the > timestamps of the input files with > the timestamp of the output file. If the latter is newer than the input > timestamps, then the jar file isn't > being rebuilt. > I am ready to provide a patch, if my suggestion should find interest. -- 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-69) Secondary artifacts aren't being attached
Secondary artifacts aren't being attached
-
Key: MWAR-69
URL: http://jira.codehaus.org/browse/MWAR-69
Project: Maven 2.x War Plugin
Issue Type: Bug
Reporter: Jochen Wiedmann
Attachments: maven-secondary-artifact.patch
If I do configure the maven-war-plugin to create a secondary artifact, then
that artifact isn't attached. I do believe, this is because the following code
snippet is missing:
Index: src/main/java/org/apache/maven/plugin/war/WarMojo.java
===
--- src/main/java/org/apache/maven/plugin/war/WarMojo.java (revision
433193)
+++ src/main/java/org/apache/maven/plugin/war/WarMojo.java (working copy)
@@ -192,6 +192,10 @@
{
artifact.setFile( warFile );
}
+else
+{
+ projectHelper.attachArtifact( getProject(). "war", warFile );
+}
}
}
}
--
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-2499) Attach sources to maven-plugin-testing-harness
Attach sources to maven-plugin-testing-harness -- Key: MNG-2499 URL: http://jira.codehaus.org/browse/MNG-2499 Project: Maven 2 Issue Type: Improvement Components: Plugin Creation Tools Reporter: Jochen Wiedmann Attachments: maven-plugin-testing-harness-source.patch Sorry, if this should be the wrong project or component, but I was unable to find any better. Please attach sources to the maven-plugin-testing-harness. It helps a lot when understanding the plugins error messages. Patch is 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: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
[ http://jira.codehaus.org/browse/MSUREFIRE-131?page=comments#action_72232
]
Jochen Wiedmann commented on MSUREFIRE-131:
---
For whatever reason, this problem doesn't seem to apply to version 2.3-SNAPSHOT
of the maven-surefire-plugin.
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: MSUREFIRE-131
> URL: http://jira.codehaus.org/browse/MSUREFIRE-131
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Philip Gerlach
> Fix For: 2.3
>
> Attachments: commons-events-pom.xml,
> maven-surefire-junit-trunk-412516.patch
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
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-42) Add LICENCE and NOTICE files to the jar
[ http://jira.codehaus.org/browse/MJAR-42?page=comments#action_72130 ] Jochen Wiedmann commented on MJAR-42: - I'd like to recall that Maven is an Apache project. In other words, if there is something like "Apache-specific", then the "Maven standard" should at least make it possible to follow. Additionally, I'd like to point out a problem with Bretts suggestion to use the mechanism: If I do specify a resource, which lives in the base directory, then I'll encounter problems while building a source jar: The maven-source-plugin will include my whole project into the jar file. (This may be a bug in the maven-source-plugin, I am unsure what to think of it.) > Add LICENCE and NOTICE files to the jar > --- > > Key: MJAR-42 > URL: http://jira.codehaus.org/browse/MJAR-42 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Jeremy Boynes > Attachments: mvn-jar-patch.txt > > > Patch attached that adds project LICENSE and NOTICE files into the output > jar. By default it will add LICENSE.txt and NOTICE.txt files from the > project's basedir (if they are present) into the META-INF directory of the > 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] Created: (MAVENUPLOAD-1038) Upload neethi-1.0.1
Upload neethi-1.0.1 --- Key: MAVENUPLOAD-1038 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1038 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Neethi 1.0.1 is used by popular packages like Axis2-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] Closed: (MAVENUPLOAD-1037) Upload neethi-1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1037?page=all ] Jochen Wiedmann closed MAVENUPLOAD-1037. Resolution: Incomplete Sorry, I have picked the wrong version number. Recreating this request with 1.0.1. > Upload neethi-1.0 > - > > Key: MAVENUPLOAD-1037 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1037 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Jochen Wiedmann > > Neethi 1.0 is used by popular packages like Axis2-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] Created: (MAVENUPLOAD-1037) Upload neethi-1.0
Upload neethi-1.0 - Key: MAVENUPLOAD-1037 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1037 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Neethi 1.0 is used by popular packages like Axis2-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] Created: (MAVENUPLOAD-1036) Upload axiom-1.0
Upload axiom-1.0 Key: MAVENUPLOAD-1036 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1036 Project: maven-upload-requests Issue Type: Improvement Reporter: Jochen Wiedmann Axiom 1.0 is used by popular packages like Axis2-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] Created: (MAVENUPLOAD-1035) POM for wstx-asl-2.9.3 is missing
POM for wstx-asl-2.9.3 is missing - Key: MAVENUPLOAD-1035 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1035 Project: maven-upload-requests Issue Type: Bug Reporter: Jochen Wiedmann The directory http://repo1.maven.org/maven2/woodstox/wstx-asl/2.9.3 does not contain a POM. This jar file is referenced by popular applications like Axis2-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: (MCHANGES-50) Handle JIRA authentication failure
[ http://jira.codehaus.org/browse/MCHANGES-50?page=comments#action_70708 ] Jochen Wiedmann commented on MCHANGES-50: - Mike, are you sure about the 500 error? If so, then Jira behaves very unfortunate, as 500 is "Internal Server Error", which is more than unusual for authentication requests. Besides, please note that I could not find any problems with http://jira.webifysolutions.com/ as a Jira server. (See the attached test project.) > Handle JIRA authentication failure > -- > > Key: MCHANGES-50 > URL: http://jira.codehaus.org/browse/MCHANGES-50 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-2 >Reporter: Mike Perham > Assigned To: Dennis Lundberg > Fix For: 2.0-beta-2 > > Attachments: MCHANGES-50.tar.gz > > > Private instances of JIRA require authentication. If the changes report > queries this server, the server returns a HTML 500 error page, rather than > the expected XML content and the changes plugin throws an exception. This > case should be handled and a warning printed to the screen (maybe with a hint > as to the parameter(s) they need to set) so the site generation can continue. > See http://jira.webifysolutions.com for instance. You can use this URL for > one-off testing of this fix. -- 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: (MCHANGES-50) Handle JIRA authentication failure
[ http://jira.codehaus.org/browse/MCHANGES-50?page=all ] Jochen Wiedmann updated MCHANGES-50: Attachment: MCHANGES-50.tar.gz Mike, I have tried to reproduce your problem, using the attached test project, but could not. Could you please be more specific how to reproduce it? > Handle JIRA authentication failure > -- > > Key: MCHANGES-50 > URL: http://jira.codehaus.org/browse/MCHANGES-50 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-2 >Reporter: Mike Perham > Assigned To: Dennis Lundberg > Fix For: 2.0-beta-2 > > Attachments: MCHANGES-50.tar.gz > > > Private instances of JIRA require authentication. If the changes report > queries this server, the server returns a HTML 500 error page, rather than > the expected XML content and the changes plugin throws an exception. This > case should be handled and a warning printed to the screen (maybe with a hint > as to the parameter(s) they need to set) so the site generation can continue. > See http://jira.webifysolutions.com for instance. You can use this URL for > one-off testing of this fix. -- 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: (MASSEMBLY-109) Assembly task does not include deeper nested modules
[ http://jira.codehaus.org/browse/MASSEMBLY-109?page=all ] Jochen Wiedmann updated MASSEMBLY-109: -- Attachment: assembly-modules-problem.tar.bz2 Reduced test project, which exhibits the same problem. The suggested workaround to use a package phase doesn't work. > Assembly task does not include deeper nested modules > --- > > Key: MASSEMBLY-109 > URL: http://jira.codehaus.org/browse/MASSEMBLY-109 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Linux, Sun jdk 5.0 >Reporter: gunter zeilinger > Fix For: 2.2 > > Attachments: assembly-modules-problem.tar.bz2, > scratch-assembly.tar.bz2 > > > If one of the modules of the root pom is itself a "pom" packaging project, > specifying > > > > lib > true > false > > > > in the descriptor fails with > [INFO] Included module: dcm4che:dcm4che-tool:pom:1 does not have an artifact > with a file. Please ensure the package phase is run before the assembly is > generated. > Excluding it by (e.g.) > > > > dcm4che:dcm4che-tool > > : > excludes also the artifacts from its sub-modules. > Also listing such deeper nested modules by its groupId:artifactId as > (e.g:) > > > > dcm4che:dcm4che-tool-dcm2txt > dcm4che:dcm4che-tool-dcm2xml > dcm4che:dcm4che-tool-pdf2dcm > dcm4che:dcm4che-tool-xml2dcm > : > does not help. -- 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: (MCOMPILER-40) Add enableassertions property
[ http://jira.codehaus.org/browse/MCOMPILER-40?page=all ] Jochen Wiedmann closed MCOMPILER-40. Resolution: Fixed Fool that I am! I just understood that enableassertions is a property of "java", not "javac"! > Add enableassertions property > - > > Key: MCOMPILER-40 > URL: http://jira.codehaus.org/browse/MCOMPILER-40 > Project: Maven 2.x Compiler Plugin > Issue Type: New Feature >Reporter: Jochen Wiedmann > Attachments: maven-compiler-plugin-assertions.patch > > > The attached patch adds a property "enableAssertions" to the maven compiler > plugin. > Note, that assertions are a construct which can be found in multiple > languages. In other words, adding the property would be no harm to the > language independent approach of the maven-compiler-plugin. > This feature request depends on PLX-246. -- 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: (MCOMPILER-40) Add enableassertions property
Add enableassertions property - Key: MCOMPILER-40 URL: http://jira.codehaus.org/browse/MCOMPILER-40 Project: Maven 2.x Compiler Plugin Issue Type: New Feature Reporter: Jochen Wiedmann Attachments: maven-compiler-plugin-assertions.patch The attached patch adds a property "enableAssertions" to the maven compiler plugin. Note, that assertions are a construct which can be found in multiple languages. In other words, adding the property would be no harm to the language independent approach of the maven-compiler-plugin. This feature request depends on PLX-246. -- 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=all ] Jochen Wiedmann updated MAVENUPLOAD-966: Attachment: retroweaver-rt-1.2.3.jar retroweaver-1.2.3.jar Attaching new upload archives for retroweaver-1.2.3.jar and retroweaver-rt-1.2.3.jar. The groupId is now changed to net.sourceforge.retroweaver. > Upload Retroweaver 1.2.3 > > > Key: MAVENUPLOAD-966 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > Attachments: retroweaver-1.2.3-upload.jar, retroweaver-1.2.3.jar, > retroweaver-rt-1.2.3.jar > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=comments#action_69565 ] Jochen Wiedmann commented on MAVENUPLOAD-966: - Are you sure about the groupId? I know, that the old groupId was net.sourceforge.retroweaver. I also know, that the project URL matches net.sourceforge.retroweaver. However, the code is in the package com.rc.retroweaver. As for the "bundle per artifact": I have submitted three different issues initially, when you asked me to supply a single jar file instead? > Upload Retroweaver 1.2.3 > > > Key: MAVENUPLOAD-966 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 > Project: maven-upload-requests > Type: Task > Reporter: Jochen Wiedmann > Attachments: retroweaver-1.2.3-upload.jar > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=all ] Jochen Wiedmann updated MAVENUPLOAD-966: Attachment: retroweaver-1.2.3-upload.jar > Upload Retroweaver 1.2.3 > > > Key: MAVENUPLOAD-966 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 > Project: maven-upload-requests > Type: Task > Reporter: Jochen Wiedmann > Attachments: retroweaver-1.2.3-upload.jar > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=all ] Jochen Wiedmann reopened MAVENUPLOAD-966: - Reopening; I wasn't able to reply to Carlos' comments on MAVENUPLOAD-965, due to a hard drive crash. > Upload Retroweaver 1.2.3 > > > Key: MAVENUPLOAD-966 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 > Project: maven-upload-requests > Type: Task > Reporter: Jochen Wiedmann > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=all ] Jochen Wiedmann closed MAVENUPLOAD-966: --- Resolution: Fixed See MAVENUPLOAD-965 > Upload Retroweaver 1.2.3 > > > Key: MAVENUPLOAD-966 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 > Project: maven-upload-requests > Type: Task > Reporter: Jochen Wiedmann > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-964) Upload retroweaver-rt 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-964?page=all ] Jochen Wiedmann closed MAVENUPLOAD-964: --- Resolution: Fixed See MAVENUPLOAD-965 > Upload retroweaver-rt 1.2.3 > --- > > Key: MAVENUPLOAD-964 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-964 > Project: maven-upload-requests > Type: Task > Reporter: Jochen Wiedmann > > > RetroWeaver transforms Java classes, which have been compiled by a Java 5 > compiler, into class files, that are accepable by Java 1.4. Ibiblio already > contains version 1.0 (under the group net.sourceforge.retroweaver). > I am not the author, but would like to use this version in plugins. -- 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-965) Upload retroweaver-all 1.2.3
Upload retroweaver-all 1.2.3 Key: MAVENUPLOAD-965 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-965 Project: maven-upload-requests Type: Task Reporter: Jochen Wiedmann RetroWeaver transforms Java classes, which have been compiled by a Java 5 compiler, into class files, that are accepable by Java 1.4. Ibiblio already contains version 1.0 (under the group net.sourceforge.retroweaver). I am not the author, but would like to use this version in plugins. -- 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-966) Upload Retroweaver 1.2.3
Upload Retroweaver 1.2.3 Key: MAVENUPLOAD-966 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 Project: maven-upload-requests Type: Task Reporter: Jochen Wiedmann RetroWeaver transforms Java classes, which have been compiled by a Java 5 compiler, into class files, that are accepable by Java 1.4. Ibiblio already contains version 1.0 (under the group net.sourceforge.retroweaver). I am not the author, but would like to use this version in plugins. -- 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-964) Upload retroweaver-rt 1.2.3
Upload retroweaver-rt 1.2.3 --- Key: MAVENUPLOAD-964 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-964 Project: maven-upload-requests Type: Task Reporter: Jochen Wiedmann RetroWeaver transforms Java classes, which have been compiled by a Java 5 compiler, into class files, that are accepable by Java 1.4. Ibiblio already contains version 1.0 (under the group net.sourceforge.retroweaver). I am not the author, but would like to use this version in plugins. -- 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-20) Don't create empty jars
[ http://jira.codehaus.org/browse/MJAR-20?page=all ] Jochen Wiedmann updated MJAR-20: Attachment: MJAR-20.patch > Don't create empty jars > --- > > Key: MJAR-20 > URL: http://jira.codehaus.org/browse/MJAR-20 > Project: Maven 2.x Jar Plugin > Type: Improvement > Versions: 2.0 > Reporter: Carlos Sanchez > Priority: Minor > Fix For: 2.1 > Attachments: MJAR-20.patch > > > Creating empty jars is confusing, it should just print a warning > use case: > parent pom attaching test jar, some subprojects may not have tests, why > create jars for them? -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=comments#action_67569 ] Jochen Wiedmann commented on MJAR-38: - Brett, I have read your quote and my impression is, that the problem report is in essence a duplicate of MJAR-39. As for your comment on releasing the maven-archiver: I'd recommend that this be done after Mike's patch to this issue is committed, which I cannot do. Perhaps Mike can do this now? > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Attachments: Jar Extension-Name Tester.zip, MJAR-38.patch, MJAR-38.patch > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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: (DOXIA-64) FmlParser adds CDATA as text
[ http://jira.codehaus.org/browse/DOXIA-64?page=all ] Jochen Wiedmann closed DOXIA-64: Resolution: Fixed Sorry, I was wrong. For reasons I don't understand, the CDATA section will be removed in the trunk, as can be seen when running the FmlParserTest. > FmlParser adds CDATA as text > > > Key: DOXIA-64 > URL: http://jira.codehaus.org/browse/DOXIA-64 > Project: doxia > Type: Bug > Reporter: Jochen Wiedmann > Attachments: doxia-fml-cdata.patch > > > The FML parser has an error in its handling of CDATA. > A CDATA section is a different syntactical representation of text. > Nevertheless, its contents are simply text. But the FmlParser treats a CDATA > section very different: > buffer.append( "" ); > Consequently, the generated site contains the strings , > which it should not. The applied patch fixes the problem by handling CDATA > and simple text in the same manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-64) FmlParser adds CDATA as text
FmlParser adds CDATA as text Key: DOXIA-64 URL: http://jira.codehaus.org/browse/DOXIA-64 Project: doxia Type: Bug Reporter: Jochen Wiedmann Attachments: doxia-fml-cdata.patch The FML parser has an error in its handling of CDATA. A CDATA section is a different syntactical representation of text. Nevertheless, its contents are simply text. But the FmlParser treats a CDATA section very different: buffer.append( "" ); Consequently, the generated site contains the strings , which it should not. The applied patch fixes the problem by handling CDATA and simple text in the same manner. -- 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-38) Maven Puts Arbitrary Extension Definition in JAR Manifest by Default.
[ http://jira.codehaus.org/browse/MJAR-38?page=all ] Jochen Wiedmann updated MJAR-38: Attachment: MJAR-38.patch > Maven Puts Arbitrary Extension Definition in JAR Manifest by Default. > - > > Key: MJAR-38 > URL: http://jira.codehaus.org/browse/MJAR-38 > Project: Maven 2.x Jar Plugin > Type: Bug > Versions: 2.0 > Environment: Maven version: 2.0.4 > Microsoft Windows XP [Version 5.1.2600] > Reporter: Steven Coco > Attachments: Jar Extension-Name Tester.zip, MJAR-38.patch, MJAR-38.patch > > > I'm using the latest Maven release. When I build my project, the > resulting Jar file's manifest contains an Extension-Name attribute along with > Specification and Implementation attributes. The POM contains no mention > that this project is a Java optional package -- an "extension" (or an > extension of any other kind). > I don't know why Maven is doing that. > If Maven is doing this by default for some reason, it absolutely > shouldn't. Maven should not identify my Jar as an optional package unless I > explicitly say so. Jars are only extensions if explicitly created as such. > The name it uses for the extension name is the POM's . > That's not even a UID! -- 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
