[jira] Updated: (SUREFIRE-422) Strip "Maven" from report title
[ http://jira.codehaus.org/browse/SUREFIRE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated SUREFIRE-422: --- Fix Version/s: (was: 2.5) 2.4.3 > Strip "Maven" from report title > --- > > Key: SUREFIRE-422 > URL: http://jira.codehaus.org/browse/SUREFIRE-422 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Trivial > Fix For: 2.4.3 > > Attachments: report-title.patch > > > Currently, the plugin generates a report named "Maven Surefire Report". I > consider "Maven" boilerplate text here that should be removed (of course it's > Maven, what else?). All other reporing plugins I have come along so far do > not use "Maven" in their title neither. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-423) Output a title for the report
[
http://jira.codehaus.org/browse/SUREFIRE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated SUREFIRE-423:
---
Fix Version/s: (was: 2.5)
2.4.3
> Output a title for the report
> -
>
> Key: SUREFIRE-423
> URL: http://jira.codehaus.org/browse/SUREFIRE-423
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.3
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Trivial
> Fix For: 2.4.3
>
> Attachments: report-header.patch
>
>
> Currently, the final HTML output of the report plugin has a title like
> "${project.name} - ". See the [Surefire report of the Taglist
> Plugin|http://mojo.codehaus.org/taglist-maven-plugin/surefire-report.html|]
> for an example. But it should be something like "${project.name} - Surefire
> Report".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-460) surefire-api manifest content is wrong: it is a copy of commons-lang
[ http://jira.codehaus.org/browse/SUREFIRE-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated SUREFIRE-460: --- Fix Version/s: (was: 2.5) 2.4.3 > surefire-api manifest content is wrong: it is a copy of commons-lang > > > Key: SUREFIRE-460 > URL: http://jira.codehaus.org/browse/SUREFIRE-460 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4, 2.4.1, 2.4.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.4.3 > > > this causes trouble if you're relying (like me) on the manifest content to > know a jar content description -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-484) Don't output empty tables
[
http://jira.codehaus.org/browse/SUREFIRE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated SUREFIRE-484:
---
Fix Version/s: (was: 2.5)
2.4.3
> Don't output empty tables
> -
>
> Key: SUREFIRE-484
> URL: http://jira.codehaus.org/browse/SUREFIRE-484
> Project: Maven Surefire
> Issue Type: Improvement
> Components: report plugin
>Affects Versions: 2.4.2
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.4.3
>
>
> This makes creating a nice custom skin difficult:
> {code:java}
> private void sinkLineBreak( Sink sink )
> {
> sink.table();
> sink.tableRow();
> sink.tableRow_();
> sink.tableRow();
> sink.tableRow_();
> sink.table_();
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-426) Add german translation
[ http://jira.codehaus.org/browse/SUREFIRE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated SUREFIRE-426: --- Fix Version/s: (was: 2.5) 2.4.3 > Add german translation > -- > > Key: SUREFIRE-426 > URL: http://jira.codehaus.org/browse/SUREFIRE-426 > Project: Maven Surefire > Issue Type: Improvement > Components: report plugin >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.4.3 > > Attachments: i18n-de.patch > > > Teaching the report another language. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-264) XRef links do not work with aggregated reports on windows
[
http://jira.codehaus.org/browse/SUREFIRE-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated SUREFIRE-264:
---
Fix Version/s: (was: 2.5)
2.4.3
> XRef links do not work with aggregated reports on windows
> -
>
> Key: SUREFIRE-264
> URL: http://jira.codehaus.org/browse/SUREFIRE-264
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.0 Report Plugin
>Reporter: Maarten Winkels
>Assignee: Herve Boutemy
> Fix For: 2.4.3
>
> Attachments: outputDirectoryIsFile.patch
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When generating aggregated reports with the jxr-plugin, the xref links cannot
> be generated correctly on windows.
> This is mainly due to the fact that the outputDirectory is a java.lang.String
> property in stead of a java.io.File property. This makes the propert os
> dependant. The expression with this property is
> ${project.build.directory}/site. On windows this should be
> ${project.build.directory}\site. It might even be beter to change it to
> ${project.reporting.outputDirectory}. See the checkstyle plugin for reference.
> When working with aggregated jxr-reports, the xrefLocation (which IS a
> java.io.File property) should preferable be
> ${project.build.directory}/site/../xref-test, since this is the relative
> publish location of the reports. Being a java.lang.String property, this will
> resolve to something like c:\[path to build
> directory]\target\site\..\xref-test. In the
> SurefireReportMojo.determineXrefLocation the absolute path of this file
> property is compared to the outputDirectory which is a java.lang.String it
> will probably be set to c:\[path to build directory]\target/site (n.b.
> forward slash in stead of backward slash), which will lead to an empty
> relative path, where ../xref-test would be expected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-459) Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated SUREFIRE-459: --- Fix Version/s: (was: 2.5) 2.4.3 > Integration test using Jetty and JSP 2.1 fails after update to > maven-surefire-plugin 2.4 > > > Key: SUREFIRE-459 > URL: http://jira.codehaus.org/browse/SUREFIRE-459 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, plugin >Affects Versions: 2.4, 2.4.1 > Environment: Maven 2.0.8, Windows XP >Reporter: Nils-Helge Garli >Assignee: Dan Fabulich > Fix For: 2.4.3 > > > We have an integration test running in a Struts 2 sample application, and > after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is > failing. There's an issue registered in the Struts 2 JIRA explaining the > error: https://issues.apache.org/struts/browse/WW-2494 > I have no idea what's causing the error, but I suspect it has something to do > witn classloader configuration, as aparently no tld files are found inside > the jar files on the classpath. > It should be pretty easy to reproduce. Just checkout the Struts 2 code and > run 'mvn test' on the portlet example application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-467) NoSuchMethodError UrlUtils.getURL when using JDK3 for testing
[
http://jira.codehaus.org/browse/SUREFIRE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated SUREFIRE-467:
---
Fix Version/s: (was: 2.5)
2.4.3
> NoSuchMethodError UrlUtils.getURL when using JDK3 for testing
> -
>
> Key: SUREFIRE-467
> URL: http://jira.codehaus.org/browse/SUREFIRE-467
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4.2
> Environment: Maven 2.0.8
> JDK 1.5.0_11
> JDK 1.3.1_20
>Reporter: Antoine Véret
>Assignee: Herve Boutemy
> Fix For: 2.4.3
>
> Attachments: debug.log
>
>
> java.lang.NoSuchMethodError
> at org.apache.maven.surefire.util.UrlUtils.getURL(UrlUtils.java:39)
> at
> org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:730)
> Only appears when using JDK3, not JDK4 with the following configuration
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> ${JDK3_HOME}/bin/java
>
>
> See the debug 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] Updated: (SUREFIRE-440) Fix serialization of File[] into properties for forked Surefire run
[ http://jira.codehaus.org/browse/SUREFIRE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated SUREFIRE-440: --- Fix Version/s: (was: 2.5) 2.4.3 > Fix serialization of File[] into properties for forked Surefire run > --- > > Key: SUREFIRE-440 > URL: http://jira.codehaus.org/browse/SUREFIRE-440 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.4 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy > Fix For: 2.4.3 > > Attachments: file-array-conversion.patch > > > The logic in SurefireBooter.convert() to produce a string for a File[] is > broken. It currently produces something like > [file1file2,] > instead of > [file1,file2] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error
[ http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133395#action_133395 ] Herve Boutemy commented on MANTTASKS-87: can you attach a testcase, please? > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error > - > > Key: MANTTASKS-87 > URL: http://jira.codehaus.org/browse/MANTTASKS-87 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.7 > Environment: WindowsXP > Ant version 1.7.0 >Reporter: Jeff Campbell >Assignee: Herve Boutemy >Priority: Blocker > Fix For: 2.0.8 > > > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error. > This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to > maven-ant-tasks-2.0.7.jar and still an issue with the latest > maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)). > Just to see if I had done something wrong with the pom.xml file I tried to > run a Maven goal against the pom.xml file. I found that if I run "mvn clean" > from this same directory (where the build.xml and pom.xml file is located), > using Maven-2.0.7, I get a build successfull (it was able to find the parent > pom.xml file... so this seems to be isolated to JUST the maven-ant-task not > being able to find the parent pom.xml) > Sample of the pom.xml file > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > intuit.sbconnect > sbclogin > 1.0.3 > SBCLogin > > > mygroup > CommonPOM > 1.0.2 > > > > > myothergroup > myartifact > 1.0 > > > > Line in Ant build.xml file that causes the error: > > Error that occurs when this line is executed in ant: > Error downloading parent pom: Missing: > -- > 1) mygroup:CommonPOM:pom:1.0.2 > Path to dependency: > 1) unspecified:unspecified:jar:0.0 > 2) mygroup:CommonPOM:pom:1.0.2 > -- > 1 required artifact is missing. > for artifact: > unspecified:unspecified:jar:0.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133371#action_133371 ] Paul Benedict commented on MNG-3268: It appears this patch also fixes MNG-3545 > Command line doesn't handle multiple -P correctly > - > > Key: MNG-3268 > URL: http://jira.codehaus.org/browse/MNG-3268 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Henri Tremblay >Assignee: Paul Gier > Fix For: 2.0.10, 2.1-alpha-1 > > Attachments: MNG-3268-maven-core.patch > > > It is currently not possible to have more than one -P on the same command > line. Only the first specified profile is considered. > So if you do > mvn -Pmain -Ptest > only the main profile will be taken into account. > This may sound enough but it's not when your maven call is wrapped into a > batch file. Let's say you have a batch doing the compilation of a given > module: > a.bat > - > mvn install -Pmymodule %* > - > and you want to pass a special integration tests profile you would do: > a.bat -Pintegration-tests > But that won't work since you are not allowed to have two -P. > To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2044) Please upload jSSLutils 0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Harbulot closed MAVENUPLOAD-2044. --- Resolution: Duplicate Sorry, I was suggested to bundle the resources required for the tests in a separate bundle. I've thus submitted a new issue in MAVENUPLOAD-2047. > Please upload jSSLutils 0.2 > --- > > Key: MAVENUPLOAD-2044 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2044 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Bruno Harbulot > > Hello, I'm the developer and project owner of jsslutils. Could you please > upload this project in the repository? > Thank you. > Bruno. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2047) Please upload jSSLutils 0.2.1
Please upload jSSLutils 0.2.1 - Key: MAVENUPLOAD-2047 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2047 Project: maven-upload-requests Issue Type: Wish Reporter: Bruno Harbulot Hello, I'm the developer and project owner of jsslutils. Could you please upload this project in the repository? There is a test-scoped dependency to com.googlecode.jsslutils:jsslutils-test-certificates:1.0 (MAVENUPLOAD-2046). Thank you. Bruno. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2046) Please upload jSSLutils test certificates 1.0
Please upload jSSLutils test certificates 1.0 - Key: MAVENUPLOAD-2046 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2046 Project: maven-upload-requests Issue Type: Wish Reporter: Bruno Harbulot Hello, I'm the developer and project owner of jsslutils. Could you please upload this bundle in the repository? Thank you. Bruno. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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&focusedCommentId=133365#action_133365 ] David Smiley commented on MCOMPILER-65: --- Great, it appears that this new "Toolchains" feature of Maven specifically addresses this concern. Hopefully it'll be the standard way the compiler is executed in maven. Does this replace the compiler plugin somehow? If not I think it'll add configuration complexity because then there are two areas to configure this, the compiler and toolchain. > 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: (MNG-2795) Classloader problem loading a resource from a build extension Jar : difference between 2.0.4 and (future) 2.0.5
[ http://jira.codehaus.org/browse/MNG-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133362#action_133362 ] Josh Kitterman commented on MNG-2795: - I still see this issue with Maven 2.0.9. 'mvn checkstyle:checkstyle site' works, but 'mvn site' fails with the error: Embedded error: Error rendering Maven report: Unable to find configuration file at location ... Could not find resource ... I have a custom jar configured as a build extension containing the configuration xml file. I can confirm it works in Maven 2.0.4, but not 2.0.5+. > Classloader problem loading a resource from a build extension Jar : > difference between 2.0.4 and (future) 2.0.5 > --- > > Key: MNG-2795 > URL: http://jira.codehaus.org/browse/MNG-2795 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.5 >Reporter: Fabrice BELLINGARD >Assignee: Jason van Zyl > Fix For: 2.0.5 > > Attachments: Checkstyle-2.0.4.txt, Checkstyle-2.0.5.txt, > Test-BuildExtension.zip > > > I had a problem when executing the Checkstyle plugin (version 2.1) with the > pre-release of Maven 2.0.5. So I dug a bit to see if this could be related to > maven core or not, and here is what I found. > I isolated the code that breaks the build in the checkstyle plugin: it > happens when the plugin tries to load my Checkstyle configuration file, which > is actually located in a JAR that is specified in the build extensions. The > code lies in the Locator#resolveLocation() method: > // Attempt a Resource. > URL url = this.getClass().getClassLoader().getResource( > location ); > This code returns null for the "url" variable, which in turns breaks the > plugin because it doesn't find any configuration file. > I haven't had the time to dig more into it, but I found the following issue > that might be related to this problem: "MNG-2228 : Classloader problem > loading jars from build extensions". Brett and Carlos worked on it and fixed > it, so maybe they could tell more about it. > I attached the logs of the execution with Maven 2.0.4 (which works fine) and > Maven 2.0.5 (which breaks). I haven't had the time yet to dig further into > that problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MNG-3268. -- Resolution: Fixed This is now fixed in svn. > Command line doesn't handle multiple -P correctly > - > > Key: MNG-3268 > URL: http://jira.codehaus.org/browse/MNG-3268 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Henri Tremblay >Assignee: Paul Gier > Fix For: 2.0.10, 2.1-alpha-1 > > Attachments: MNG-3268-maven-core.patch > > > It is currently not possible to have more than one -P on the same command > line. Only the first specified profile is considered. > So if you do > mvn -Pmain -Ptest > only the main profile will be taken into account. > This may sound enough but it's not when your maven call is wrapped into a > batch file. Let's say you have a batch doing the compilation of a given > module: > a.bat > - > mvn install -Pmymodule %* > - > and you want to pass a special integration tests profile you would do: > a.bat -Pintegration-tests > But that won't work since you are not allowed to have two -P. > To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPH-38) mvn help:active-profiles won't show the active profiles in settings.xml
[ http://jira.codehaus.org/browse/MPH-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133354#action_133354 ] Julie Pitt commented on MPH-38: --- I am having the exact same issue on windows with JDK 1.5.0_14 > mvn help:active-profiles won't show the active profiles in settings.xml > > > Key: MPH-38 > URL: http://jira.codehaus.org/browse/MPH-38 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: linux (never tried it in windows), sun's jdk 1.5.0_12 >Reporter: Allan G. Ramirez > > settings.xml has this > > appserverConfig > > pom.xml of MavenProject2 project has this > > appserverConfig-dev-2 > > true > > env > dev-2 > > > > /path/to/another/dev/appserver2 > > > I tried mvn help:active-profiles using the maven 2.1-SNAPSHOT I only got > - appserverConfig-dev-2 (source: pom) > appserverConfig defined in settings.xml is not shown -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2045) Upload SNMP4J 1.9.1e
Upload SNMP4J 1.9.1e Key: MAVENUPLOAD-2045 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2045 Project: maven-upload-requests Issue Type: Wish Reporter: Paul Donohue http://www.PaulSD.com/snmp4j-1.9.1e-bundle.jar http://www.snmp4j.org/ I AM NOT an SNMP4J developer. I asked about updating the maven repo on the SNMP4J mailing list and received no response, so I assume they are ok with me requesting an update to the maven repo. 1.9.1e is the latest release. 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] Commented: (MANTTASKS-87) Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a "Error downloading parent pom" error
[ http://jira.codehaus.org/browse/MANTTASKS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133349#action_133349 ] Pino Silvaggio commented on MANTTASKS-87: - With 2.0.9 this bug still exists. Using custom repos in settings.xml the repositories resolution of the parent pom will omit repos from settings.xml and always use the first mirror or http://repo1.maven.org/maven2. >From what I can see this issue still exists in trunk since the code hasn't >changed. In Pom.checkParentPom a Model is created from the pom.xml but the >model.getRepositories() returned is incorrect. > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error > - > > Key: MANTTASKS-87 > URL: http://jira.codehaus.org/browse/MANTTASKS-87 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.7 > Environment: WindowsXP > Ant version 1.7.0 >Reporter: Jeff Campbell >Assignee: Herve Boutemy >Priority: Blocker > Fix For: 2.0.8 > > > Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml > will cause a "Error downloading parent pom" error. > This WAS NOT a bug with version 2.0.6 of the maven-ant-tasks (new issue to > maven-ant-tasks-2.0.7.jar and still an issue with the latest > maven-ant-tasks-2.0.8-SNAPSHOT.jar (as of the writting of this bug)). > Just to see if I had done something wrong with the pom.xml file I tried to > run a Maven goal against the pom.xml file. I found that if I run "mvn clean" > from this same directory (where the build.xml and pom.xml file is located), > using Maven-2.0.7, I get a build successfull (it was able to find the parent > pom.xml file... so this seems to be isolated to JUST the maven-ant-task not > being able to find the parent pom.xml) > Sample of the pom.xml file > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > intuit.sbconnect > sbclogin > 1.0.3 > SBCLogin > > > mygroup > CommonPOM > 1.0.2 > > > > > myothergroup > myartifact > 1.0 > > > > Line in Ant build.xml file that causes the error: > > Error that occurs when this line is executed in ant: > Error downloading parent pom: Missing: > -- > 1) mygroup:CommonPOM:pom:1.0.2 > Path to dependency: > 1) unspecified:unspecified:jar:0.0 > 2) mygroup:CommonPOM:pom:1.0.2 > -- > 1 required artifact is missing. > for artifact: > unspecified:unspecified:jar:0.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133344#action_133344 ] bryanloof edited comment on MEAR-85 at 5/2/08 10:38 AM: The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use , and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. was (Author: bryanloof): The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use , and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. > ejb-client dependencies should be placed in def
[jira] Created: (MNGSITE-52) Broken link on http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Broken link on http://maven.apache.org/guides/mini/guide-central-repository-upload.html --- Key: MNGSITE-52 URL: http://jira.codehaus.org/browse/MNGSITE-52 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: Paul Donohue Priority: Minor About half way down http://maven.apache.org/guides/mini/guide-central-repository-upload.html it says: You can see the list of repositories synchronized automatically for examples And it links to https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv https currently does not appear to be working on svn.apache.org, so the link above does not work. However, if you change https to http, it works fine: http://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv It would probably be helpful if this link were updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133344#action_133344 ] Bryan Loofbourrow commented on MEAR-85: --- The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use , and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. > ejb-client dependencies should be placed in defaultLibBundleDir > --- > > Key: MEAR-85 > URL: http://jira.codehaus.org/browse/MEAR-85 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 >Reporter: James Olsen >Priority: Minor > > ejb-client jars should be placed in the defaultLibBundleDir when specified. > They're just standard jar dependencies not J2EE artifacts so should be > treated the same as other jars. They're currently being placed in the root > directory. > A workaround is to add an ejbClientModule entry to override the bundleDir: > > > ... > ... > lib > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2044) Please upload jSSLutils 0.2
Please upload jSSLutils 0.2 --- Key: MAVENUPLOAD-2044 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2044 Project: maven-upload-requests Issue Type: Wish Reporter: Bruno Harbulot Hello, I'm the developer and project owner of jsslutils. Could you please upload this project in the repository? Thank you. Bruno. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2043) Upload request for unitils-1.1-rc-2
Upload request for unitils-1.1-rc-2 --- Key: MAVENUPLOAD-2043 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2043 Project: maven-upload-requests Issue Type: Task Reporter: Tim Ducheyne "org.unitils","[EMAIL PROTECTED]:/home/groups/u/un/unitils/htdocs/m2-repo","rsync_ssh","Tim Ducheyne","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (JXR-62) Make file encoding default to platform encoding
[ http://jira.codehaus.org/browse/JXR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14#action_14 ] Benjamin Bentmann commented on JXR-62: -- You bet right, the Compiler Plugin is using platform encoding by default. I requested to change this in MCOMPILER-63 but have already re-opened the issue to revert the changes on trunk (if SVN ever comes back...). > Make file encoding default to platform encoding > --- > > Key: JXR-62 > URL: http://jira.codehaus.org/browse/JXR-62 > Project: Maven JXR > Issue Type: Wish > Components: maven2 jxr plugin >Affects Versions: 2.0 >Reporter: Benjamin Bentmann >Priority: Minor > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding and outputEncoding should default to the platform default > encoding instead of Latin-1. Since that would be a breaking change it is left > to users to vote for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (JXR-62) Make file encoding default to platform encoding
[ http://jira.codehaus.org/browse/JXR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12#action_12 ] Brian Fox commented on JXR-62: -- What encoding is the compiler using? It seems to me that this should match the compiler as it is also primarily reading the source. My bet without looking is that the compiler is using platform encoding by default. > Make file encoding default to platform encoding > --- > > Key: JXR-62 > URL: http://jira.codehaus.org/browse/JXR-62 > Project: Maven JXR > Issue Type: Wish > Components: maven2 jxr plugin >Affects Versions: 2.0 >Reporter: Benjamin Bentmann >Priority: Minor > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding and outputEncoding should default to the platform default > encoding instead of Latin-1. Since that would be a breaking change it is left > to users to vote for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-320) Reference documentation
[ http://jira.codehaus.org/browse/MSITE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133329#action_133329 ] Dennis Lundberg commented on MSITE-320: --- We have fairly extensive documentation about the site.xml file here: http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html Isn't that enough? > Reference documentation > --- > > Key: MSITE-320 > URL: http://jira.codehaus.org/browse/MSITE-320 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.0-beta-6 > Environment: All >Reporter: Alfonsas Stonis > > There is no documentation for site. I mean there is some, but this is not > enough. For example there is no reference what elements can be included in > site.xml. What are tags? No clue. It is not possible to use it as it is now. > I do understand I can find out what they do by trying, but at least I need to > know what they are. I tried to search on internet for any documentation, but > no success. It is very frustrating. I think many users give up using it, just > because they can not find what it can do and how to use it. > Please provide at least simple list of the elements that are available in > site.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] Commented: (MCHANGELOG-84) wrong SVN directory path created when using cascaded pom modules(?)
[
http://jira.codehaus.org/browse/MCHANGELOG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133311#action_133311
]
Rintcius Blok commented on MCHANGELOG-84:
-
Ah ok that makes sense. The effective-pom showed that the SCM URLs were
different than I thought they were, when I refer to a *released* version of the
parent pom. In that case the SCM url of the parent pom is changed to a
tags/parent-pom-. I assumed that what was specified under the SCM
element in the parent just served as a template, but in case of a release it is
changed to the actual url.
Maybe something can be added to the FAQ about checking the SCM element in the
effective-pom since that is quite helpful to get more insight in more complex
situations. And it makes perfectly clear when the source of the unexpected
behavior is outside the scope of the changelog plugin.
Anyway, thanks for your explanation Dennis!
> wrong SVN directory path created when using cascaded pom modules(?)
> ---
>
> Key: MCHANGELOG-84
> URL: http://jira.codehaus.org/browse/MCHANGELOG-84
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: java 1.5.0_13 / mac os x / maven 2.0.7
>Reporter: jens breitenstein
>
> When executing "site" the plugin accesses a wrong svn path (see log below).
> the pom look similar to this (well, I simplified it a bit :-)
> root.pom
>
> {code:xml}
>
>...
>
> ...
> configuration
> ...
>
>
>
> {code}
> pom (in directory configuration)
> --
> {code:xml}
>
> ... root.pom ...
>
> 4.0.0
> my.group.configuration
> PREFIX-configuration
> jar
>
>
> {code}
> directory layout:
> {noformat}
>
> ` root-pom
> `
> ` sub-module-pom this file defines the artifact
> "PREFIX-configuration.jar"
> {noformat}
> [INFO] Generating "Change Log" report.
> [INFO] Generating changed sets xml to:
> /**/trunk/configuration/target/changelog.xml
> [INFO] Executing: svn --username --password * --non-interactive log
> -v -r "{2008-03-24 13:32:56 +}:{2008-04-24 13:32:56 +}"
> https://***/svn/***/trunk/PREFIX-configuration
> [INFO] Working directory: //trunk/configuration
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: REPORT request failed on
> '/svn/!svn/bc/461/***/trunk/PREFIX-configuration'
> svn: '/svn/!svn/bc/461//trunk/PREFIX-configuration' path not found
> "PREFIX-configuration" is the artifact name in the "sub-module" pom not a
> directory. The root pom access this child pom via the module element
> "configuration" which is identical to the directory in the file system and
> the svn repository. So correctly the svn command should look like
> {noformat}"https://***/svn/***/trunk/configuration"{noformat} and not
> {noformat}"https://***/svn/***/trunk/PREFIX-configuration"{noformat}.
> In case I understand the error message correctly the plugin tries to read a
> directory which is named like the artifact-id which is wrong here?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MRESOURCES-57) Provide specific default value for "encoding" parameter
[ http://jira.codehaus.org/browse/MRESOURCES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MRESOURCES-57: - Needs to be reverted to use platform encoding by default. > Provide specific default value for "encoding" parameter > --- > > Key: MRESOURCES-57 > URL: http://jira.codehaus.org/browse/MRESOURCES-57 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.3 > > Attachments: resource-encoding.patch > > > The platform's default encoding may easily differ among machines/developers > so relying on it breaks with the aim of reproducible builds. The encoding > used should always be fixed for a particular plugin run, either explicitly by > the user or implicitly by a known default value. > See also MCOMPILER-63. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPMD-79) Warn about usage of platform encoding
[ http://jira.codehaus.org/browse/MPMD-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MPMD-79: -- Fix Version/s: 2.4 > Warn about usage of platform encoding > - > > Key: MPMD-79 > URL: http://jira.codehaus.org/browse/MPMD-79 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 2.4 > > > Relying on the platform encoding makes a build platform-dependent and > threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPMD-79) Warn about usage of platform encoding
Warn about usage of platform encoding - Key: MPMD-79 URL: http://jira.codehaus.org/browse/MPMD-79 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: CPD, PMD Affects Versions: 2.3 Reporter: Benjamin Bentmann Priority: Minor Fix For: 2.4 Relying on the platform encoding makes a build platform-dependent and threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPMD-76) use ${project.build.sourceEncoding} as default value for "sourceEncoding" parameter
[
http://jira.codehaus.org/browse/MPMD-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MPMD-76:
---
Needs to be partly reverted to keep using platform encoding by default.
> use ${project.build.sourceEncoding} as default value for "sourceEncoding"
> parameter
> ---
>
> Key: MPMD-76
> URL: http://jira.codehaus.org/browse/MPMD-76
> Project: Maven 2.x PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
>Affects Versions: 2.3
>Reporter: Herve Boutemy
>Assignee: Benjamin Bentmann
> Fix For: 2.4
>
>
> see
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPLUGIN-111) Warn about usage of platform encoding
Warn about usage of platform encoding - Key: MPLUGIN-111 URL: http://jira.codehaus.org/browse/MPLUGIN-111 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 2.4 Reporter: Benjamin Bentmann Priority: Minor Relying on the platform encoding makes a build platform-dependent and threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-100) Allow customization of file encoding used for generated help goal
[
http://jira.codehaus.org/browse/MPLUGIN-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133308#action_133308
]
Benjamin Bentmann commented on MPLUGIN-100:
---
The default encoding needs to be kept at platform encoding.
> Allow customization of file encoding used for generated help goal
> -
>
> Key: MPLUGIN-100
> URL: http://jira.codehaus.org/browse/MPLUGIN-100
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Plugin Plugin
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
> Attachments: help-goal-encoding.patch, help-goal-encoding.patch
>
>
> If the executing JVM runs using {{file.encoding}} = ISO-8859-1 but the
> project source code is expected to be encoded in UTF-8, the generated help
> goal will mess up non-ascii characters. To smoothly integrate into the build,
> the mojo needs a parameter to configure the desired encoding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-2026) JavaNCSS 29.50 Upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Brandhof updated MAVENUPLOAD-2026: Attachment: javancss-29.50-bundle.jar jhbasic-29.50-bundle.jar ccl-29.50-bundle.jar Carlos, bundles are updated with good maven versions. > JavaNCSS 29.50 Upload request > - > > Key: MAVENUPLOAD-2026 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2026 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Jean-Laurent de Morlhon > Attachments: ccl-29.50-bundle.jar, ccl-29.50-bundle.jar, > javancss-29.50-bundle.jar, javancss-29.50-bundle.jar, > jhbasic-29.50-bundle.jar, jhbasic-29.50-bundle.jar > > > This new JavaNCSS version includes a fix for java 1.5 syntax parsing. > This issue is related to MJNCSS-16 & MJNCSS-28. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (JXR-62) Make file encoding default to platform encoding
Make file encoding default to platform encoding --- Key: JXR-62 URL: http://jira.codehaus.org/browse/JXR-62 Project: Maven JXR Issue Type: Wish Components: maven2 jxr plugin Affects Versions: 2.0 Reporter: Benjamin Bentmann Priority: Minor According to the [user poll about the default file encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], the inputEncoding and outputEncoding should default to the platform default encoding instead of Latin-1. Since that would be a breaking change it is left to users to vote for this issue if they feelt it's worth to have it like that. If the change is made, we should have the plugin output a warning when using the platform encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-73) Warn about usage of platform encoding
Warn about usage of platform encoding - Key: MCOMPILER-73 URL: http://jira.codehaus.org/browse/MCOMPILER-73 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Benjamin Bentmann Priority: Minor Fix For: 2.1 Relying on the platform encoding makes a build platform-dependent and threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCOMPILER-73) Warn about usage of platform encoding
[ http://jira.codehaus.org/browse/MCOMPILER-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MCOMPILER-73: --- Fix Version/s: 2.1 > Warn about usage of platform encoding > - > > Key: MCOMPILER-73 > URL: http://jira.codehaus.org/browse/MCOMPILER-73 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 2.1 > > > Relying on the platform encoding makes a build platform-dependent and > threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3348) Add new dependency scope "bootstrap" to support concept of boot class path
[ http://jira.codehaus.org/browse/MNG-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133302#action_133302 ] Benjamin Bentmann commented on MNG-3348: Compare [Toolchains|http://docs.codehaus.org/display/MAVEN/Toolchains]. > Add new dependency scope "bootstrap" to support concept of boot class path > -- > > Key: MNG-3348 > URL: http://jira.codehaus.org/browse/MNG-3348 > Project: Maven 2 > Issue Type: New Feature > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann > > When it comes to cross-platform compilation, one needs to feed in a > bootclasspath into various JDK tools like javac or javadoc (see MCOMPILER-20, > MOJO-606). Currently, the affected Maven plugins provide a configuration > parameter on their own to deal with this concept. Usually, this configuration > needs to be configured with file system paths (either to some JARs in the > local repo or to the user's JDK installation). > That's not really the Maven way. Maven builds classpaths from dependencies > and hence, the bootclasspath should be configurable via dependencies, too. > Having a dedicated scope for such dependencies would make plugin development > and configuration more straightforeward in the case of cross-platform > compilation. > My post MCOMPILER-20#action_112355 may be used as an inspiration, how such a > new scope could look like. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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&focusedCommentId=133301#action_133301 ] Benjamin Bentmann commented on MCOMPILER-65: Compare the related proposal about [Toolchains|http://docs.codehaus.org/display/MAVEN/Toolchains]. > 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] Reopened: (MCOMPILER-63) Provide specific default value for "encoding" parameter
[ http://jira.codehaus.org/browse/MCOMPILER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MCOMPILER-63: Assignee: Benjamin Bentmann (was: Vincent Siveton) Default needs to be reverted to platform encoding according to [user poll|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-to16958386s177.html]. > Provide specific default value for "encoding" parameter > --- > > Key: MCOMPILER-63 > URL: http://jira.codehaus.org/browse/MCOMPILER-63 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 2.1 > > Attachments: source-encoding.patch > > > As stated in the [javac > doc|http://java.sun.com/javase/6/docs/technotes/tools/windows/javac.html#standard], > the parameter "encoding" defaults to the platform's default encoding if not > specified. This might be a convenient feature when running javac directly > from the console prompt (less typing) but I consider this harmful for an > automated build. The platform's default encoding might easily differ between > machines/developers, causing unreliable build output. > Maven has "reproducible builds" on its banner and as such, locking down all > plugin versions has recently become a best practice. Likewise, the encoding > used to process source files should be locked down. As Maven furthermore > prefers convention over configuration, such a lockdown should be provided > out-of-the-box. > The attached patch adds a default value for the encoding that locks the > encoding down to "ISO-8859-1" if not explicitly overriden by the user in the > POM. I chose Latin-1 for consistency with the behavior of the Maven Site > Plugin although I personally would have preferred UTF-8. > Releasing the patch might break existing builds where users have relied on > their platform's default encoding for handling Non-ASCII sources. The group > of those people is hopefully small and their build can be easily fixed by > updating the POM. > Not emulatable would be the possibility to explicitly use the platform's > default encoding as now but I do not think that there is really somebody out > there playing russian roulette with the build output... Besides, now one > requested such a risky thing for the Maven Site 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: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133299#action_133299 ] Mark Hobson commented on SUREFIRE-482: -- This is more to address the situation where mock classes named *Test are not run by Surefire. Similar to JUnit3 where classes that do not extend TestCase are not run by Surefire (SUREFIRE-346), the defining factor of a JUnit4 test case is the occurrence of one or more @Test annotations, hence for consistency Surefire should ignore classes that do not contain any @Test annotations. This also mirrors the behaviour in Eclipse, whereby: - a JUnit3 test case can only be run if it extends TestCase - a JUnit4 test case can only be run if it contains one or more @Test annotations It'd be good to have consistency across Maven and IDEs. > Surefire tries to run JUnit4 tests that contain no @Test annotations > > > Key: SUREFIRE-482 > URL: http://jira.codehaus.org/browse/SUREFIRE-482 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4.2 >Reporter: Mark Hobson > Attachments: test.zip > > > Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that > contain no @Test annotations as tests, resulting in the exception: > java.lang.Exception: No runnable methods > at > org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) > at > org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) > at > org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) > at > org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) > at > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at > org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > Such classes should be ignored by Surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MINVOKER-25) invoke postBuildHookScript even if build failed
[ http://jira.codehaus.org/browse/MINVOKER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MINVOKER-25: -- Affects Version/s: (was: 1.2) 1.1 > invoke postBuildHookScript even if build failed > --- > > Key: MINVOKER-25 > URL: http://jira.codehaus.org/browse/MINVOKER-25 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Mykola Nikishov >Assignee: Benjamin Bentmann >Priority: Critical > Fix For: 1.2 > > Attachments: 0001-enable-negative-tests.patch > > > I develop a plugin which is ok to break a build. Current workflow using > maven-invoker-plugin looks like: > - if my plug-in works as expected ;-) it breaks an IT build during > integration-test phase > - the MojoFailureException is thrown > - the maven-invoker-plugin reports that build failed > - a script defined in postBuildHookScript is never used > As a result I have a false alarm - a broken build when everything is ok. I > would like to have an opportunity to decide from a postBuildHookScript > whether a build was successful or not. > I've implemented desired functionality and attached a patch against > trunk/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MINVOKER-34) Warn about usage of platform encoding
[ http://jira.codehaus.org/browse/MINVOKER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MINVOKER-34: -- Fix Version/s: 1.2 > Warn about usage of platform encoding > - > > Key: MINVOKER-34 > URL: http://jira.codehaus.org/browse/MINVOKER-34 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Benjamin Bentmann >Priority: Minor > Fix For: 1.2 > > > Relying on the platform encoding makes a build platform-dependent and > threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MINVOKER-34) Warn about usage of platform encoding
Warn about usage of platform encoding - Key: MINVOKER-34 URL: http://jira.codehaus.org/browse/MINVOKER-34 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Affects Versions: 1.1 Reporter: Benjamin Bentmann Priority: Minor Fix For: 1.2 Relying on the platform encoding makes a build platform-dependent and threatens build reproducibility. Users should be warned about this danger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MINVOKER-30) Allow to configure file encoding for verifications scripts
[
http://jira.codehaus.org/browse/MINVOKER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MINVOKER-30:
---
Defaults needs to be changed to platform encoding.
> Allow to configure file encoding for verifications scripts
> --
>
> Key: MINVOKER-30
> URL: http://jira.codehaus.org/browse/MINVOKER-30
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.2
>
> Attachments: file-encoding.patch
>
>
> Right now, the {{verify.bsh}} is read using the platform's default encoding,
> making the tests platform-dependent. We should enrich the plugin
> configuration to allow the user to lock down the encoding and ensure
> reproducible tests.
> The same applies to the {{goals.txt}} and {{profiles.txt}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
