[jira] Commented: (MNG-1977) Global dependency exclusions

2011-10-19 Thread Jean-Noel Rouvignac (JIRA)

[ 
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

2011-10-19 Thread Darryl L. Miles (JIRA)
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

2011-10-19 Thread Falko Modler (JIRA)

[ 
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

2011-10-19 Thread Falko Modler (JIRA)

[ 
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

2011-10-19 Thread Benson Margulies (JIRA)

 [ 
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

2011-10-19 Thread Benson Margulies (JIRA)

[ 
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

2011-10-19 Thread Benson Margulies (JIRA)

[ 
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

2011-10-19 Thread Benson Margulies (JIRA)

[ 
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

2011-10-19 Thread Artem Danilenko (JIRA)
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

2011-10-19 Thread Lukas Theussl (JIRA)

[ 
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

2011-10-19 Thread Ernst de Haan (JIRA)

[ 
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