[jira] Closed: (MJAR-98) The JAR-plugin cannot bundle binary (pdf) file
[ http://jira.codehaus.org/browse/MJAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oskar Carlstedt closed MJAR-98. --- Resolution: Cannot Reproduce Fix Version/s: (was: 2.2) See above. Filtering was turned on. > The JAR-plugin cannot bundle binary (pdf) file > -- > > Key: MJAR-98 > URL: http://jira.codehaus.org/browse/MJAR-98 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Environment: Windows >Reporter: Oskar Carlstedt > > Since the last update of the jar-plgun I have trouble generating an ejb-jar > containing pdf-files. I can open the pdf files in the original version, but > cannot open the pdf files after extracting the ejb-jar file. > Best regards > /Oskar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-98) The JAR-plugin cannot bundle binary (pdf) file
[ http://jira.codehaus.org/browse/MJAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121990 ] Oskar Carlstedt commented on MJAR-98: - My fault here. I had filtering set to true which, of course, was the reason to this trouble. Maybee there can be a feature to add which resources one may include or exclude during a filtering process. There is an include and an exclude tag for the whole resources element but nor for the filtering itself. /Cheers Oskar > The JAR-plugin cannot bundle binary (pdf) file > -- > > Key: MJAR-98 > URL: http://jira.codehaus.org/browse/MJAR-98 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Environment: Windows >Reporter: Oskar Carlstedt > > Since the last update of the jar-plgun I have trouble generating an ejb-jar > containing pdf-files. I can open the pdf files in the original version, but > cannot open the pdf files after extracting the ejb-jar file. > Best regards > /Oskar -- 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-79) exclude dependencies from the Classpath Container
[ http://jira.codehaus.org/browse/MECLIPSE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof closed MECLIPSE-79. --- Assignee: nicolas de loof Resolution: Fixed Fix Version/s: 2.5 patch applied with minor change : groupId artifactId separator changed to ":" as this is the conventions used by other maven plugins (maven-assembly-plugin for example) : junit:junit > exclude dependencies from the Classpath Container > - > > Key: MECLIPSE-79 > URL: http://jira.codehaus.org/browse/MECLIPSE-79 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Dependencies resolution and build path > Environment: Windows, Eclipse 3.1.2 >Reporter: Martin Goldhahn >Assignee: nicolas de loof > Fix For: 2.5 > > Attachments: MECLIPSE-79.patch > > > There are some dependencies that need to be in the POM in order to compile > the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an > error because the servlet classes from the POM are included in the classpath > via the classpath container. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-98) The JAR-plugin cannot bundle binary (pdf) file
[ http://jira.codehaus.org/browse/MJAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121993 ] Joerg Schaible commented on MJAR-98: You can configure th resource plugin to run twice with different configuration, so simply separate filtered from unfiltered sources. > The JAR-plugin cannot bundle binary (pdf) file > -- > > Key: MJAR-98 > URL: http://jira.codehaus.org/browse/MJAR-98 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Environment: Windows >Reporter: Oskar Carlstedt > > Since the last update of the jar-plgun I have trouble generating an ejb-jar > containing pdf-files. I can open the pdf files in the original version, but > cannot open the pdf files after extracting the ejb-jar file. > Best regards > /Oskar -- 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: (CONTINUUM-1643) Perform release page results to a blank page after submitted
[ http://jira.codehaus.org/browse/CONTINUUM-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated CONTINUUM-1643: Fix Version/s: 1.2 > Perform release page results to a blank page after submitted > > > Key: CONTINUUM-1643 > URL: http://jira.codehaus.org/browse/CONTINUUM-1643 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: ubuntu linux >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching >Priority: Minor > Fix For: 1.2 > > > Steps to replicate: > 1. Add Maven 2.0x Project > 2. Build Project > 3. Click on the Release button > 4. It is then directed to Release project page > 5. Select Perform Project Release > 6. Click Submit button and it would then be directed to Perform Project > Release page > 7. Click Submit button > Result: Blank 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: (CONTINUUM-1643) Perform release page results to a blank page after submitted
Perform release page results to a blank page after submitted Key: CONTINUUM-1643 URL: http://jira.codehaus.org/browse/CONTINUUM-1643 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1 Environment: ubuntu linux Reporter: Maria Odea Ching Priority: Minor Fix For: 1.2 Steps to replicate: 1. Add Maven 2.0x Project 2. Build Project 3. Click on the Release button 4. It is then directed to Release project page 5. Select Perform Project Release 6. Click Submit button and it would then be directed to Perform Project Release page 7. Click Submit button Result: Blank 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] Assigned: (CONTINUUM-1643) Perform release page results to a blank page after submitted
[ http://jira.codehaus.org/browse/CONTINUUM-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned CONTINUUM-1643: --- Assignee: Maria Odea Ching > Perform release page results to a blank page after submitted > > > Key: CONTINUUM-1643 > URL: http://jira.codehaus.org/browse/CONTINUUM-1643 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: ubuntu linux >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching >Priority: Minor > Fix For: 1.2 > > > Steps to replicate: > 1. Add Maven 2.0x Project > 2. Build Project > 3. Click on the Release button > 4. It is then directed to Release project page > 5. Select Perform Project Release > 6. Click Submit button and it would then be directed to Perform Project > Release page > 7. Click Submit button > Result: Blank 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: (SUREFIRE-449) In multi-module projects, all tests are run for each module in the module tree
In multi-module projects, all tests are run for each module in the module tree -- Key: SUREFIRE-449 URL: http://jira.codehaus.org/browse/SUREFIRE-449 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.4 Environment: Maven 2.0.8, Linux Reporter: Stefan Seidel Priority: Blocker Attachments: mvnexec.zip In a multi-module project, since version 2.4, all tests of all modules are run once for each module. This is *very* bad with many modules & many tests. Attached is a sample project which contains a parent module and two child modules. Each of the child modules contains one JUnit test. mvn clean site runs each test three times (once for the parent and once for each of the two submodules). When changing the surefire-report-plugin to version 2.3, each test is run only once, as it is supposed to -- 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-1921) Upload ZK 3.0.3 to the central repository
Upload ZK 3.0.3 to the central repository - Key: MAVENUPLOAD-1921 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1921 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh http://www.zkoss.org/maven/bundles/3.0.3/zcommon-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zweb-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zk-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zul-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zhtml-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zml-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zkex-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zkmax-3.0.3-bundle.jar http://www.zkoss.org/maven/bundles/3.0.3/zkplus-3.0.3-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. Thanks. -- 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: (MJAVADOC-171) Modules in multi-module projects are "built" too often
Modules in multi-module projects are "built" too often -- Key: MJAVADOC-171 URL: http://jira.codehaus.org/browse/MJAVADOC-171 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Maven 2.0.8, Linux Reporter: Stefan Seidel Priority: Critical Attachments: mvnexec.zip In a multi-module project, all modules are "built" twice for each module. This leads to huge performance problems when many modules are in a project. In the attached sample project, the xmlbeans plugin is executed 27 times for a project with one parent module and two submodules. 18 of these executions can be attributed to the javadoc plugin. With version 2.2, only 3 invocations (once for each project) are caused by the javadoc plugin. -- 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: (MPLUGIN-40) All plugins should by default have an auto-generated goal 'help'
[ http://jira.codehaus.org/browse/MPLUGIN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121999 ] Tobias Roeser commented on MPLUGIN-40: -- This is not working with the current maven-plugin-plugin (version 2.3). I couldn't find the svn repository to this plugin, just the tags svn repo with version 2.3 which is to old. The error message is: [ERROR] BUILD ERROR [INFO] [INFO] 'helpmojo' was specified in an execution, but not found in the plugin [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: 'helpmojo' was specified in an execution, but not found in the plugin at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle(DefaultLifecycleExecutor.java:1342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1243) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) 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: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) [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Fri Feb 01 11:40:00 CET 2008 [INFO] Final Memory: 3M/68M [INFO] > All plugins should by default have an auto-generated goal 'help' > > > Key: MPLUGIN-40 > URL: http://jira.codehaus.org/browse/MPLUGIN-40 > Project: Maven 2.x Plugin Tools > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Eirik Maus >Assignee: Vincent Siveton > Fix For: 2.4 > > > All plugins should have a goal called "help" providing help on how to use the > plugin. This should be auto-generated if it doesn't already exist as a goal > in the mojo. The autogenerated help should typically list the goals (and > settable properties) of the plugin, and probably also print out the url to > the plugin's website (if available). This will most likely affect the plugin > archetype as well, I guess. -- 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-1905) Upload request for artifact: Java Utilities - OstermillerUtils
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122005 ] Diego Schivo commented on MAVENUPLOAD-1905: --- Sorry, we had network problems that day. Please try now. Thank you. > Upload request for artifact: Java Utilities - OstermillerUtils > -- > > Key: MAVENUPLOAD-1905 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1905 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Diego Schivo > > http://repository.openmindonline.it/_bundle-upload/ostermiller-utils-1.07.00.jar > http://ostermiller.org/utils > I'm not a developer, please upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1644) Test failures occur in tagged sources
[
http://jira.codehaus.org/browse/CONTINUUM-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Napoleon Esmundo C. Ramirez updated CONTINUUM-1644:
---
Attachment: CONTINUUM-1644.patch
This patch locks the version of the maven-surefire-plugin used.
> Test failures occur in tagged sources
> -
>
> Key: CONTINUUM-1644
> URL: http://jira.codehaus.org/browse/CONTINUUM-1644
> Project: Continuum
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Napoleon Esmundo C. Ramirez
> Attachments: CONTINUUM-1644.patch
>
>
> I checked out the sources of continuum 1.1 and tried to build it, but I
> encountered a test failure in continuum-api:
> {code}
> $ svn co http://svn.apache.org/repos/asf/maven/continuum/tags/continuum-1.1
> $ cd continuum-1.1
> $ mvn clean install
> {code}
> {code}
> [INFO]
>
> [INFO] Building Continuum API
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /home/nramirez/src/continuum-1.1/continuum-api/target
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 37 source files to
> /home/nramirez/src/continuum-1.1/continuum-api/target/classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 2 source files to
> /home/nramirez/src/continuum-1.1/continuum-api/target/test-classes
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> /home/nramirez/src/continuum-1.1/continuum-api/target/surefire-reports
> ---
> T E S T S
> ---
> Running
> org.apache.maven.continuum.project.builder.AbstractContinuumProjectBuilderTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<<
> FAILURE!
> Running org.apache.maven.continuum.utils.ContinuumUtilsTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
> Results :
> Failed tests:
> warning(junit.framework.TestSuite$1)
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] There are test failures.
> Please refer to
> /home/nramirez/src/continuum-1.1/continuum-api/target/surefire-reports for
> the individual test results.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 21 seconds
> [INFO] Finished at: Fri Feb 01 17:19:29 PHT 2008
> [INFO] Final Memory: 28M/115M
> [INFO]
>
> {code}
> I think this was caused by using maven-surefire-plugin:2.4, when it builds
> with version 2.3 before.
--
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: (MPLUGIN-40) All plugins should by default have an auto-generated goal 'help'
[ http://jira.codehaus.org/browse/MPLUGIN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122011 ] Vincent Siveton commented on MPLUGIN-40: Tobias, you need to specify 2.4-SNAPSHOT as version. > All plugins should by default have an auto-generated goal 'help' > > > Key: MPLUGIN-40 > URL: http://jira.codehaus.org/browse/MPLUGIN-40 > Project: Maven 2.x Plugin Tools > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Eirik Maus >Assignee: Vincent Siveton > Fix For: 2.4 > > > All plugins should have a goal called "help" providing help on how to use the > plugin. This should be auto-generated if it doesn't already exist as a goal > in the mojo. The autogenerated help should typically list the goals (and > settable properties) of the plugin, and probably also print out the url to > the plugin's website (if available). This will most likely affect the plugin > archetype as well, I guess. -- 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-120) Force inter-project dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122014 ] Max Bowsher commented on MECLIPSE-120: -- I'm not sure that MECLIPSE-344 really addresses this use-case - if I'm reading it right, the MECLIPSE-344 changes allow connecting project dependencies to projects already in the workspace. This use-case, though, is about constructing set of project files that refer to each other as dependencies, before they are imported into the workspace. IIUC, the MECLIPSE-344 feature would allow this to be approximated by (1) doing normal eclipse:eclipse (2) importing the projects (3) redoing eclipse:eclipse in MECLIPSE-344 mode. A bit inelegant. Also, ideally it should be possible to use this feature without having to specify the path to your eclipse workspace on the command line. Therefore I think it is inaccurate to resolve this issue as a duplicate of MECLIPSE-344 - it's just loosely related. I think there is value in implementing this feature as described above alongside the MECLIPSE-344 feature. > Force inter-project dependencies > > > Key: MECLIPSE-120 > URL: http://jira.codehaus.org/browse/MECLIPSE-120 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Multi-projects >Affects Versions: 2.2 >Reporter: Joerg Schaible >Assignee: Arnaud Heritier > Fix For: 2.5 > > > In a multi-module setup, the dependencies between the projects are only > created, if the project's version match the one of the referenced artfiact. > After a release this is normally no longer the case if you have modules with > independent release cycles. Therefore it would be good, if the plugin could > be forced with an option (e.g. -forceSnapshot) to use a dependency to a > module's project with a snapshot version instead of a dependency to the > released artifact in the local repository. The plugin detects this situation > already, but logs just a warning. Without this feature, refactorings are > getting really tedious. -- 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: (MCOMPILER-65) Intelligent fork or bootclasspath based on desired target JDK
[ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122023 ] Joerg Schaible commented on MCOMPILER-65: - It's too short sighted to think only of JDK 1.4 vs. JDK 5. For some libraries it makes also a tremendous difference which vendor delivered the JDK, because a JDK 5 delivered by Sun, IBM, BEA, Apple, SAP, Hitachi, Oracle and the more individual JDKs like Apache Harmony, gcj, IVKM may really behave different. Simply because it is not relevant for a lot of applications (or they do not care using com.sun.* classes and therefore enforcing a JDK) it should be supported by Maven. By defining individual JDKs in the settings using an individual id (like it is done for servers), you may support such a strategy. > Intelligent fork or bootclasspath based on desired target JDK > - > > Key: MCOMPILER-65 > URL: http://jira.codehaus.org/browse/MCOMPILER-65 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Reporter: David Smiley > > I work with Maven on a few projects, some jdk 1.4, some jdk 1.5. The only > way to get a consistent compiled build is to fork the compiler so that a > particular jdk is used, it's not necessarily enough to set the "source" and > "target" params on the compiler plugin ( see > http://madbean.com/2006/target14/ ) for an explanation. I say not > necessarily in part not just on the info in that referred URL, but we really > can't and shouldn't assume that maven itself is using a particular jdk > either. I think this is a big deal and I would guess that the maven team > would also think it's a big deal based on a cornerstone philosophy of > repeatable builds. -- Builds that shouldn't come with special instructions > to do some magic (like run maven in a certain VM or set certain system > properties). > This issue needs to be more prominently displayed in the maven documentation, > both for the plugin and most certainly this FAQ entry: > http://maven.apache.org/general.html#Compiling-J2SE-5 -- if only it were > that simple. > I have an idea for a solution that involves only forking when necessary and > if not that possibly setting the bootclasspath. The idea is to avoid > forking, and to avoid setting bootclasspath if neither are necessary. And of > course the result is a compiler configuration that can and should be as > simple as setting the "target" param to get a repeatable build no matter what > JDK maven is running under. > 1. Standardize on the system property names for the java homes, i.e. > JAVA_1_4_HOME JAVA_1_5_HOME etc. Furthermore... this *should* be set in the > user's settings.xml. Yes this means installation requires another step but I > see no way around that unless maven were to try and figure out these based on > operating-specific logic. > 2. Based on the "source" and "target" parameters, determine wether (a) > Maven's current VM can be used as-is without setting bootclasspath for javac > (b) Maven's current VM can be used but needs to set the bootclasspath for > javac, or (c) fork and use an external javac. If (a) can be chosen then the > standardized property names don't need to be consulted. In (b) the java home > is needed for the bootclasspath, and in (c) to fork javac. Also, ensure that > the choice of a,b,c is somehow displayed in the maven output so the developer > knows. > Implementation note: I noticed that the maven compiler plugin uses Ant > heavily to do its job. In light of that, implementing this feature might > instead involve enhancing the ant side to have this feature and then making > minor changes on the maven side to accommodate 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: (MECLIPSE-120) Force inter-project dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122017 ] Joerg Schaible commented on MECLIPSE-120: - I think we'll have to try out how this is suitable in daily work. As I already stated, the mode above should not be the default mode, but it is quite essential for refactoring base functionality. Therefore you will normally already have all the projects generated and imported, so it is not necessarily an additional step. Also MECLIPSE-344 seems to imply that you can create linked projects even if you generate the Eclipse project for a sub module only, while the solution above forces you to generate all Eclipse files at once. > Force inter-project dependencies > > > Key: MECLIPSE-120 > URL: http://jira.codehaus.org/browse/MECLIPSE-120 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Multi-projects >Affects Versions: 2.2 >Reporter: Joerg Schaible >Assignee: Arnaud Heritier > Fix For: 2.5 > > > In a multi-module setup, the dependencies between the projects are only > created, if the project's version match the one of the referenced artfiact. > After a release this is normally no longer the case if you have modules with > independent release cycles. Therefore it would be good, if the plugin could > be forced with an option (e.g. -forceSnapshot) to use a dependency to a > module's project with a snapshot version instead of a dependency to the > released artifact in the local repository. The plugin detects this situation > already, but logs just a warning. Without this feature, refactorings are > getting really tedious. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-65) Intelligent fork or bootclasspath based on desired target JDK
Intelligent fork or bootclasspath based on desired target JDK - Key: MCOMPILER-65 URL: http://jira.codehaus.org/browse/MCOMPILER-65 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Reporter: David Smiley I work with Maven on a few projects, some jdk 1.4, some jdk 1.5. The only way to get a consistent compiled build is to fork the compiler so that a particular jdk is used, it's not necessarily enough to set the "source" and "target" params on the compiler plugin ( see http://madbean.com/2006/target14/ ) for an explanation. I say not necessarily in part not just on the info in that referred URL, but we really can't and shouldn't assume that maven itself is using a particular jdk either. I think this is a big deal and I would guess that the maven team would also think it's a big deal based on a cornerstone philosophy of repeatable builds. -- Builds that shouldn't come with special instructions to do some magic (like run maven in a certain VM or set certain system properties). This issue needs to be more prominently displayed in the maven documentation, both for the plugin and most certainly this FAQ entry: http://maven.apache.org/general.html#Compiling-J2SE-5 -- if only it were that simple. I have an idea for a solution that involves only forking when necessary and if not that possibly setting the bootclasspath. The idea is to avoid forking, and to avoid setting bootclasspath if neither are necessary. And of course the result is a compiler configuration that can and should be as simple as setting the "target" param to get a repeatable build no matter what JDK maven is running under. 1. Standardize on the system property names for the java homes, i.e. JAVA_1_4_HOME JAVA_1_5_HOME etc. Furthermore... this *should* be set in the user's settings.xml. Yes this means installation requires another step but I see no way around that unless maven were to try and figure out these based on operating-specific logic. 2. Based on the "source" and "target" parameters, determine wether (a) Maven's current VM can be used as-is without setting bootclasspath for javac (b) Maven's current VM can be used but needs to set the bootclasspath for javac, or (c) fork and use an external javac. If (a) can be chosen then the standardized property names don't need to be consulted. In (b) the java home is needed for the bootclasspath, and in (c) to fork javac. Also, ensure that the choice of a,b,c is somehow displayed in the maven output so the developer knows. Implementation note: I noticed that the maven compiler plugin uses Ant heavily to do its job. In light of that, implementing this feature might instead involve enhancing the ant side to have this feature and then making minor changes on the maven side to accommodate 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: (MECLIPSE-344) connecting existing workspace artifact-projects
[ http://jira.codehaus.org/browse/MECLIPSE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122018 ] Joerg Schaible commented on MECLIPSE-344: - Will it link always all projects or is it possible to link only the SNAPSHOTs? The difference is, that with the information from the Eclipse workspace you don't have to rebuild all Eclipse files at once to get the SNAPSHOTs linked. You will have the information now to rebuild the Eclipse projects for a single submodule only, but have the SNAPSHOTs still linked. Therefore it would be really nice to have both operation modes. > connecting existing workspace artifact-projects > --- > > Key: MECLIPSE-344 > URL: http://jira.codehaus.org/browse/MECLIPSE-344 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-344+rad7.patch, MECLIPSE-344+rad7.tgz, > MECLIPSE-344.patch, MECLIPSE-344.tgz, workspace-new-files.tgz, > workspace.patch, workspace_with_limit.patch > > > This patch enables you to specify your workspace, and all dependent artefacts > that are available in your eclipse-workspace will be attached as project > references even if they are not in the reactor. > the property can be set with -DworkspaceToConnect=. > I did not have the time to create Test cases but, i maybe someone can help > with that! > The patch is based on the MECLIPSE-333 branch. > as usual the new files are in the extra tgz. -- 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: (MENFORCER-30) RequirePluginVersions breaks when using project.parent.groupId and project.parent.version.
[
http://jira.codehaus.org/browse/MENFORCER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122047
]
Nick Stolwijk commented on MENFORCER-30:
I had already spoken to Brian about this issue and that was indeed the
solution. He only wanted it registered here, so he would not forget it. No
problem, no hurry, this is just a reminder.
> RequirePluginVersions breaks when using project.parent.groupId and
> project.parent.version.
> --
>
> Key: MENFORCER-30
> URL: http://jira.codehaus.org/browse/MENFORCER-30
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Trivial
>
> We were using a obsolete but working child pom file, like:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> org.example.petstore
> petstore
> 0.2-SNAPSHOT
>
> ${project.parent.groupId}
> petstore-common
> 0.2-SNAPSHOT
> jar
> Common module
> The Common module.
>
> The rule will fail, when the child is not in the local or a remote
> repository, because ${project.parent.groupId} and org.example.petstore are
> not the same and the artifact can not be found.
--
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: (MENFORCER-30) RequirePluginVersions breaks when using project.parent.groupId and project.parent.version.
[
http://jira.codehaus.org/browse/MENFORCER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122043
]
pgier edited comment on MENFORCER-30 at 2/1/08 8:52 AM:
As a workaround, I think you can just leave groupId and artifactId blank, and
they will default to the parent's values.
Does it behave this way for all properties used in the groupId or artifactId?
was (Author: pgier):
As a workaround, I think you can just leave groupId and artifactId blank.
Does it behave this way for all properties used in the groupId or artifactId?
> RequirePluginVersions breaks when using project.parent.groupId and
> project.parent.version.
> --
>
> Key: MENFORCER-30
> URL: http://jira.codehaus.org/browse/MENFORCER-30
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Trivial
>
> We were using a obsolete but working child pom file, like:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> org.example.petstore
> petstore
> 0.2-SNAPSHOT
>
> ${project.parent.groupId}
> petstore-common
> 0.2-SNAPSHOT
> jar
> Common module
> The Common module.
>
> The rule will fail, when the child is not in the local or a remote
> repository, because ${project.parent.groupId} and org.example.petstore are
> not the same and the artifact can not be found.
--
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: (MCOMPILER-65) Intelligent fork or bootclasspath based on desired target JDK
[ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122035 ] David Smiley commented on MCOMPILER-65: --- I was about to suggest that adding a "targetVendor" attribute would address your concern (and I suppose it would), but then I got thinking about an entirely different approach. What if a project didn't articulate that it was targeting jdk 1.4 via "target", what if it used a dependency? For example here's a hypothetical groupid:artifactId:version -- java:java:1.4 and the proposed scope would be something like "jdk". The installed JDK's pom would transitively depend on java:java:1.4 but it would itself offer it's extras. It's pom might be something like com.sun:java:1.4.2 So if you want sun's stuff, you refer to com.sun:java:1.4.2 otherwise you refer to just java:java:1.4. This would be a sort of special dependency that isn't searched for in repos since the installed JDKs contain it. It's something that maven would make available specially. What do you think? In any case... the status quo of just "source" and "target" is misleading and arguably a bad practice if maven's philosophies are to be taken to heart. > Intelligent fork or bootclasspath based on desired target JDK > - > > Key: MCOMPILER-65 > URL: http://jira.codehaus.org/browse/MCOMPILER-65 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Reporter: David Smiley > > I work with Maven on a few projects, some jdk 1.4, some jdk 1.5. The only > way to get a consistent compiled build is to fork the compiler so that a > particular jdk is used, it's not necessarily enough to set the "source" and > "target" params on the compiler plugin ( see > http://madbean.com/2006/target14/ ) for an explanation. I say not > necessarily in part not just on the info in that referred URL, but we really > can't and shouldn't assume that maven itself is using a particular jdk > either. I think this is a big deal and I would guess that the maven team > would also think it's a big deal based on a cornerstone philosophy of > repeatable builds. -- Builds that shouldn't come with special instructions > to do some magic (like run maven in a certain VM or set certain system > properties). > This issue needs to be more prominently displayed in the maven documentation, > both for the plugin and most certainly this FAQ entry: > http://maven.apache.org/general.html#Compiling-J2SE-5 -- if only it were > that simple. > I have an idea for a solution that involves only forking when necessary and > if not that possibly setting the bootclasspath. The idea is to avoid > forking, and to avoid setting bootclasspath if neither are necessary. And of > course the result is a compiler configuration that can and should be as > simple as setting the "target" param to get a repeatable build no matter what > JDK maven is running under. > 1. Standardize on the system property names for the java homes, i.e. > JAVA_1_4_HOME JAVA_1_5_HOME etc. Furthermore... this *should* be set in the > user's settings.xml. Yes this means installation requires another step but I > see no way around that unless maven were to try and figure out these based on > operating-specific logic. > 2. Based on the "source" and "target" parameters, determine wether (a) > Maven's current VM can be used as-is without setting bootclasspath for javac > (b) Maven's current VM can be used but needs to set the bootclasspath for > javac, or (c) fork and use an external javac. If (a) can be chosen then the > standardized property names don't need to be consulted. In (b) the java home > is needed for the bootclasspath, and in (c) to fork javac. Also, ensure that > the choice of a,b,c is somehow displayed in the maven output so the developer > knows. > Implementation note: I noticed that the maven compiler plugin uses Ant > heavily to do its job. In light of that, implementing this feature might > instead involve enhancing the ant side to have this feature and then making > minor changes on the maven side to accommodate 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] Closed: (MEAR-83) Documentation refers to jarModule instead of javaModule but jarModule doesn't seem to be released yet
[ http://jira.codehaus.org/browse/MEAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-83. --- Assignee: Stephane Nicoll Resolution: Won't Fix It's released for more than 2 releases and the doc on the web site refers to the latest release anyway. If you have version 2.1 for the plugin, use -U to grab the latest version (or specify it in your pom). > Documentation refers to jarModule instead of javaModule but jarModule doesn't > seem to be released yet > - > > Key: MEAR-83 > URL: http://jira.codehaus.org/browse/MEAR-83 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_13 >Reporter: David Smiley >Assignee: Stephane Nicoll > > The documentation up right now > http://maven.apache.org/plugins/maven-ear-plugin/modules.html mentions that > jarModule should be used instead of javaModule. That may be so for the > latest released version of this plugin, but if I use the plugin without > explicitly specifying the version with maven 2.0.8, I don't get that version > -- I get version 2.1. > FYI, the error I got when attempted to use jarModule was bizarre. ALL it > told me (no other info was helpful whatsoever) was the following error: > java.lang.InstantiationException: org.apache.maven.plugin.ear.EarModule -- 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: (MENFORCER-30) RequirePluginVersions breaks when using project.parent.groupId and project.parent.version.
[
http://jira.codehaus.org/browse/MENFORCER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122051
]
Brian Fox commented on MENFORCER-30:
I have to manually read the poms because I can't get the real info from the
models about the plugins. That means that I also have to manually interpolate
the values I find.
> RequirePluginVersions breaks when using project.parent.groupId and
> project.parent.version.
> --
>
> Key: MENFORCER-30
> URL: http://jira.codehaus.org/browse/MENFORCER-30
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Trivial
>
> We were using a obsolete but working child pom file, like:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> org.example.petstore
> petstore
> 0.2-SNAPSHOT
>
> ${project.parent.groupId}
> petstore-common
> 0.2-SNAPSHOT
> jar
> Common module
> The Common module.
>
> The rule will fail, when the child is not in the local or a remote
> repository, because ${project.parent.groupId} and org.example.petstore are
> not the same and the artifact can not be found.
--
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: (CONTINUUM-1587) Unable to change default build definition where one definition is a PROJECT definition and one is a GROUP
[ http://jira.codehaus.org/browse/CONTINUUM-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Le Merdy updated CONTINUUM-1587: - Attachment: screenshot-1.jpg Edit build definition : "default" attribute is read-only ! > Unable to change default build definition where one definition is a PROJECT > definition and one is a GROUP > - > > Key: CONTINUUM-1587 > URL: http://jira.codehaus.org/browse/CONTINUUM-1587 > Project: Continuum > Issue Type: Bug > Components: Project Grouping >Affects Versions: 1.1-beta-4 >Reporter: Ross Lamont > Attachments: screenshot-1.jpg > > > This is perhaps related to CONTINUUM-1410: > We create a MVN2 project in the usual manner within a predefined project > group. > We then added a non-default build definition to the project - the GROUP > definition continues to be the default. > Sometime later, we wanted to temporarily change the default to the PROJECT > definition. > When attempting to change the default back to the GROUP, the default field > for both definitions (from the Project page) is read-only set to true. -- 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: (MENFORCER-30) RequirePluginVersions breaks when using project.parent.groupId and project.parent.version.
[
http://jira.codehaus.org/browse/MENFORCER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122043
]
Paul Gier commented on MENFORCER-30:
As a workaround, I think you can just leave groupId and artifactId blank.
Does it behave this way for all properties used in the groupId or artifactId?
> RequirePluginVersions breaks when using project.parent.groupId and
> project.parent.version.
> --
>
> Key: MENFORCER-30
> URL: http://jira.codehaus.org/browse/MENFORCER-30
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Nick Stolwijk
>Assignee: Brian Fox
>Priority: Trivial
>
> We were using a obsolete but working child pom file, like:
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> org.example.petstore
> petstore
> 0.2-SNAPSHOT
>
> ${project.parent.groupId}
> petstore-common
> 0.2-SNAPSHOT
> jar
> Common module
> The Common module.
>
> The rule will fail, when the child is not in the local or a remote
> repository, because ${project.parent.groupId} and org.example.petstore are
> not the same and the artifact can not be found.
--
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: (MASSEMBLY-243) Support for patching
[ http://jira.codehaus.org/browse/MASSEMBLY-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-243. Assignee: John Casey Resolution: Won't Fix Fix Version/s: 2.2-beta-2 should be used in concert with the patch plugin to achieve desired results, to avoid creating further duplication of other plugins' functionalities within the assembly plugin. > Support for patching > > > Key: MASSEMBLY-243 > URL: http://jira.codehaus.org/browse/MASSEMBLY-243 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Frank Cornelis >Assignee: John Casey > Fix For: 2.2-beta-2 > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > What I'm still missing from Ant is the ability to apply patches to assemblies > that you're creating via the maven-assembly-plugin. > In our project we're using JBoss AS bundled as a ZIP. To create a final > distribution of the product we unpack and then have to change quite some > configuration files within the JBoss AS tree. The problem right now is that > for every JBoss AS update we have to re-patch the configuration files > manually. It would be great if the maven-assembly-plugin would have inherent > support for patches. That way it's also more clear what configuration section > you're changing exactly. > See also: http://ant.apache.org/manual/CoreTasks/patch.html -- 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-3229) Active by default profile is ignored when another is specified explicitly.
[ http://jira.codehaus.org/browse/MNG-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122054 ] Wendy Smoak commented on MNG-3229: -- I always understood activeByDefault to mean "active _unless_ another profile is explicitly specified". Testing with 2.0.8, I'm seeing *both* profiles active, which is what you asked for, but *not* how it has ever worked in the past. Can someone confirm? > Active by default profile is ignored when another is specified explicitly. > --- > > Key: MNG-3229 > URL: http://jira.codehaus.org/browse/MNG-3229 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Oleksandr Maksymchuk > Fix For: Documentation Deficit > > > When default profile is added its used only when there is no another profile > specified to be used on command line via -P option. > So in the pom containig: > > default > > true > > > dev > > default profile is used only when running command without -P dev > mvn > but not used when running: > mvn -P dev > Expected: should be used in both variants as per doc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-274) descriptorSourceDirectory should only scan for xml files.
[ http://jira.codehaus.org/browse/MASSEMBLY-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-274: - Fix Version/s: 2.2-beta-2 > descriptorSourceDirectory should only scan for xml files. > - > > Key: MASSEMBLY-274 > URL: http://jira.codehaus.org/browse/MASSEMBLY-274 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Paul Gier > Fix For: 2.2-beta-2 > > Attachments: descriptor-source-dir-default-excludes.patch, > maven-assembly-plugin-directoryScan-it.patch, > maven-assembly-plugin-directoryScan.patch > > > The descriptorSourceDirectory parameter currently treats all files in the > directory like assembly descriptors. Only files ending with .xml should be > picked up as descriptors. I noticed this because the assembly plugin keeps > trying to use files from my .svn directory as assembly descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-189) plugin not correctly interpolating POM variables like project.build.directory
[
http://jira.codehaus.org/browse/MASSEMBLY-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-189:
-
Fix Version/s: (was: 2.2)
2.2-beta-2
> plugin not correctly interpolating POM variables like project.build.directory
> -
>
> Key: MASSEMBLY-189
> URL: http://jira.codehaus.org/browse/MASSEMBLY-189
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: I used both released version 2.1 and also 2.2-SNAPSHOT
>Reporter: Ray Suliteanu
>Priority: Critical
> Fix For: 2.2-beta-2
>
> Attachments: multi-dot-pom-expression.patch
>
>
> I have a assembly descriptor file with ${project.build.directory} in the
> element of a . I get an error "Failed to create assembly: File
> to filter not found" because the file path has "${project.build.directory}"
> rather than the value of ${project.build.directory}.
> I have traced the problem to AssemblyInterpolator.interpolateElementValue().
> It tries to look up build.directory in ReflectionValueExtractor.evaluate()
> rather than project.build.directory, and it can't evaluate build.directory. A
> hack workaround is ...
> if (value == null)
> {
> try
> {
> value = ReflectionValueExtractor.evaluate(realExpr, project);
> if (value == null)
> {
> // HACK: strip ${ and } and retry
> wholeExpr = wholeExpr.substring(2, wholeExpr.length() - 1);
> value = ReflectionValueExtractor.evaluate(wholeExpr, 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: (MASSEMBLY-188) manifestEntries are not set in resulting jar
[
http://jira.codehaus.org/browse/MASSEMBLY-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-188:
-
Fix Version/s: (was: 2.2-beta-3)
2.2-beta-2
> manifestEntries are not set in resulting jar
>
>
> Key: MASSEMBLY-188
> URL: http://jira.codehaus.org/browse/MASSEMBLY-188
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: maven 2.0.5, windows/linux
>Reporter: Vlad Skarzhevskyy
> Fix For: 2.2-beta-2
>
>
> archive manifestEntries are not set in resulting jar. even so the mainClass
> is set properly.
> assembly format is jar
> Example:
>
>true
>false
>
>assembly.xml
>
>
>
> org.microemu.app.Main
>
>
> ${label}
> ${cctimestamp}
>
>
>
> full pom is here:
> http://microemulator.svn.sourceforge.net/viewvc/microemulator/trunk/microemulator/microemulator/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-216) archive element in assembly descriptor
[ http://jira.codehaus.org/browse/MASSEMBLY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-216: - Fix Version/s: (was: 2.2) 2.2-beta-2 > archive element in assembly descriptor > -- > > Key: MASSEMBLY-216 > URL: http://jira.codehaus.org/browse/MASSEMBLY-216 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Greg Wilkins > Fix For: 2.2-beta-2 > > > Currently it is not possible to have an archive element (and thus manipulate > the manifest) in an assembly descriptor. > This means that manifest entries must be set in the assembly plugin > configuration and this makes it difficult to have different manifests for > different assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
http://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-256:
-
Affects Version/s: (was: 2.2-beta-3)
2.2-beta-2
Fix Version/s: 2.2-beta-2
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: http://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
> Fix For: 2.2-beta-2
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-266) Property expansion does not work for ${project.build.finalName} in descriptor file
[
http://jira.codehaus.org/browse/MASSEMBLY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-266:
-
Fix Version/s: 2.2-beta-2
> Property expansion does not work for ${project.build.finalName} in descriptor
> file
> --
>
> Key: MASSEMBLY-266
> URL: http://jira.codehaus.org/browse/MASSEMBLY-266
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Michael Osipov
> Fix For: 2.2-beta-2
>
>
> Instead of showing the value, I see the reference literal :-(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-182) document behavior when two sources selected for single archived file
[ http://jira.codehaus.org/browse/MASSEMBLY-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-182: - Fix Version/s: (was: 2.2-beta-3) 2.2-beta-2 > document behavior when two sources selected for single archived file > > > Key: MASSEMBLY-182 > URL: http://jira.codehaus.org/browse/MASSEMBLY-182 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: John Franey >Priority: Minor > Fix For: 2.2-beta-2 > > Attachments: archive-rule.patch > > > I was befuddled by how this plugin decides which source file to use when, for > example, a file element and fileSet element identify different sources for > the same archived file. So, I worked through the ones that got me bugged > most and wrote them down. > Attached is a diff of changes to document the behavior I observed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-272) getDescriptor and getDescriptorId should be deprecated.
[ http://jira.codehaus.org/browse/MASSEMBLY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-272: - Fix Version/s: 2.2-beta-2 > getDescriptor and getDescriptorId should be deprecated. > --- > > Key: MASSEMBLY-272 > URL: http://jira.codehaus.org/browse/MASSEMBLY-272 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier >Priority: Minor > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-deprecation-r616611.patch > > > The instance variables descriptor and descriptorId are deprecated. The > matching getter and setter methods should also be deprecated with a comment > about replacement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-275) Use properties to select IT pom includes
[ http://jira.codehaus.org/browse/MASSEMBLY-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-275: - Affects Version/s: 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Use properties to select IT pom includes > > > Key: MASSEMBLY-275 > URL: http://jira.codehaus.org/browse/MASSEMBLY-275 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier >Priority: Trivial > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-it-pom-r616784.patch > > > Profile properties could be used to select which integration tests to run > instead of editing the pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-257) OutOfMemoryError when assembling large binary file
[ http://jira.codehaus.org/browse/MASSEMBLY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-257: - Fix Version/s: 2.2-beta-2 > OutOfMemoryError when assembling large binary file > -- > > Key: MASSEMBLY-257 > URL: http://jira.codehaus.org/browse/MASSEMBLY-257 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Jelte van der Hoek > Fix For: 2.2-beta-2 > > Attachments: fileitem-oome.patch > > > The assembly phase reads all files into a single String, irrespective of > whether they need filtering or not. > This makes it unable to handle large binary files in an assembly. > The quick fix for this is to not read the file at all if there is no > 'lineEnding' nor 'filtered' option set. > (The long fix would be to not read the file that way) > Patch against 2.2-beta-1 attached (most of the patch changes . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-152) Support Ant token
[
http://jira.codehaus.org/browse/MASSEMBLY-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-152:
-
Affects Version/s: (was: 2.2)
2.2-beta-1
Fix Version/s: (was: 2.3-beta-1)
2.2-beta-2
> Support Ant token
> -
>
> Key: MASSEMBLY-152
> URL: http://jira.codehaus.org/browse/MASSEMBLY-152
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-1
> Environment: Maven 2.0.4
>Reporter: Rémy Sanlaville
>Priority: Critical
> Fix For: 2.2-beta-2
>
> Attachments: ant-token-fix.diff
>
>
> For the moment Maven 2.x Assembly Plugin support only maven token (${token})
> But I need to share some properties file with ant and maven.
> So It would be nice to also add Ant token support (@token@)
> For the version 2.1, I can give a patch
> The version 2.2-SNAPSHOT seems to be all refactoring and I don't have a patch
> for the moment.
> I think we have to look at the method private String filter( String
> rawContents ) of the org.apache.maven.plugin.assembly.format.FileFormatter
> class. But I don't know how the RegexBasedInterpolator class works.
> Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-264) Filtering in Assembly Generates Blank Files in the Archive
[ http://jira.codehaus.org/browse/MASSEMBLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-264: - Affects Version/s: (was: 2.2-beta-3) 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Filtering in Assembly Generates Blank Files in the Archive > -- > > Key: MASSEMBLY-264 > URL: http://jira.codehaus.org/browse/MASSEMBLY-264 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Neill Alexander > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-bug-test.tar.gz > > > When filers are filtered during assembly, the result is an empty file in the > archive (see output from unzip below): > $ unzip -l assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Archive: assembly-bug-1.0.0-SNAPSHOT-buggy.zip > Length Date TimeName > > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/ > 0 15/01/08 13:05 assembly-bug-1.0.0-SNAPSHOT/bin/test.ini > --- > 0 3 files > This appears to be a result of some recent changes to the > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java > file (changeset 591556) which deletes the files from the temporary > directory. The problem with this is that the archive object has a reference > to the filtered files in the temporary directory. When the call to > archive.createArchive( ) is made it can't find the filtered files, and > therefore they end up empty in the archive. > The attached archive contains a test maven project you can run which will > demonstrate this bug. Run 'mvn clean assembly:assembly' and check out the > contents of target/assembly-bug-1.0.0-SNAPSHOT-buggy.zip > The simply fix is simply to roll-back the 'finally' clause added as part of > 591556 to > src/main/java/org/apache/maven/plugin/assembly/archive/task/AddFileSetsTask.java. > Whether or not it is the best fix, I don't know (hence the absence of a > patch). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-278) Do not fail on missing descriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-278: - Fix Version/s: 2.2-beta-2 > Do not fail on missing descriptors > -- > > Key: MASSEMBLY-278 > URL: http://jira.codehaus.org/browse/MASSEMBLY-278 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Sejal Patel > Fix For: 2.2-beta-2 > > Attachments: ignore-descriptor.patch > > > Assembly requires too much boilerplate right now to be used in a reactor > based project because of the way it fails out if no descriptors are found. I > suggest adding a boolean parameter (probably ignoreMissingDescriptors) which > can default to false for backwards compatability but when set to true, does > nothing if no descriptors are found. > Then in org.apache.maven.plugin.assembly.io.DefaultAssemblyReader line 131 > add the check for that new parameter so that it only fails out if it was > configured to fail out. Otherwise it just goes about its business of assembly > nothing (which seems like a perfectly reasonable logic as well). > By doing these things, it makes it possible to configure the assembly plugin > 1 time in a parent pom and then not have to configure it in several (in my > case 11 out of 19) different modules again and again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-231) Allow Assembly plugin to specify alternate DistributionManagement
[ http://jira.codehaus.org/browse/MASSEMBLY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-231: - Affects Version/s: (was: 2.2-beta-3) 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Allow Assembly plugin to specify alternate DistributionManagement > - > > Key: MASSEMBLY-231 > URL: http://jira.codehaus.org/browse/MASSEMBLY-231 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: James William Dumay > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin.patch, > maven-assembly-plugin.patch, maven-assembly-plugin.patch, > maven-assembly-plugin.patch > > > The following patch allows the assembly plugin to specify alternate > repository locations for deployment of its attached artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-277) NullPointerException
[ http://jira.codehaus.org/browse/MASSEMBLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-277: - Fix Version/s: 2.2-beta-2 > NullPointerException > > > Key: MASSEMBLY-277 > URL: http://jira.codehaus.org/browse/MASSEMBLY-277 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Sejal Patel >Priority: Minor > Fix For: 2.2-beta-2 > > Attachments: npe-patch.txt > > > org.apache.maven.plugin.assembly.archive.task.AddFileSetsTask line 76 > is a NullPointerException spot (which bit me when I tried to make a new > plugin that extended the current abstract one). Line 78 checks if project is > null and retrieves the project. However, line 76 uses the project before the > check/assignment is done. Recommend moving line 76 to be after the line 78 > check. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
[ http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-211: - Fix Version/s: (was: 2.2-beta-3) 2.2-beta-2 > assembly plugin and jar plugin disagree about whether to use uniqueVersion > snapshot names > - > > Key: MASSEMBLY-211 > URL: http://jira.codehaus.org/browse/MASSEMBLY-211 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Max Bowsher >Priority: Blocker > Fix For: 2.2-beta-2 > > Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt > > > Background: Consider the following setup: > jar-plugin configured with addClasspath=true, writing list of dependency jar > file names into manifest of project jar. > assembly-plugin configured with a dependencySet pulling all dependencies into > a single directory. > Result: application is runnable with with "java -jar mainartifact.jar" > There has long been a problem (i.e. with assembly-plugin 2.1) that when > deployed snapshot jars were in use, the jar and assembly plugins would > disagree in whether the uniqueVersion name was used, and this is MNG-2456. > However, assembly-plugin 2.2-beta-1 has introduced further complications to > the situation by not using the lifecycle's default set of resolved artifacts, > but by running a manual resolution of its own. This has made the two plugins > disagree in more scenarios than before, and broke the workaround patch that I > posted in MNG-2456. > At the root of these problems is some very peculiar handling of the 'file', > 'baseVersion' and 'version' fields of Artifact objects, two notable instances > of which are the DefaultArtifact.isSnapshot method, which despite being an > accessor, actually changes the state of the object, and the > DefaultArtifactResolver.resolve method, which contains some rather bizarre > manipulation of the 'file' field (more detail may comments in MNG-2456). > An interim fix to this issue might involve workarounds in both the jar and > assembly plugins to get them to agree. A true fix probably also involves > fixing Maven core 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] Updated: (MASSEMBLY-279) Small improvement to error messages
[ http://jira.codehaus.org/browse/MASSEMBLY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-279: - Affects Version/s: 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Small improvement to error messages > --- > > Key: MASSEMBLY-279 > URL: http://jira.codehaus.org/browse/MASSEMBLY-279 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-error-messages.patch > > > Currently if there is an exception thrown, for example with an empty archive, > the message does not specify which assembly is causing the problem. > The attached patch includes the assemblyId in the error message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-261) Use plexus-archiver 1.0-alpha-10
[ http://jira.codehaus.org/browse/MASSEMBLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-261: - Affects Version/s: 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Use plexus-archiver 1.0-alpha-10 > > > Key: MASSEMBLY-261 > URL: http://jira.codehaus.org/browse/MASSEMBLY-261 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Jochen Wiedmann > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-resources.patch > > > Quoting PLXCOMP-88: > The handling of ArchivedFileSet is currently extremely slow: The archive is > extracted to a temporary directory where the usual archiver logic is being > applied. > A considerable speed improvement could be achieved by replacing the FileSet > internally with the PlexusIoResourceCollection. This would allow to select > files (aka resources) within the archive file. > Additionally, this setup would allow to include content filters and file name > mappers (see the respective Ant types), thus modifying the archive contents > on the fly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-258) Sync usage guide with Maven standard directory layout
[ http://jira.codehaus.org/browse/MASSEMBLY-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-258: - Affects Version/s: 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Sync usage guide with Maven standard directory layout > - > > Key: MASSEMBLY-258 > URL: http://jira.codehaus.org/browse/MASSEMBLY-258 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Benjamin Bentmann >Priority: Trivial > Fix For: 2.2-beta-2 > > Attachments: directory-layout.patch > > > According to > [http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html] > and > [http://docs.codehaus.org/display/MAVENUSER/The+Standard+Directory+Layout], > assembly descriptors should be stored under "src/main/assembly". The usage > guide currenlty suggests to use "src/assembly" which misleads the reader to > break with the standard directory layout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-267) Configure surefire to redirect test output to file
[ http://jira.codehaus.org/browse/MASSEMBLY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-267: - Affects Version/s: 2.2-beta-1 Fix Version/s: 2.2-beta-2 > Configure surefire to redirect test output to file > -- > > Key: MASSEMBLY-267 > URL: http://jira.codehaus.org/browse/MASSEMBLY-267 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier >Priority: Trivial > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-r612994.patch > > > There is a significant amount of debug output coming from the unit tests. It > would make the build output a little cleaner if this output was redirected to > a file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-177) There should be a manifest section in an assembly [external] descriptor
[ http://jira.codehaus.org/browse/MASSEMBLY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-177: - Fix Version/s: (was: 2.3-beta-1) 2.2-beta-2 > There should be a manifest section in an assembly [external] descriptor > --- > > Key: MASSEMBLY-177 > URL: http://jira.codehaus.org/browse/MASSEMBLY-177 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Bernd > Fix For: 2.2-beta-2 > > > Manifest modifications should be possible on a per assembly basis, e.g. > different main 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] Commented: (MNG-3368) Printing version (-v argument) should not stop lifecycle execution
[
http://jira.codehaus.org/browse/MNG-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122063
]
Paul Benedict commented on MNG-3368:
I believe the fix is easy. Two use cases have to be supported:
1) If --version and no phase specified, then print version and quit. This
prevents the "You must specify at least one goal" message.
2) If --version and phase(s) specified, then print version and continue.
The change needs to be made in org.apache.maven.cli.MavenCli
Line 142 has this:
if ( commandLine.hasOption( CLIManager.VERSION ) )
{
showVersion();
if ( // *** Add second condition ) {
return 0;
}
}
> Printing version (-v argument) should not stop lifecycle execution
> --
>
> Key: MNG-3368
> URL: http://jira.codehaus.org/browse/MNG-3368
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build, Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Benedict
>
> I wanted to always print the Maven version when I build, but unfortunately
> Maven immediately quits after outputting the version. This option should not
> quit when a lifecycle is also specified. Example: mvn -v install
--
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-3229) Active by default profile is ignored when another is specified explicitly.
[ http://jira.codehaus.org/browse/MNG-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122057 ] Wendy Smoak commented on MNG-3229: -- Apparently there is some debate around this topic. :) On irc, Brian mentioned that the activeByDefault behavior we are discussing only works in pom.xml. Then later, jdcasey: wsmoak: activeByDefault should never work in settings or profiles.xml jdcasey: you have to use activeProfiles jdcasey: that's the way it was designed, it was just an oversight to put those fields in the model for profiles.xml and settings.xml wsmoak: personally I always use activeProfiles. what I'm seeing is that activeByDefault *does* (sort of) work in settings.xml -- it activates the profile. wsmoak: but you lose the 'deactivate when another profile is specified' behavior. jdcasey: hmm jdcasey: it shouldn't be active at all...that's a bug, at least in the current design. I know a lot of people disagree on how profiles should work when coming from external sources, though With 2.0.8, I am able to activate a profile (permanently!) by using activeByDefault in settings.xml. > Active by default profile is ignored when another is specified explicitly. > --- > > Key: MNG-3229 > URL: http://jira.codehaus.org/browse/MNG-3229 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Oleksandr Maksymchuk > Fix For: Documentation Deficit > > > When default profile is added its used only when there is no another profile > specified to be used on command line via -P option. > So in the pom containig: > > default > > true > > > dev > > default profile is used only when running command without -P dev > mvn > but not used when running: > mvn -P dev > Expected: should be used in both variants as per doc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1908) JavaCSV 2.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Slowikowski reopened MAVENUPLOAD-1908: --- I made a small but critical bug in pom.xml. Connection element looks like: scm:cvs:pserver:anonymous:@javacsv.cvs.sourceforge.net:/cvsroot/javacsv:javacsv Closing tag without a slash. In this form pom is not parseable. Can you fix this? This fix would not change any dependency or other logic, so maybe this is allowed. If not, should I prepare 2.0-1 version for upload? > JavaCSV 2.0 > --- > > Key: MAVENUPLOAD-1908 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1908 > Project: maven-upload-requests > Issue Type: Task >Reporter: Grzegorz Slowikowski >Assignee: Carlos Sanchez > Attachments: javacsv-2.0-bundle.jar > > > Java CSV is a small fast open source java library for reading and writing CSV > and plain delimited text files. All kinds of CSV files can be handled, text > qualified, Excel formatted, etc. > This is the first upload of this artifact. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1907) Winstone 0.9.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Slowikowski reopened MAVENUPLOAD-1907: --- Hi Carlos You missed 'lite' boundle. There is only winstone 0.9.10 on ibiblio, but not winstone-lite 0.9.10. > Winstone 0.9.10 > --- > > Key: MAVENUPLOAD-1907 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1907 > Project: maven-upload-requests > Issue Type: Task >Reporter: Grzegorz Slowikowski >Assignee: Carlos Sanchez > Attachments: winstone-0.9.10-bundle.jar, > winstone-lite-0.9.10-bundle.jar > > > Winstone pom.xml from project cvs repository: > http://winstone.cvs.sourceforge.net/winstone/winstone/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: (MECLIPSE-383) Tests should be independent of downloadSources set in settings.xml
Tests should be independent of downloadSources set in settings.xml -- Key: MECLIPSE-383 URL: http://jira.codehaus.org/browse/MECLIPSE-383 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Max Bowsher Priority: Trivial Currently, some tests fail if the user has configured downloadSources=true in their settings.xml: testProject13(org.apache.maven.plugin.eclipse.EclipsePluginTest) testProject22(org.apache.maven.plugin.eclipse.EclipsePluginTest) testProject29(org.apache.maven.plugin.eclipse.EclipsePluginTest) testProject30(org.apache.maven.plugin.eclipse.EclipsePluginTest) These are comparison failures because the actual .classpath then includes sourcepath="..." which is not present in the expected. Ideally the tests would force downloadSources one way or the other, for reproducible results independent of the local settings.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: (MRM-679) Provide a test button for network proxy and remote proxy
Provide a test button for network proxy and remote proxy Key: MRM-679 URL: http://jira.codehaus.org/browse/MRM-679 Project: Archiva Issue Type: Wish Components: remote proxy Affects Versions: Future Reporter: Carlton Brown Priority: Minor On the network proxy, there are 2 icons for "edit proxy" or "delete proxy". There should also be a "test proxy" button to test whether the proxy settings are valid. The "test proxy" button could open a form consisting simply of a textbox in which to enter a remote URL and a "Go" button to attempt a get. The results should return success or failure to reach the remote URL along with whatever other useful diagnostic information could be retrieved in such a test. Likewise the repository proxy connectors should have a "test" button in addition to the existing edit, delete, up, down buttons. -- 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-383) Tests should be independent of downloadSources set in settings.xml
[ http://jira.codehaus.org/browse/MECLIPSE-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122076 ] Arnaud Heritier commented on MECLIPSE-383: -- I began to force the download but I probably forgot some of them. I'l try to review this. What I'll probably do is to add a parent pom where I set it for all tests. > Tests should be independent of downloadSources set in settings.xml > -- > > Key: MECLIPSE-383 > URL: http://jira.codehaus.org/browse/MECLIPSE-383 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Reporter: Max Bowsher >Priority: Trivial > > Currently, some tests fail if the user has configured downloadSources=true in > their settings.xml: > testProject13(org.apache.maven.plugin.eclipse.EclipsePluginTest) > testProject22(org.apache.maven.plugin.eclipse.EclipsePluginTest) > testProject29(org.apache.maven.plugin.eclipse.EclipsePluginTest) > testProject30(org.apache.maven.plugin.eclipse.EclipsePluginTest) > These are comparison failures because the actual .classpath then includes > sourcepath="..." which is not present in the expected. > Ideally the tests would force downloadSources one way or the other, for > reproducible results independent of the local settings.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] Closed: (DOXIA-209) FAQ section without question ends up in NPE
[ http://jira.codehaus.org/browse/DOXIA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-209. --- Assignee: Lukas Theussl Resolution: Cannot Reproduce > FAQ section without question ends up in NPE > --- > > Key: DOXIA-209 > URL: http://jira.codehaus.org/browse/DOXIA-209 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Fml >Affects Versions: 1.0-alpha-10 >Reporter: Jerome Lacoste >Assignee: Lukas Theussl >Priority: Critical > > This happened during a release:perform > [INFO] [site:site] > [WARNING] Unable to load parent project from repository: Could not > find the model file > '/home/jerome/Code/OSS/m2/mojo/keytool-maven-plugin/target/checkout/../pom.xml'. > [INFO] Skipped "Maven Surefire Report" report, file > "surefire-report.html" already exists for the English version. > [INFO] Skipped "About" report, file "index.html" already exists for > the English version. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.doxia.module.fml.FmlParser.createSink(FmlParser.java:270) > at > org.apache.maven.doxia.module.fml.FmlParser.parse(FmlParser.java:61) > at > org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:52) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:264) > at > org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:43) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124) > at > org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > 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:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 6 minutes 48 seconds > [INFO] Finished at: Wed Jan 30 22:46:46 GMT+01:00 2008 > [INFO] Final Memory: 35M/108M > [INFO] > > [INFO] > > This faq should help reproducing the pb: > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http:
[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_122085 ] Siarhei Dudzin commented on MECLIPSE-184: - Arnaud, I don't think this issue is valid anymore. I configure location of utility jar's by specifying lib in the config of ear plugin and it deploys correctly by WTP+JBoss Tools combination (it does exploded deployment which works very well). So by using this setting I get the /lib in my ear where all the utility jar's are stored... > 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] Closed: (MPLUGIN-61) NPE in plugin site when a mojo has no configuration injection
[ http://jira.codehaus.org/browse/MPLUGIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-61. -- Assignee: Vincent Siveton Resolution: Cannot Reproduce Cannot reproduce on trunk > NPE in plugin site when a mojo has no configuration injection > - > > Key: MPLUGIN-61 > URL: http://jira.codehaus.org/browse/MPLUGIN-61 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin > Environment: xp >Reporter: Dan Tran >Assignee: Vincent Siveton > Attachments: site.log > > > When a plugin has a mojo with no configuration injection like the one at > https://svn.codehaus.org/mojo/tags/maven-native-1.0-alpha-1/native-maven-plugin/src/main/java/org/codehaus/mojo/natives/plugin/NativeInitializeMojo.java > mvn site throws NPE. See attached log -- 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-96) WebResource not filtered with system properties.
[
http://jira.codehaus.org/browse/MWAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MWAR-96.
Assignee: Olivier Lamy
Resolution: Fixed
fixed in rev 617677. Now the plugin use the maven-filtering component.
> WebResource not filtered with system properties.
>
>
> Key: MWAR-96
> URL: http://jira.codehaus.org/browse/MWAR-96
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: java 5.0, Windows XP
>Reporter: KlaasJan Elzinga
>Assignee: Olivier Lamy
> Fix For: 2.1-alpha-2
>
> Attachments: patch-CompositeMapa.txt, patch-junit-test.txt
>
>
> When filtering a resource:
>
>
> ${basedir}/src/main/resources/
> true
>
> index.jsp
>
>
>
> The index.jsp contains:
> java version${java.version}
> Project${pom.name}
> Version${pom.version}
> After mvn clean install the filtered index.jsp looks like:
> java version1.0.0.SNAPSHOT
> ProjectFrieslandBank TMS TNS WebApp
> Version1.0.0.SNAPSHOT
> The value java.version is filtered to the version of the pom and not the
> system property. The same goes for os.name which is translated to pom.name.
--
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: (MPLUGIN-11) add an introduction to plugin configuration in plugin report
[ http://jira.codehaus.org/browse/MPLUGIN-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-11. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 Fixed in r617684 with some changes from your patch to include also system requirements. Snapshot deployed. > add an introduction to plugin configuration in plugin report > > > Key: MPLUGIN-11 > URL: http://jira.codehaus.org/browse/MPLUGIN-11 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement >Reporter: Herve Boutemy >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.4 > > Attachments: MPLUGIN-11.patch, MPLUGIN-intro.patch, > MPLUGIN-intro2.patch, plugin-info.html, PluginXdocGenerator.java > > > From: Hervé BOUTEMY [mailto:...] > Sent: Thursday, January 05, 2006 2:34 AM > To: Maven Users List > Subject: Re: [ANN] dependency-maven-plugin 1.0 > > (The following is a little off-topic for dependency-maven-plugin > > specifically, but I think it needs to be said.) > > > > For an experience Maven2 user, the value of these docs is immediately > > obvious. > > > > For the newbie, however, there is still the feeling: > > > >"OK, so now what do I do." > +1 (+2 if I could) > a simple addition in the "About xxx plugin" generated file would do the trick. > For example, if you see > http://maven.apache.org/plugins/maven-site-plugin/index.html > After the "Goals available:" table, simply add : > "Configuration: > To use this plugin, you will need to add to your pom : > > org.apache.maven.plugins (is this necessary ? > perhaps not for org.apache.maven.plugins, but for other like > org.codehaus.mojo...) > maven-site-plugin > > For more information, see "Guide to Conguring Plug-ins" (link to > http://maven.apache.org/guides/mini/guide-configuring-plugins.html)" > the patch provided inserts text to the Plugin documentation report, not to > the "About" 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: (MPLUGIN-67) Document somewhere the minimum version of maven required by the plugin
[ http://jira.codehaus.org/browse/MPLUGIN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-67. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 Fixed in r617684. Snapshot deployed. > Document somewhere the minimum version of maven required by the plugin > -- > > Key: MPLUGIN-67 > URL: http://jira.codehaus.org/browse/MPLUGIN-67 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Arnaud Heritier >Assignee: Vincent Siveton > Fix For: 2.4 > > > When a plugin is designed for a minimal version of maven this information > isn't documented on the web site. It is important to have this information to > know if we can upgrade it or not on a given version of maven. > A cool thing could be to have an history of this compatibility to know which > is the last version available for a given version of maven's core. -- 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
