[jira] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123752 ] Ramon Havermans commented on MSITE-159: --- I think it should work what one would expect. In HTML there is absolute and relative. Don't translate it. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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-140) Review the Doxia site documentation
[ http://jira.codehaus.org/browse/DOXIA-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-140. --- Assignee: Lukas Theussl Resolution: Fixed Site looks good now IMO, the refs to xsd/dtd should be added as soon as we have them, see DOXIA-141. > Review the Doxia site documentation > --- > > Key: DOXIA-140 > URL: http://jira.codehaus.org/browse/DOXIA-140 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123756 ] Kay Grosskop commented on MSITE-159: (John, sorry for my late reaction.) You are right: the internal references of the generated site should work wherever its build. Thats why the url's should be relative there. BUT: in the example above the point to use an absolute url is, that it refers to an EXTERNAL resource (https://bla.mycomp.nl/docs). Since this resource happens to have the same base url than the site deployment url, maven thinks that it should be treated as relative. I agree with Ramon, that maven should not override well established conventions here just to correct wrong configuration (people using absolute url's in the site descriptors where they should use relatives). Also I did not say that the project's main site url should be relative. What would the configuration option be here? 'interpret ALL absolute url's with the same base-url as the site root as relative url's' ? Correct me if I didn't get what you commented. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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-295) Make the distributionManagement.site.url configurable from the command line
[
http://jira.codehaus.org/browse/MSITE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123757
]
Yongshin Yu commented on MSITE-295:
---
Is there a way that I could set the site url to be dynamic? I would like to
publish to a folder based on a buildNumber generated by the
maven-buildnumber-plugin. Please let me know. Otherwise I am going to be forced
to open up a new issue. Thanks.
buildsite
Build Site
scp://mycompany.com/buildrepository/builds/${buildNumber}
> Make the distributionManagement.site.url configurable from the command line
> ---
>
> Key: MSITE-295
> URL: http://jira.codehaus.org/browse/MSITE-295
> Project: Maven 2.x Site Plugin
> Issue Type: Improvement
> Components: site:deploy
>Affects Versions: 2.0-beta-6
>Reporter: Gabriel Falkenberg
>
> It should be possible to override the attribute
> distributionManagement.site.url from the command line like this:
> mvn site:site site:deploy
> -DdistributionManagement.site.url=file:///some/local/or/external/path/
> This would not really be necessary if site:stage worked like it should but is
> needed since it does not.
--
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-624) automatic parent versioning
[
http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123758
]
Jean-Charles Meyrignac commented on MNG-624:
I was building Selenium, and found that I could propagate automatically the
version number as follows:
org.openqa.selenium
${SeleniumVersion}
selenium-rc
This worked on Maven 2.0.4, but doesn't with 2.0.6.
Alas, I was forced to upgrade due to maven-assembly-plugin, version
2.2-beta-2-SNAPSHOT, which forces the use of 2.0.6.
> automatic parent versioning
> ---
>
> Key: MNG-624
> URL: http://jira.codehaus.org/browse/MNG-624
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: Jason van Zyl
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
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-2569) Expressions not evaluated inside
[
http://jira.codehaus.org/browse/MNG-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123759
]
Jean-Charles Meyrignac commented on MNG-2569:
-
I was building Selenium, and found that I could propagate automatically the
version number as follows:
org.openqa.selenium
${SeleniumVersion}
selenium-rc
This worked on Maven 2.0.4, but doesn't with 2.0.6.
Alas, I was forced to upgrade due to maven-assembly-plugin, version
2.2-beta-2-SNAPSHOT, which forces the use of 2.0.6.
> Expressions not evaluated inside
> -
>
> Key: MNG-2569
> URL: http://jira.codehaus.org/browse/MNG-2569
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.4
> Environment: WinXP
> Java 1.5_08
> Maven 2.04
>Reporter: Thomas Minor
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
>
> The version tag within the parrent block does not evaluate properties.
> If I put a Version String directly in there, it works.
> A correctly defined property doesn't.
--
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: (MIDEA-112) Make class generation directory configurable
Make class generation directory configurable Key: MIDEA-112 URL: http://jira.codehaus.org/browse/MIDEA-112 Project: Maven 2.x IDEA Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Brice Beard The generated project files set target/classes as the output dir for classes, this can be inconvenient if the user wants to run independent action with idea and maven. For instance, running slow tests in maven while fixing some bugs and having to compile in idea. This would be solved by letting the user specify the output dir for classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-297) Child site.xml not used from parent + inheritance
Child site.xml not used from parent + inheritance - Key: MSITE-297 URL: http://jira.codehaus.org/browse/MSITE-297 Project: Maven 2.x Site Plugin Issue Type: Bug Components: multi module Affects Versions: 2.0-beta-6 Reporter: Ramon Havermans When using a parent child project building from the parent, the child site.xml is not used. Instead I get the parent lay-out with menu's I don't want and links that won't 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] Commented: (MSITE-297) Child site.xml not used from parent + inheritance
[ http://jira.codehaus.org/browse/MSITE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123769 ] Ramon Havermans commented on MSITE-297: --- Another problem is that the content (dependencies) in the modules are wrong (I think they are from the parent). Switching back to 2.0-beta-5 did resolve the issue, but at that version siteDirectory doens't work. > Child site.xml not used from parent + inheritance > - > > Key: MSITE-297 > URL: http://jira.codehaus.org/browse/MSITE-297 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > > When using a parent child project building from the parent, the child > site.xml is not used. Instead I get the parent lay-out with menu's I don't > want and links that won't 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] Commented: (MSITE-297) Child site.xml not used from parent + inheritance
[ http://jira.codehaus.org/browse/MSITE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123773 ] Ramon Havermans commented on MSITE-297: --- To reproduce: * Make parent ** Make parent site.xml ** Give parent his own menu (ParentMenu) * Make child ** Make child site.xml ** give child own menu (ChildMenu) If you do a mvn site-deploy and look at the child it will have a ParentMenu which you don't want and it doen't have a ChildMenu which you do want. > Child site.xml not used from parent + inheritance > - > > Key: MSITE-297 > URL: http://jira.codehaus.org/browse/MSITE-297 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > > When using a parent child project building from the parent, the child > site.xml is not used. Instead I get the parent lay-out with menu's I don't > want and links that won't 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] Commented: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123774 ] Dave Syer commented on DOXIA-170: - I think it should render to something that is readable. Ini the case of citation and underline, the intention of the author was to highlight the text, so citation->italic, underline->italic/bold makes sense. Strikethrough is difficult because the intention of the author is to show something that is visible but can be ignored. Maybe a special bracket construct like [ignore]...[/ignore]. Superscript and subscript could be rendered as ^(...) and _(...). > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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] Issue Comment Edited: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123774 ] dsyer edited comment on DOXIA-170 at 2/15/08 6:55 AM: -- I think it should render to something that is readable. In the case of citation and underline, the intention of the author was to highlight the text, so citation->italic, underline->italic/bold makes sense. Strikethrough is difficult because the intention of the author is to show something that is visible but can be ignored. Maybe a special bracket construct like [ignore]...[/ignore]? Superscript and subscript could be rendered as ^(...) and _(...). was (Author: dsyer): I think it should render to something that is readable. Ini the case of citation and underline, the intention of the author was to highlight the text, so citation->italic, underline->italic/bold makes sense. Strikethrough is difficult because the intention of the author is to show something that is visible but can be ignored. Maybe a special bracket construct like [ignore]...[/ignore]. Superscript and subscript could be rendered as ^(...) and _(...). > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123772 ] Lukas Theussl commented on DOXIA-170: - Could you specify what you mean with 'do something' and 'recognize'? If the confluence parser can't emit an event to a sink, then what's the point in recognizing it? What else do you want to do with it? > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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-297) Child site.xml not used from parent + inheritance
[ http://jira.codehaus.org/browse/MSITE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123771 ] Ramon Havermans commented on MSITE-297: --- Forget the last comment, was doing something wrong > Child site.xml not used from parent + inheritance > - > > Key: MSITE-297 > URL: http://jira.codehaus.org/browse/MSITE-297 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > > When using a parent child project building from the parent, the child > site.xml is not used. Instead I get the parent lay-out with menu's I don't > want and links that won't 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] Commented: (DOXIA-56) clean up doxia api and code
[ http://jira.codehaus.org/browse/DOXIA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123781 ] Lukas Theussl commented on DOXIA-56: Also rename StructureSink, the name is completely misleading as it is not a sink, and on top contains only apt specific methods, it shouldn't be used by anything else, maybe put it into apt module? > clean up doxia api and code > --- > > Key: DOXIA-56 > URL: http://jira.codehaus.org/browse/DOXIA-56 > Project: Maven Doxia > Issue Type: Task > Components: Core >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > there is a lot of "throws Exception" and uncertainty in the API. It needs a > clean up before 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: (MSITE-298) Bump to Doxia 1.0-beta-1-SNAPSHOT
Bump to Doxia 1.0-beta-1-SNAPSHOT - Key: MSITE-298 URL: http://jira.codehaus.org/browse/MSITE-298 Project: Maven 2.x Site Plugin Issue Type: Task Affects Versions: 2.0-beta-7 Reporter: Vincent Siveton -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-299) Add Doxia logging support
Add Doxia logging support - Key: MSITE-299 URL: http://jira.codehaus.org/browse/MSITE-299 Project: Maven 2.x Site Plugin Issue Type: Sub-task Components: doxia integration Affects Versions: 2.0-beta-7 Reporter: Vincent Siveton -- 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: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123783 ] Dave Syer commented on DOXIA-170: - I imagine they are not lost as things are, but they also won't come out in HTML anything like the author intended. They will come out with the formatting characters from confluence, which might mean something to the author, but will be nonsense to the reader. > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123782 ] Lukas Theussl commented on DOXIA-170: - What's happening currently with the content of these elements, are they swallowed? If yes I guess we should at least output the text content as plain text, so no information is lost. > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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: (MECLIPSE-390) myeclipse goal ignores additionalConfig
[
http://jira.codehaus.org/browse/MECLIPSE-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-390.
Resolution: Fixed
Fix Version/s: 2.5
This issue is fixed. Thanks for your patch.
To try the latest SNAPSHOT (2.5-20080215.121626-22) of the incoming version you
have to define and activate this profile :
{code}
apache.snapshots
false
apache.snapshots
Maven Snapshots
http://people.apache.org/maven-snapshot-repository
false
apache.plugin.snapshots
Maven Plugin Snapshots
http://people.apache.org/maven-snapshot-repository
{code}
Then you have to call this command :
{code}
mvn org.apache.maven.plugins:maven-eclipse-plugin:2.5-SNAPSHOT:eclipse
{code}
> myeclipse goal ignores additionalConfig
> ---
>
> Key: MECLIPSE-390
> URL: http://jira.codehaus.org/browse/MECLIPSE-390
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: MyEclipse support
>Affects Versions: 2.4, 2.5
> Environment: Maven 2.0.8, maven-eclipse-plugin 2.4,
> maven-eclipse-plugin-2.5 2/11/2008 SNAPSHOT
>Reporter: Julien Jakubowski
>Assignee: Arnaud Heritier
> Fix For: 2.5
>
> Attachments: myeclipse-bug-additionalconfig.patch,
> project-myeclipse-05.zip
>
>
> MyEclipse support doesn't write additional configuration files such as
> .checkstyle file. This is because additionalConfig is not used by
> MyEclipsePlugin class.
> Here is a patch that fix this bug. I also provide a unit test and a test
> project, included inside zip file attachment.
--
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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MNG-3402: - Fix Version/s: 2.1-alpha-1 2.0.9 > MavenArtifactFilterManager needs to not filtering doxia-sink-api > > > Key: MNG-3402 > URL: http://jira.codehaus.org/browse/MNG-3402 > Project: Maven 2 > Issue Type: Improvement > Components: Maven Filtering >Affects Versions: 2.0.8 >Reporter: Vincent Siveton > Fix For: 2.0.9, 2.1-alpha-1 > > Attachments: MavenArtifactFilterManager.diff > > > A plugin (like pdf-plugin) needs to use the most recent sink API and not the > API embedded in maven. -- 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: (DOXIA-145) Adding logger feature
[ http://jira.codehaus.org/browse/DOXIA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123785 ] Vincent Siveton commented on DOXIA-145: --- Fixed in r62806. Lukas, could you review it? Thanks. > Adding logger feature > - > > Key: DOXIA-145 > URL: http://jira.codehaus.org/browse/DOXIA-145 > Project: Maven Doxia > Issue Type: New Feature > Components: Core, Modules, Sink API >Reporter: Vincent Siveton > Fix For: 1.0-beta-1 > > Attachments: DOXIA-145.patch > > > Doxia needs to have logger capability insides -- 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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
MavenArtifactFilterManager needs to not filtering doxia-sink-api Key: MNG-3402 URL: http://jira.codehaus.org/browse/MNG-3402 Project: Maven 2 Issue Type: Improvement Components: Maven Filtering Affects Versions: 2.0.8 Reporter: Vincent Siveton Fix For: 2.0.9, 2.1-alpha-1 Attachments: MavenArtifactFilterManager.diff A plugin (like pdf-plugin) needs to use the most recent sink API and not the API embedded in maven. -- 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: (MSITE-299) Add Doxia logging support
[ http://jira.codehaus.org/browse/MSITE-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MSITE-299: -- Attachment: MSITE-299_maven-site-plugin.diff MSITE-299_maven-doxia-tools.diff The patch on maven-doxia-tools just provides a wrapper to doxia logger. The patch on maven-site-plugin fails IT (see MNG-3402) > Add Doxia logging support > - > > Key: MSITE-299 > URL: http://jira.codehaus.org/browse/MSITE-299 > Project: Maven 2.x Site Plugin > Issue Type: Sub-task > Components: doxia integration >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton > Attachments: MSITE-299_maven-doxia-tools.diff, > MSITE-299_maven-site-plugin.diff > > -- 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: (MRESOURCES-48) Failed to copy full contents from
[
http://jira.codehaus.org/browse/MRESOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123787
]
Brad Szabo commented on MRESOURCES-48:
--
I have this issue appearing consistently on a build using Maven 2.0.8,
Resources plugin version 2.2, and JDK 1.6.0_04 all running on RHEL 4. The JDK
bug referenced above obviously does not apply to this environment, but just for
reference, the path length causing the problem is only 146 characters.
> Failed to copy full contents from
> -
>
> Key: MRESOURCES-48
> URL: http://jira.codehaus.org/browse/MRESOURCES-48
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Hart
>Priority: Blocker
> Attachments: error.log
>
>
> Every time i execute a maven i get the message: 'Failed to copy full
> contents'. I check the code from the class FileUtils and there is a simle
> File#length() compare.
> {code}
> if( source.length() != destination.length() )
> {
> final String message = "Failed to copy full contents from " + source +
> " to " + destination;
> throw new IOException( message );
> }
> {code}
> mvn -version
> Maven version: 2.0.7
> Java version: 1.5.0_04
> OS name: "windows xp" version: "5.1" arch: "x86"
--
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] Issue Comment Edited: (MRESOURCES-48) Failed to copy full contents from
[
http://jira.codehaus.org/browse/MRESOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123787
]
bszabo edited comment on MRESOURCES-48 at 2/15/08 8:30 AM:
---
I have this issue appearing consistently on a build using Maven 2.0.8,
Resources plugin version 2.2, and JDK 1.6.0_04 all running on RHEL 4. The JDK
bug referenced above I don't think applies to this issue, and obviously not to
my environment, but just for reference, the path length causing the problem is
only 146 characters.
was (Author: bszabo):
I have this issue appearing consistently on a build using Maven 2.0.8,
Resources plugin version 2.2, and JDK 1.6.0_04 all running on RHEL 4. The JDK
bug referenced above obviously does not apply to this environment, but just for
reference, the path length causing the problem is only 146 characters.
> Failed to copy full contents from
> -
>
> Key: MRESOURCES-48
> URL: http://jira.codehaus.org/browse/MRESOURCES-48
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Hart
>Priority: Blocker
> Attachments: error.log
>
>
> Every time i execute a maven i get the message: 'Failed to copy full
> contents'. I check the code from the class FileUtils and there is a simle
> File#length() compare.
> {code}
> if( source.length() != destination.length() )
> {
> final String message = "Failed to copy full contents from " + source +
> " to " + destination;
> throw new IOException( message );
> }
> {code}
> mvn -version
> Maven version: 2.0.7
> Java version: 1.5.0_04
> OS name: "windows xp" version: "5.1" arch: "x86"
--
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: (DOXIA-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123790 ] Lukas Theussl commented on DOXIA-170: - OK, thanks for the clarification. I have scheduled this for a later release for now, but if anyone attaches a patch (hint!) we can incorporate this easily. Just bear in mind that the parser events should be consumable by any type of sink, eg I think citation->italic, underline->bold makes perfect sense, however inserting special markup might lead to trouble later, so just output plain text would be enough IMO. > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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-145) Adding logger feature
[ http://jira.codehaus.org/browse/DOXIA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-145. --- Assignee: Lukas Theussl Resolution: Fixed Closing as it works for me, but obviously needs testing on a wider basis. > Adding logger feature > - > > Key: DOXIA-145 > URL: http://jira.codehaus.org/browse/DOXIA-145 > Project: Maven Doxia > Issue Type: New Feature > Components: Core, Modules, Sink API >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: DOXIA-145.patch > > > Doxia needs to have logger capability insides -- 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: (MRESOURCES-48) Failed to copy full contents from
[
http://jira.codehaus.org/browse/MRESOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123794
]
Brad Szabo commented on MRESOURCES-48:
--
I spoke too soon. It looks like an environment issue. After posting, I renamed
the local repository (mv ~/.m2/repository ~/.m2/repository.bkup) to run a
completely clean test and then started getting errors like this:
Downloading:
http://internal.repo.com/maven2/releases/package/name/project-parent/3/project-parent-3.pom
15K downloaded
[DEBUG] Artifact resolved
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Caused by: org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0
POM. for project package.name:project-parent at
/home/builduser/.m2/repository/package/name/project-parent/3/project-parent-3.pom
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1405)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:528)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1255)
When I checked the downloaded parent POM file it turned out to be empty, so I
tried to simply copy a file and found out the real cause of the problem:
-bash$ cp pom.xml ~/.m2/test
cp: closing `/home/builduser/.m2/test': Disk quota exceeded
In my case /home/builduser is a mounted drive and I had not been aware of its
quota.
> Failed to copy full contents from
> -
>
> Key: MRESOURCES-48
> URL: http://jira.codehaus.org/browse/MRESOURCES-48
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Hart
>Priority: Blocker
> Attachments: error.log
>
>
> Every time i execute a maven i get the message: 'Failed to copy full
> contents'. I check the code from the class FileUtils and there is a simle
> File#length() compare.
> {code}
> if( source.length() != destination.length() )
> {
> final String message = "Failed to copy full contents from " + source +
> " to " + destination;
> throw new IOException( message );
> }
> {code}
> mvn -version
> Maven version: 2.0.7
> Java version: 1.5.0_04
> OS name: "windows xp" version: "5.1" arch: "x86"
--
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-3401) Maven Dependency Plugin vs Eclipse Plugin Errors caused by MVN Core
[
http://jira.codehaus.org/browse/MNG-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123797
]
Brian Fox commented on MNG-3401:
The problem is that when plugins are invoked from the command line (or bound
directly to the default lifecycle), they don't execute with an execution id.
This means that the configuration of that plugin must be done outside the
block. This is confusing for the user, but also doesn't allow much
flexibility. If you want to support a plugin being run from the command line
and bound to the pom, your configuration will be in the default section and
thus inherited by all executions. This usually is not what you want.
Any of these default executions should actually use an execution and we could
probably do something simple like use "default" as the execution name.
> Maven Dependency Plugin vs Eclipse Plugin Errors caused by MVN Core
> ---
>
> Key: MNG-3401
> URL: http://jira.codehaus.org/browse/MNG-3401
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.8
>Reporter: Michael Heß
>
> According to Brian E. Fox there is something wrong with the Maven Core which
> causes the maven-dependency-plugin to fail if it is called by the
> mvn-eclipse-plugin. I can't tell any specifics since Brian looked into it,
> and only provided me a workaround. I'm pasting our dialog from the mailing
> list in here. Any further questions regarding this should be directed to
> Brian, since I am just a user and do not have the necessary insight.
> - snip mailinglist transscript starts here
> No, this is a maven core bug and will probably have to be fixed in 2.1, but
> file an issue anyway.
> -Original Message-
> From: Michael Heß [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 14, 2008 12:57 AM
> To: Maven Users List
> Subject: RE: dependency:unpack vs. eclipse:eclipse
> Thanks Brian, for finding this out.
> I have created a workaround as suggested. Only additional thing I had to
> do, was to also bind the resources:resources to process-resources phase,
> because otherwise the filtering occured before the dependency:unpack. It's
> dirty, but at least it works now.
> Have you already taken care of filing a bug? If not, I would take care of
> this. The bug is in the dependency-plugin, right?
> bye, Michael
> Brian E. Fox schrieb:
> > I am able to reproduce this and it's an unfortunate bug in 2.0.x. The only
> > workaround I can suggest is to change the dependency plugin binding to a
> > later phase than is invoked by the eclipse plugin. According to [1] the
> > phase is generate-resources so you can bump it to process-resources.
> >
> > [1]:
> > http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
> >
> > -Original Message-
> > From: Michael Heß [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 13, 2008 1:07 AM
> > To: Maven Users List
> > Subject: RE: dependency:unpack vs. eclipse:eclipse
> >
> > Sure,
> >
> > here you go, I hope it somehow survives the transfer to the list. If it's
> > completely garbled I can also send you the file directly as an attachment.
> >
> > Furthermore I'd like to add the error I'm getting when binding the
> > dependendy-plugin unpack goal to a specific phase:
> >
> > ERROR -
> > [INFO] One or more required plugin parameters are invalid/missing for
> > 'dependency:unpack'
> >
> > [0] Inside the definition for plugin 'maven-dependency-plugin' specify the
> > following:
> >
> >
> > ...
> > VALUE
> > .
> > ERROR -
> >
> > But as you can see in the pom below, I do have the wanted configuration
> > settings. Thanks for looking into this.
> >
> > bye, Michael
> >
> > ---pom starts here---
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> >
> > abc
> > de.customer
> > 1.0.0-SNAPSHOT
> >
> > 4.0.0
> > de.customer.abc
> > product-config
> > jar
> > ${parent.version}
> > product-config
> >
> >
> > de.customer.abc.common
> > abc-basis-config
> > ${abc.common.version}
> > compile
> >
> >
> >
> >
> > local
> >
> >
> > local
> >
> >
> >
> >
> > true
> >
> >
[jira] Commented: (DOXIA-99) Figures require extension in APT and they should not
[ http://jira.codehaus.org/browse/DOXIA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123793 ] Lukas Theussl commented on DOXIA-99: I think it has by now become a de-facto standard in maven land that figures in apt require an extension. Figure sources are just links, and so should be valid and unique as such. Since we have already decided to deviate from the original apt format (see http://docs.codehaus.org/display/DOXIA/Proposed+Changes+to+the+APT+Format), I think it would be the cleanest solution to leave it like that. So a parser should just emit the figure source as is, and any sink can check if it supports the figure format and if not, give a warning, try to convert, look for another source, or whatever. One option we could implement for (partial) compatibility with aptconvert is that the AptParser checks if the figure source has an extension, and if not append a default one. > Figures require extension in APT and they should not > > > Key: DOXIA-99 > URL: http://jira.codehaus.org/browse/DOXIA-99 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-5, 1.0-alpha-6, 1.0-alpha-7, 1.0-alpha-8 >Reporter: Greg Luck >Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > Figures require extension in APT and they should not. > For example, http://ehcache.sourceforge.net/nameandlogo.html shows a broken > image. The APT for this page is: > [images/ehcache_logo] > Now, if I change it to [images/ehcache_logo.gif] it works. However this > breaks aptconvert. The reason is that it is illegal in APT to specify the > figure extension. I use aptconvert to create a pdf and single HTML page. -- 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-144) Custom filter list does not work
Custom filter list does not work
Key: MWAR-144
URL: http://jira.codehaus.org/browse/MWAR-144
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Trygve Laugstol
When specifying filters on the plugin (not inside ) like this:
{code}
polopoly-resources/config_ptest
WEB-INF/config
ptest
target/ptest-work
src/main/filters/filter.ptest.properties
src/main/resources
WEB-INF/classes
true
{code}
the list of filters is ignored. If I move the list to inside the
they work as expected. The documentation explicitly say that this is
possible under the section "Filtering webResources".
--
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-144) Custom filter list does not work
[
http://jira.codehaus.org/browse/MWAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123805
]
Olivier Lamy commented on MWAR-144:
---
Did you try on last SNAPSHOT ?
Concerning plugin configuration :
{code:xml}
src/main/filters/filter.ptest.properties
{code}
I would prefer something like
{code:xml}
${basedir}/src/main/filters/filter.ptest.properties
{code}
> Custom filter list does not work
>
>
> Key: MWAR-144
> URL: http://jira.codehaus.org/browse/MWAR-144
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Trygve Laugstol
>
> When specifying filters on the plugin (not inside ) like this:
> {code}
>
>
> polopoly-resources/config_ptest
> WEB-INF/config
>
> ptest
> target/ptest-work
>
> src/main/filters/filter.ptest.properties
>
>
>
> src/main/resources
> WEB-INF/classes
> true
>
>
> {code}
> the list of filters is ignored. If I move the list to inside the
> they work as expected. The documentation explicitly say that this
> is possible under the section "Filtering webResources".
--
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: (MCHANGES-101) Consider changing log outputs to debug
Consider changing log outputs to debug
--
Key: MCHANGES-101
URL: http://jira.codehaus.org/browse/MCHANGES-101
Project: Maven 2.x Changes Plugin
Issue Type: Wish
Components: jira-report
Affects Versions: 2.0-beta-3
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: jira-debug-logs.patch
Log levels are quite controversial but I would like to see some less output
from the report generation on the INFO level. Currently, one gets:
{noformat}
[INFO] Generating "JIRA Report" report.
[INFO] JIRA lives at: http://jira.codehaus.org
> I know, that where it was configured in the POM
[INFO] The JIRA URL http://jira.codehaus.org/browse/MJAVACC doesn't include a
pid, trying to extract it from JIRA.
> Well, I know this as well
[INFO] Successfully reached JIRA.
> Hopefully
[INFO] Downloading from JIRA at:
http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11216
&statusIds=6&resolutionIds=1&sorter/field=fixVersions&sorter/order=DESC&tempMax=100&reset=true&decorator=none
> Wow, that's a pretty URL to read
[INFO] Downloading from JIRA was successful
> I'm an optimist so I expected that. Better tell me things that suprise me.
[INFO] The JIRA Report will contain issues only for the current version.
> Cool, it's honoring my configuration again!
{noformat}
As my not so serious comments shall indicate, I consider most of the current
INFO ouput quite uninteresting during a regular build. It either reports back
the plugin configuration or the expected behavior. Therefore, I personally
would be fine with just "Generating "JIRA Report" report".
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123801 ] Arnaud Heritier commented on MECLIPSE-184: -- m2eclipse doesn't use maven 2.1, but Q4E do it. Support for WTP in Q4E and m2eclipse is very very far from what you have with the eclipse:eclipse mojo > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-246) Add a switch to use ${groupId}.${artifactId} as Bundle-SymbolicName in PDE mode
[
http://jira.codehaus.org/browse/MECLIPSE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123802
]
Arnaud Heritier commented on MECLIPSE-246:
--
No this is a component for internal use only.
> Add a switch to use ${groupId}.${artifactId} as Bundle-SymbolicName in PDE
> mode
> ---
>
> Key: MECLIPSE-246
> URL: http://jira.codehaus.org/browse/MECLIPSE-246
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: PDE support
>Affects Versions: 2.3
>Reporter: Markus Wiederkehr
>
> Currently only the artifact ID is used as bundle name in
> META-INF/MANIFEST.MF. It should be possible to use the combination of group
> ID and artifact ID instead.
--
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-1933) Please add sync script for de.sven-jacobs.loremipsum
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123807 ] Sven Jacobs commented on MAVENUPLOAD-1933: -- Sorry, typo :( My name is Sven Jacobs > Please add sync script for de.sven-jacobs.loremipsum > > > Key: MAVENUPLOAD-1933 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1933 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sven Jacobs > Attachments: de.sven-jacobs.loremipsum.sh > > > Please add the attached sync script to the Maven 2 repo. > PROOF: http://loremipsum.sven-jacobs.de redirects to project website at > http://loremipsum.sourceforge.net/. My name, Sven Jacons, is mentioned on > that page. -- 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-1933) Please add sync script for de.sven-jacobs.loremipsum
Please add sync script for de.sven-jacobs.loremipsum Key: MAVENUPLOAD-1933 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1933 Project: maven-upload-requests Issue Type: Task Reporter: Sven Jacobs Attachments: de.sven-jacobs.loremipsum.sh Please add the attached sync script to the Maven 2 repo. PROOF: http://loremipsum.sven-jacobs.de redirects to project website at http://loremipsum.sourceforge.net/. My name, Sven Jacons, is mentioned on that page. -- 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: (MNG-3403) profiles.xml in same directory as parent pom ignored when building chld module
[ http://jira.codehaus.org/browse/MNG-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Piterman closed MNG-3403. - Resolution: Cannot Reproduce sorry, invalid > profiles.xml in same directory as parent pom ignored when building chld module > -- > > Key: MNG-3403 > URL: http://jira.codehaus.org/browse/MNG-3403 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Ron Piterman > > Seen in a flat structure where : > parent/pom.xml > parent/profiles.xml > module1/pom.xml -- 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-3403) profiles.xml in same directory as parent pom ignored when building chld module
profiles.xml in same directory as parent pom ignored when building chld module -- Key: MNG-3403 URL: http://jira.codehaus.org/browse/MNG-3403 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.7 Reporter: Ron Piterman Seen in a flat structure where : parent/pom.xml parent/profiles.xml module1/pom.xml -- 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: (MCHANGES-102) Fix case-insensitive string handling
Fix case-insensitive string handling Key: MCHANGES-102 URL: http://jira.codehaus.org/browse/MCHANGES-102 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.0-beta-3 Reporter: Benjamin Bentmann Priority: Minor Attachments: case-insensitive-strings.patch Please see [Common Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a14931921] for an explanation. -- 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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123947 ] Arnaud Heritier commented on MECLIPSE-184: -- thanks for this info. I didn't know. I known that it was the case for Q4E but not for m2eclipse. It's certainly new. I didn't used and had a look at this plugin for several monthes. thx > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123957
]
Arnaud Heritier commented on MECLIPSE-388:
--
It could be possible but I wouldn't force to have maven 2.0.9 to use the next
version of the plugin.
I'll try to see, but I think we'll rewrite/refactor an important part after the
2.5 release (perhaps it will be a 3.0)
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[ http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123951 ] Siarhei Dudzin commented on MECLIPSE-184: - I had to drop it because it didn't support all the features of the pom I used for maven 2.0.x. And there was no major (if at all) release since... Which is unfortunate because now I have to use this: [http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven%20as%20an%20external%20tool] > Ear utility-jar are put in WEB-INF/lib of the wtp ear > - > > Key: MECLIPSE-184 > URL: http://jira.codehaus.org/browse/MECLIPSE-184 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake >Reporter: Elid OR >Assignee: Arnaud Heritier >Priority: Critical > > It seems that the maven eclipse plugin add ear jar dependencies in the > WEB-INF/lib directory. > I've used the following command : mvn eclipse:clean > eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot > version) > And when deploy the ear project through WTP in a J2EE Server I see the > following structure : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- WEB-INF/ > | lib > | dependency-1.jar > | dependency-2.jar > But I don't expect these dependencies to be here, I expect something like > this : > my-ear > | my-ejb.jar > | my-webapp.war > | META-INF/ > | application.xml > | MANIFEST.MF > | > |- dependency-1.jar > |- dependency-2.jar > So I've checked quickly the SVN repository and it seems that the directory in > which we put "ear utility jar" is hard coded as "WEB-INF/lib" (-> > AbstractWtpResourceWritter.addDependency() which is the same for the war and > the ear ... ) > Are you OK with this packaging ? It can be a good thing if we could configure > where wtp will > put these ear utility-jars and by default it would be in "/" or "lib". > Thanks In Advance > Elid OR -- 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-144) Custom filter list does not work
[
http://jira.codehaus.org/browse/MWAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MWAR-144:
--
Assignee: Olivier Lamy
Fix Version/s: 2.1-alpha-2
> Custom filter list does not work
>
>
> Key: MWAR-144
> URL: http://jira.codehaus.org/browse/MWAR-144
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Trygve Laugstol
>Assignee: Olivier Lamy
> Fix For: 2.1-alpha-2
>
>
> When specifying filters on the plugin (not inside ) like this:
> {code}
>
>
> polopoly-resources/config_ptest
> WEB-INF/config
>
> ptest
> target/ptest-work
>
> src/main/filters/filter.ptest.properties
>
>
>
> src/main/resources
> WEB-INF/classes
> true
>
>
> {code}
> the list of filters is ignored. If I move the list to inside the
> they work as expected. The documentation explicitly say that this
> is possible under the section "Filtering webResources".
--
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: (MCHANGES-103) Allow suffix "ASC" for sort columns
Allow suffix "ASC" for sort columns
---
Key: MCHANGES-103
URL: http://jira.codehaus.org/browse/MCHANGES-103
Project: Maven 2.x Changes Plugin
Issue Type: Improvement
Components: jira-report
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: asc-sorting.patch
As a matter of consistency, it would be good if the plugin accepted the suffix
"ASC" to denote ascending sorting as well. When somebody sees a plugin
configuration like
{code:xml}
Key DESC
{code}
I argue most peoply would expect that "Key ASC" is a valid input, too.
--
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: (MDEP-144) Add mojos to copy/unpack dependencies specified by POMs
[ http://jira.codehaus.org/browse/MDEP-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123964 ] Brian Fox commented on MDEP-144: I just added a new filter to maven-common-artifact-filters that does exactly what you ask. I need it for another plugin, but intend to pull it to mdep also. > Add mojos to copy/unpack dependencies specified by POMs > --- > > Key: MDEP-144 > URL: http://jira.codehaus.org/browse/MDEP-144 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > > It would be cool if there were mojos that can read dependencies from other > POM files. This would allow to handle dependencies that are external to the > current project and not known in advance. > The user would feed in a directory (with includes/excludes) which the plugin > would scan for POMs. For every POM, the plugin gets direct/transitive > dependencies of scope x and copies/unpacks 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] Created: (MSITE-300) Using maven-shade-plugin instead of forking plexus-utils
Using maven-shade-plugin instead of forking plexus-utils Key: MSITE-300 URL: http://jira.codehaus.org/browse/MSITE-300 Project: Maven 2.x Site Plugin Issue Type: Sub-task Affects Versions: 2.0-beta-6 Reporter: Vincent Siveton -- 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-132) dependencies with same artifactId and != groupId result is conflicts in WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MWAR-132: -- Assignee: Olivier Lamy Fix Version/s: 2.1 > dependencies with same artifactId and != groupId result is conflicts in > WEB-INF/lib > --- > > Key: MWAR-132 > URL: http://jira.codehaus.org/browse/MWAR-132 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.1-alpha-1 >Reporter: nicolas de loof >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.1 > > > as discussed on dev mailing list (groupId/artifactId mapping for Eclipse > jars) the War plugin may fail creating the webapp WEB-INF/lib if multiple > dependencies use the same artifactId, but different groupIds. > This is not the case now as many libs are created with maven1 "Id" in mind, > for example all apache commons having "commons-" as artifactId prefix. In > future, some libs may start using simplier names and rely more on maven > groupId. For such case, the war plugin MAY provide and option to add groupIds > to artifacts copied to WEB-INF/lib. -- 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: (MSITE-298) Bump to Doxia 1.0-beta-1-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MSITE-298: -- Affects Version/s: (was: 2.0-beta-7) 2.0-beta-6 Fix Version/s: 2.0-beta-7 > Bump to Doxia 1.0-beta-1-SNAPSHOT > - > > Key: MSITE-298 > URL: http://jira.codehaus.org/browse/MSITE-298 > Project: Maven 2.x Site Plugin > Issue Type: Task >Affects Versions: 2.0-beta-6 >Reporter: Vincent Siveton > Fix For: 2.0-beta-7 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-452) suitename always = "TestSuite" even if defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123962
]
Dan Fabulich commented on SUREFIRE-452:
---
Two points.
1) I find it hard to believe that you're "blocked" by this bug. Yes, it's
certainly annoying that everything gets dumped into a file called
TestSuite.xml. But that's only bothering you because of a bug in JUnitReport
where it only pays attention to the name of the file, instead of paying
attention to the "classname" attribute inside the XML file.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24106
JUnitReport is kinda broken. May I recommend our fine Surefire Report instead?
2) I just attempted to test your revised patch, and I didn't entirely grasp the
intended effect of this code. This code doesn't do anything *except* honor the
"suitename" option if you forcibly pass it in. Naturally, you can only do this
on a per-project basis.
I don't think this really helps you very much. All test results are going to
go into one file, and because of Ant bug 24106, all test results will be
reported as coming from one class. Does it matter whether the file is called
"TestSuite" or whether it's called ${artifactId}? You still won't be able to
tell what class had a test failure.
> suitename always = "TestSuite" even if defined as property
> --
>
> Key: SUREFIRE-452
> URL: http://jira.codehaus.org/browse/SUREFIRE-452
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4, 2.4.1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> and also on Linux
>Reporter: Erez Nahir
> Fix For: 2.x
>
> Attachments: TestNGDirectoryTestSuite.java,
> TestNGDirectoryTestSuite.java
>
>
> Using surefire and testng with no testng.xml but with , the
> generated standard output xml always have suite name="TestSuite".
> This is an issue while using CruiseControl and JUnitReport to generate a
> JUnit report.
> Here is the configuration in my pom file:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.4.1
>
> true
> fast
> broken
>
>
> suitename
> ${artifactId}
>
>
> testname
> ${artifactId}
>
>
>
>
> There is an attached patch too.
--
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: (MWAR-134) ClasscastException when turning filtering on the web resources
[ http://jira.codehaus.org/browse/MWAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-134. - Resolution: Fixed Fix Version/s: 2.1-alpha-2 fixed with using maven-filtering component > ClasscastException when turning filtering on the web resources > -- > > Key: MWAR-134 > URL: http://jira.codehaus.org/browse/MWAR-134 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Maven 2.0.8, Win XP >Reporter: Ludovic Claude >Assignee: Olivier Lamy > Fix For: 2.1-alpha-2 > > > Hello, > I have configured the maven-war-plugin to filter my files in src/main/webapp, > in particular web.xml. > > org.apache.maven.plugins > maven-war-plugin > > > > false > > > > > true > > src/main/webapp > > > **/* > > > > > > But when I run Maven, I get the following error: > [INFO] Copy webapp webResources to [...]\client-framework-webapp-0.2-SNAPSHOT > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.project.MavenProject > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.project.MavenProject > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) > at java.io.Reader.read(Reader.java:100) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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:324) > 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) > [INFO] > > Any idea? > Thanks, > Ludovic -- This message is automatically generated by JIRA. - If you think it was se
[jira] Closed: (MJAVADOC-176) javadoc uses the undcoumented and platform unspecific -J-fullversion to determine version instead of the more standardized -J-version
[ http://jira.codehaus.org/browse/MJAVADOC-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-176. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 Patch applied and snapshot deployed. Thanks! > javadoc uses the undcoumented and platform unspecific -J-fullversion to > determine version instead of the more standardized -J-version > - > > Key: MJAVADOC-176 > URL: http://jira.codehaus.org/browse/MJAVADOC-176 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: All Platforms >Reporter: Alexander Sack >Assignee: Vincent Siveton > Fix For: 2.4 > > Attachments: MNG-176-maven-javadoc-plugin.patch > > > The -J-fullversion is not as standardized as the -Jversion across multiple > platforms. On SCO UnixWare 7.1.4, the -J-fullversion returns the equivalent > of the System's java.vm.version which has a non-standard string compared to > the normal -J-version (the output you expect to be java version is > "x.y.z_rev" etc. Its wiser going forward to use just -J-version to determine > the javadoc version number. -- 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: (SUREFIRE-452) suitename always = "TestSuite" even if defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-452.
-
Resolution: Fixed
Fix Version/s: (was: 2.x)
2.4.2
Ah, whatever. I fixed your patch to make it work with XML suites and submitted
it in revision revision 628192. It will go out in 2.4.2.
> suitename always = "TestSuite" even if defined as property
> --
>
> Key: SUREFIRE-452
> URL: http://jira.codehaus.org/browse/SUREFIRE-452
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4, 2.4.1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> and also on Linux
>Reporter: Erez Nahir
> Fix For: 2.4.2
>
> Attachments: TestNGDirectoryTestSuite.java,
> TestNGDirectoryTestSuite.java
>
>
> Using surefire and testng with no testng.xml but with , the
> generated standard output xml always have suite name="TestSuite".
> This is an issue while using CruiseControl and JUnitReport to generate a
> JUnit report.
> Here is the configuration in my pom file:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.4.1
>
> true
> fast
> broken
>
>
> suitename
> ${artifactId}
>
>
> testname
> ${artifactId}
>
>
>
>
> There is an attached patch too.
--
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-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MWAR-9: Fix Version/s: 2.1 > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mike Perham >Assignee: Stephane Nicoll > Fix For: 2.1 > > Attachments: AbstractWarMojo.patch > > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- 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-109) Problem using webResources in configuration
[ http://jira.codehaus.org/browse/MWAR-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123966 ] Olivier Lamy commented on MWAR-109: --- As we have moved filtering jobs to an other component. This must be fixed now. Can you try with last SNAPSHOT or provide a project to reproduce ? Thanks ! > Problem using webResources in configuration > --- > > Key: MWAR-109 > URL: http://jira.codehaus.org/browse/MWAR-109 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1-alpha-1 >Reporter: David Castro > > I have been trying to get web resources into a resources directory where I > can have them copied over during packaging and filtered as necessary. With > 2.0 the targetPath doesn't work. And with 2.0.2 and 2.0.3-SNAPSHOT I can't > seem to configure without it blowing up at all. They both die at the > IOUtil.copy call in AbstractWarMojo > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > --- > > org.apache.maven.plugins > maven-war-plugin > 2.0.2 > > > > WEB-INF/spring > true > src/main/resources/WEB-INF/spring > > *.xml > *.properties > > > > > > --- > [INFO] Copy webapp webResources to > /home/arimus/workspace-ym/ym/ym-proj/ym-web/target/myapp > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.project.MavenProject cannot be cast to > java.lang.String > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.project.MavenProject cannot be > cast to java.lang.String > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:201) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) > at java.io.Reader.read(Reader.java:123) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administra
[jira] Updated: (MSITE-300) Using maven-shade-plugin instead of forking plexus-utils
[ http://jira.codehaus.org/browse/MSITE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MSITE-300: -- Fix Version/s: 2.0-beta-7 > Using maven-shade-plugin instead of forking plexus-utils > > > Key: MSITE-300 > URL: http://jira.codehaus.org/browse/MSITE-300 > Project: Maven 2.x Site Plugin > Issue Type: Sub-task >Affects Versions: 2.0-beta-6 >Reporter: Vincent Siveton > Fix For: 2.0-beta-7 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-176) javadoc uses the undcoumented and platform unspecific -J-fullversion to determine version instead of the more standardized -J-version
[ http://jira.codehaus.org/browse/MJAVADOC-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123967 ] Vincent Siveton commented on MJAVADOC-176: -- Related thread: http://www.nabble.com/Re%3A-Javadoc-plugin-bug-issue-reprised-td15400050s177.html > javadoc uses the undcoumented and platform unspecific -J-fullversion to > determine version instead of the more standardized -J-version > - > > Key: MJAVADOC-176 > URL: http://jira.codehaus.org/browse/MJAVADOC-176 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: All Platforms >Reporter: Alexander Sack > Fix For: 2.4 > > Attachments: MNG-176-maven-javadoc-plugin.patch > > > The -J-fullversion is not as standardized as the -Jversion across multiple > platforms. On SCO UnixWare 7.1.4, the -J-fullversion returns the equivalent > of the System's java.vm.version which has a non-standard string compared to > the normal -J-version (the output you expect to be java version is > "x.y.z_rev" etc. Its wiser going forward to use just -J-version to determine > the javadoc version number. -- 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-184) Ear utility-jar are put in WEB-INF/lib of the wtp ear
[
http://jira.codehaus.org/browse/MECLIPSE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123940
]
Siarhei Dudzin commented on MECLIPSE-184:
-
Well I thought it does because I saw this (and in more places):
[http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-WhatMavenversionisusedbyplugin]
it says:
{quote}
"Plugin is not actually using Maven itself. It is using component that is part
of Maven called Maven Embedder. This component *is not available for Maven
2.0.x*. Embedder is used by the Maven command line interface (CLI) starting
from version 2.1, so the current version of Embedder *correspond to the Maven
2.1* code line that include number of improvements to allow to actually embed
Maven."
{quote}
I agree with you, Arnaud, on both those plugins - they are pretty far from full
wtp interop yet.
> Ear utility-jar are put in WEB-INF/lib of the wtp ear
> -
>
> Key: MECLIPSE-184
> URL: http://jira.codehaus.org/browse/MECLIPSE-184
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: WTP support
>Affects Versions: 2.3
> Environment: Tested on Windows XP and Linux Ubuntu Dapper Drake
>Reporter: Elid OR
>Assignee: Arnaud Heritier
>Priority: Critical
>
> It seems that the maven eclipse plugin add ear jar dependencies in the
> WEB-INF/lib directory.
> I've used the following command : mvn eclipse:clean
> eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot
> version)
> And when deploy the ear project through WTP in a J2EE Server I see the
> following structure :
> my-ear
> | my-ejb.jar
> | my-webapp.war
> | META-INF/
> | application.xml
> | MANIFEST.MF
> |
> |- WEB-INF/
> | lib
> | dependency-1.jar
> | dependency-2.jar
> But I don't expect these dependencies to be here, I expect something like
> this :
> my-ear
> | my-ejb.jar
> | my-webapp.war
> | META-INF/
> | application.xml
> | MANIFEST.MF
> |
> |- dependency-1.jar
> |- dependency-2.jar
> So I've checked quickly the SVN repository and it seems that the directory in
> which we put "ear utility jar" is hard coded as "WEB-INF/lib" (->
> AbstractWtpResourceWritter.addDependency() which is the same for the war and
> the ear ... )
> Are you OK with this packaging ? It can be a good thing if we could configure
> where wtp will
> put these ear utility-jars and by default it would be in "/" or "lib".
> Thanks In Advance
> Elid OR
--
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: (MDEP-144) Add mojos to copy/unpack dependencies specified by POMs
Add mojos to copy/unpack dependencies specified by POMs --- Key: MDEP-144 URL: http://jira.codehaus.org/browse/MDEP-144 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Affects Versions: 2.0 Reporter: Benjamin Bentmann Assignee: Brian Fox Priority: Minor It would be cool if there were mojos that can read dependencies from other POM files. This would allow to handle dependencies that are external to the current project and not known in advance. The user would feed in a directory (with includes/excludes) which the plugin would scan for POMs. For every POM, the plugin gets direct/transitive dependencies of scope x and copies/unpacks 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: (MWAR-128) war goal does not copy empty directories from webapp directory
[ http://jira.codehaus.org/browse/MWAR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123961 ] Olivier Lamy commented on MWAR-128: --- You cann add an empty file called safeToDelete.tmp in your directory src/main/webapp/WEB-INF/logs/ . > war goal does not copy empty directories from webapp directory > -- > > Key: MWAR-128 > URL: http://jira.codehaus.org/browse/MWAR-128 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2 >Reporter: Ken Geis > > I have an empty directory src/main/webapp/WEB-INF/logs. I expect it to be > created in target when the war goal tells me "Copy webapp webResources to > ..." It does not get created. -- 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-145) Add a mojo parameter for file extensions which must not be filtered.
Add a mojo parameter for file extensions which must not be filtered. Key: MWAR-145 URL: http://jira.codehaus.org/browse/MWAR-145 Project: Maven 2.x War Plugin Issue Type: New Feature Reporter: Olivier Lamy Fix For: 2.1-alpha-2 When filtering is set on for webResouces and overlay, binary files are damaged. Adding a configuration parameter nonFilteredFileExtensions to not filtering a list of file extensions (no default value!). -- 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-145) Add a mojo parameter for file extensions which must not be filtered.
[ http://jira.codehaus.org/browse/MWAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MWAR-145: -- Assignee: Olivier Lamy Affects Version/s: 2.1-alpha-1 Fix Version/s: 2.1-alpha-2 > Add a mojo parameter for file extensions which must not be filtered. > > > Key: MWAR-145 > URL: http://jira.codehaus.org/browse/MWAR-145 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.1-alpha-1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.1-alpha-2 > > > When filtering is set on for webResouces and overlay, binary files are > damaged. > Adding a configuration parameter nonFilteredFileExtensions to not filtering a > list of file extensions (no default value!). -- 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: (SUREFIRE-458) alternative test-class scanner (by type filter)
[
http://jira.codehaus.org/browse/SUREFIRE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-458:
--
Fix Version/s: 2.x
> alternative test-class scanner (by type filter)
>
>
> Key: SUREFIRE-458
> URL: http://jira.codehaus.org/browse/SUREFIRE-458
> Project: Maven Surefire
> Issue Type: Improvement
> Components: plugin
>Affects Versions: 2.4.1
>Reporter: manuel aldana
> Fix For: 2.x
>
>
> hi,
> currently test filtering is done by using the directive, which
> includes test-classes by file name pattern. this approach is sometimes a bit
> annoying for namings of classes are unreliable. test data classes are
> sometimes named like TestDataForXXX or XXXDataForTest so they are included to
> testsuite too.
> a better approach would be to scan test classes by the type. currently we are
> using gsbase-test-suite scanner to accomplish this. it would be cool if this
> kind of scanner would be included in surefire-plugin, so it is not neccessary
> to implement such a collector for each project.
> following code as example (scans for test-classes which are concrete):
> {code:java title=Test-class Scanner}
> import java.lang.reflect.Modifier;
> import com.gargoylesoftware.base.testing.RecursiveTestSuite;
> import com.gargoylesoftware.base.testing.TestFilter;
> import junit.framework.Test;
> /** @author manuel aldana, [EMAIL PROTECTED] */
> public class TestCaseCollector {
> /** @return Testsuite, which returns all concrete Test-classes */
> public static Test suite() throws Exception {
> return new RecursiveTestSuite("target/test-classes", new
> TestFilter() {
> public boolean accept(Class clazz) {
> if (isConcreteTestCase(clazz))
> return true;
> return false;
> }
> });
> }
> private static boolean isConcreteTestCase(Class clazz) {
> if (isAbstractClass(clazz))
> // it is assumed, that abstract classes have no
> superclasses which are concrete test classes
> return false;
> if (clazz.getSuperclass().getName().equals("java.lang.Object"))
> return false;
> if
> (clazz.getSuperclass().getName().equals("junit.framework.TestCase"))
> return true;
> // recurse to parents
> return isConcreteTestCase(clazz.getSuperclass());
> }
> private static boolean isAbstractClass(Class clazz) {
> if (Modifier.isAbstract(clazz.getModifiers()))
> return true;
> return false;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-56) clean up doxia api and code
[ http://jira.codehaus.org/browse/DOXIA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123969 ] Vincent Siveton commented on DOXIA-56: -- Fixed in r628207. Renamed o.a.m.d.s.StructureSink to o.a.m.d.u.StructureSinkUtils. Snapshots deployed. > clean up doxia api and code > --- > > Key: DOXIA-56 > URL: http://jira.codehaus.org/browse/DOXIA-56 > Project: Maven Doxia > Issue Type: Task > Components: Core >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > there is a lot of "throws Exception" and uncertainty in the API. It needs a > clean up before 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: (MWAR-145) Add a mojo parameter for file extensions which must not be filtered.
[
http://jira.codehaus.org/browse/MWAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MWAR-145.
-
Resolution: Fixed
fixed in rev 628218.
Configuration sample
{code:xml}
maven-war-plugin
2.1-alpha-2-SNAPSHOT
jpg
png
{code}
> Add a mojo parameter for file extensions which must not be filtered.
>
>
> Key: MWAR-145
> URL: http://jira.codehaus.org/browse/MWAR-145
> Project: Maven 2.x War Plugin
> Issue Type: New Feature
>Affects Versions: 2.1-alpha-1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 2.1-alpha-2
>
>
> When filtering is set on for webResouces and overlay, binary files are
> damaged.
> Adding a configuration parameter nonFilteredFileExtensions to not filtering a
> list of file extensions (no default value!).
--
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: (MENFORCER-35) Add new rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MENFORCER-35: --- Attachment: require-skin-version.patch Simplified patch by reusing SiteTool.codeToLocale() as recently added by Vincent Siveton. > Add new rule RequireSkinVersion > --- > > Key: MENFORCER-35 > URL: http://jira.codehaus.org/browse/MENFORCER-35 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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-128) war goal does not copy empty directories from webapp directory
[ http://jira.codehaus.org/browse/MWAR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123973 ] Ken Geis commented on MWAR-128: --- That is obvious, Olivier. > war goal does not copy empty directories from webapp directory > -- > > Key: MWAR-128 > URL: http://jira.codehaus.org/browse/MWAR-128 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2 >Reporter: Ken Geis > > I have an empty directory src/main/webapp/WEB-INF/logs. I expect it to be > created in target when the war goal tells me "Copy webapp webResources to > ..." It does not get created. -- 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: (MECLIPSE-373) eclipse:to-maven cannot resolve Required-Bundle: system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-373:
-
Component/s: PDE support
> eclipse:to-maven cannot resolve Required-Bundle: system.bundle
> --
>
> Key: MECLIPSE-373
> URL: http://jira.codehaus.org/browse/MECLIPSE-373
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: OSGi, Manifest, PDE support
>Affects Versions: 2.4, 2.5
> Environment: Observed under MS Windows XP, probably affects all
> environments
>Reporter: Immo Huneke
>
> Install vanilla download of Eclipse RCP Developer (version 3.3.1.1, Europa).
> Try to install its plugins into the local Maven repository using
> mvn -DeclipseDir="/path/to/eclipse" eclipse:to-maven
> The error you get is:
> {code}[INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system
> , artifactId=bundle, version=[0,), type=jar} in project org.apache.xerces
> [INFO]
> {code}
> My investigations have established that this can be worked around by (a)
> creating a Maven artifact called "system.bundle" using file:deploy-file, and
> (b) altering the manifest file to add the specific version number of that
> artifact to the above bundle requirement. You have to do this for every
> single Eclipse plugin that has a dependency on the OSGi system bundle. This
> is very laborious!
> I tried expressing the version number in the manifest as a range, but that
> didn't work. In other cases, where a version range is required, it seems to
> work fine, but not for system.bundle. See my blog at
> http://aspsp.blogspot.com/ for more details.
--
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: (MECLIPSE-373) eclipse:to-maven cannot resolve Required-Bundle: system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-373:
-
Component/s: OSGi, Manifest
> eclipse:to-maven cannot resolve Required-Bundle: system.bundle
> --
>
> Key: MECLIPSE-373
> URL: http://jira.codehaus.org/browse/MECLIPSE-373
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: OSGi, Manifest, PDE support
>Affects Versions: 2.4, 2.5
> Environment: Observed under MS Windows XP, probably affects all
> environments
>Reporter: Immo Huneke
>
> Install vanilla download of Eclipse RCP Developer (version 3.3.1.1, Europa).
> Try to install its plugins into the local Maven repository using
> mvn -DeclipseDir="/path/to/eclipse" eclipse:to-maven
> The error you get is:
> {code}[INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system
> , artifactId=bundle, version=[0,), type=jar} in project org.apache.xerces
> [INFO]
> {code}
> My investigations have established that this can be worked around by (a)
> creating a Maven artifact called "system.bundle" using file:deploy-file, and
> (b) altering the manifest file to add the specific version number of that
> artifact to the above bundle requirement. You have to do this for every
> single Eclipse plugin that has a dependency on the OSGi system bundle. This
> is very laborious!
> I tried expressing the version number in the manifest as a range, but that
> didn't work. In other cases, where a version range is required, it seems to
> work fine, but not for system.bundle. See my blog at
> http://aspsp.blogspot.com/ for more details.
--
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: (MECLIPSE-386) Modified MANIFEST.MF file for eclipse jars packaged from folders with eclipse:to-maven
[ http://jira.codehaus.org/browse/MECLIPSE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-386: - Component/s: PDE support OSGi, Manifest > Modified MANIFEST.MF file for eclipse jars packaged from folders with > eclipse:to-maven > -- > > Key: MECLIPSE-386 > URL: http://jira.codehaus.org/browse/MECLIPSE-386 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: OSGi, Manifest, PDE support >Reporter: Pierre-Arnaud Marcelot > > The MANIFEST.MF file of some Eclipse jars deployed on the > http://repo1.maven.org/maven2 repository using the eclipse:to-maven goal has > been modified. > When using these jars within Eclipse, the jar signing verification fails. > The line "Archiver-Version : Plexus Archiver" has been added to the original > MANIFEST.MF. > This issue seems to apply only on Eclipse jars that are packaged as folder in > the 'plugins' folder of an Eclipse installation. > The following (at least) packages fails verification with eclipse: > * org.eclipse.core.runtime.compatibility.registry plugin, version > 3.2.100-v20070316 > * org.eclipse.ui.workbench.compatibility plugin, version 3.2.0.I20070319-0010 > For instance in the org.eclipse.core.runtime.compatibility.registry plugin, > version 3.2.100-v20070316 plugin, not only the MANIFEST.MF file is modified > in the way I described earlier, but the SHA1-Digest of the > runtime_registry_compatibilty.jar has been changed too (and thus the file > itself). -- 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: (MECLIPSE-387) download source should accept exclusion of artifact
[ http://jira.codehaus.org/browse/MECLIPSE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-387: - Component/s: Core : Dependencies resolution and build path > download source should accept exclusion of artifact > --- > > Key: MECLIPSE-387 > URL: http://jira.codehaus.org/browse/MECLIPSE-387 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Dominique Jean-Prost > > It would be nice to be possible to exclude specific group/artifact when > downloadSources is to true (in pom.xml for instance). > As the sources jar or the javadoc jar will never be available in repo, for > specific artifact, mvn eclipse:eclipse keep on trying to download them, and > it slows the 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: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[
http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123975
]
Brian Fox commented on MNG-3259:
The issue is in the maven-artifact resolver.DefaultArtifactCollector in this
vicinity of this line:
{noformat}
// Also, we need to ensure that any exclusions it
presents are
// added to the artifact before we retrive the
metadata
// for the artifact; otherwise we may end up with
unwanted
// dependencies.
Artifact ma = (Artifact) managedVersions.get(
childKey );
ArtifactFilter managedExclusionFilter =
ma.getDependencyFilter();
if ( null != managedExclusionFilter )
{
System.out.println("Adding Exclusion
Filter:"+ma);
if ( null != artifact.getDependencyFilter() )
{
AndArtifactFilter aaf = new
AndArtifactFilter();
aaf.add( artifact.getDependencyFilter() );
aaf.add( managedExclusionFilter );
artifact.setDependencyFilter( aaf );
}
else
{
artifact.setDependencyFilter(
managedExclusionFilter );
}
}
}
{noformat}
I believe the scope transformation is taking place before the exclusion is
processed, thus the artifact is first dumped out of the compile classpath and
then erroneously excluded.
> Regression: Maven drops dependencies in multi-module build
> --
>
> Key: MNG-3259
> URL: http://jira.codehaus.org/browse/MNG-3259
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.7, 2.0.8
>Reporter: Joerg Schaible
>Assignee: Brian Fox
>Priority: Blocker
> Fix For: 2.0.9
>
> Attachments: MNG-3259-2.zip, MNG-3259.zip
>
> Time Spent: 5 hours
> Remaining Estimate: 0 minutes
>
> Under some circumstances Maven "forgets" about test dependencies in
> multi-module builds. The affected module can be build only if the build is
> started from its local project directory. If the build is run from a parent
> directory, the test fails because of missing classes. This issue applies to
> M207 and recent M208-RC1, the project can be build without problems with M205
> (M206 is completely bogus). The problem was for us already the show stopper
> for M207 and I thought with some of the now resolved issues it has been gone,
> but I was wrong. I did not report it earlier, because I was never able to
> reproduce the problem with a minimal build ... until now and it took me about
> 3 days to create a demonstrating multi module 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] Updated: (MECLIPSE-379) When downloading sources and javadocs dependency classifier is not respected.
[ http://jira.codehaus.org/browse/MECLIPSE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-379: - Fix Version/s: 2.5 > When downloading sources and javadocs dependency classifier is not respected. > - > > Key: MECLIPSE-379 > URL: http://jira.codehaus.org/browse/MECLIPSE-379 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 > Environment: windows vista ultimate > java 1.6_01 > maven-2.0.8 >Reporter: Erick Dovale > Fix For: 2.5 > > > When running goal eclipse:eclipse with downloadSources and downloadJavadocs > set to true this plugin tries to download the javadocs and sources without > appending the classifier value to the name of the files to download. > Eg. json-lib uses clsasifiers for the java version. This is how the > dependency is defined in my pom.xml: > > net.sf.json-lib > json-lib > 2.2 > jdk15 > compile > > This is the relevant output of running mvn eclipse:eclipse for the sources: > Downloading: > http://mikemps.no-ip.com/artifactory/repo/net/sf/json-lib/json-lib/2.2/json-lib-2.2-sources.jar > Downloading: > http://repo1.maven.org/maven2/net/sf/json-lib/json-lib/2.2/json-lib-2.2-sources.jar > Downloading: > http://download.java.net/maven/1/net.sf.json-lib/java-sources/json-lib-2.2-sources.jar > and for the javadocs: > Downloading: > http://mikemps.no-ip.com/artifactory/repo/net/sf/json-lib/json-lib/2.2/json-lib-2.2-javadoc.jar > Downloading: > http://repo1.maven.org/maven2/net/sf/json-lib/json-lib/2.2/json-lib-2.2-javadoc.jar > Downloading: > http://download.java.net/maven/1/net.sf.json-lib/javadocs/json-lib-2.2-javadoc.jar > If the classifier was taken into consideration then the file names would > starts with json-lib-2.2-jdk15-.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] Updated: (MECLIPSE-384) New-in-2.5 javadoc attaching can produce annoyingly verbose output.
[ http://jira.codehaus.org/browse/MECLIPSE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-384: - Component/s: Core : Dependencies resolution and build path > New-in-2.5 javadoc attaching can produce annoyingly verbose output. > --- > > Key: MECLIPSE-384 > URL: http://jira.codehaus.org/browse/MECLIPSE-384 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path >Affects Versions: 2.5 >Reporter: Max Bowsher >Priority: Minor > > I'm trying out maven-eclipse-plugin 2.5-SNAPSHOT, and I've noticed I now get: >Javadoc for some artifacts is not available. >Please run the same goal with the -DdownloadJavadoc=true parameter in > order to check remote repositories for javadoc. >List of artifacts without a javadoc archive: > o > Which is fine and true, but the list is so long it fills even a full-screen > terminal and pushes potentially useful output off-screen - and since > downloadJavadoc is off (and I don't particularly want to turn it on), it's > unsurprising that the maven-eclipse-plugin can't find any. > Is there any reason to display this list when downloadJavadoc is false? -- 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-332) mvn-eclipse-cache.properties is never filled
[ http://jira.codehaus.org/browse/MECLIPSE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123974 ] Arnaud Heritier commented on MECLIPSE-332: -- I never succeeded to reproduce it :-( If someone has a test-case to help us to reproduce it. Wat is the version of maven ? > mvn-eclipse-cache.properties is never filled > > > Key: MECLIPSE-332 > URL: http://jira.codehaus.org/browse/MECLIPSE-332 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Wouter de Vaal > > See summary, the file is writen, but no data is in it, resulting in very long > builds each time the eclipse update is needed. -- 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: (MECLIPSE-377) eclipse:eclipse -DdownloadSources=true shouldn't attempt download more than once in a multi-project
[ http://jira.codehaus.org/browse/MECLIPSE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-377: - Component/s: Core : Dependencies resolution and build path > eclipse:eclipse -DdownloadSources=true shouldn't attempt download more than > once in a multi-project > --- > > Key: MECLIPSE-377 > URL: http://jira.codehaus.org/browse/MECLIPSE-377 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path, Core : > Multi-projects >Affects Versions: 2.4 >Reporter: Steinar Bang > > If you run "mvn eclipse:eclipse -DdownloadSources=true" it attempts to > download source jars for all projects, even when it has tried (and failed) to > download the jars in earlier projects. This slows down the goal a lot on > slow network connections. -- 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: (MECLIPSE-376) Project site documentation is wrong
[ http://jira.codehaus.org/browse/MECLIPSE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-376. Assignee: Arnaud Heritier Resolution: Fixed Fixed. I redeployed 2.4 web site. > Project site documentation is wrong > --- > > Key: MECLIPSE-376 > URL: http://jira.codehaus.org/browse/MECLIPSE-376 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Plugin Documentation >Affects Versions: 2.4 >Reporter: TJ Herring >Assignee: Arnaud Heritier > > The public documentation site contains the documentation for version 2.5 > which has not been released. Since 2.4 is current, should you revert the > site to 2.4? > When is 2.5 going to be released? -- 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: (SUREFIRE-452) suitename always = "TestSuite" even if defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123977
]
Erez Nahir commented on SUREFIRE-452:
-
First, thanks for applying this patch, it will allow me to move to surefire as
soon as 2.4.2 gets out.
I'll save you the story why in a 100+ engineers team with 100+ maven
components, this is a blocking issue, but believe me, without it, I can use
surefire (although I agree it's not broken).
Thanks again.
> suitename always = "TestSuite" even if defined as property
> --
>
> Key: SUREFIRE-452
> URL: http://jira.codehaus.org/browse/SUREFIRE-452
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4, 2.4.1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> and also on Linux
>Reporter: Erez Nahir
> Fix For: 2.4.2
>
> Attachments: TestNGDirectoryTestSuite.java,
> TestNGDirectoryTestSuite.java
>
>
> Using surefire and testng with no testng.xml but with , the
> generated standard output xml always have suite name="TestSuite".
> This is an issue while using CruiseControl and JUnitReport to generate a
> JUnit report.
> Here is the configuration in my pom file:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.4.1
>
> true
> fast
> broken
>
>
> suitename
> ${artifactId}
>
>
> testname
> ${artifactId}
>
>
>
>
> There is an attached patch too.
--
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: (MWAR-109) Problem using webResources in configuration
[ http://jira.codehaus.org/browse/MWAR-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-109. Resolution: Duplicate Fix Version/s: 2.1-alpha-2 It really looks like the other one. Let's fix this as duplicate. David, reopen if you can still reproduce. > Problem using webResources in configuration > --- > > Key: MWAR-109 > URL: http://jira.codehaus.org/browse/MWAR-109 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1-alpha-1 >Reporter: David Castro > Fix For: 2.1-alpha-2 > > > I have been trying to get web resources into a resources directory where I > can have them copied over during packaging and filtered as necessary. With > 2.0 the targetPath doesn't work. And with 2.0.2 and 2.0.3-SNAPSHOT I can't > seem to configure without it blowing up at all. They both die at the > IOUtil.copy call in AbstractWarMojo > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > --- > > org.apache.maven.plugins > maven-war-plugin > 2.0.2 > > > > WEB-INF/spring > true > src/main/resources/WEB-INF/spring > > *.xml > *.properties > > > > > > --- > [INFO] Copy webapp webResources to > /home/arimus/workspace-ym/ym/ym-proj/ym-web/target/myapp > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.project.MavenProject cannot be cast to > java.lang.String > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.project.MavenProject cannot be > cast to java.lang.String > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:201) > at > org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) > at java.io.Reader.read(Reader.java:123) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) > at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) > at > org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly co
[jira] Closed: (MECLIPSE-332) mvn-eclipse-cache.properties is never filled
[ http://jira.codehaus.org/browse/MECLIPSE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wouter de Vaal closed MECLIPSE-332. --- Resolution: Fixed Fix Version/s: 2.5 I've tested this by setting 2.4 on the plugin and there the problem exists, however removing the version tag and using the latest version, the problem is gone. > mvn-eclipse-cache.properties is never filled > > > Key: MECLIPSE-332 > URL: http://jira.codehaus.org/browse/MECLIPSE-332 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Wouter de Vaal > Fix For: 2.5 > > > See summary, the file is writen, but no data is in it, resulting in very long > builds each time the eclipse update is needed. -- 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
