[jira] Created: (SUREFIRE-692) Wrong link to API
Wrong link to API - Key: SUREFIRE-692 URL: http://jira.codehaus.org/browse/SUREFIRE-692 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 2.7.2 Environment: All Reporter: Karl Heinz Marbaise Priority: Minor The link API found on maven-failsafe-plugin (http://maven.apache.org/plugins/maven-failsafe-plugin/) site is wrong it's pointing to http://maven.apache.org/plugins/maven-failsafe-plugin/api.html which produces a "Page not 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] Created: (MCHECKSTYLE-151) Rules are not loaded from http location
Rules are not loaded from http location --- Key: MCHECKSTYLE-151 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-151 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.6 Environment: Maven 3.0.2, 2.2.1 Reporter: Marcin Kuthan Priority: Critical I configured plugin to use rules from: http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml Plugin logs that resource is found by URLResourceLoader: [DEBUG] request.getConfigLocation() http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml [DEBUG] The resource 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was not found with resourceLoader org.codehaus.plexus.resource.loader.FileResourceLoader. [DEBUG] The resource 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader. [DEBUG] The resource 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was not found with resourceLoader org.codehaus.plexus.resource.loader.ThreadContextClasspathResourceLoader. [DEBUG] URLResourceLoader: Found 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' at '' [DEBUG] The resource 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was found as http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml. But configured rules are ingored and sun defaults are loaded. The file target/checkstyle-checker.xml contains default sun rules not mine. When I change location from http:// to file:///... my rules are applied as I expect. You can reproduce error with: http://code.google.com/p/m4enterprise/source/browse/trunk/simple-war/ and http://code.google.com/p/m4enterprise/source/browse/trunk/corporate-pom/ Remote location for Checkstyle rules is the most important feature in my case. I have to prepare and manage common rules for all projects. Many thanks in advance, Marcin -- 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: (MCHECKSTYLE-152) encoding property in maven plugin is never set correctly to charset property of the checkstyle itself.
encoding property in maven plugin is never set correctly to charset property of the checkstyle itself. -- Key: MCHECKSTYLE-152 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-152 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.6, 2.5, 2.4 Environment: Windows x Reporter: Svetlomira Manova Attachments: DefaultCheckstyleExecutor.java, fix_CodeDifference.jpg 1. In the pom.xml i set property : org.apache.maven.plugins maven-checkstyle-plugin 2.6 UTF-8 2. When i run the checkstyle (mvn checkstyle:checkstyle) this property is not set to "charset" attribute. 3. I noticed that this functionality works for version 2.2. However it does not work for versions 2.4 and above. I think that this functionality does not work after some refactoring is done and this functionality is moved in org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor -> "public Configuration getConfiguration( CheckstyleExecutorRequest request )". The problem is that in this method the developer tries to find the Checker module and to set its "charset" attribute as a child of the "config" object. However the "config" object it the Checker module itself. Fix is simple - just take out adding of "charset" attribute value from the for cycle. I will attach the class with the new code and difference between the new and old code. I hope this bug can be fixed soon. Thanks! Best regards, Svetlomira -- 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: (MSITE-338) URLs in site.xml banner tags not rendered by site plugin if host not resolved by "nslookup"
[ http://jira.codehaus.org/browse/MSITE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-338. --- Resolution: Duplicate Assignee: Lukas Theussl See http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links > URLs in site.xml banner tags not rendered by site plugin if host not resolved > by "nslookup" > --- > > Key: MSITE-338 > URL: http://jira.codehaus.org/browse/MSITE-338 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Paul Spencer >Assignee: Lukas Theussl > > Absolute URL's in the banner tags of site.xml are translated to relative URLs > by the maven-site-plugin when the hostname is not found by nslookup. In my > case the hostname only exists in my hosts files on a the Windows machine > running "mvn site". > In the example below, the generated URLs for bannerLeft will be absolute and > the URL's for bannerRight will be relative. Adding "badhost.apache.org" to > the hosts file will not change the outcome. > > > > Maven > http://maven.apache.org/images/apache-maven-project.png > http://maven.apache.org/ > > > Maven > http://badhost.apache.org/images/apache-maven-project.png > http://badhost.apache.org/ > > > It appears the plugin is validating the hostname. Is their a way of turning > this validation off? -- 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-62) Allow multiple options to be passed to compiler for options not supported by the compiler mojo
[
http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253324#action_253324
]
Stephane Nicoll commented on MCOMPILER-62:
--
there's a thread that is referring to this issue regarding annotation
processors but there is a separate option for that since 2.2
{code:xml}
maven-compiler-plugin
org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
{code}
> Allow multiple options to be passed to compiler for options not supported by
> the compiler mojo
> --
>
> Key: MCOMPILER-62
> URL: http://jira.codehaus.org/browse/MCOMPILER-62
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
> Environment: Maven version: 2.0.7
>Reporter: Sanjeeb Sahoo
> Attachments: MCOMPILER-62-2.3.2.patch, MCOMPILER-62-2.3.2.patch,
> MCOMPILER-62.patch
>
>
> Look at the mail thread in maven user group:
> http://www.nabble.com/Not-able-to-pass-multiple-arguments-to-javac-tf4857909s177.html
> User may have to pass options to the underlying compiler that are not yet
> supported by the mojo. Current implementation of the maven-compiler-plugin
> allows user to specify only one option. Neither of the following techniques
> work:
>
>-proc:none
>-implicit
>
> or
>
> -proc:none -impicit
>
> In the first approach, only one of the compilerArgument is considered, in the
> second approach since maven quotes the argument, it ends up as a single
> argument to javac and hence becomes an invalid option.
> The best suggestion is to allow multiple compilerArgument -- may be something
> 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] Closed: (MSHARED-175) wrong relative path resolution for links
[ http://jira.codehaus.org/browse/MSHARED-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSHARED-175. - Resolution: Won't Fix Assignee: Lukas Theussl obsolete now > wrong relative path resolution for links > > > Key: MSHARED-175 > URL: http://jira.codehaus.org/browse/MSHARED-175 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-doxia-tools >Affects Versions: maven-doxia-tools 1.4 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > > See patch attached at MSITE-423 and test project at MSITE-534 -- 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: (MSHARED-183) Add Galician locale (gl) support
Add Galician locale (gl) support Key: MSHARED-183 URL: http://jira.codehaus.org/browse/MSHARED-183 Project: Maven Shared Components Issue Type: Improvement Components: maven-doxia-tools Affects Versions: maven-doxia-tools 1.3 Reporter: Lukas Theussl Patch attached at MSITE-429 -- 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: (MPIR-219) Add Galician locale (gl) support
Add Galician locale (gl) support Key: MPIR-219 URL: http://jira.codehaus.org/browse/MPIR-219 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: Lukas Theussl Patch attached at MSITE-429 -- 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: (MSHARED-183) Add Galician locale (gl) support
[ http://jira.codehaus.org/browse/MSHARED-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSHARED-183. - Resolution: Fixed Fix Version/s: maven-doxia-tools 1.4 Assignee: Lukas Theussl Patch applied in [r1064624|http://svn.apache.org/viewvc?rev=1064624&view=rev] > Add Galician locale (gl) support > > > Key: MSHARED-183 > URL: http://jira.codehaus.org/browse/MSHARED-183 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-doxia-tools >Affects Versions: maven-doxia-tools 1.3 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: maven-doxia-tools 1.4 > > > Patch attached at MSITE-429 -- 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: (MPIR-219) Add Galician locale (gl) support
[ http://jira.codehaus.org/browse/MPIR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPIR-219. -- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Lukas Theussl Patch applied in [r1064625|http://svn.apache.org/viewvc?rev=1064625&view=rev] > Add Galician locale (gl) support > > > Key: MPIR-219 > URL: http://jira.codehaus.org/browse/MPIR-219 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 2.3.2 > > > Patch attached at MSITE-429 -- 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: (MSITE-429) Add Galician locale (gl) support
[ http://jira.codehaus.org/browse/MSITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-429. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Lukas Theussl Patches applied, see linked issues and [r1064626|http://svn.apache.org/viewvc?rev=1064626&view=rev]. Thanks! > Add Galician locale (gl) support > > > Key: MSITE-429 > URL: http://jira.codehaus.org/browse/MSITE-429 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement > Components: internationalization >Affects Versions: 2.0.1 >Reporter: Daniel Fernández >Assignee: Lukas Theussl > Fix For: 2.3 > > Attachments: project-info-report_gl.properties, > site-plugin_gl.properties, site-tool_gl.properties > > > Galician locales (gl, gl_ES), which apply to one of the four official > languages of Spain (and native to more than 3 million people), are not > supported out-of-the-box by Sun's Java Virtual Machine, but it can be added > as a JVM extension, as you can read in http://www.javagalician.org > Attached are the files to add Galician (gl) support to the Maven Site Plugin > in order to be able to create maven sites in Galician 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] Commented: (MCHECKSTYLE-111) More information on issue: "Got an exception - java.lang.RuntimeException: Unable to get class information for [exception]"
[
http://jira.codehaus.org/browse/MCHECKSTYLE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253338#action_253338
]
Aart commented on MCHECKSTYLE-111:
--
Is there some activity on this topic? I can find similar error reports from
years back - it looks like either this bug is very hard to track down, or it's
simply not worked on :) I, and I think many others, would be very grateful to
see this issue removed
Thanks
> More information on issue: "Got an exception - java.lang.RuntimeException:
> Unable to get class information for [exception]"
> ---
>
> Key: MCHECKSTYLE-111
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-111
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows Vista Business (x64), Windows XP (x86), Windows
> 2003 Server (x86)
> Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) and Maven 2.0.10
> Java version: 1.6.0_13
>Reporter: Michael Grossniklaus
>Priority: Blocker
> Attachments: maven-checkstyle-plugin.zip, output.txt
>
>
> This bug report provides more insight on the situations in which the
> maven-checkstyle-plugin is unable to get the class information for exceptions
> that are declared by the project. This report is, therefore, a refinement of
> prior bug reports such as MPCHECKSTYLE-1, MPCHECKSTYLE-20, or MCHECKSTYLE-54.
> We believe, however, that through a more in-depth study of the problem we can
> provide a narrower definition of the problem that, hopefully, will result in
> it resolution.
> Our experiments have shown that the maven-checkstyle-plugin fails for classes
> or interfaces that contain method signatures with a "throws" clause pointing
> to exception defined by both the project and elsewhere. This is demonstrated
> by the interface "ch.ethz.globis.demo.Demo" contained in the attached demo
> project.
> {{
> public interface Demo {
>void foo() throws DemoException, IOException, FileNotFoundException;
>void foofoo() throws DemoException;
>void bar() throws IOException, FileNotFoundException,
> IllegalArgumentException;
> }
> }}
> If the command "mvn checkstyle:check" is executed in the project, it will
> fail with one checkstyle violation. If, however, the method "foo()" is
> commented (or removed), everything works fine. Note that method "foofoo()"
> which *only* declares "ch.ethz.globis.demo.DemoException" is unproblematic as
> well as method "bar()" which declares a set of exceptions that are declared
> outside the project. Hence, the conclusion is that it is the combination of
> *both* project and outside-project exceptions that make the
> maven-checkstyle-plugin fail. Note that we have run maven on clean
> installation (where the local repository has been removed first) to produce a
> reproducible error.
> The attached zip file contains both the demo project that can be used to
> reproduce the error as well as the output of the "mvn checkstyle:check"
> command under "target". We also provide the file "output.txt" that documents
> the console output of the command. If further documentation is required, do
> not hesitate to contact me. We hope that by providing this information we can
> contribute to the resolution of said issue, once and for all.
--
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: (DOXIASITETOOLS-49) paths are loosing their query parts when being relativized
paths are loosing their query parts when being relativized -- Key: DOXIASITETOOLS-49 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-49 Project: Maven Doxia Sitetools Issue Type: Bug Components: Decoration model Affects Versions: 1.1.4 Reporter: Lukas Theussl See MSITE-244 -- 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: (DOXIASITETOOLS-49) paths are loosing their query parts when being relativized
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIASITETOOLS-49. --- Resolution: Fixed Fix Version/s: 1.1.5 Assignee: Lukas Theussl Fixed in [r1064665|http://svn.apache.org/viewvc?rev=1064665&view=rev] > paths are loosing their query parts when being relativized > -- > > Key: DOXIASITETOOLS-49 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-49 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Decoration model >Affects Versions: 1.1.4 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.1.5 > > > See MSITE-244 -- 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: (MSITE-244) Relative paths are losing their query parts
[ http://jira.codehaus.org/browse/MSITE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-244. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Lukas Theussl Fixed with DOXIASITETOOLS-49 > Relative paths are losing their query parts > --- > > Key: MSITE-244 > URL: http://jira.codehaus.org/browse/MSITE-244 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.0-beta-6 > Environment: Windows, French Locale, Maven 2.0.6, Site plugin > maven-site-plugin-2.0-beta-6-20070716.231146-1 >Reporter: Denis Cabasson >Assignee: Lukas Theussl > Fix For: 2.3 > > Attachments: MSITE-test-case.zip > > > Urls are compared to project url and when necessary are transformed to > relative URLs. > In the process those trimmed url loose their query part. -- 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: (MPOM-2) apache-release does unwanted things in the prepare goal
[ http://jira.codehaus.org/browse/MPOM-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPOM-2. --- Resolution: Won't Fix moved to https://issues.apache.org/jira/browse/MPOM-1 > apache-release does unwanted things in the prepare goal > --- > > Key: MPOM-2 > URL: http://jira.codehaus.org/browse/MPOM-2 > Project: Apache or Maven Parent POMs > Issue Type: Bug > Components: Apache Parent POM >Reporter: Benson Margulies > > Release 7 of the org.apache:apache use -P to turn on an 'apache-release' > profile in the release plugin. By using -P, this profile is turned on in > prepare as well as perform. > This may turn into a contest of opinion, and you all may just tell me to jump > in a lake, but I think this is a bad idea. At prepare time, we're just > looking to get the versions setup and the tag made. Having to deal with gpg > signing, and source archiving seems out of place. > At very least, I'd request that this the element be left out of > the release plugin spec. If some project wants to use that particular > collection of functions, fine. For the rest of us, who just want to get > distribution management and other universals, you we wouldn't have to worry > about it. -- 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: (MPOM-3) Support additional boilerplate in NOTICE file
[ http://jira.codehaus.org/browse/MPOM-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPOM-3. --- Resolution: Won't Fix moved to https://issues.apache.org/jira/browse/MPOM-3 > Support additional boilerplate in NOTICE file > - > > Key: MPOM-3 > URL: http://jira.codehaus.org/browse/MPOM-3 > Project: Apache or Maven Parent POMs > Issue Type: Improvement > Components: Apache Parent POM > Environment: org/apache/apache.jar.resource.bundle/1.4, > org/apache/apache/7/apache-7.pom >Reporter: Marshall Schor >Priority: Minor > > The pom includes using the maven-remote-resources-plugin to get the > resourceBundle org.apache:apache-jar-resource-bundle:1.4 which has the > "Standard" LICENSE, NOTICE, and DEPENDENCIES .vm files. > The DEPENDENCIES.vm file has already the function at the end to add > user-defined boilerplate: > #if($postDepListText) > $postDepListText > #end > It would be very useful to us to have similar code at the end of the > NOTICE.vm file: > #if($project.properties.postNoticeText) > $project.properties.postNoticeText > #end > The use case is we have many files which have the same copyright notice moved > to the NOTICES file, and would like to automatically have this included. By > doing this, we can define a common parent-pom for these files, which defines > the postNoticeText property, and have it included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPOM-4) Apache Parent Pom should be properly documented
[ http://jira.codehaus.org/browse/MPOM-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPOM-4. --- Resolution: Won't Fix moved to https://issues.apache.org/jira/browse/MPOM-2 > Apache Parent Pom should be properly documented > --- > > Key: MPOM-4 > URL: http://jira.codehaus.org/browse/MPOM-4 > Project: Apache or Maven Parent POMs > Issue Type: Improvement > Components: Apache Parent POM > Environment: Apache Parent POM v1-v7 >Reporter: SebbASF > > [Cannot select the appropriate versions as they are not listed] > There does not appear to be any documentation on the Apache Parent Pom. > Please can the following be added to the next release: > - how to report issues > - where to find the source > Ideally there should be a page on the Maven web-site that documents it as > well. > In which case please link to that from the POM as well. -- 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: (MPOM-5) source jars are not signed when releasing maven-indexer
[ http://jira.codehaus.org/browse/MPOM-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPOM-5. --- Resolution: Won't Fix moved to https://issues.apache.org/jira/browse/MPOM-4 > source jars are not signed when releasing maven-indexer > --- > > Key: MPOM-5 > URL: http://jira.codehaus.org/browse/MPOM-5 > Project: Apache or Maven Parent POMs > Issue Type: Bug > Components: Apache Parent POM >Affects Versions: apache-parent-7 >Reporter: Brian Demers >Assignee: Brian Demers > > The sources plugin runs after the gpg plugin. > They both run in the verify phase. -- 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: (MCHECKSTYLE-151) Rules are not loaded from http location
[ http://jira.codehaus.org/browse/MCHECKSTYLE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253367#action_253367 ] Marcin Kuthan commented on MCHECKSTYLE-151: --- I've just checked build on Ubuntu and the rules were loaded from remote location successfully. I tested plugin before on Windows XP under cygwin environment, and I will be able to verify it again on Monday. Please don't close the issue until I confirm my last finding. > Rules are not loaded from http location > --- > > Key: MCHECKSTYLE-151 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-151 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 3.0.2, 2.2.1 >Reporter: Marcin Kuthan >Priority: Critical > > I configured plugin to use rules from: > http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml > Plugin logs that resource is found by URLResourceLoader: > [DEBUG] request.getConfigLocation() > http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml > [DEBUG] The resource > 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was > not found with resourceLoader > org.codehaus.plexus.resource.loader.FileResourceLoader. > [DEBUG] The resource > 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was > not found with resourceLoader > org.codehaus.plexus.resource.loader.JarResourceLoader. > [DEBUG] The resource > 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was > not found with resourceLoader > org.codehaus.plexus.resource.loader.ThreadContextClasspathResourceLoader. > [DEBUG] URLResourceLoader: Found > 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' at '' > [DEBUG] The resource > 'http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml' was > found as http://m4enterprise.googlecode.com/svn/trunk/conf/checkstyle-1.0.xml. > But configured rules are ingored and sun defaults are loaded. The file > target/checkstyle-checker.xml contains default sun rules not mine. > When I change location from http:// to file:///... my rules are applied > as I expect. > You can reproduce error with: > http://code.google.com/p/m4enterprise/source/browse/trunk/simple-war/ > and > http://code.google.com/p/m4enterprise/source/browse/trunk/corporate-pom/ > Remote location for Checkstyle rules is the most important feature in my > case. I have to prepare and manage common rules for all projects. > Many thanks in advance, > Marcin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
Variables interpolation: dynamic in Maven 2, static in Maven 3
--
Key: MNG-4998
URL: http://jira.codehaus.org/browse/MNG-4998
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
Please, see
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
It demonstrates two examples where expression with ${variables} are
interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
and effect expressions interpolated later, Maven 3 also allows to
update but all expressions are interpolated with their old values.
I believe Maven 2 dynamic behavior is much more preferable than Maven 3
Ant-like "stickiness" to what's defined in .
--
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: (MINSTALL-18) Bad algorithm to decide if the main artifact is to be installed or not
[
http://jira.codehaus.org/browse/MINSTALL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253383#action_253383
]
Gili commented on MINSTALL-18:
--
Maven 2.3 doesn't exist. Do you plan on releasing such a version or am I
required to use Maven 3.0 to get this fix?
> Bad algorithm to decide if the main artifact is to be installed or not
> --
>
> Key: MINSTALL-18
> URL: http://jira.codehaus.org/browse/MINSTALL-18
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: Benjamin Bentmann
> Fix For: 2.3
>
>
> Here' s what's in InstallMojo's execute method:
> {code}
> // Here, we have a temporary solution to MINSTALL-3
> (isDirectory() is true if it went through compile
> // but not package). We are designing in a proper solution
> for Maven 2.1
> if ( file != null && !file.isDirectory() )
> {
> installer.install( file, artifact, localRepository );
> }
> else if ( !attachedArtifacts.isEmpty() )
> {
> getLog().info( "No primary artifact to install,
> installing attached artifacts instead." );
> }
> {code}
> This fails if we're building a JAR with no sources but with an attached
> artifact and only the attached artifact is created (this is the case when
> using the clover plugin). In that case, the install mojo tries to install the
> main artifact which doesn't exist).
> The error is in "!file.isDirectory". In the case of a jar with no sources,
> this directory will not have been created...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253388#action_253388
]
Stefan Hansel commented on MSITE-227:
-
Hi Lukas,
I'm still struggling with this one and I'm happy to accept any workaround
possible.
My main goal is just get a report, where childs and masters are linked with
relative links (based on the demo project attached here).
The distribution URL is configured in the settings.xml of our buildserver, I
have no influence on it. But I can use any url that helps in the project's pom.
As our buildserver then takes the generated sites and puts them somewhere on
the webserver relative to the current build number it's important, that the
final reports only have relative URLs.
I tried different things now in the url-tags of parent and child, but nothing
gives my any succes:
A) your proposed solution:
parent: file:///tmp/MSITE-227/
child:file:///tmp/module1/
distribution: file:///buildXYZ
=> give absolute links from parent to child and from child to parent => not
working for me
B) relative pathes 1
parent: .
child:./module1
distribution: file:///buildXYZ
=> creates only relative links between parent + childs.
Unfortunately expects a folder structure, where module1 is withing the parent
folder.
But all reports are generated in the same folder (flat structure), so the links
are not working.
If I could manipulate the site-deploy target to create a nested folder
structure, this would work.
C) relative pathes 2
parent: .
child:./../module1
distribution: file:///buildXYZ
parent to child link is relative and working
child to parent link is relative but not working ("../../../index.html" instead
of "../MSITE-227/index.html")
If the created folder structure wasn't flat (i.e. every project in the same
folder opposed to having the childs below the parent) then solution (B) what be
what I wanted.
This folder structure is already created when artifactID!=foldername but I
cannot use this because either I had to rename my VCS-Project names to
something strange or I had to rename the artifactID to something strange.
I cannot believe that I'm the first one how wants to create multimodule sites
with only relative links to be copied by the buildserver to some other (maven
independent) location.
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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: (MINSTALL-18) Bad algorithm to decide if the main artifact is to be installed or not
[
http://jira.codehaus.org/browse/MINSTALL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253390#action_253390
]
Benjamin Bentmann commented on MINSTALL-18:
---
Don't confuse Maven (core) with the Maven Install Plugin. This fix is in the
Maven Install Plugin, not Maven core.
> Bad algorithm to decide if the main artifact is to be installed or not
> --
>
> Key: MINSTALL-18
> URL: http://jira.codehaus.org/browse/MINSTALL-18
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: Benjamin Bentmann
> Fix For: 2.3
>
>
> Here' s what's in InstallMojo's execute method:
> {code}
> // Here, we have a temporary solution to MINSTALL-3
> (isDirectory() is true if it went through compile
> // but not package). We are designing in a proper solution
> for Maven 2.1
> if ( file != null && !file.isDirectory() )
> {
> installer.install( file, artifact, localRepository );
> }
> else if ( !attachedArtifacts.isEmpty() )
> {
> getLog().info( "No primary artifact to install,
> installing attached artifacts instead." );
> }
> {code}
> This fails if we're building a JAR with no sources but with an attached
> artifact and only the attached artifact is created (this is the case when
> using the clover plugin). In that case, the install mojo tries to install the
> main artifact which doesn't exist).
> The error is in "!file.isDirectory". In the case of a jar with no sources,
> this directory will not have been created...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253398#action_253398
]
Stefan Hansel commented on MSITE-227:
-
even more strange:
when I use
mvn site:stage
all links are nice and relative and it just works (regardless of whether I have
url tags or not)!
When using
mvn site-deploy
trouble begins again :(
Doesn't this make this quote from the docs
{quote}To review/test the generated web site before an official deploy, you can
stage the site in a specific directory.{quote}
somehow wrong, when links are different in the end?
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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: (MINSTALL-18) Bad algorithm to decide if the main artifact is to be installed or not
[
http://jira.codehaus.org/browse/MINSTALL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253402#action_253402
]
Gili commented on MINSTALL-18:
--
Makes sense :) Thank you for the clarification!
> Bad algorithm to decide if the main artifact is to be installed or not
> --
>
> Key: MINSTALL-18
> URL: http://jira.codehaus.org/browse/MINSTALL-18
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: Benjamin Bentmann
> Fix For: 2.3
>
>
> Here' s what's in InstallMojo's execute method:
> {code}
> // Here, we have a temporary solution to MINSTALL-3
> (isDirectory() is true if it went through compile
> // but not package). We are designing in a proper solution
> for Maven 2.1
> if ( file != null && !file.isDirectory() )
> {
> installer.install( file, artifact, localRepository );
> }
> else if ( !attachedArtifacts.isEmpty() )
> {
> getLog().info( "No primary artifact to install,
> installing attached artifacts instead." );
> }
> {code}
> This fails if we're building a JAR with no sources but with an attached
> artifact and only the attached artifact is created (this is the case when
> using the clover plugin). In that case, the install mojo tries to install the
> main artifact which doesn't exist).
> The error is in "!file.isDirectory". In the case of a jar with no sources,
> this directory will not have been created...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-547) Links to child modules do not work when using flat structure
[ http://jira.codehaus.org/browse/MSITE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ackermann updated MSITE-547: --- Attachment: trial-maven-with-urls-and-sitexml.zip > Links to child modules do not work when using flat structure > - > > Key: MSITE-547 > URL: http://jira.codehaus.org/browse/MSITE-547 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-3 > Environment: Maven 3.0.1, Windows XP SP3 >Reporter: Martin Ackermann > Attachments: trial-maven-with-urls-and-sitexml.zip, trial-maven.zip > > > trial-maven-child-module has trial-maven-product as parent. When they are > both in the same directory (flat structure), "mvn site-deploy" does not > generate working links for the site. See attached example project. > If trial-maven-child-module is a sub-directory of trial-maven-product (deep > structure), "mvn site-deploy" generates working links. -- 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-547) Links to child modules do not work when using flat structure
[
http://jira.codehaus.org/browse/MSITE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253409#action_253409
]
Martin Ackermann commented on MSITE-547:
In trial-maven.zip, I did not specify the in any of my poms.
If I add "file://${user.dir}/target/site-deploy" to the parent POM
in trial maven and
"file://${user.dir}/target/site-deploy/${artifactId}" to the POMs of
trial-maven-product and trial-maven-child-module, the resulting links work. But
only with default site.xml.
As soon as I add a custom site.xml with custom menus, the links get broken when
using "". See example project trial-maven-with-urls-and-sitexml.zip. It
doesn't help if I use ""
instead of "".
BTW, I have set distributionManagement.site.url to
"file://${user.dir}/target/site-deploy".
> Links to child modules do not work when using flat structure
> -
>
> Key: MSITE-547
> URL: http://jira.codehaus.org/browse/MSITE-547
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-3
> Environment: Maven 3.0.1, Windows XP SP3
>Reporter: Martin Ackermann
> Attachments: trial-maven-with-urls-and-sitexml.zip, trial-maven.zip
>
>
> trial-maven-child-module has trial-maven-product as parent. When they are
> both in the same directory (flat structure), "mvn site-deploy" does not
> generate working links for the site. See attached example project.
> If trial-maven-child-module is a sub-directory of trial-maven-product (deep
> structure), "mvn site-deploy" generates working links.
--
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-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253423#action_253423
]
Lukas Theussl commented on MSITE-227:
-
Stefan: this issue is closed, please open a new one (linking back to this) and
attach a test project. I'll have a look at it.
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253432#action_253432
]
Mark Struberg commented on MNG-4977:
which servlet engine is your corporate maven repository using? Not sure if this
is a maven problem or a problem of the repo manager (sending the wrong size).
We would need to test this with downloading from a plane httpd.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
manifest archive issue
I am trying to add archive configuration but that is not helping ( it is not adding/updating manifest file generated as part of the war). true true Can anyone suggest what could be wrong here ? -Sanju
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253437#action_253437
]
Evgeny Goldin commented on MNG-4977:
Hi Mark,
We use Artifactory and downloading over HTTP works Ok with it. I'll see what
headers are sent in response when Maven is making a request for .
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253438#action_253438
]
Evgeny Goldin commented on MNG-4977:
I tried to sniff the headers when dependency is sent but it's not that easy.
IEInspector HTTP Analyzer crashes, WireShark freezes and I can't see the
headers. But on one occasion before HTTP Analyzer crashed I saw the correct
response length header was sent. I'll try to see if there are other ways to see
the headers. May be you can also reproduce this problem and sniff the traffic
with better tools or better machines than mine.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253440#action_253440
]
Benjamin Bentmann commented on MNG-4977:
[URLConnection.getContentLength()|http://download.oracle.com/javase/1.5.0/docs/api/java/net/URLConnection.html#getContentLength%28%29]
is of type {{int}}, this might explain the trouble with wagon-http-lightweight.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin commented on MNG-4977:
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Goldin updated MNG-4977:
---
Attachment: 1.png
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:18 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:19 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1< will try to reproduce it again
with 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 3.0.2.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:19 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1, will try to reproduce it again
with 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1< will try to reproduce it again
with 3.0.2.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Goldin updated MNG-4977:
---
Attachment: 2.png
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalyan C. Akella updated MNG-3321:
--
Attachment: MNG-3321-core-integration-testing.patch
MNG-3321-maven-core.patch
Thank you for the comments. Attaching the patch files with the following
changes,
1. Added the license headers.
2. Added integration tests. Tests for normal execution when no skip.plugin
property specified, skipping of plugin & skipping of an execution within a
plugin.
3. Fixed the code style to use the maven project settings in my IDE.
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-3321-core-integration-testing.patch,
> MNG-3321-maven-core.patch, MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
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
