[jira] Created: (MRELEASE-656) Unable to release multi-module project with pom module referencing a property inheriting from the parent&aggregator root pom
Unable to release multi-module project with pom module referencing a property
inheriting from the parent&aggregator root pom
Key: MRELEASE-656
URL: http://jira.codehaus.org/browse/MRELEASE-656
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.1
Reporter: Baptiste MATHUS
Priority: Critical
Hi,
In our multi-modules project, we have added a bunch of poms that are designed
to be parent poms from other projects when using our corporate archetypes.
Those poms reference artifacts from the reactors with the same version. To do
that, we have a property inside the aggregator that we manually set that is
always equal to As we can't use ${project.version
--
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: (MRELEASE-656) Unable to release multi-module project with pom module referencing a property inheriting from the parent&aggregator root pom
[
http://jira.codehaus.org/browse/MRELEASE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Baptiste MATHUS closed MRELEASE-656.
Resolution: Duplicate
> Unable to release multi-module project with pom module referencing a property
> inheriting from the parent&aggregator root pom
>
>
> Key: MRELEASE-656
> URL: http://jira.codehaus.org/browse/MRELEASE-656
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
>Reporter: Baptiste MATHUS
>Priority: Critical
>
> Hi,
> In our multi-modules project, we have added a bunch of poms that are designed
> to be parent poms from other projects when using our corporate archetypes.
> Those poms reference artifacts from the reactors with the same version. To do
> that, we have a property inside the aggregator that we manually set that is
> always equal to As we can't use ${project.version
--
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: (MRELEASE-657) Unable to release multi-module project with pom module referencing a property coming from the parent&aggregator root pom as a dependency version : "The version could not
Unable to release multi-module project with pom module referencing a property
coming from the parent&aggregator root pom as a dependency version : "The
version could not be updated: ${...}"
-
Key: MRELEASE-657
URL: http://jira.codehaus.org/browse/MRELEASE-657
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.1
Reporter: Baptiste MATHUS
Priority: Critical
Attachments: mreleasebug.zip, output.txt
Hi,
In our multi-modules project (same version for all modules, using
autoVersionSubmodules=true), we have added a bunch of poms that are designed to
be parent poms from other projects when using our corporate archetypes.
Those poms reference artifacts from the reactor with the same version.
To do that, we have a manually set property inside the aggregator root pom.
This version is always equal to the project version.
(We do that because we can't use ${project.version} : if we do, when someone
will use this parent pom, and they define their version, this version will be
used for the dependencies defined in the parent pom using ${project.version}).
As I'm aware this is not really simple to explain&understand, I attached a
testcase to show the problem.
I'm also attaching the resulting output.
This problem is present with both maven 3.0.2 and 2.2.1.
Cheers
--
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: (MSITE-558) Flexible site descriptor inheritance
Flexible site descriptor inheritance Key: MSITE-558 URL: http://jira.codehaus.org/browse/MSITE-558 Project: Maven 2.x and 3.x Site Plugin Issue Type: New Feature Components: inheritance Reporter: SebbASF Inheritance as currently implemented means that elements (for example) are inherited, Descendants can either accept the or replace it completely with their own version. There's no concept of merging such elements, though this would be quite useful on occasion. My suggestion is to add an optional name (or id) to elements such as , (when implemented), etc. Elements with the same name would replace their parent, as at present. Elements with different names would be merged. Since ordering is important for some elements, the name would be used to define the order (i.e. alphabetical). If not specified, the name would default to "main", which by happy co-incidence is roughly in the middle of the alphabet. -- 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: (SUREFIRE-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-700: Attachment: stage2.patch Added "shade" based solution in r1075071. Please note that this will not be effective until after we have released a version with this patch in it, at which time we can apply this subsequent patch, stage2.patch. Make sure the version numbers (in shaderfire pom.xml) file are correct when applying this patch. I just add this patch to in case I get run over by a truck > Surefire is not isolated from itself > > > Key: SUREFIRE-700 > URL: http://jira.codehaus.org/browse/SUREFIRE-700 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.7.3 > > Attachments: stage2.patch > > > The current classloader structure in surefire does not isolate surefire from > changes to surefire in itself. This means an interface change in *most* > private interfaces and classes can break the build of surefire itself. > This is due to the classloader structure > systemclassloader<-testclassloader<-providerclassloader, where a modified > surefire immediately becomes effective by being loaded in testclassloader. > This issue will be fixed by making the following structure: > systemclassloader<-testframeworkclassloader<-testclassloader > systemclassloader<-testframeworkclassloader<-surefireclassloader > Pardon the ascii graphics but it seems like jira does not allow me to draw > systemclassloader<-testframeworkclassloader as one common root ;) -- 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: (SUREFIRE-700) Surefire is not isolated from itself
[ http://jira.codehaus.org/browse/SUREFIRE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257899#action_257899 ] Kristian Rosenvold edited comment on SUREFIRE-700 at 2/27/11 9:39 AM: -- Added "shade" based solution in r1075071. Please note that this will not be effective until after we have released a version with this patch in it, at which time we can apply this subsequent patch, stage2.patch. Make sure the version numbers (in shaderfire pom.xml) file are correct when applying this patch. I just add this patch to JIRA in case I get run over by a truck "shadedVersion" in root pom should be the version of surefire you will be building with, and should be N-1. was (Author: krosenvold): Added "shade" based solution in r1075071. Please note that this will not be effective until after we have released a version with this patch in it, at which time we can apply this subsequent patch, stage2.patch. Make sure the version numbers (in shaderfire pom.xml) file are correct when applying this patch. I just add this patch to in case I get run over by a truck > Surefire is not isolated from itself > > > Key: SUREFIRE-700 > URL: http://jira.codehaus.org/browse/SUREFIRE-700 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.4.1, 2.4.2, 2.4.3, 2.5, 2.6, 2.7, 2.7.1, 2.7.2 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.7.3 > > Attachments: stage2.patch > > > The current classloader structure in surefire does not isolate surefire from > changes to surefire in itself. This means an interface change in *most* > private interfaces and classes can break the build of surefire itself. > This is due to the classloader structure > systemclassloader<-testclassloader<-providerclassloader, where a modified > surefire immediately becomes effective by being loaded in testclassloader. > This issue will be fixed by making the following structure: > systemclassloader<-testframeworkclassloader<-testclassloader > systemclassloader<-testframeworkclassloader<-surefireclassloader > Pardon the ascii graphics but it seems like jira does not allow me to draw > systemclassloader<-testframeworkclassloader as one common root ;) -- 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: (SUREFIRE-704) maven surefire Error while executing forked tests.; nested exception is java.lang.IllegalStateException: testSetStarting called twice
[ http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257900#action_257900 ] Kristian Rosenvold commented on SUREFIRE-704: - Are you sure you got this exact message with 2.7.2 ? It was fixed for 2.7.2, but we have a *similar* issue (SUREFIRE-690) that has a slightly different error message that will be fixed for 2.7.3. The only known workaround at the moment is to insert a minor Thread.sleep() in an @after method for tests that write a lot to console. And 690 is targeted for 2.7.3 (will be 2.8) > maven surefire Error while executing forked tests.; nested exception is > java.lang.IllegalStateException: testSetStarting called twice > - > > Key: SUREFIRE-704 > URL: http://jira.codehaus.org/browse/SUREFIRE-704 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.7.2 > Environment: Windows/Linux/SunOS >Reporter: S Daigle > Attachments: surefire.txt > > > We want to upgrade from our current 2.5 version of the maven-surefire-plugin > to something newer but cannot get past the error below. We've tried versions > 2.6, 2.7 up to and including 2.7.3-SNAPSHOT but they all fail. > When setting forkmode to "once" and redirectTestOutputToFile to "true", we > get the following error on multiple tests: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.7.3-SNAPSHOT:test > (default-test) on project api: Error while executing forked tests.; nested > exception is java.lang.IllegalStateException: testSetStarting called twice -> > [Help 1] > Please see the attachment for full "mvn -e test" output. > If we set the redirectTestOutputToFile to false, it works but we need this > option set to true. > Thanks -- 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: (MDEPLOY-93) Deploy plugin does not honor modification of final name by assembly plugin
[
http://jira.codehaus.org/browse/MDEPLOY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257903#action_257903
]
Florian Brunner commented on MDEPLOY-93:
This is really strange.
I have a project with:
groupId=mySite.myProject
artifact=lib-core
To avoid name clashes (e.g. when copying dependencies to a directory) and to
easily identify a jar in the library view of IDEs (NetBeans, Eclipse), I
renamed the artifacts to:
myProject-${project.artifactId}-v${project.version}
I was surprised that the deployed file name was "lib-core-0.1.jar", which
really doesn't say much about the jar.
I actually don't see the lookup issue. In Nexus the the files are organized
like:
mySite.myProject.artifactId.version
Afterwards the file names should be allowed to have arbitrary names, as long as
the file extensions are correct. It would be slightly more complex, but not
much, I think.
> Deploy plugin does not honor modification of final name by assembly plugin
> --
>
> Key: MDEPLOY-93
> URL: http://jira.codehaus.org/browse/MDEPLOY-93
> Project: Maven 2.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Thorsten Möller
>Assignee: Benjamin Bentmann
>
> When using the Maven assembly plugin to create an assembly for a project and
> using "fileName" parameter inside the plugin to change the final name of the
> assembly this new name will not be used by the deploy plugin. The deploy
> plugin always uses the default behavior. The following excerpt from a POM
> illustrates this:
> myGoupID
> myArtifactID
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
>
> src/main/assembly/bin.xml
>
> false
> foo
> gnu
>
>
>
> minimal
> package
>
> single
>
>
>
>
>
>
> With this configuration an assembly named "foo.{tar.gz|zip}" will be created
> in the target folder of the project (note that the artifact is attached
> because the assembly plugin is attached to the package lifecycle phase).
> However, when deploying the project file to the distribution repository it
> will be named "myArtifactId.{tar.gz|zip}", which is the default behavior if
> "finalName" is not specified. Interesting is that in the local repository the
> file name always corresponds to what is specified by "fileName", just for the
> distribution repository the parameter is not honored.
> BTW, the other parameter "appendAssemblyId" is honored correctly, i.e,
> depending on the boolean value the assembly Id will be appended to the name,
> or not.
--
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: (MECLIPSE-680) StringIndexOutOfBoundsException on Apache Commons VFS Core
StringIndexOutOfBoundsException on Apache Commons VFS Core
--
Key: MECLIPSE-680
URL: http://jira.codehaus.org/browse/MECLIPSE-680
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Ubuntu 10.10, Maven 3.0.2, Apache Commons VFS r1075087
Reporter: James Shaw
The error given by {{mvn eclipse:eclipse -X}} is:
{code}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Commons VFS ... SUCCESS [2.278s]
[INFO] Commons VFS Core .. FAILURE [0.473s]
[INFO] Commons VFS Examples .. SKIPPED
[INFO] Commons VFS Sandbox ... SKIPPED
[INFO] Commons VFS Distribution .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.872s
[INFO] Finished at: Sun Feb 27 16:54:37 GMT 2011
[INFO] Final Memory: 13M/32M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project commons-vfs2: Execution default-cli of goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse failed: String index
out of range: -5 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse (default-cli) on
project commons-vfs2: Execution default-cli of goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse failed: String index
out of range: -5
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
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:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse
failed: String index out of range: -5
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
range: -5
at java.lang.String.substring(String.java:1949)
at java.lang.String.substring(String.java:1916)
at
org.apache.maven.plugin.eclipse.writers.EclipseSettingsWriter.write(EclipseSettingsWriter.java:111)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1113)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
... 20 more
{code}
--
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: (SUREFIRE-659) Maven PDF plugin:showSuccess=false creates empty table causing error
[ http://jira.codehaus.org/browse/SUREFIRE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-659: Attachment: surefire659testcase.patch Enclosed is an IT project that can be used to work on this issue. > Maven PDF plugin:showSuccess=false creates empty table causing error > > > Key: SUREFIRE-659 > URL: http://jira.codehaus.org/browse/SUREFIRE-659 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.6 > Environment: maven 2.2.1, surefire 2.6, maven-pdf-plugin >Reporter: Darren Hartford > Attachments: surefire659testcase.patch > > > The problem is that for > showSuccess=false an empty table is written but fo expects some > tableRows even if they are empty. > Cheers, > -Lukas > Darren Hartford wrote: > > Hey all, > > Not sure where to put this issue, but using the surefire-report(2.6) with > > showSuccess=false, with the maven-pdf-plugin (1.1) breaks. This is using a > > multi-module/aggregate report approach, maven 2.2.1. With > > showSuccess=true, everything works fine. > > > > Basic intent is to, on a release, create an aggregate/summary PDF of the > > release, but some of the items. such as the surefire-report, are too > > verbose. > > > > > > org.apache.maven.plugins > > maven-surefire-report-plugin > > 2.6 > > > > > >false > > true > > > > > > > > > > > > > > > > Error > > === > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Error during document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > > > [INFO] > > > > [DEBUG] Trace > > org.apache.maven.lifecycle.LifecycleExecutionException: Error during > > document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) > > 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:616) > > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during > > document generation: Error creating PDF from > > /dev//target/pdf/maven-pdf-plugin-doc-3.6.fo: > > org.apache.fop.fo.ValidationException: > > file:/dev//target/pdf/maven-pdf-plugin-doc-3.6.fo:3089:16: Error(3089/16): > > fo:table-body is missing child elements. > > Required Content Model: marker* (table-row+|table-cell+) > > at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:574) > > at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391) > > at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.e
[jira] Created: (MNG-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1
Problem executing custom surefire implementation in Maven 3.0.3-RC1 --- Key: MNG-5027 URL: http://jira.codehaus.org/browse/MNG-5027 Project: Maven 2 & 3 Issue Type: Bug Components: Plugins and Lifecycle Reporter: Paul Gier Attachments: build.log There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When executing the jboss-as build [1] the build fails during execution of our custom implementation of the surefire plugin. [1]https://github.com/jbossas/jboss-as -- 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-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1
[ http://jira.codehaus.org/browse/MNG-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-5027: --- Description: There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When executing the jboss-as build [1] the build fails during execution of our custom implementation of the surefire plugin [2]. [1]https://github.com/jbossas/jboss-as [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin was: There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When executing the jboss-as build [1] the build fails during execution of our custom implementation of the surefire plugin. [1]https://github.com/jbossas/jboss-as > Problem executing custom surefire implementation in Maven 3.0.3-RC1 > --- > > Key: MNG-5027 > URL: http://jira.codehaus.org/browse/MNG-5027 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Paul Gier > Attachments: build.log > > > There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When > executing the jboss-as build [1] the build fails during execution of our > custom implementation of the surefire plugin [2]. > [1]https://github.com/jbossas/jboss-as > [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin -- 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: (SUREFIRE-566) Bump to Doxia 1.1.1
[ http://jira.codehaus.org/browse/SUREFIRE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-566: Attachment: surefire566VersionUpdates.patch This patch just ups the versions, but there seem to be some problems > Bump to Doxia 1.1.1 > --- > > Key: SUREFIRE-566 > URL: http://jira.codehaus.org/browse/SUREFIRE-566 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Report Plugin >Affects Versions: 2.4.3 >Reporter: Vincent Siveton > Attachments: surefire566VersionUpdates.patch > > -- 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: (SCM-611) AccuRev - call replica sync before export
[ http://jira.codehaus.org/browse/SCM-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-611: - Fix Version/s: 1.5 Assignee: Olivier Lamy > AccuRev - call replica sync before export > - > > Key: SCM-611 > URL: http://jira.codehaus.org/browse/SCM-611 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-accurev >Affects Versions: 1.5 >Reporter: Grant Gardner >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.5 > > Attachments: SCM-611.patch > > > When using the AccuRev 4.9 feature that allows export of a specific version > (transaction id), this will fail if you are using a replica server where this > transaction is not available. > This appears for me in the[Bamboo maven scm > integration|https://studio.plugins.atlassian.com/wiki/display/BMSCM/Home] > since Bamboo does its change detection against the AccuRev master server and > passes the top transaction id to an agent which exports the code from an > AccuRev replica. > Unfortunately there isn't a nice way to detect if you are using a replica, > apart from seeing a warning message when you try to sync so fix is to just > always call replica sync and ignore any errors. -- 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: (MRRESOURCES-51) Publish the XML schemas for remote-resources and supplemental-model
[ http://jira.codehaus.org/browse/MRRESOURCES-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRRESOURCES-51. -- Resolution: Fixed > Publish the XML schemas for remote-resources and supplemental-model > --- > > Key: MRRESOURCES-51 > URL: http://jira.codehaus.org/browse/MRRESOURCES-51 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 1.2 > > > The XML schemas for remote-resources and supplemental-model are not published > anywhere. -- 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: (MRELEASE-645) Allow File/Directory Patterns for the checkModificationExcludes Option
[
http://jira.codehaus.org/browse/MRELEASE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257913#action_257913
]
Mike Whittemore commented on MRELEASE-645:
--
I would very much like to see the suggested improvements. Plus they would make
this plugin's configuration consistent with most other plugins.
> Allow File/Directory Patterns for the checkModificationExcludes Option
> --
>
> Key: MRELEASE-645
> URL: http://jira.codehaus.org/browse/MRELEASE-645
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: branch, prepare, scm
>Affects Versions: 2.1
> Environment: all
>Reporter: Stefan Ferstl
>Priority: Minor
> Attachments: modification-excludes.patch
>
>
> The {{checkModificationExcludes}} option does currently only allow the
> definition single files to be excluded from the SCM modification check. If
> this option is defined, all files anywhere in the maven project structure
> with the specified name will be excluded from the check. It is currently not
> possible to exclude files only within a specific directory or to exclude
> classes of files, i.e. all files matching a specific file name pattern.
> If the {{checkModificationExcludes}} option allowed the definition of file
> and directory patterns, these things would be possible.
> *Example 1*: I'd like to exclude a test resource
> {{src/test/resources/foo.properties}} from the modification check but the
> real foo.properties in {{src/main/resources}} should still be checked.
> {code:xml}
>
>
> src/test/resources/foo.properties
>
> {code}
> *Example 2*: I'd like to exclude all properties files with the prefix {{bar}}
> from the modification check:
> {code:xml}
>
> **/bar*.properties
>
> {code}
> The attached patch modifies the {{ScmCheckModificationsPhase}} to use the
> {{DirectoryScanner}} from plexus-utils instead of doing a strict file name
> comparison. The patch does not provide more unit tests for this feature but
> it adjusts the existing tests to run without any failures.
--
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-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1
[ http://jira.codehaus.org/browse/MNG-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257916#action_257916 ] Stuart McCulloch commented on MNG-5027: --- Hi Paul - could you add a direct link to the source of your patched surefire plugin? I couldn't find it from the above links - thanks. > Problem executing custom surefire implementation in Maven 3.0.3-RC1 > --- > > Key: MNG-5027 > URL: http://jira.codehaus.org/browse/MNG-5027 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Paul Gier > Attachments: build.log > > > There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When > executing the jboss-as build [1] the build fails during execution of our > custom implementation of the surefire plugin [2]. > [1]https://github.com/jbossas/jboss-as > [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin -- 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-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1
[ http://jira.codehaus.org/browse/MNG-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257925#action_257925 ] Paul Gier commented on MNG-5027: The source for the forked surefire are located here: https://github.com/kabir/jboss-modules-surefire-plugin > Problem executing custom surefire implementation in Maven 3.0.3-RC1 > --- > > Key: MNG-5027 > URL: http://jira.codehaus.org/browse/MNG-5027 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Paul Gier > Attachments: build.log > > > There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When > executing the jboss-as build [1] the build fails during execution of our > custom implementation of the surefire plugin [2]. > [1]https://github.com/jbossas/jboss-as > [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin -- 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: (MSITE-559) Delayed resolution of variables in inherited site.xml files
Delayed resolution of variables in inherited site.xml files --- Key: MSITE-559 URL: http://jira.codehaus.org/browse/MSITE-559 Project: Maven 2.x and 3.x Site Plugin Issue Type: Improvement Components: inheritance Reporter: SebbASF At present, variable references in site.xml files are resolved in the context of the project that contains the site.xml. This is often not what is required - e.g. if a parent site.xml is used to define settings for several modules. It would be useful if there was a way to declare references that are resolved in the context of the module that is being built. -- 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
