[jira] (MASSEMBLY-691) dependencySet with filtered option has differents behaviors
Arnaud Brunet created MASSEMBLY-691: --- Summary: dependencySet with filtered option has differents behaviors Key: MASSEMBLY-691 URL: https://jira.codehaus.org/browse/MASSEMBLY-691 Project: Maven Assembly Plugin Issue Type: Bug Components: dependencySet Affects Versions: 2.4 Reporter: Arnaud Brunet Attachments: sample.zip Hello, In the sample projet, there are two artifacts : - "bug:assembly" contains an assembly descriptor which includes the other artifact. - "bug:assembly-dependency" is a simple artifact with a properties file. In the assembly description, I want to unpack the artifact "bug:assembly-dependency". In the unpack options, - if I put parameter "filtered" on false, my properties file is put in conf directory, - but if I put "filtered" on true, my properties file is in conf/assembly-dependency-0.0.1-SNAPSHOT.jar directory. I expected that only my properties file exchange between the two options. Why am I getting the "assembly-dependency-0.0.1-SNAPSHOT.jar " directory ? Regards, Arnaud -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-690) Think about WARNING for module dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-690:
--
Summary: Think about WARNING for module dependencies (was: Think about
WARNING for )
> Think about WARNING for module dependencies
> ---
>
> Key: MASSEMBLY-690
> URL: https://jira.codehaus.org/browse/MASSEMBLY-690
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: moduleSet
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the maven-assembly-plugin produces a WARNING like this:
> {code}
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-attached) @ dist ---
> [INFO] Reading assembly descriptor: proj1-assembly.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Building zip:
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin.zip
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-not-attached) @
> dist ---
> [INFO] Reading assembly descriptor: proj1-dir.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Copying files to
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin-dir
> [INFO]
>
> {code}
> If you use a moduleSet within your descriptor which should only happen if
> really problem exist. In this
> [case|https://github.com/khmarbaise/massembly/tree/master/massembly-628] it
> does not exist really a problem, cause all versions are fine.
> This means that we need to check the versions? Can we predict this in a
> better way...? Is this really possible within maven-assembly-plugin ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
[
https://jira.codehaus.org/browse/MASSEMBLY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342601#comment-342601
]
Karl Heinz Marbaise edited comment on MASSEMBLY-687 at 3/20/14 3:24 PM:
There have been many other locations like {{src/assemble/}} instead of
{{src/assembly}}.
was (Author: khmarbaise):
The have been many other locations like {{src/assemble/}} instead of
{{src/assembly}}.
> Change the prefered location for assembly descriptors and filter files
> --
>
> Key: MASSEMBLY-687
> URL: https://jira.codehaus.org/browse/MASSEMBLY-687
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: site
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> We should [improve the
> documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
> according to the default folder layout which uses {{src/main/assembly}}
> whereas we documented
> [here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
> {{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-690) Think about WARNING for
Karl Heinz Marbaise created MASSEMBLY-690:
-
Summary: Think about WARNING for
Key: MASSEMBLY-690
URL: https://jira.codehaus.org/browse/MASSEMBLY-690
Project: Maven Assembly Plugin
Issue Type: Improvement
Components: moduleSet
Affects Versions: 2.4
Reporter: Karl Heinz Marbaise
Priority: Minor
Currently the maven-assembly-plugin produces a WARNING like this:
{code}
[INFO]
[INFO] --- maven-assembly-plugin:2.4:single (make-bundles-attached) @ dist ---
[INFO] Reading assembly descriptor: proj1-assembly.xml
[WARNING] NOTE: Currently, inclusion of module dependencies may produce
unpredictable results if a version conflict occurs.
[INFO] Building zip:
/Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin.zip
[INFO]
[INFO] --- maven-assembly-plugin:2.4:single (make-bundles-not-attached) @ dist
---
[INFO] Reading assembly descriptor: proj1-dir.xml
[WARNING] NOTE: Currently, inclusion of module dependencies may produce
unpredictable results if a version conflict occurs.
[INFO] Copying files to
/Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin-dir
[INFO]
{code}
If you use a moduleSet within your descriptor which should only happen if
really problem exist. In this
[case|https://github.com/khmarbaise/massembly/tree/master/massembly-628] it
does not exist really a problem, cause all versions are fine.
This means that we need to check the versions? Can we predict this in a better
way...? Is this really possible within maven-assembly-plugin ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-677) NPE using includeMetadata true for repository in a descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-677:
--
Description:
I'm trying to create a repository via Maven assembly plugin and used the
includeMetadata option. If i use false everything is ok (or just remove
completely cause false is the default). If i change it to true i got the
following failure:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
project dist: Execution make-bundles of goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-bundles) on
project dist: Execution make-bundles of goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
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:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
make-bundles of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:60)
at
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
at
org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOfLocalRepositoryMetadata(DefaultArtifactRepository.java:128)
at
org.apache.maven.shared.repository.DefaultRepositoryAssembler.assembleRepositoryMetadata(DefaultRepositoryAssembler.java:487)
at
org.apache.maven.shared.repository.DefaultRepositoryAssembler.buildRemoteRepository(DefaultRepositoryAssembler.java:231)
at
org.apache.maven.plugin.assembly.archive.phase.RepositoryAssemblyPhase.execute(RepositoryAssemblyPhase.java:99)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:183)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
... 20 more
[ERROR]
{code}
Created a
[github|https://github.com/khmarbaise/massembly/tree/master/massembly-677]
project to reproduce the problem and attached the project which produces the
failure.
The assembly-repository is exactly as the assembly-repository-failure except
with the difference in the includeMetadata entry in the assembly descriptor.
was:
I'm trying to create a repository via Maven assembly plugin and used the
includeMetadata option. If i use false everything is ok (or just remove
completely cause false is the default). If i change it to true i got the
following failure:
{code}
[ERROR] Failed to execute goal
org.
[jira] (MASSEMBLY-680) Allow option to silently skip empty assemblies
[ https://jira.codehaus.org/browse/MASSEMBLY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MASSEMBLY-680: -- Fix Version/s: backlog > Allow option to silently skip empty assemblies > -- > > Key: MASSEMBLY-680 > URL: https://jira.codehaus.org/browse/MASSEMBLY-680 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: maven-archiver >Affects Versions: 2.4 >Reporter: Jeff Care >Priority: Minor > Fix For: backlog > > > I have a use case where many of my projects need to construct an > "installation fragment" as a secondary artifact. I would like to define the > assembly configuration for this installation fragment on a parent project > such that it is automatically inherited by all of my projects. Certain > projects though do not have any content that would get picked up by the > assembly descriptor, thus assembly:single fails for these projects. > I would like to add an option to the single mojo such that empty assemblies > can be silently skipped instead of failing the build. I have started > researching how to accomplish this & would be willing to submit patches. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-189) ReactorModuleConvergence is not compatible with 'advanced' reactor options: -pl, -rf
[
https://jira.codehaus.org/browse/MENFORCER-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-189:
-
Assignee: Karl Heinz Marbaise
> ReactorModuleConvergence is not compatible with 'advanced' reactor options:
> -pl, -rf
>
>
> Key: MENFORCER-189
> URL: https://jira.codehaus.org/browse/MENFORCER-189
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
>Reporter: Samuel Langlois
>Assignee: Karl Heinz Marbaise
>
> I have the {{}} rule enabled, in my multi-module
> build. The whole build runs fine.
> However, when I use the (very handy) {{\-\-projects}} or {{\-\-resume-from}}
> Maven options, to limit the number of projects to build in the reactor, the
> rule is triggered and complains:
> {code}
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.ReactorModuleConvergence
> failed with message:
> Module parents have been found which could not be found in the reactor.
> module: org.alfresco:alfresco-data-model:jar:4.3.0-BF-SNAPSHOT
> {code}
> This limits the interest of the rule, since we use these all the time.
> Would it make sense to have a flag to disable this check, and only run the
> rule on projects the reactor knows?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343344#comment-343344 ] Martin Ellis commented on MRELEASE-812: --- Just experienced this bug with maven-release-plugin 2.5 using git. Reverting to 2.4.2 fixes the behaviour for me (i.e. commits the pom with a release version). > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Claszen updated MNG-5604:
---
Labels: build pom.xml (was: )
> make it possible to mark a maven module as deprected
>
>
> Key: MNG-5604
> URL: https://jira.codehaus.org/browse/MNG-5604
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Klaus Claszen
>Priority: Minor
> Labels: build, pom.xml
>
> It would be great if it would be possible to mark a maven module as
> 'deprecated'. It would help to document that a module is outdated. The
> information could be used during build processes to show warnings and guide
> the user to a better alternative.
> Maybe it could be a pom enhancement linke this
> {code:xml}
>
> not maintained anymore
>
> foo
> bar
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
Klaus Claszen created MNG-5604:
--
Summary: make it possible to mark a maven module as deprected
Key: MNG-5604
URL: https://jira.codehaus.org/browse/MNG-5604
Project: Maven 2 & 3
Issue Type: Wish
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Klaus Claszen
Priority: Minor
It would be great if it would be possible to mark a maven module as
'deprecated'. It would help to document that a module is outdated. The
information could be used during build processes to show warnings and guide the
user to a better alternative.
Maybe it could be a pom enhancement linke this
{code:xml}
not maintained anymore
foo
bar
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-744) api's AbstractConsumer ignores Locale when using a custom dateFormatter
Matías Albanesi created SCM-744:
---
Summary: api's AbstractConsumer ignores Locale when using a custom
dateFormatter
Key: SCM-744
URL: https://jira.codehaus.org/browse/SCM-744
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-api
Affects Versions: 1.8.1
Reporter: Matías Albanesi
Priority: Minor
Class org.apache.maven.scm.util.AbstractConsumer contains a method:
protected Date parseDate( String date, String userPattern, String
defaultPattern, Locale locale )
Which ignores the specified locale if there is a userPattern specified. Current
implementation is:
if ( StringUtils.isNotEmpty( userPattern ) )
{
format = new SimpleDateFormat( userPattern );
patternUsed = userPattern;
}
When the date parsing fails it misleadingly displays a message indicating that
it did make use of the Locale but clearly it did not:
[ERROR] skip ParseException: Unparseable date: "Mon Oct 21 18:14:36 2013 -0300"
during parsing date Mon Oct 21 18:14:36 2013 -0300 with pattern EEE MMM dd
HH:mm:ss Z with Locale en
java.text.ParseException: Unparseable date: "Mon Oct 21 18:14:36 2013 -0300"
at java.text.DateFormat.parse(DateFormat.java:337)
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
at
org.apache.maven.scm.provider.hg.command.changelog.HgChangeLogConsumer.doConsume(HgChangeLogConsumer.java:196)
at
org.apache.maven.scm.provider.hg.command.changelog.HgChangeLogConsumer.consumeLine(HgChangeLogConsumer.java:97)
at
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:195)
The issue happens because my environment has user.language=es, user.country=AR.
Even passing these parameters in the command line does not help:
mvn clean changelog:changelog -Duser.language=en -Duser.country=US
fails the same way.
How this was tested:
- Mercurial repository
- using maven-changelog-plugin (specifying system parameters here does not help
either)
org.apache.maven.plugins
maven-changelog-plugin
2.2
EEE MMM dd HH:mm:ss Z
user.languageen
user.countryUS
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1070) Forks would complete more uniformly if slow tests aren't run last
[ https://jira.codehaus.org/browse/SUREFIRE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343335#comment-343335 ] NAthan McDonald commented on SUREFIRE-1070: --- documentation says "Balanced is only relevant with parallel=classes", but we aren't using parallel, only forkCount. Tried this anyway, using balanced does seem to actually run a bit quicker for subsequent runs, but this still does not solve our problem. Our CI server does a fresh checkout/build each time, so the statistics file which improves future runs doesn't come into effect. > Forks would complete more uniformly if slow tests aren't run last > - > > Key: SUREFIRE-1070 > URL: https://jira.codehaus.org/browse/SUREFIRE-1070 > Project: Maven Surefire > Issue Type: Improvement >Reporter: NAthan McDonald >Priority: Minor > > Have started using forkCount to use multiple forks when running unit/IT tests. > We've got a handful of slow tests, but without more than 1 fork, makes no > difference in the order they run. > However once we forked (we use 4 forks, on 8 cores), I noticed one or two > forks run longer than the others, completing our slow tests. > Ideally we want each fork to execute in the same time, but this presents > packing problem. > At simplest term, seems improvements would be achieved if we ensured we ran > slow tests first, dividing these up among the initial forks. I've got this > as a workaround, by configuring runOrder to be alphabetical, and > renaming/moving slow tests to an aaslow package, and can see performance > improvements. This is not ideal though. > For a few known slow classes, could have a means to specify them. Otherwise > was thinking would be nice if we annotated slow tests with junit categories, > and then could specify forked mode to run certain categories first. Guess > the solution is up for debate, but this does provide significant gains in > performance would be nice for a way to tweak the runner without having to > move tests to different paths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-410) Private Key from settings.xml ignored on SSH upload-single
[
https://jira.codehaus.org/browse/WAGON-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343331#comment-343331
]
Daniel Plasto commented on WAGON-410:
-
Same problem for me on Windows Server 2003. It is also ignoring SSH credentials
that 2.5 can pick up from the .ssh directory.
> Private Key from settings.xml ignored on SSH upload-single
> --
>
> Key: WAGON-410
> URL: https://jira.codehaus.org/browse/WAGON-410
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.6
> Environment: Windows 8
> org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4
>Reporter: Robert Novotny
>Priority: Critical
>
> When uploading a WAR file via scp:// on wagon-maven plugin combined with
> {{wagon-ssh:2.6}} extension seems to ignore the {{privateKey}} setting from
> Maven {{settings.xml}} (the {{server}} section). The SCP server ignores the
> certificate and asks for user password to the SCP account.
> This does not happen with wagon-ssh:2.5
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1070) Forks would complete more uniformly if slow tests aren't run last
[ https://jira.codehaus.org/browse/SUREFIRE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343330#comment-343330 ] Kristian Rosenvold commented on SUREFIRE-1070: -- runOrder=balanced does not cut it for this ? > Forks would complete more uniformly if slow tests aren't run last > - > > Key: SUREFIRE-1070 > URL: https://jira.codehaus.org/browse/SUREFIRE-1070 > Project: Maven Surefire > Issue Type: Improvement >Reporter: NAthan McDonald >Priority: Minor > > Have started using forkCount to use multiple forks when running unit/IT tests. > We've got a handful of slow tests, but without more than 1 fork, makes no > difference in the order they run. > However once we forked (we use 4 forks, on 8 cores), I noticed one or two > forks run longer than the others, completing our slow tests. > Ideally we want each fork to execute in the same time, but this presents > packing problem. > At simplest term, seems improvements would be achieved if we ensured we ran > slow tests first, dividing these up among the initial forks. I've got this > as a workaround, by configuring runOrder to be alphabetical, and > renaming/moving slow tests to an aaslow package, and can see performance > improvements. This is not ideal though. > For a few known slow classes, could have a means to specify them. Otherwise > was thinking would be nice if we annotated slow tests with junit categories, > and then could specify forked mode to run certain categories first. Guess > the solution is up for debate, but this does provide significant gains in > performance would be nice for a way to tweak the runner without having to > move tests to different paths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1070) Forks would complete more uniformly if slow tests aren't run last
NAthan McDonald created SUREFIRE-1070: - Summary: Forks would complete more uniformly if slow tests aren't run last Key: SUREFIRE-1070 URL: https://jira.codehaus.org/browse/SUREFIRE-1070 Project: Maven Surefire Issue Type: Improvement Reporter: NAthan McDonald Priority: Minor Have started using forkCount to use multiple forks when running unit/IT tests. We've got a handful of slow tests, but without more than 1 fork, makes no difference in the order they run. However once we forked (we use 4 forks, on 8 cores), I noticed one or two forks run longer than the others, completing our slow tests. Ideally we want each fork to execute in the same time, but this presents packing problem. At simplest term, seems improvements would be achieved if we ensured we ran slow tests first, dividing these up among the initial forks. I've got this as a workaround, by configuring runOrder to be alphabetical, and renaming/moving slow tests to an aaslow package, and can see performance improvements. This is not ideal though. For a few known slow classes, could have a means to specify them. Otherwise was thinking would be nice if we annotated slow tests with junit categories, and then could specify forked mode to run certain categories first. Guess the solution is up for debate, but this does provide significant gains in performance would be nice for a way to tweak the runner without having to move tests to different paths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-637) fileSet unix strips last newline of file
[ https://jira.codehaus.org/browse/MASSEMBLY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343294#comment-343294 ] Dennis Lundberg commented on MASSEMBLY-637: --- The patch has already been applied. You can use trunk if you want to try out the fix. > fileSet unix strips last newline of file > - > > Key: MASSEMBLY-637 > URL: https://jira.codehaus.org/browse/MASSEMBLY-637 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Linux ws117v6226517 2.6.32-5-686 #1 SMP Sun Sep 23 > 09:49:36 UTC 2012 i686 GNU/Linux > Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700) > Maven home: /usr/local/lib/apache-maven-3.0.4 > Java version: 1.6.0_33, vendor: Sun Microsystems Inc. > Java home: /usr/local/lib/jdk1.6.0_33/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.32-5-686", arch: "i386", family: "unix" >Reporter: deckrider >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: MASSEMBLY-637.patch > > > using unix strips last newline of file when > building on Linux platform (not sure about other platforms) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
