[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281661#comment-281661 ] Jean-Noel Rouvignac commented on MNG-1977: -- Thanks for the feedback guys. My use case is as simple as that: I want to exclude some transitive dependencies accross all dependencies to allow compiling GWT code. Otherwise I get the error "the input line is too long" on windows. So far we have to exclude the same transitive dependencies for all the dependencies where they exist which can be as many as 8 today. Not nice :-/, hence why I am looking at this solution. A simple global exclude would solve the problem for us. It looks to me the code I did is good enough to handle my use case. I just need to know how the Maven team wants this configuration to look in the pom.xml file and then I can look at doing it. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-210) Maven2OsgiConverter provide simple mechanism for more than 3 version part conversion
Maven2OsgiConverter provide simple mechanism for more than 3 version part conversion Key: MSHARED-210 URL: https://jira.codehaus.org/browse/MSHARED-210 Project: Maven Shared Components Issue Type: New Feature Reporter: Darryl L. Miles At the moment the default Maven2OsgiConverter implementation truncates the version number after the 3rd part. 1.2.3.4.5.20111019-SNAPSHOT => 1.2.3.SNAPSHOT This request is to provide a mechanism to allow a fully numeric part to be padded with leading zeros like: 1.2.3.4.5.20111019-SNAPSHOT => 1.2.00300400520111019.SNAPSHOT 1.2.20111019-SNAPSHOT => 1.2.20111019.SNAPSHOT 1.2.3.20111019-SNAPSHOT => 1.2.00320111019.SNAPSHOT The only option the user needs to supply in configuration is the number of places to pad it out to, if the part is already that long (or longer) then no extra padding is added. Maybe the default is 3 (or an automatic default of). I think this kind of conversion should be an option built into the stock Maven/OSGi integration, you are converting a valid Maven version number into a valid OSGi version number and providing a mechanism to loose the least amount of precision of information. A really nice to have feature would be an option to specify a formatter %{03:1}.%{2}.%{06:3} where all padding presumes leading zeros (never spaces), where is uses some other Java convention for String formatting, where the output must have no more than 3 full-stop characters in it (and other validation fules). So a sub-set of String formatter rules but allowing total control. Any parts not conforming to the rules would cause plugin build failure and suitable conversion error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3244) inherited site url not properly handling parameters
[ https://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281645#comment-281645 ] Falko Modler commented on MNG-3244: --- It's sad to see that this issue hasn't been fixed in all these years. People *really* need it. I ended up specifying following snippet in each and every child pom: {code:xml} ${distributionManagement.site.id} ${distributionManagement.site.url} {code} Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties: {code:xml} someid scp://somehos.example.org/u/admin/maven/site/${project.artifactId} {code} I needed to do the same for project.url and all the URLs in project.scm. It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment. > inherited site url not properly handling parameters > --- > > Key: MNG-3244 > URL: https://jira.codehaus.org/browse/MNG-3244 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Sites & Reporting >Affects Versions: 2.0.7 >Reporter: Jacob Robertson >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: fix-inherited-site-url.patch, guide-site.patch, > mng-3244_patch.txt > > > Here is the test case to reproduce this problem. Take the following two > pom.xml files > {code:xml} > > org.bar > foo > foo > 1.0-SNAPSHOT > pom > 4.0.0 > > > foo-site > file://C:/Documents and > Settings/foo/.m2/site/${project.artifactId} > > > {code} > {code:xml} > > org.bar > baz > baz > 1.0-SNAPSHOT > pom > 4.0.0 > > foo > org.bar > 1.0-SNAPSHOT > > {code} > And run the site-deploy goal on each. What you get under the site directory > is this > {noformat}- site > /- foo > ---/site docs > /- baz > ---/- baz (extra directory) > --- ---/site docs{noformat} > This is the simplest test case. In the case where I have a "grandparent" > pom, the site directory uses the grandparent/parent as the path to the site, > and doesn't use the actual artifactId of the artifact I'm creating the site > for. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3244) inherited site url not properly handling parameters
[ https://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281645#comment-281645 ] Falko Modler edited comment on MNG-3244 at 10/19/11 9:46 AM: - It's sad to see that this issue hasn't been fixed in all these years. People *really* need it. I ended up specifying following snippet in each and every child pom: {code:xml} ${distributionManagement.site.id} ${distributionManagement.site.url} {code} Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties: {code:xml} someid scp://somehost.example.org/u/admin/maven/site/${project.artifactId} {code} I needed to do the same for project.url and all the URLs in project.scm. It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment. was (Author: famod): It's sad to see that this issue hasn't been fixed in all these years. People *really* need it. I ended up specifying following snippet in each and every child pom: {code:xml} ${distributionManagement.site.id} ${distributionManagement.site.url} {code} Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties: {code:xml} someid scp://somehos.example.org/u/admin/maven/site/${project.artifactId} {code} I needed to do the same for project.url and all the URLs in project.scm. It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment. > inherited site url not properly handling parameters > --- > > Key: MNG-3244 > URL: https://jira.codehaus.org/browse/MNG-3244 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Sites & Reporting >Affects Versions: 2.0.7 >Reporter: Jacob Robertson >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: fix-inherited-site-url.patch, guide-site.patch, > mng-3244_patch.txt > > > Here is the test case to reproduce this problem. Take the following two > pom.xml files > {code:xml} > > org.bar > foo > foo > 1.0-SNAPSHOT > pom > 4.0.0 > > > foo-site > file://C:/Documents and > Settings/foo/.m2/site/${project.artifactId} > > > {code} > {code:xml} > > org.bar > baz > baz > 1.0-SNAPSHOT > pom > 4.0.0 > > foo > org.bar > 1.0-SNAPSHOT > > {code} > And run the site-deploy goal on each. What you get under the site directory > is this > {noformat}- site > /- foo > ---/site docs > /- baz > ---/- baz (extra directory) > --- ---/site docs{noformat} > This is the simplest test case. In the case where I have a "grandparent" > pom, the site directory uses the grandparent/parent as the path to the site, > and doesn't use the actual artifactId of the artifact I'm creating the site > for. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated DOXIA-452: --- Attachment: doxia-452.tar > Doxia doesn't know about UTF-8 BOMs > --- > > Key: DOXIA-452 > URL: https://jira.codehaus.org/browse/DOXIA-452 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > Attachments: doxia-452.tar > > > If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise > characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281627#comment-281627 ] Benson Margulies edited comment on DOXIA-452 at 10/19/11 6:56 AM: -- I made the test. There is a problem. if the first line of the file is: {noformat} {noformat} then the minus signs are not interpreted as format. I'll make a little project and paste it together for you later. was (Author: bmargulies): I made the test. There is a problem. if the first line of the file is: {noformat} {noformat} then the minus signs are not interpreted as format. I'll make a little project and paste it together for you later. > Doxia doesn't know about UTF-8 BOMs > --- > > Key: DOXIA-452 > URL: https://jira.codehaus.org/browse/DOXIA-452 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > > If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise > characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281627#comment-281627 ] Benson Margulies commented on DOXIA-452: I made the test. There is a problem. if the first line of the file is: {noformat} {noformat} then the minus signs are not interpreted as format. I'll make a little project and paste it together for you later. > Doxia doesn't know about UTF-8 BOMs > --- > > Key: DOXIA-452 > URL: https://jira.codehaus.org/browse/DOXIA-452 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > > If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise > characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281626#comment-281626 ] Benson Margulies commented on DOXIA-452: I dropped an APT file into a Maven project and ran the site plugin. The site plugin config is: {code} maven-site-plugin 3.0 true false false {code} I *thought* that project.build.sourceEncoding was UTF-8, but I just checked and I was wrong, it's not set. So I'll either make a test case or close this today after I add that and try again. > Doxia doesn't know about UTF-8 BOMs > --- > > Key: DOXIA-452 > URL: https://jira.codehaus.org/browse/DOXIA-452 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > > If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise > characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-638) includes/excludes filters are not passed to scm:checkout command
includes/excludes filters are not passed to scm:checkout command Key: SCM-638 URL: https://jira.codehaus.org/browse/SCM-638 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.5 Reporter: Artem Danilenko We have behavior while user is specifying excludes and includes filters they cant be accessed byfileSet.getIncludes() in checkout implementation. But After checkout scm plugin deletes all files which do not match excludes and includes criteria by itself. This operation may take very much time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
[ https://jira.codehaus.org/browse/DOXIA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281607#comment-281607 ] Lukas Theussl commented on DOXIA-452: - How did you test this? If with the site plugin: did you set the input- and outputEncoding in the site plugin configuration? Can you provide a test case? > Doxia doesn't know about UTF-8 BOMs > --- > > Key: DOXIA-452 > URL: https://jira.codehaus.org/browse/DOXIA-452 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > > If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise > characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5183) NPE in ComponentValueSetter
[ https://jira.codehaus.org/browse/MNG-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281603#comment-281603 ] Ernst de Haan commented on MNG-5183: I know what the problem is now: some configuration settings for the Jetty plugin are set via properties, and these properties are not set. > NPE in ComponentValueSetter > --- > > Key: MNG-5183 > URL: https://jira.codehaus.org/browse/MNG-5183 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.3 > Environment: $ uname -a > Linux kslv221 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 > x86_64 x86_64 GNU/Linux > Environment settings:{code}MAVEN_HOME=/opt/apache-maven-3.0.3 > PATH=/bin:/usr/bin:/opt/apache-maven-3.0.3/bin{code} >Reporter: Ernst de Haan > > Here's part of the log tail:{code}[DEBUG] Configuring mojo > org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war from plugin > realm ClassRealm[plugin>org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725, > parent: sun.misc.Launcher$AppClassLoader@35a16869] > [DEBUG] Configuring mojo > 'org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war' with basic > configurator --> > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Pluto . SUCCESS [0.528s] > [INFO] Pluto Types ... SUCCESS [4.730s] > [INFO] Pluto CAPI SUCCESS [4.567s] > [INFO] Pluto Server .. FAILURE [12.077s] > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 22.073s > [INFO] Finished at: Tue Oct 18 11:42:41 CEST 2011 > [INFO] Final Memory: 41M/411M > [INFO] > > [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.NullPointerException > at > org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: java.lang.NullPointerException > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:89) > at > org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromChildren(ArrayConverter.java:129) > at > org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:91) > at > org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151) > at > org.codehaus.plexus.componen