[jira] Commented: (SUREFIRE-726) Test list preprocessor support for tests to be run
[ https://jira.codehaus.org/browse/SUREFIRE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281599#comment-281599 ] Parameswaran Raman commented on SUREFIRE-726: - Hi, I am looking to use TLB with Maven for my project. It would be great if you can push in this patch as quickly as possible as there is a significant improvement (in build time) that we are looking forward to. -- Thanks, Params parame...@gmail.com Test list preprocessor support for tests to be run -- Key: SUREFIRE-726 URL: https://jira.codehaus.org/browse/SUREFIRE-726 Project: Maven Surefire Issue Type: New Feature Affects Versions: 2.9 Reporter: Janmejay Singh Fix For: 3.0 Attachments: 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch, 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch, 0003-exposed-testPreprocessor-configuration-parameter-as-.patch, 0004-exposed-testPreprocessor-for-IntegrationTestMojo-as-.patch This exposes an interface(named TestListPreprocessor, which has a method named preprocessTestClasses) that can be implemented by a user and injected into surefire plugin configuration to have it used for preprocessing list of tests to be run. Given the original test list, user's preprocessing algorithm can choose to prune or reorder the list and return it back from TestListPreprocessor#preprocessTestClasses, which is then used as the list of tests to be executed. The patches attached expose a configuration element named testPreprocessor the default value of which is none. User can choose to set it to a value matching the format fully-qualified-class-name[group-id:artifact-id:version] and have the class loaded and called with list of tests to be run. The list of tests returned by the call is then considered for execution. Patch description: The feature is done in 2 patches. Description follows: 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch This patch actually adds the feature and unit tests. It adds the interface, an abstraction that encapsulates aforementioned configuration, booter serialization/deserialization, directory-scanner changes etc. The changes have effect in both forked and in-process execution mode. 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch This patch adds an integration test for preprocessor feature. The integration test uses a 2 module setup, where the first module implements the TestListPreprocessor interface which selects only even indexed test classes from the list passed in. The second module(which depends on first) uses the artifact from first and uses the following configuration: configuration testPreprocessortest.preprocessor.EvenTestOnlyPreprocessor[org.apache.maven.plugins.surefire:preprocessor-impl:1.0-SNAPSHOT]/testPreprocessor /configuration The test then asserts that only 2(0th and 2nd) of the 4 test classes the second module has are executed. The patches are created on a git-svn clone using format-patch, please use 'patch -p1 0001-Adds...'(while in the trunk directory) to apply the patches on svn repository. If using git-svn, git-am can be directly be invoked. The patches are done over http://svn.apache.org/repos/asf/maven/surefire/trunk@1091357 (trunk HEAD) so should apply cleanly on any recent enough revision. === Context: http://stackoverflow.com/questions/5124823/reducing-the-build-time-hudson http://code.google.com/p/tlb/issues/detail?id=1 http://test-load-balancer.github.com -- 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-tabpanelfocusedCommentId=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[pluginorg.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
[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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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}
plugin
artifactIdmaven-site-plugin/artifactId
version3.0/version
configuration
chmodtrue/chmod
dependencyDetailsEnabledfalse/dependencyDetailsEnabled
dependencyLocationsEnabledfalse/dependencyLocationsEnabled
/configuration
/plugin
{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] 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-tabpanelfocusedCommentId=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}
BOM
{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] 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-tabpanelfocusedCommentId=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}
BOM
{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}
BOM
{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] 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: (MNG-3244) inherited site url not properly handling parameters
[
https://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
!-- repositories inherited--
site
id${distributionManagement.site.id}/id
url${distributionManagement.site.url}/url
/site
/distributionManagement
{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}
distributionManagement.site.idsomeid/distributionManagement.site.id
distributionManagement.site.urlscp://somehost.example.org/u/admin/maven/site/${project.artifactId}/distributionManagement.site.url
{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
!-- repositories inherited--
site
id${distributionManagement.site.id}/id
url${distributionManagement.site.url}/url
/site
/distributionManagement
{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}
distributionManagement.site.idsomeid/distributionManagement.site.id
distributionManagement.site.urlscp://somehos.example.org/u/admin/maven/site/${project.artifactId}/distributionManagement.site.url
{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}?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdfoo/artifactId
namefoo/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
distributionManagement
site
idfoo-site/id
urlfile://C:/Documents and
Settings/foo/.m2/site/${project.artifactId}/url
/site
/distributionManagement
/project{code}
{code:xml}?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdbaz/artifactId
namebaz/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
parent
artifactIdfoo/artifactId
groupIdorg.bar/groupId
version1.0-SNAPSHOT/version
/parent
/project{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] 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-tabpanelfocusedCommentId=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
!-- repositories inherited--
site
id${distributionManagement.site.id}/id
url${distributionManagement.site.url}/url
/site
/distributionManagement
{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}
distributionManagement.site.idsomeid/distributionManagement.site.id
distributionManagement.site.urlscp://somehos.example.org/u/admin/maven/site/${project.artifactId}/distributionManagement.site.url
{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}?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdfoo/artifactId
namefoo/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
distributionManagement
site
idfoo-site/id
urlfile://C:/Documents and
Settings/foo/.m2/site/${project.artifactId}/url
/site
/distributionManagement
/project{code}
{code:xml}?xml version=1.0 encoding=UTF-8?
project
groupIdorg.bar/groupId
artifactIdbaz/artifactId
namebaz/name
version1.0-SNAPSHOT/version
packagingpom/packaging
modelVersion4.0.0/modelVersion
parent
artifactIdfoo/artifactId
groupIdorg.bar/groupId
version1.0-SNAPSHOT/version
/parent
/project{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] 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-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 exclusions 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
