[jira] Created: (MEV-615) Synchronize JSignature repository with repo1
Synchronize JSignature repository with repo1 Key: MEV-615 URL: http://jira.codehaus.org/browse/MEV-615 Project: Maven Evangelism Issue Type: Wish Reporter: Davide Simonetti Hi, I'm the owner of the project jsignature at sourceforge.net. I'd like my repository is kept in sync with repo1. as a proof of ownership i uploaded the following page: http://jsignature.sourceforge.net/mantainers.html "net.sf.jsignature","mavens...@web.sourceforge.net:/home/groups/j/js/jsignature/htdocs/maven2","rsync_ssh","Simonetti Davide","dvd.s...@gmail.com",, Best Regards Davide -- 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: (MEV-615) Synchronize JSignature repository with repo1
[ http://jira.codehaus.org/browse/MEV-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Simonetti closed MEV-615. Resolution: Fixed sorry i open an issue on the wrong project by mistake > Synchronize JSignature repository with repo1 > > > Key: MEV-615 > URL: http://jira.codehaus.org/browse/MEV-615 > Project: Maven Evangelism > Issue Type: Wish >Reporter: Davide Simonetti > > Hi, > I'm the owner of the project jsignature at sourceforge.net. I'd like my > repository is kept in sync with repo1. > as a proof of ownership i uploaded the following page: > http://jsignature.sourceforge.net/mantainers.html > "net.sf.jsignature","mavens...@web.sourceforge.net:/home/groups/j/js/jsignature/htdocs/maven2","rsync_ssh","Simonetti > Davide","dvd.s...@gmail.com",, > Best Regards > Davide -- 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-2337) Synchronize JSignature repository with repo1
Synchronize JSignature repository with repo1 Key: MAVENUPLOAD-2337 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2337 Project: Maven Upload Requests Issue Type: Wish Reporter: Davide Simonetti Hi, I'm the owner of the project jsignature at sourceforge.net. I'd like my repository is kept in sync with repo1. "net.sf.jsignature","mavens...@web.sourceforge.net:/home/groups/j/js/jsignature/htdocs/maven2","rsync_ssh","Simonetti Davide","dvd.s...@gmail.com",, Best Regards Davide -- 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162018#action_162018
]
Martin Nilsson commented on SCM-406:
I have experienced the same problem, but after changing the protocol from http
to svn (i.e. using svnserve instead of apache) I managed to release without the
error.
I'm using svn 1.5.5
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (DOXIA-254) Using the last version of modello-maven-plugin
[ http://jira.codehaus.org/browse/DOXIA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-254: -- Attachment: testInheritence.diff The tests like testInheritence() were originally wrong. I tried to debug the mergedModel and childModel object using Xstream. The attachment shows the Xstream differences: mainly links in childModel should be .. (dotdot) I will fix tests under latest Modello. > Using the last version of modello-maven-plugin > -- > > Key: DOXIA-254 > URL: http://jira.codehaus.org/browse/DOXIA-254 > Project: Maven Doxia > Issue Type: Task > Components: Decoration Model >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Olivier Lamy > Fix For: 1.1 > > Attachments: DOXIA-254, testInheritence.diff > > > modello-maven-plugin:1.0-alpha-21 produces errors in doxia-decoration-model > 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] Closed: (DOXIA-254) Using the last version of modello-maven-plugin
[ http://jira.codehaus.org/browse/DOXIA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-254. - Assignee: Vincent Siveton (was: Olivier Lamy) Resolution: Fixed fixed in [r736628|http://svn.apache.org/viewvc?rev=736628&view=rev] > Using the last version of modello-maven-plugin > -- > > Key: DOXIA-254 > URL: http://jira.codehaus.org/browse/DOXIA-254 > Project: Maven Doxia > Issue Type: Task > Components: Decoration Model >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > Attachments: DOXIA-254, testInheritence.diff > > > modello-maven-plugin:1.0-alpha-21 produces errors in doxia-decoration-model > project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162050#action_162050 ] Christophe Lallement commented on MCHANGES-106: --- I confirm we have the same problem. The JIRA url dump on the log is [INFO] Downloading from JIRA at: https:///jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&resolutionIds=1&tempMax=25&reset=true&decorator=none this request return an empty list of release/issue. Te same think when i make this request into a browser (with authentication or not) we use JIRA Version: 3.12.1-#299 Regards > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-report.log, jira-results.xml, > jira-results.xml, pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- 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-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162058#action_162058 ] Timothy Twelves commented on MNG-2205: -- Hi, In the context of a "war" a dependency that is "provided" can mean 1 of two things: 1. It is provided within the application ear OR 2. It is provided by the environment. The solution for (1) is easy because we could have "provided" being transitive and have the ear-plugin package the "provided" dependencies. The solution for (2) is tricky because (as in the servlets example) we need it for compilation and we do NOT want it packaged by the ear-plugin since it is provided by the appserver or jvm path. I considered "runtime" but this would make it unavailable during compilation and with the servlet -api example we need those dependencies during compilation. "optional" for (2) works fine however the reasons why it works are not obvious to the layman. The solution is to introduce a new state called "environmental" and duplicate functionality around "optional". Make a "provided" transitive and have all class-packaging plugins (maven-ear-plugin, maven-war-plugin) support the correct packaging of "provided" dependencies. >From my understanding of the maven code base (i've been digging) this is >relatively do-able and the semantic changes are not going to be too bad >considering the way people work around the problem of creating wars. I have >only one problem which is the need to rewrite the manifest within jar/war/etc >to support bundled libraries with different jar locations and signed jar/wars >but again i believe this can be managed in the context of how people work >around skinny jars at the moment. -Tim > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can 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: (MNG-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162059#action_162059 ] Timothy Twelves commented on MNG-2205: -- Just to clarify around "optional" i am referring to a "compile" dependencies that are marked optional. This means that "environmental" dependencies will be there for compilation, tests, execution within maven but excluded from packaging. Alternatively you could leave "provided" the way it is and add a new dependency type called "application" that is intended to be provided and packaged by the deliverable application component (war, ear, etc). In the context of a war an dependency marked "application" must be packaged by the ear. -Tim > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can 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: (DOXIA-278) Character encoding autodetection fails for APT source files
Character encoding autodetection fails for APT source files --- Key: DOXIA-278 URL: http://jira.codehaus.org/browse/DOXIA-278 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.0-alpha-11 Environment: Mac OS X 10.5.6, Java 1.6.0_07 Reporter: Trevor Harmon Attachments: HelloWorld.zip Doxia unnecessarily forces all APT source files to be encoded in ISO-8859-1. Files encoded in UTF-8 can have garbage characters as a result. Doxia should be able to autodetect the encoding of the APT file to prevent this problem, as it already does for XML (see DOXIA-133). A test case is attached. It includes two APT source files, one encoded in ISO-8859-1 and another encoded in UTF-8. Both contain the copyright symbol. To reproduce the problem, simply run "mvn site" on the project and open the target/site/test-utf8.html and target/site/test-iso-8859-1.html. The file encoded with ISO-8859-1 should display the copyright symbol correctly, while the one encoded with UTF-8 contains a garbage character immediately before the symbol. -- 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-278) Character encoding autodetection fails for APT source files
[ http://jira.codehaus.org/browse/DOXIA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162067#action_162067 ] Trevor Harmon commented on DOXIA-278: - Another user complained of this problem a few years ago: http://www.mailinglistarchive.com/us...@maven.apache.org/msg21983.html > Character encoding autodetection fails for APT source files > --- > > Key: DOXIA-278 > URL: http://jira.codehaus.org/browse/DOXIA-278 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-11 > Environment: Mac OS X 10.5.6, Java 1.6.0_07 >Reporter: Trevor Harmon > Attachments: HelloWorld.zip > > > Doxia unnecessarily forces all APT source files to be encoded in ISO-8859-1. > Files encoded in UTF-8 can have garbage characters as a result. Doxia should > be able to autodetect the encoding of the APT file to prevent this problem, > as it already does for XML (see DOXIA-133). > A test case is attached. It includes two APT source files, one encoded in > ISO-8859-1 and another encoded in UTF-8. Both contain the copyright symbol. > To reproduce the problem, simply run "mvn site" on the project and open the > target/site/test-utf8.html and target/site/test-iso-8859-1.html. The file > encoded with ISO-8859-1 should display the copyright symbol correctly, while > the one encoded with UTF-8 contains a garbage character immediately before > the symbol. -- 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-367) add skip parameter for multimodule project
[ http://jira.codehaus.org/browse/MSITE-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162068#action_162068 ] Jörg Hohwiller commented on MSITE-367: -- Shouldn't this be covered by a general feature for maven (2.1) instead of re-inventing the wheel for every plugin? > add skip parameter for multimodule project > -- > > Key: MSITE-367 > URL: http://jira.codehaus.org/browse/MSITE-367 > Project: Maven 2.x Site Plugin > Issue Type: New Feature > Components: multi module >Reporter: Martijn Dashorst > > When generating a multi module site, give the possibility to skip a module > from site generation similar to the javadoc plugin. > something like a way to exclude the site plugin to run for a specific > modulebest configured in the submodule's site configuration. -- 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-356) Be able to provide username/password as CLI parameters (and not only from settings.xml)
[ http://jira.codehaus.org/browse/MSITE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162069#action_162069 ] Jörg Hohwiller commented on MSITE-356: -- I agree. However I think this is to be targeted by maven itself (in 2.1) rather the site-plugin. > Be able to provide username/password as CLI parameters (and not only from > settings.xml) > --- > > Key: MSITE-356 > URL: http://jira.codehaus.org/browse/MSITE-356 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: site:deploy >Affects Versions: 2.0-beta-7 > Environment: N/A >Reporter: David J. M. Karlsen > > It would be very handy if it was possible to provide username and credentials > as CLI params (-Dusername -Dpassword) when doing site:stage-deploy -- 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-278) Character encoding autodetection fails for APT source files
[ http://jira.codehaus.org/browse/DOXIA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162070#action_162070 ] Trevor Harmon commented on DOXIA-278: - As a workaround, it is possible to tell Doxia to use UTF-8 explicitly by adding the following plugin declaration: maven-site-plugin UTF-8 However, this has the side effect of breaking all non-UTF-8 files. Doxia should be able to detect the input encoding automatically. > Character encoding autodetection fails for APT source files > --- > > Key: DOXIA-278 > URL: http://jira.codehaus.org/browse/DOXIA-278 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-11 > Environment: Mac OS X 10.5.6, Java 1.6.0_07 >Reporter: Trevor Harmon > Attachments: HelloWorld.zip > > > Doxia unnecessarily forces all APT source files to be encoded in ISO-8859-1. > Files encoded in UTF-8 can have garbage characters as a result. Doxia should > be able to autodetect the encoding of the APT file to prevent this problem, > as it already does for XML (see DOXIA-133). > A test case is attached. It includes two APT source files, one encoded in > ISO-8859-1 and another encoded in UTF-8. Both contain the copyright symbol. > To reproduce the problem, simply run "mvn site" on the project and open the > target/site/test-utf8.html and target/site/test-iso-8859-1.html. The file > encoded with ISO-8859-1 should display the copyright symbol correctly, while > the one encoded with UTF-8 contains a garbage character immediately before > the symbol. -- 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-3998) Loss of execution configuration
Loss of execution configuration --- Key: MNG-3998 URL: http://jira.codehaus.org/browse/MNG-3998 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.0-alpha-2 Reporter: Shane Isbell Fix For: 3.0-alpha-2 Lose an execution configuration if there are two or more executions with configuration and pluginManagement rule is applied. -- 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-3998) Loss of execution configuration
[ http://jira.codehaus.org/browse/MNG-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3998: -- Fix Version/s: 3.0-alpha-2 > Loss of execution configuration > --- > > Key: MNG-3998 > URL: http://jira.codehaus.org/browse/MNG-3998 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0-alpha-2 >Reporter: Shane Isbell > Fix For: 3.0-alpha-2 > > > Lose an execution configuration if there are two or more executions with > configuration and pluginManagement rule is applied. -- 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-3886) [regression] Ordering of goals from a plugin execution is not respected if plugin management applies
[
http://jira.codehaus.org/browse/MNG-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3886:
--
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-2
> [regression] Ordering of goals from a plugin execution is not respected if
> plugin management applies
>
>
> Key: MNG-3886
> URL: http://jira.codehaus.org/browse/MNG-3886
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-2
>
>
> For a POM snippet like
> {code:xml}
>
> test
> validate
>
> one
> two
>
>
> {code}
> the effective execution order of the specified goals is either [one, two] or
> [two, one] depending on the existence of {{}} for the
> plugin in question.
--
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-3925) [regression] Wrong order of plugin executions after merge with executions inherted from parent
[
http://jira.codehaus.org/browse/MNG-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3925:
--
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-2
Need to start bringing these into alpha-2 to get projects like nexus building.
> [regression] Wrong order of plugin executions after merge with executions
> inherted from parent
> --
>
> Key: MNG-3925
> URL: http://jira.codehaus.org/browse/MNG-3925
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-2
>
>
> In Maven 2.x, plugin executions defined by the child are appended to the list
> of executions inherited from the parent. Maven 3.x breaks this behavior
> (currently also depending on the usage of {{}}.
--
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-3887) [regression] Order of plugin executions within same phase does not match POM order when plugin management is used
[
http://jira.codehaus.org/browse/MNG-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3887:
--
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-2
> [regression] Order of plugin executions within same phase does not match POM
> order when plugin management is used
> -
>
> Key: MNG-3887
> URL: http://jira.codehaus.org/browse/MNG-3887
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-2
>
>
> For a POM snippet like
> {code:xml}
>
>
> test-1
> validate
>
> one
>
>
>
> test-2
> validate
>
> two
>
>
>
> {code}
> the effective goal execution order is either [one, two] or [two, one]
> depending on the usage of {{}} for the plugin in question.
--
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: (ARCHETYPE-225) Add Camel archetypes to internal catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp closed ARCHETYPE-225. - Assignee: Daniel Kulp Resolution: Fixed > Add Camel archetypes to internal catalog > > > Key: ARCHETYPE-225 > URL: http://jira.codehaus.org/browse/ARCHETYPE-225 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes >Reporter: Jonathan Anstey >Assignee: Daniel Kulp > Attachments: camel-archetypes.patch > > > It would be nice if someone could add the Apache Camel archetypes to the > internal catalog. I've attached a patch so it would be really easy to do :) -- 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-278) Character encoding autodetection fails for APT source files
[
http://jira.codehaus.org/browse/DOXIA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed DOXIA-278.
---
Assignee: Herve Boutemy
Resolution: Not A Bug
auto-detecting encoding isn't a bullet-proof feature: nobody can assure to
really detect encoding of a byte stream, the better that can be done is a
guess, without any guarantee
XML encoding selection is possible because encoding is written into the XML
document in a [precise
manner|http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing]: here, we have
automatic encoding *selection*. If the stream effective encoding is different
from the encoding in {{}}, there will be broken
characters because the parser is using what is told is the header.
FYI, there has already been a [long discussion in Maven dev
list|http://www.nabble.com/-VOTE--POM-Element-for-Source-File-Encoding-to16515820.html#a16558356]
about this
APT format does not provide such a convention: it's pure text, without encoding
information.
If a convention similar to the XML convention was added.
bq. an APT file starting with {{~~ encoding="xxx"}} should be considered as
being written in the specified encoding
we could implement a text reader using it.
Don't know if such a comment at APT file start is copmpatible with title
headers though...
Last point: the user complaining about encoding problems you show was hitting a
real bug, when encoding wasn't properly handled in Doxia and maven-site-plugin
this is fixed now: see MSITE-314 and [POM Element for Source File
Encoding|http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding]
> Character encoding autodetection fails for APT source files
> ---
>
> Key: DOXIA-278
> URL: http://jira.codehaus.org/browse/DOXIA-278
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Apt
>Affects Versions: 1.0-alpha-11
> Environment: Mac OS X 10.5.6, Java 1.6.0_07
>Reporter: Trevor Harmon
>Assignee: Herve Boutemy
> Attachments: HelloWorld.zip
>
>
> Doxia unnecessarily forces all APT source files to be encoded in ISO-8859-1.
> Files encoded in UTF-8 can have garbage characters as a result. Doxia should
> be able to autodetect the encoding of the APT file to prevent this problem,
> as it already does for XML (see DOXIA-133).
> A test case is attached. It includes two APT source files, one encoded in
> ISO-8859-1 and another encoded in UTF-8. Both contain the copyright symbol.
> To reproduce the problem, simply run "mvn site" on the project and open the
> target/site/test-utf8.html and target/site/test-iso-8859-1.html. The file
> encoded with ISO-8859-1 should display the copyright symbol correctly, while
> the one encoded with UTF-8 contains a garbage character immediately before
> the symbol.
--
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-3998) Loss of execution configuration
[ http://jira.codehaus.org/browse/MNG-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162082#action_162082 ] Shane Isbell commented on MNG-3998: --- This required a small change in model-builder, so once I get that release, I'll check in test to maven. > Loss of execution configuration > --- > > Key: MNG-3998 > URL: http://jira.codehaus.org/browse/MNG-3998 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0-alpha-2 >Reporter: Shane Isbell >Assignee: Shane Isbell > Fix For: 3.0-alpha-2 > > > Lose an execution configuration if there are two or more executions with > configuration and pluginManagement rule is applied. -- 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-3886) [regression] Ordering of goals from a plugin execution is not respected if plugin management applies
[
http://jira.codehaus.org/browse/MNG-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162084#action_162084
]
Shane Isbell commented on MNG-3886:
---
Have this one fixed. Will check in after release of model-builder.
> [regression] Ordering of goals from a plugin execution is not respected if
> plugin management applies
>
>
> Key: MNG-3886
> URL: http://jira.codehaus.org/browse/MNG-3886
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-2
>
>
> For a POM snippet like
> {code:xml}
>
> test
> validate
>
> one
> two
>
>
> {code}
> the effective execution order of the specified goals is either [one, two] or
> [two, one] depending on the existence of {{}} for the
> plugin in question.
--
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: (MRELEASE-156) Prompt for customizing commit comment during release preparation
[
http://jira.codehaus.org/browse/MRELEASE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161982#action_161982
]
Andreas Dejung edited comment on MRELEASE-156 at 1/22/09 4:26 PM:
--
I found the place where tag message is created.
In org.apache.maven.shared.release.phaseScmCommitPhase from the
maven-release-manager project line 164 and 165:
return MessageFormat.format( releaseDescriptor.getScmCommentPrefix() +
messageFormat,
new
Object[]{releaseDescriptor.getScmReleaseLabel()} );
If that would be changed to
String
noTagMessageExtention=System.getProperty("noTagMessageExtention",null);
if(noTagMessageExtention!=null){
return releaseDescriptor.getScmReleaseLabel();
}else{
return MessageFormat.format( releaseDescriptor.getScmCommentPrefix() +
messageFormat,
new
Object[]{releaseDescriptor.getScmReleaseLabel()} );
}
Then it would not change the message.
So far so good. The problem I got now is I can not build the
maven-release-manager. Or better the mvn install works fine but when I try to
run the project I get :
E:\eclipse3.4\test\tool-configuration\target\checkout>mvn release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building Tool configuration
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-release-plugin:2.0-beta-8:prepare'
: Unable to find the mojo
'org.apache.maven.plugins:maven-release-plugin:2.0-beta-8:prepare' in the
plugin 'org.apache.maven.
plugins:maven-release-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.scm.manager.ScmManagerdefault.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Thu Jan 22 10:57:19 CST 2009
[INFO] Final Memory: 7M/14M
[INFO]
Any help on that ?
Cheers Andreas
was (Author: adejung):
I found the place where tag message is created.
In org.apache.maven.shared.release.phaseScmCommitPhase from the
maven-release-manager project line 164 and 165:
return MessageFormat.format( releaseDescriptor.getScmCommentPrefix() +
messageFormat,
new
Object[]{releaseDescriptor.getScmReleaseLabel()} );
If that would be changed to
String
noTagMessageExtention=System.getProperty("noTagMessageExtention",null);
if(noTagMessageExtention==null){
return releaseDescriptor.getScmReleaseLabel();
}else{
return MessageFormat.format( releaseDescriptor.getScmCommentPrefix() +
messageFormat,
new
Object[]{releaseDescriptor.getScmReleaseLabel()} );
}
Then it would not change the message.
So far so good. The problem I got now is I can not build the
maven-release-manager. Or better the mvn install works fine but when I try to
run the project I get :
E:\eclipse3.4\test\tool-configuration\target\checkout>mvn release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO]
[INFO] Building Tool configuration
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-release-plugin:2.0-beta-8:prepare'
: Unable to find the mojo
'org.apache.maven.plugins:maven-release-plugin:2.0-beta-8:prepare' in the
plugin 'org.apache.maven.
plugins:maven-release-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.scm.manager.ScmManagerdefault.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO]
[jira] Commented: (DOXIA-254) Using the last version of modello-maven-plugin
[ http://jira.codehaus.org/browse/DOXIA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162093#action_162093 ] Dennis Lundberg commented on DOXIA-254: --- Thanks for looking into this Vincent. I have been trying to fix this on the 1.0.x branch before I release 1.0. Do you think it's possible/preferable to merge r736628 to the 1.0.x branch? > Using the last version of modello-maven-plugin > -- > > Key: DOXIA-254 > URL: http://jira.codehaus.org/browse/DOXIA-254 > Project: Maven Doxia > Issue Type: Task > Components: Decoration Model >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > Attachments: DOXIA-254, testInheritence.diff > > > modello-maven-plugin:1.0-alpha-21 produces errors in doxia-decoration-model > 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] Created: (MAVENUPLOAD-2338) Upload maven-timestamp-plugin 1.0
Upload maven-timestamp-plugin 1.0 - Key: MAVENUPLOAD-2338 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338 Project: Maven Upload Requests Issue Type: Wish Reporter: Antonio Agudo Please upload the maven-timestamp-plugin bundle from http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central repository. Thank you very much. -- 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-2338) Upload maven-timestamp-plugin 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162098#action_162098 ] Dan Tran commented on MAVENUPLOAD-2338: --- what does it do? the site shows nothing > Upload maven-timestamp-plugin 1.0 > - > > Key: MAVENUPLOAD-2338 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Antonio Agudo > > Please upload the maven-timestamp-plugin bundle from > http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central > repository. > Thank you very much. -- 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-2338) Upload maven-timestamp-plugin 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162101#action_162101 ] Antonio Agudo commented on MAVENUPLOAD-2338: Yeah I know. That's because I didn't mess with the apt yet. But anyways, I updated the start doc for the sake of completeness: http://keyboardsamurais.com/projects/maven-timestamp-plugin/site/ > Upload maven-timestamp-plugin 1.0 > - > > Key: MAVENUPLOAD-2338 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Antonio Agudo > > Please upload the maven-timestamp-plugin bundle from > http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central > repository. > Thank you very much. -- 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-2338) Upload maven-timestamp-plugin 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162102#action_162102 ] Dan Tran commented on MAVENUPLOAD-2338: --- why are you not using buildnumber-maven-plugin? > Upload maven-timestamp-plugin 1.0 > - > > Key: MAVENUPLOAD-2338 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Antonio Agudo > > Please upload the maven-timestamp-plugin bundle from > http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central > repository. > Thank you very much. -- 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: (MSHADE-30) duplicate entry error
[ http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162103#action_162103 ] Roger Pack commented on MSHADE-30: -- could you do me a favor and provide an example of said "non-sense " stuffs? Also for me, at least, changing pom.xml to say maven-shade-plugin 1.2 fixed it. Thanks much. -=r > duplicate entry error > - > > Key: MSHADE-30 > URL: http://jira.codehaus.org/browse/MSHADE-30 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0.1 >Reporter: Michael Mattox >Assignee: Benjamin Bentmann > Fix For: 1.2 > > Attachments: mshade-30-patch.txt > > > I receive this error: > Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class > It started with a javax.xml.namespace class. So I started putting excludes, > and then I kept getting one new class after another. If I exclude everything > then I doubt my application is going to work. > I really don't understand this error. I have never seen this type of error > with the fatjar eclipse plugin. I understand it's complaining about having > the same class twice, but if it's not a problem for my eclipse project or the > maven build, why is it a problem for shade? > I feel the shade plugin should be able to handle this gracefully. -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162112#action_162112 ] Oleg Gusakov commented on MNG-553: -- I started adding this to 2.1 trunk > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 2.2.0-M1 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- 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: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162112#action_162112 ] Oleg Gusakov edited comment on MNG-553 at 1/22/09 9:15 PM: --- I started adding this to 2.1 trunk according to http://docs.codehaus.org/display/MAVEN/Secured+Passwords was (Author: olle): I started adding this to 2.1 trunk > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 2.2.0-M1 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- 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-254) Using the last version of modello-maven-plugin
[ http://jira.codehaus.org/browse/DOXIA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162117#action_162117 ] Vincent Siveton commented on DOXIA-254: --- Dennis, I was thinking to ping you since you are our official branch maintainer! So feel free to do it :) > Using the last version of modello-maven-plugin > -- > > Key: DOXIA-254 > URL: http://jira.codehaus.org/browse/DOXIA-254 > Project: Maven Doxia > Issue Type: Task > Components: Decoration Model >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > Attachments: DOXIA-254, testInheritence.diff > > > modello-maven-plugin:1.0-alpha-21 produces errors in doxia-decoration-model > project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-254) Using the last version of modello-maven-plugin
[ http://jira.codehaus.org/browse/DOXIA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162118#action_162118 ] Vincent Siveton commented on DOXIA-254: --- An other comment, FYI the generated XSD is actually wrong, but it is fixed with the modello beta-1 > Using the last version of modello-maven-plugin > -- > > Key: DOXIA-254 > URL: http://jira.codehaus.org/browse/DOXIA-254 > Project: Maven Doxia > Issue Type: Task > Components: Decoration Model >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > Attachments: DOXIA-254, testInheritence.diff > > > modello-maven-plugin:1.0-alpha-21 produces errors in doxia-decoration-model > project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162119#action_162119 ] Haikal Saadh commented on MECLIPSE-94: -- Also consider a use case such as the integration builds module from "Better Builds.." If I import such a module, m2eclipse generates a project with a layout like this: !http://content.screencast.com/users/tunaranch/folders/Jing/media/63a6b364-1c5f-499c-add6-65b7d2677714/0074.png! I would expect an eclipse:m2eclipse to generate the same structure. > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > Attachments: MECLIPSE-94.patch > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162119#action_162119 ] Haikal Saadh edited comment on MECLIPSE-94 at 1/22/09 10:17 PM: Also consider a use case such as the integration builds module from "Better Builds.." If I import such a module, m2eclipse generates a project with a layout like this: !http://content.screencast.com/users/tunaranch/folders/Jing/media/63a6b364-1c5f-499c-add6-65b7d2677714/0074.png! This is a proper java project, with classpaths, builders, and all the rest of it configured. I can edit java in src/test/java as if it were a jar project. I would expect an eclipse:m2eclipse to generate the same structure. was (Author: tunaranch): Also consider a use case such as the integration builds module from "Better Builds.." If I import such a module, m2eclipse generates a project with a layout like this: !http://content.screencast.com/users/tunaranch/folders/Jing/media/63a6b364-1c5f-499c-add6-65b7d2677714/0074.png! I would expect an eclipse:m2eclipse to generate the same structure. > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > Attachments: MECLIPSE-94.patch > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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-2338) Upload maven-timestamp-plugin 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162134#action_162134 ] Antonio Agudo commented on MAVENUPLOAD-2338: Well, to be honest, when I wrote it, buildnumber didn't have a timestamp. This is the first time I took a look at the thing in months. But still, I don't like the way the configuration is implemented in buildnumber, too much noise. I can see what you mean though. If you don't want to add it to central because it's redundant that's fine with me. > Upload maven-timestamp-plugin 1.0 > - > > Key: MAVENUPLOAD-2338 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2338 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Antonio Agudo > > Please upload the maven-timestamp-plugin bundle from > http://keyboardsamurais.com/projects/maven-timestamp-plugin/ to central > repository. > Thank you very much. -- 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: (MECLIPSE-521) A materialized scope: runtime dependency project is not available in webapp classloader
A materialized scope: runtime dependency project is not available in webapp classloader --- Key: MECLIPSE-521 URL: http://jira.codehaus.org/browse/MECLIPSE-521 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Environment: Running latest m2eclipse, http://m2eclipse.sonatype.org/update-dev/ on Eclipse Version: 3.4.1 Ganymede Reporter: Jakob Ericsson We have a standard war-packaging pom file that use projects with both default dependency (compile) scope and runtime dependency scope. If I do not materialize the the runtime dependencies everything works fine but as soon as I materialize a runtime project my webapp get ClassNotFoundException, i.e. my materialized dependency (with runtime) is not added to the classpath. If I change my runtime dependency scope to default, materialized project is added to the classpath and everything works fine. -- 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
