[jira] Created: (CONTINUUM-1248) site:stage doesn't work for cobertura report
site:stage doesn't work for cobertura report Key: CONTINUUM-1248 URL: http://jira.codehaus.org/browse/CONTINUUM-1248 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Environment: windows server 2003; java 1.5 Reporter: Larry Hamel create project with cobertura report. use goal site:stage -DstagingDirectory=..\..\webapp\ notice that other reports stage to given directory OK, but cobertura shows normal logging (no errors), but does not copy -- 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: (ARCHETYPE-70) Add project description as a mojo parameter
Add project description as a mojo parameter
---
Key: ARCHETYPE-70
URL: http://jira.codehaus.org/browse/ARCHETYPE-70
Project: Maven Archetype
Issue Type: New Feature
Components: Plugin
Reporter: Michael Heuer
Priority: Minor
Attachments: patch.txt
For my archetype bundle, I require the project description as a parameter.
I use it in the pom.xml
${description}
in a license HEADER.txt
/*
${artifactId} ${description}
Copyright ...
in a package.html
${description}
and so on.
The attached patch to MavenArchetypeMojo.java provides a project description
parameter in addition to project groupId, artifactId, and version:
$ mvn -X archetype:create
-DgroupId=foo
-DartifactId=bar
-Dversion=1.0-SNAPSHOT
-Ddescription="bar description." ...
--
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-178) filtering doesn't read filter files
[
http://jira.codehaus.org/browse/MASSEMBLY-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Fovez updated MASSEMBLY-178:
-
Attachment: filter-test.zip
Here is a sample derived from John's one showing that filtering doesn't seem to
worok with tag, even with the doc fix.
> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Attachments: filt-dist.diff, filter-test.tar.gz, filter-test.zip
>
>
> The assembly plugin's filtering supports POM properties like
> ${project.artifactId}, but not properties read from the filter file, contrary
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by
> saying "mvn clean package." It tries to filter a README file with both
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-178) filtering doesn't read filter files
[
http://jira.codehaus.org/browse/MASSEMBLY-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93832
]
Bertrand Fovez commented on MASSEMBLY-178:
--
Hello,
The fix works fine, indeed, for the tag. I tried with the tag
and it doesn't seem to work in this case.
I tested with Maven 2.0.6 and Assembly plug-in 2.2-beta-1.
I attached an sample derived from John's one.
> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Attachments: filt-dist.diff, filter-test.tar.gz
>
>
> The assembly plugin's filtering supports POM properties like
> ${project.artifactId}, but not properties read from the filter file, contrary
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by
> saying "mvn clean package." It tries to filter a README file with both
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.
--
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-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93804 ] Stephane Nicoll commented on MWAR-97: - Piotr, I added some nice helpers to test the overlay functionality. I have written 3 very simple tests but they tests quite everything (content of the webapp, text file content, content completeness that is it tests that only the specified files are there). It would be nice if we could port all your tests to this technique (see WarOverlaysTest, note that the wars are generated automatically from the content of src/test/resources/overlays/XXX). I had a look to the code, I'd like to separate the logic in a manager. AbstractWarMojo contains way too much code. What about a WarTask just like in the assembly plugin (one task to handle an overlay, one task to copy the web resources, one task to copy the src/main/webapp content, etc). Are you going to work on it short term ? Let me know. Thanks! > War plugin and Overlays handling > > > Key: MWAR-97 > URL: http://jira.codehaus.org/browse/MWAR-97 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Piotr Tabor >Assignee: Stephane Nicoll > Attachments: MWAR-97.diff > > > Piotr and I are currently working on the war plugin and especially > this overlay mechanism that needs to be upgraded. Currently a couple > of issues [1] in the war plugin are linked to this functionality and > we should really address them. > The idea here is to provide a better way to handle overlays through an > explicit configuration. An overlay has the following parameters: > * groupId > * artifactId > * classifier (optionnal) > * includes (default includes everything) > * excludes (default META-INF) > The order in which overlays are specified defined the order in which > they are applied. An overlay without a groupId/artifactId is > considered as the current build. If no such overlay is defined, it is > applied *last*. > The behavior should be deterministic so the copy will happen not > matter how if a file is newer than the one being applied. Overlays > order always wins. > If no overlays section is defined, the wars are processed as before; > dependentWarIncludes and dependentWarExcludes are honored. If an > overlays section is defined and those configuration items are defined, > they are ignored and a warning is logged. > If a dependent war is missing in the overlays section, it's applied > after custom overlays *and* before the current build (if the current > build is not specified of course) with the default includes/excludes. > Does that sounds ok to you? If so I'll add the proposition to the war > site and start the implementation with Piotr. We're also thinking > about integrating the merge functionality of the cargo plugin but we > still need to discuss with the cargo guys if it will be feasible. > Please comment. > Stéphane -- 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: (MANTTASKS-64) uberjar does not contain the lightweight http wagon
[ http://jira.codehaus.org/browse/MANTTASKS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MANTTASKS-64. -- Resolution: Fixed > uberjar does not contain the lightweight http wagon > --- > > Key: MANTTASKS-64 > URL: http://jira.codehaus.org/browse/MANTTASKS-64 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Brett Porter >Assignee: Jason van Zyl > Attachments: MANTTASKS-64.diff, MANTTASKS-64_site.diff > > > the new uberjar does not contain the lightweight wagon, so any use fails > unles you add a declaration to your script which was not necessary in the > previous release. > In addition, the JAR seems to be larger than before despite the omission - > was something unnecessarily included? -- 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-1494) spoon-core-1.1
spoon-core-1.1 -- Key: MAVENUPLOAD-1494 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1494 Project: maven-upload-requests Issue Type: New Feature Reporter: David Bernard Spoon is a Java program processor that fully supports Java 5. It provides a complete and fine-grained Java metamodel where any program element (classes, methods, fields, statements, expressions...) can be accessed both for reading and modification. javadoc : http://spoon.gforge.inria.fr/maven2/fr/inria/gforge/spoon/spoon-core/1.1/spoon-core-1.1-javadoc.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] Commented: (MONE-8) The goal one:convert is not implement in version 1.0 although it is documented and should work.
[ http://jira.codehaus.org/browse/MONE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93800 ] Dennis Lundberg commented on MONE-8: The convert goal is not available in 1.0. It is only available in 1.1-SNAPSHOT. Do you have a pointer to some web page that says otherwise? I'll make sure to republish the site to get the @since markings up there. > The goal one:convert is not implement in version 1.0 although it is > documented and should work. > --- > > Key: MONE-8 > URL: http://jira.codehaus.org/browse/MONE-8 > Project: Maven 2.x M1 Plugin > Issue Type: Bug > Environment: Win XP >Reporter: Eric Vanlaeken > > The goal one:convert is not implement in version 1.0 although it is > documented and should work. > Could you give an estimation when this will work? > tnx > Eric -- 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: (MANTTASKS-15) scp:// urls not recognised, even when wagon-ssh is installed.
[
http://jira.codehaus.org/browse/MANTTASKS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-15:
---
Attachment: MANTTASKS-15.diff
Here is a patch to get a complete list of supported protocols.
When Ant is run in verbose mode ("ant -v"), the list of supported protocols is
displayed after the new provider has been installed.
> scp:// urls not recognised, even when wagon-ssh is installed.
> -
>
> Key: MANTTASKS-15
> URL: http://jira.codehaus.org/browse/MANTTASKS-15
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MANTTASKS-15.diff
>
>
> I have got the task working to pull in the various deployment wagons
>
> version="${wagon-ssh.version}"/>
> version="${wagon-ssh-external.version}"/>
> version="${wagon-file.version}"/>
> version="${wagon-ftp.version}"/>
>
> But when I run a deploy target and use the scp:// protocol , I get the
> unknown protocol error.
>
>
>value="scp://${ssh.host}/www/repository"/>
>
>
>privateKey="${ssh.keyfile}"/>
>
>
>
>
> This is only for scp:, the others, scpexe, file: and ftp: do work. Is the url
> schema wrong? Is there any way to enum what protocols are currently supported?
> I would recommend that the error message "unsupported protocol" is
> supplemented with a listing of what protocols are supported. That way its
> easier to differentiate spelling error from uninstalled wagon.
--
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-2715) Maven does not comply to XML rules regarding prefixes.
[
http://jira.codehaus.org/browse/MNG-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93797
]
Arik Kfir commented on MNG-2715:
Seva,
I don't think Jason meant Maven will *never* support namespaces; only the 2.0.x
branch won't. I'm quite sure Maven 2.1 will support it (by moving to a standard
XML parser) - I think work has already began on the matter.
Jason, please correct me if I'm mistaken.
Best regards,
Arik.
> Maven does not comply to XML rules regarding prefixes.
> --
>
> Key: MNG-2715
> URL: http://jira.codehaus.org/browse/MNG-2715
> Project: Maven 2
> Issue Type: Bug
> Environment: Ubuntu 6.10
> Maven 2.0.4
>Reporter: Seva Safris
>Priority: Critical
>
> I am new to Maven and have been trying to learn how to create a simple
> project.
> Let me walk through my scenario of creating a pom.xml file:
> 1. I bind the {http://maven.apache.org/POM/4.0.0} namespace (defined at
> "http://maven.apache.org/maven-v4_0_0.xsd";) to Java classes using an XML
> Binding solution.
> 2. I use the bound classes to create a simple as one would expect
> to see in a pom.xml file.
> 3. I marshal the bound Java objects into xml and write it into pom.xml. Here
> is the xml I use:
>xmlns:ns1="http://maven.apache.org/POM/4.0.0";>
> 4.0.0
> com.myapp
> sample-project
> Sample Maven Project
> 1.0
>
>
> ssafris
> Seva Safris
>
>
>
> ${basedir}/src/java
>
>
> 4. I run mvn, and am promptly given a "Not a v4.0.0 POM." exception.
> Tracing through Maven's source, I went to the exact location of the exception
> in DefaultMavenProjectBuilder.java. On line 1297 it has:
> if ( modelSource.indexOf( "4.0.0" ) < 0 )
> {
> throw new InvalidProjectModelException( projectId, pomLocation, "Not a
> v4.0.0 POM." );
> }
> Since modelSource is checked explicitly for
> xml as shown above will fail this test because it has: This is most definitely a bug in Maven and should be fixed as soon as
> possible. The workaround is to use a
> xmlns="http://maven.apache.org/POM/4.0.0"; and define all elements without a
> prefix. However, my use of xmlns:ns1="http://maven.apache.org/POM/4.0.0";
> should not break Maven as it is not merely legal by xml conventions, but is
> also a better practice for xml documents.
> I hope you see the importance of getting this bug fixed: My use of a XML
> Binding solution to bind Maven's xml to Java allows me a strongly-typed level
> of indirection that will deterministically create proper xml that will
> validate successfully. If this bug is not fixed, then this level of
> indirection is not possible (or very very very difficult because the XML
> Binding solution would have to be hacked to use the xmlns="[...]"
> convention). I have only found this one instance of where the bug is obvious,
> but perhaps there are more locations in Maven where the same kind of error
> can occur.
> Thank you for your time, and I hope you consider this issue as seriously as I
> do.
> Sincerely,
> Seva Safris
--
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: (MANTTASKS-64) uberjar does not contain the lightweight http wagon
[ http://jira.codehaus.org/browse/MANTTASKS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-64: --- Attachment: MANTTASKS-64_site.diff Here is a patch for the documentation http://maven.apache.org/ant-tasks.html. I think I covered every new feature added to this release. My (fr)english is not so good, you'll probably need some corrections before commit... > uberjar does not contain the lightweight http wagon > --- > > Key: MANTTASKS-64 > URL: http://jira.codehaus.org/browse/MANTTASKS-64 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Brett Porter > Attachments: MANTTASKS-64.diff, MANTTASKS-64_site.diff > > > the new uberjar does not contain the lightweight wagon, so any use fails > unles you add a declaration to your script which was not necessary in the > previous release. > In addition, the JAR seems to be larger than before despite the omission - > was something unnecessarily included? -- 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
