[jira] (MSITE-634) Invalid links to sub-modules when specifying site url using a profile
Matthias Henkel created MSITE-634:
-
Summary: Invalid links to sub-modules when specifying site url
using a profile
Key: MSITE-634
URL: https://jira.codehaus.org/browse/MSITE-634
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links
Affects Versions: 2.3
Reporter: Matthias Henkel
Attachments: childpom.xml
When using a profile for specifying the site url the links to the sub-modules
get broken.
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.company.application
application
pom
04.00.02-9_19-SNAPSHOT
application
2.2.1
org.apache.maven.plugins
maven-site-plugin
2.3
company
application.site
scpexe://projects.company.com/srv/filestore/application/site/siteFixing/
com.company.application.module
{code}
Executed command: {{mvn clean site-deploy -P company}}
Reproducible with: {{maven-site-plugin}} {{2.3}} but not with {{2.2}}.
When specifying the {{distributionManagement}} section outside of a profile
everything works fine.
The site of the parent module is deployed to
https://projects.company.com/application/filestore/site/siteFixing/index.html
but the link to the sub-module points to
https://projects.company.com/module/index.html even though the sub-module has
been deployed to
https://projects.company.com/application/filestore/site/siteFixing/module/index.html
.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-149) skinnyWars and SNAPSHOT unique dependencies
Seth Rife created MEAR-149: -- Summary: skinnyWars and SNAPSHOT unique dependencies Key: MEAR-149 URL: https://jira.codehaus.org/browse/MEAR-149 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.7 Environment: All Reporter: Seth Rife Priority: Minor Attachments: ear-snapshot-dependencies.txt When trying to create skinnyWars, any SNAPSHOTS dependencies are not extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. The AbstractFileNameMapping class uses the baseVersion to generate the filename which doesn't take into account timestamp dependencies, therefore the plugin is unable to delete any dependency in the libDir folder. Using the Artifact.version property will produce the correct filename for deletion. The really only affects DEV-produced artifacts where EARs are built for deployment and testing. Additionally, bloated EARs can affect repository managers where excessive disk space may not be available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-758) Documentation incorrect for running single integration test
[ https://jira.codehaus.org/browse/SUREFIRE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295565#comment-295565 ] Grmblmbl commented on SUREFIRE-758: --- Still a valid bug with Failsafe 2.12, there is no way to run a single integration test. It would be nice to have an option for this, thanks. > Documentation incorrect for running single integration test > --- > > Key: SUREFIRE-758 > URL: https://jira.codehaus.org/browse/SUREFIRE-758 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation >Reporter: Lyle Hanson >Priority: Minor > > The online documentation for Failsafe which describes [Running a Single > Test|http://maven.apache.org/plugins/maven-failsafe-plugin/examples/single-test.html] > shows: > bq.mvn -Dit.test=ITCircle verify > The it.test parameter does not seem to work. Rather, the same parameter as > Surefire (-Dtest=foo) appears to also work for Failsafe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-758) Documentation incorrect for running single integration test
[ https://jira.codehaus.org/browse/SUREFIRE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295566#comment-295566 ] Grmblmbl commented on SUREFIRE-758: --- Seems to be a regression as it works with Failsafe 2.11 > Documentation incorrect for running single integration test > --- > > Key: SUREFIRE-758 > URL: https://jira.codehaus.org/browse/SUREFIRE-758 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation >Reporter: Lyle Hanson >Priority: Minor > > The online documentation for Failsafe which describes [Running a Single > Test|http://maven.apache.org/plugins/maven-failsafe-plugin/examples/single-test.html] > shows: > bq.mvn -Dit.test=ITCircle verify > The it.test parameter does not seem to work. Rather, the same parameter as > Surefire (-Dtest=foo) appears to also work for Failsafe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-114) Specifying DontIncludeResourceTransformer before ManifestResourceTransformer causes PluginConfigurationException: Unable to parse configuration of mojo shade for parameter transfor
Martin Stein created MSHADE-114:
---
Summary: Specifying DontIncludeResourceTransformer before
ManifestResourceTransformer causes PluginConfigurationException: Unable to
parse configuration of mojo shade for parameter transformer: Cannot find
setter...
Key: MSHADE-114
URL: https://jira.codehaus.org/browse/MSHADE-114
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.4
Environment: Windows 7 x64
JVM 1.6
Mvn 3.0.4
Reporter: Martin Stein
Using the transformer declaration:
.so
org.jacoco.agent.${rt}.JacocoAgent
causes the exception:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project
org.jacoco.agent.rt: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-shade-plugin:1.4:shade for parameter
transformer: Cannot find setter, adder nor field in
org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer for
'manifestEntries' -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on project
org.jacoco.agent.rt: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-shade-plugin:1.4:shade for parameter
transformer: Cannot find setter, adder nor field in
org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer for
'manifestEntries'
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:221)
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:320)
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)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to
parse configuration of mojo
org.apache.maven.plugins:maven-shade-plugin:1.4:shade for parameter
transformer: Cannot find setter, adder nor field in
org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer for
'manifestEntries'
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:597)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:529)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 25 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot find setter, adder nor field in
org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer for
'manifestEntries'
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.(ComponentValueSetter.java:95)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.pr
[jira] (MEAR-78) Library directory configuration
[
https://jira.codehaus.org/browse/MEAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295588#comment-295588
]
Yifei Zhang edited comment on MEAR-78 at 4/2/12 12:57 PM:
--
I don't get it. What if I want the defaultLibBundleDir is WEB-INF/lib??? You
will using WEB-INF/lib as library-directory??? Is that correct??? What are you
thinking about???
was (Author: iameinstein):
I don't get it. What if I want the defaultLibBundleDir is WEB-INF/lib???
You will using WEB-INF/lib as library-directory??? Is that correct??? What are
thinking about???
> Library directory configuration
> ---
>
> Key: MEAR-78
> URL: https://jira.codehaus.org/browse/MEAR-78
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: Danilo Eiji Seki
>Assignee: Stéphane Nicoll
> Fix For: 2.3.2
>
> Attachments: MEAR-78-new.patch, MEAR-78.patch
>
>
> Plugin configuration should include a property to set {{library-directory}}
> configuration in generated {{application.xml}}. It may not be necessary to
> include this property. Maybe something like "if {{defaultLibBundleDir}} is
> different from {{lib}}, include configuration".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-78) Library directory configuration
[
https://jira.codehaus.org/browse/MEAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295588#comment-295588
]
Yifei Zhang commented on MEAR-78:
-
I don't get it. What if I want the defaultLibBundleDir is WEB-INF/lib??? You
will using WEB-INF/lib as library-directory??? Is that correct??? What are
thinking about???
> Library directory configuration
> ---
>
> Key: MEAR-78
> URL: https://jira.codehaus.org/browse/MEAR-78
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: Danilo Eiji Seki
>Assignee: Stéphane Nicoll
> Fix For: 2.3.2
>
> Attachments: MEAR-78-new.patch, MEAR-78.patch
>
>
> Plugin configuration should include a property to set {{library-directory}}
> configuration in generated {{application.xml}}. It may not be necessary to
> include this property. Maybe something like "if {{defaultLibBundleDir}} is
> different from {{lib}}, include configuration".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-78) Library directory configuration
[
https://jira.codehaus.org/browse/MEAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295588#comment-295588
]
Yifei Zhang edited comment on MEAR-78 at 4/2/12 1:06 PM:
-
I don't get it. What if I want the defaultLibBundleDir is APP-INF/lib??? You
will using APP-INF/lib as library-directory??? Is that correct??? What are you
thinking about???
was (Author: iameinstein):
I don't get it. What if I want the defaultLibBundleDir is APP-INF/lib???
You will using WEB-INF/lib as library-directory??? Is that correct??? What are
you thinking about???
> Library directory configuration
> ---
>
> Key: MEAR-78
> URL: https://jira.codehaus.org/browse/MEAR-78
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: Danilo Eiji Seki
>Assignee: Stéphane Nicoll
> Fix For: 2.3.2
>
> Attachments: MEAR-78-new.patch, MEAR-78.patch
>
>
> Plugin configuration should include a property to set {{library-directory}}
> configuration in generated {{application.xml}}. It may not be necessary to
> include this property. Maybe something like "if {{defaultLibBundleDir}} is
> different from {{lib}}, include configuration".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-78) Library directory configuration
[
https://jira.codehaus.org/browse/MEAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295588#comment-295588
]
Yifei Zhang edited comment on MEAR-78 at 4/2/12 1:06 PM:
-
I don't get it. What if I want the defaultLibBundleDir is APP-INF/lib??? You
will using WEB-INF/lib as library-directory??? Is that correct??? What are you
thinking about???
was (Author: iameinstein):
I don't get it. What if I want the defaultLibBundleDir is WEB-INF/lib???
You will using WEB-INF/lib as library-directory??? Is that correct??? What are
you thinking about???
> Library directory configuration
> ---
>
> Key: MEAR-78
> URL: https://jira.codehaus.org/browse/MEAR-78
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: Danilo Eiji Seki
>Assignee: Stéphane Nicoll
> Fix For: 2.3.2
>
> Attachments: MEAR-78-new.patch, MEAR-78.patch
>
>
> Plugin configuration should include a property to set {{library-directory}}
> configuration in generated {{application.xml}}. It may not be necessary to
> include this property. Maybe something like "if {{defaultLibBundleDir}} is
> different from {{lib}}, include configuration".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5270) README.bootstrap.txt says "Ant 1.6.5 or later" BUT 1.8 or later is needed
[ https://jira.codehaus.org/browse/MNG-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNG-5270. - Resolution: Fixed Fix Version/s: 3.0.5 Assignee: Olivier Lamy fixed. Thanks for the report! > README.bootstrap.txt says "Ant 1.6.5 or later" BUT 1.8 or later is needed > - > > Key: MNG-5270 > URL: https://jira.codehaus.org/browse/MNG-5270 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.0.4 > Environment: all >Reporter: Larry Kluger >Assignee: Olivier Lamy >Priority: Minor > Fix For: 3.0.5 > > > For a new build on a clean system, the README.bootstrap.txt says "Ant 1.6.5 > or later" BUT build fails if ant 1.6.5 is installed. > Solution: > Ant 1.8 or later is needed according to docs bug. > See http://jira.codehaus.org/browse/MNGSITE-147 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-634) Invalid links to sub-modules when specifying site url using a profile
[
https://jira.codehaus.org/browse/MSITE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295595#comment-295595
]
Dennis Lundberg commented on MSITE-634:
---
The Site Plugin uses the value of the element in the POMs, to create
relative links. I don't see any such element in the samples you provided. Note
that I'm not talking about //.
You can read more at:
http://maven.apache.org/plugins/maven-site-plugin-2.3/faq.html#Use_of_url
> Invalid links to sub-modules when specifying site url using a profile
> -
>
> Key: MSITE-634
> URL: https://jira.codehaus.org/browse/MSITE-634
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links
>Affects Versions: 2.3
>Reporter: Matthias Henkel
> Attachments: childpom.xml
>
>
> When using a profile for specifying the site url the links to the sub-modules
> get broken.
> {code}
>
> http://maven.apache.org/POM/4.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.company.application
> application
> pom
> 04.00.02-9_19-SNAPSHOT
> application
>
> 2.2.1
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-site-plugin
> 2.3
>
>
>
>
>
>
> company
>
>
> application.site
>
> scpexe://projects.company.com/srv/filestore/application/site/siteFixing/
>
>
>
>
>
> com.company.application.module
>
>
> {code}
> Executed command: {{mvn clean site-deploy -P company}}
> Reproducible with: {{maven-site-plugin}} {{2.3}} but not with {{2.2}}.
> When specifying the {{distributionManagement}} section outside of a profile
> everything works fine.
> The site of the parent module is deployed to
> https://projects.company.com/application/filestore/site/siteFixing/index.html
> but the link to the sub-module points to
> https://projects.company.com/module/index.html even though the sub-module has
> been deployed to
> https://projects.company.com/application/filestore/site/siteFixing/module/index.html
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5267) False positive as DuplicateProjectException doesn't check project absolute path
[ https://jira.codehaus.org/browse/MNG-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295596#comment-295596 ] John Patrick commented on MNG-5267: --- Additional submit needed https://github.com/nhojpatrick/maven-3/commit/433d908014304514380807b89c48ba2fe38f3b5a to handle ProjectSorter duplication check. > False positive as DuplicateProjectException doesn't check project absolute > path > --- > > Key: MNG-5267 > URL: https://jira.codehaus.org/browse/MNG-5267 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 > Environment: loki:~ john$ mvn -version > Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+) > Maven home: /opt/local/share/java/maven3 > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x", version: "10.6.8", arch: "x86_64", family: "mac" > loki:~ john$ java -version > java version "1.6.0_29" > Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) > Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) > loki:~ john$ >Reporter: John Patrick > Attachments: DefaultMaven.java.patch, exact-same-module.output.log, > exact-same-module.zip > > > I'm getting false positive DuplicateProjectException being thrown, when > modules refer to the exact same project, i.e. pom absolute path is the same. > Parent Pom > -Sub Project One Pom > -Sub Project Two Pom > -Jar > For ease of building individual sub components both Sub Project One and Two > refer to jar as being a module. I realize that having two pom's refering to > the same artifact as a module isn't the best solutions. > But a simple change to when the Exception is thrown would remove this false > positive. In the exception is outputs both pom locations and they are exactly > the same absolute path. > I've also forked on github. > https://github.com/nhojpatrick/maven-3/commit/8e8c512d9535c58808fe1c4f58349313bbc3a887 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295599#comment-295599 ] Mirko Friedenhagen commented on MRELEASE-723: - @Mark: I do not think it will be a problem for Git or Mercurial as there was no support for this right now. In regards to subversion using tag is probably unneeded as the SCM-URL is unique already? I would be willing to edit the patch to exclude the subversion usecase but think it to be valuable for the DVCSes. > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen > Fix For: 2.3 > > Attachments: add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-167) Incorrect default for generatedTestSourcesDirectory
Jesse Glick created MCOMPILER-167:
-
Summary: Incorrect default for generatedTestSourcesDirectory
Key: MCOMPILER-167
URL: https://jira.codehaus.org/browse/MCOMPILER-167
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Jesse Glick
http://maven.apache.org/plugins/maven-compiler-plugin/testCompile-mojo.html#generatedTestSourcesDirectory
shows the default location as
${project.build.directory}/generated-sources/test-annotations, but as
http://netbeans.org/bugzilla/show_bug.cgi?id=208286#c1 mentions this should be
${project.build.directory}/generated-test-sources/annotations instead, to
enforce the convention that target/generated-sources/* are main source roots
whereas target/generated-test-sources/* are test source roots.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-279) ability to skip for Jira is offlince
Swapnil Sapar created MCHANGES-279:
--
Summary: ability to skip for Jira is offlince
Key: MCHANGES-279
URL: https://jira.codehaus.org/browse/MCHANGES-279
Project: Maven 2.x Changes Plugin
Issue Type: Improvement
Components: jira
Affects Versions: 2.6
Environment: {code}
$ mvn -v
Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.6.8", arch: "x86_64", family: "mac"
{code}
Reporter: Swapnil Sapar
maven-changes-plugin is great and compiles a nice Jira report.
We need an ability to skip the Jira report compilation. Jira instance may not
always be available when on different network or completely disconnected from
Jira.
{code:xml}
org.apache.maven.plugins
maven-changes-plugin
2.6
true
...
{code}
Skip flag above can then be parameterized.
I'm not sure if the plugin can be sensitive to --offline flag instead of
flag.
When Jira is unavailable, current behavior just times out during the build. But
build takes forever to complete waiting for times outs and retries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-634) Invalid links to sub-modules when specifying site url using a profile
[
https://jira.codehaus.org/browse/MSITE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295615#comment-295615
]
Matthias Henkel commented on MSITE-634:
---
Thank you for your immediate response!
Unfortunately adding the URL didn't help. I added the URL
https://projects.company.com/application/filestore/site/siteFixing/
in the parent pom and
https://projects.company.com/application/filestore/site/siteFixing/module
in the child pom - as "root element", not in
//.
These are exactly the links to the location where the deployed site is
available but the generated relative link didn't change at all. (Of course
"company" and "application" are only replacements for the real values I use.)
Am I missing something? I still wonder why everything works fine when using 2.2
or not using a profile.
> Invalid links to sub-modules when specifying site url using a profile
> -
>
> Key: MSITE-634
> URL: https://jira.codehaus.org/browse/MSITE-634
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links
>Affects Versions: 2.3
>Reporter: Matthias Henkel
> Attachments: childpom.xml
>
>
> When using a profile for specifying the site url the links to the sub-modules
> get broken.
> {code}
>
> http://maven.apache.org/POM/4.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.company.application
> application
> pom
> 04.00.02-9_19-SNAPSHOT
> application
>
> 2.2.1
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-site-plugin
> 2.3
>
>
>
>
>
>
> company
>
>
> application.site
>
> scpexe://projects.company.com/srv/filestore/application/site/siteFixing/
>
>
>
>
>
> com.company.application.module
>
>
> {code}
> Executed command: {{mvn clean site-deploy -P company}}
> Reproducible with: {{maven-site-plugin}} {{2.3}} but not with {{2.2}}.
> When specifying the {{distributionManagement}} section outside of a profile
> everything works fine.
> The site of the parent module is deployed to
> https://projects.company.com/application/filestore/site/siteFixing/index.html
> but the link to the sub-module points to
> https://projects.company.com/module/index.html even though the sub-module has
> been deployed to
> https://projects.company.com/application/filestore/site/siteFixing/module/index.html
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
