[jira] Commented: (MCHECKSTYLE-135) Can't use a configFile with an URL
[
http://jira.codehaus.org/browse/MCHECKSTYLE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235041#action_235041
]
Dominique Jean-Prost commented on MCHECKSTYLE-135:
--
@Rick : I marked as fixed as the source trunk contains the fix. But 2.6 hasn't
been released yet. As there is no issue remaining at this time, I think
everything should go quickly for now.
Please also note that I didn't manage to make 2.5 version work by adding the
dependency element in my pom.xml. I don't know if it's a problem or not.
> Can't use a configFile with an URL
> --
>
> Key: MCHECKSTYLE-135
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-135
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dominique Jean-Prost
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: log.txt
>
>
> If I specify a config file with an url, this file can't be downloaded anymore.
> I double checked that this file is reachable by http.
> After searching a bit, I guess the problem comes from
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(String) in
> the following lines :
> for ( Iterator i = paths.iterator(); i.hasNext(); ) { <-- paths is empty there
> }
--
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: (MNG-4789) [regression] Difference in compile scope dependency resolution
[ http://jira.codehaus.org/browse/MNG-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4789. -- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Benjamin Bentmann Fixed in [r996468|http://svn.apache.org/viewvc?view=revision&revision=996468]. > [regression] Difference in compile scope dependency resolution > -- > > Key: MNG-4789 > URL: http://jira.codehaus.org/browse/MNG-4789 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0-beta-3 > Environment: maven-3.0-beta-2 vs. maven-3.0-beta-3 (trunk) >Reporter: Paul Gier >Assignee: Benjamin Bentmann > Fix For: 3.0-beta-4 > > Attachments: maven-3-dependency-issue.zip, > maven-3-dependency-issue.zip > > > There is a small difference in dependency resolution behaviour from > 3.0-beta-2 to 3.0-beta-3. I have a project with multiple interdependent > modules. > module 2 -> module 1 -> thirdparty dep > Module 1 has a compile scope dependency on thirdparty dep. Module 2 has a > test scope dependency on module 1. Using dependency management, in > 3.0-beta-2 module 2 ended up with a test scope dependency on thirdparty. In > 3.0-beta-3 module 2 ends up with a compile scope dependency. "mvn > dependency:tree" reports a test scope in both cases, but with > maven-3.0-beta-3 the thirdparty dep appears in the compile classpath. -- 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: (MNG-4800) Conflict resolution does not pick sub tree of nearest dependency if farther conflicting dependency has wider scope
[
http://jira.codehaus.org/browse/MNG-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4800.
--
Resolution: Fixed
Fix Version/s: 3.0-beta-4
Assignee: Benjamin Bentmann
Fixed in [r996468|http://svn.apache.org/viewvc?view=revision&revision=996468].
> Conflict resolution does not pick sub tree of nearest dependency if farther
> conflicting dependency has wider scope
> --
>
> Key: MNG-4800
> URL: http://jira.codehaus.org/browse/MNG-4800
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.11, 2.2.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-4
>
>
> This is a follow-up for the observations made in MNG-4761 and MNG-4790 where
> scope widening during conflict resolution will cause inconsistent sub trees
> in the resolved dependency graph. For example the unresolved tree
> {noformat}
> project
> +- a:runtime
> | \- c:1:runtime
> | \- x:runtime
> \- b:compile
>\- c:2:compile
> \- y:compile
> {noformat}
> will be resolved to
> {noformat}
> project
> +- a:runtime
> \- b:compile
>\- c:1:compile
> \- y:compile
> {noformat}
> instead of
> {noformat}
> project
> +- a:runtime
> | \- c:1:compile
> | \- x:compile
> \- b:compile
> {noformat}
> Note the difference regarding inclusion of x/y. The latter tree structure is
> however successfully resolved when using compile scope for dependency a.
--
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: (MNG-4807) Extend core artifact filter to exclude relocated Guice-based Plexus shim
Extend core artifact filter to exclude relocated Guice-based Plexus shim
Key: MNG-4807
URL: http://jira.codehaus.org/browse/MNG-4807
Project: Maven 2 & 3
Issue Type: Task
Components: Class Loading, Plugins and Lifecycle
Affects Versions: 3.0-beta-3
Reporter: Benjamin Bentmann
Priority: Minor
The Guice-based Plexus shim has been relocated from
{{org.sonatype.spice:spice-inject-plexus}} to
{{org.sonatype.sisu:sisu-inject-plexus}}, the artifact filter needs to account
for this as well.
--
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: (MNG-4807) Extend core artifact filter to exclude relocated Guice-based Plexus shim
[
http://jira.codehaus.org/browse/MNG-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4807.
--
Resolution: Fixed
Fix Version/s: 3.0-beta-4
Assignee: Benjamin Bentmann
Done in [r996480|http://svn.apache.org/viewvc?view=revision&revision=996480].
> Extend core artifact filter to exclude relocated Guice-based Plexus shim
>
>
> Key: MNG-4807
> URL: http://jira.codehaus.org/browse/MNG-4807
> Project: Maven 2 & 3
> Issue Type: Task
> Components: Class Loading, Plugins and Lifecycle
>Affects Versions: 3.0-beta-3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-beta-4
>
>
> The Guice-based Plexus shim has been relocated from
> {{org.sonatype.spice:spice-inject-plexus}} to
> {{org.sonatype.sisu:sisu-inject-plexus}}, the artifact filter needs to
> account for this as well.
--
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-502) Multiple Parent-Links and additional module-link inherited wrong from parent
Multiple Parent-Links and additional module-link inherited wrong from parent Key: MSITE-502 URL: http://jira.codehaus.org/browse/MSITE-502 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.1.1 Reporter: Michael Wenig Attachments: siteInheritance.zip Attached is a couple of projects showing a problem with the site inheritance. The projects have the following structure: parentPom1 -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml) -> projectB (parentPom3) -> projectC (projectRoot with a submodule 'projectModule') I ran the following commands: parentPom1: install projectA: site site:attach-descriptor install projectB site install projectC site install I added the corresponding target-folders to the zip: projectA: generated correctly projectB: shows two(!) parent links: -> to parentPom1 (which is wrong and IMHO inherited out of the attached site-descriptor) -> to parentPom2 (which is correct) projectC (root): shows two(!) parent links: -> to parentPom1 (which is wrong and IMHO inherited out of the attached site-descriptor) -> to projectB (which is correct) shows two modules: -> dummyModule (the one of projectA which is wrong and IMHO inherited out of the attached site-descriptor) -> projectModule (correct) ==> I expected the parent-Menu to only contain the direct parent ==> I expected the modules menu to only contain modules of the pom and not the modules of a parent... Content of the attached site descriptor: http://maven.apache.org/DECORATION/1.0.1 http://maven.apache.org/xsd/decoration-1.0.1.xsd"; xmlns="http://maven.apache.org/DECORATION/1.0.1"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> I think the problem are the contained item-tags which are included in the sites of consumer projects. -- 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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[ http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235052#action_235052 ] Michael Wenig commented on MSITE-502: - I manually removed the two items from the site.xml in our nexus instance and the sites were generated correctly. I think the fix should be to remove the items from the site (but keep the menu-tag) before attaching the descriptor - or to remove the items on read onthefly > Multiple Parent-Links and additional module-link inherited wrong from parent > > > Key: MSITE-502 > URL: http://jira.codehaus.org/browse/MSITE-502 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.1.1 >Reporter: Michael Wenig > Attachments: siteInheritance.zip > > > Attached is a couple of projects showing a problem with the site inheritance. > The projects have the following structure: > parentPom1 > -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml) > -> projectB (parentPom3) > -> projectC (projectRoot with a submodule 'projectModule') > I ran the following commands: > parentPom1: install > projectA: site site:attach-descriptor install > projectB site install > projectC site install > I added the corresponding target-folders to the zip: > projectA: > generated correctly > projectB: > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to parentPom2 (which is correct) > projectC (root): > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to projectB (which is correct) > shows two modules: > -> dummyModule (the one of projectA which is wrong and IMHO inherited out of > the attached site-descriptor) > -> projectModule (correct) > ==> I expected the parent-Menu to only contain the direct parent > ==> I expected the modules menu to only contain modules of the pom and not > the modules of a parent... > Content of the attached site descriptor: > xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1 > http://maven.apache.org/xsd/decoration-1.0.1.xsd"; > xmlns="http://maven.apache.org/DECORATION/1.0.1"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > > > > > > > > > > I think the problem are the contained item-tags which are included in the > sites of consumer projects. -- 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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[ http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235057#action_235057 ] Michael Wenig commented on MSITE-502: - As a workaround I copied the generated site.xml, removed the two items and attach the copy using the buildhelper-plugin. This is not very nice but works for the moment (and also workaorunds MSITE-163) > Multiple Parent-Links and additional module-link inherited wrong from parent > > > Key: MSITE-502 > URL: http://jira.codehaus.org/browse/MSITE-502 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.1.1 >Reporter: Michael Wenig > Attachments: siteInheritance.zip > > > Attached is a couple of projects showing a problem with the site inheritance. > The projects have the following structure: > parentPom1 > -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml) > -> projectB (parentPom3) > -> projectC (projectRoot with a submodule 'projectModule') > I ran the following commands: > parentPom1: install > projectA: site site:attach-descriptor install > projectB site install > projectC site install > I added the corresponding target-folders to the zip: > projectA: > generated correctly > projectB: > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to parentPom2 (which is correct) > projectC (root): > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to projectB (which is correct) > shows two modules: > -> dummyModule (the one of projectA which is wrong and IMHO inherited out of > the attached site-descriptor) > -> projectModule (correct) > ==> I expected the parent-Menu to only contain the direct parent > ==> I expected the modules menu to only contain modules of the pom and not > the modules of a parent... > Content of the attached site descriptor: > xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1 > http://maven.apache.org/xsd/decoration-1.0.1.xsd"; > xmlns="http://maven.apache.org/DECORATION/1.0.1"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > > > > > > > > > > I think the problem are the contained item-tags which are included in the > sites of consumer projects. -- 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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[ http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235057#action_235057 ] Michael Wenig edited comment on MSITE-502 at 9/13/10 7:06 AM: -- As a workaround I copied the generated site.xml, removed the two items and attach the copy using the buildhelper-plugin. This is not very nice but works for the moment (and also workaorunds MSITE-163 / MSITE-417) was (Author: micha123): As a workaround I copied the generated site.xml, removed the two items and attach the copy using the buildhelper-plugin. This is not very nice but works for the moment (and also workaorunds MSITE-163) > Multiple Parent-Links and additional module-link inherited wrong from parent > > > Key: MSITE-502 > URL: http://jira.codehaus.org/browse/MSITE-502 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.1.1 >Reporter: Michael Wenig > Attachments: siteInheritance.zip > > > Attached is a couple of projects showing a problem with the site inheritance. > The projects have the following structure: > parentPom1 > -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml) > -> projectB (parentPom3) > -> projectC (projectRoot with a submodule 'projectModule') > I ran the following commands: > parentPom1: install > projectA: site site:attach-descriptor install > projectB site install > projectC site install > I added the corresponding target-folders to the zip: > projectA: > generated correctly > projectB: > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to parentPom2 (which is correct) > projectC (root): > shows two(!) parent links: > -> to parentPom1 (which is wrong and IMHO inherited out of the attached > site-descriptor) > -> to projectB (which is correct) > shows two modules: > -> dummyModule (the one of projectA which is wrong and IMHO inherited out of > the attached site-descriptor) > -> projectModule (correct) > ==> I expected the parent-Menu to only contain the direct parent > ==> I expected the modules menu to only contain modules of the pom and not > the modules of a parent... > Content of the attached site descriptor: > xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1 > http://maven.apache.org/xsd/decoration-1.0.1.xsd"; > xmlns="http://maven.apache.org/DECORATION/1.0.1"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > > > > > > > > > > I think the problem are the contained item-tags which are included in the > sites of consumer projects. -- 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: (MSITE-417) CLONE -The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235058#action_235058 ] Michael Wenig commented on MSITE-417: - Hint: MSITE-502 contains a workaround for this > CLONE -The modules menu is not inherited if the parent project has no modules > of its own > > > Key: MSITE-417 > URL: http://jira.codehaus.org/browse/MSITE-417 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0 > Environment: ubuntu linux / debian linux >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Attachments: MSITE-417.zip > > > if I have a site.xml in a parent project that contains the line ref="modules" inherit="top" /> it is not inherited by child projects. > works, as does parent. > This happens when the parent project has no modules of its own. -- 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-261) release:prepare should support flat directory multi-module projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235067#action_235067
]
Mike R. Haller commented on MRELEASE-261:
-
I'd like to share my use case with you to understand why people may have
'unusual' project structures.
I think that my problem is the same as the one in this issue, but not sure.
So, my apologizes if this does not fit 100% and should be posted to MRELEASE-516
We started with the following set up:
{code}
ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
ModuleC/trunk/pom.xml
{code}
These were more or less independent artifacts and the release process was just
releasing those three artifacts individually.
Every module's pom.xml has its own element.
After a while, additional modules were implemented and a common parent pom was
introduced, hence the structure became:
{code}
Parent/trunk/pom.xml
ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
...
ModuleY/trunk/pom.xml
ModuleZ/trunk/pom.xml
{code}
Now, the release process for many modules takes up a lot of time and the idea
is to aggregate all the releases into
a single release step from a release manager point of view. So, a reactor build
is put on top of the whole thing:
{code}
Everything/trunk/pom.xml (Modules: ModuleA, ModuleB ... ModuleZ)
ModuleA/trunk/pom.xml
ModuleB/trunk/pom.xml
...
ModuleY/trunk/pom.xml
ModuleZ/trunk/pom.xml
{code}
The Everything-pom.xml contains the modules:
{code}
ModuleA
ModuleB
...
ModuleY
ModuleZ
{code}
Then, all the trunks are checked out from SCM (SVN, using the svn:externals
property) into the local working copy, so they reflect the correct
structure without any 'trunk' folders or relative paths like "../ModuleA".
{code}
pom.xml (from Everything/trunk/pom.xml)
+ ModuleA/pom.xml
+ ModuleB/pom.xml
...
+ ModuleY/pom.xml
+ ModuleZ/pom.xml
{code}
Now, i'm trying to perform a release in the root of this folder, e.g. the
"Everything" project.
The reactor will prepare all modules, but unfortunately, the SVN tag of each
module is overwritten and becomes incorrect.
Each module should be committed to its own 'tags/' folder with name and version
of the module.
However, what actually happens is, the release plugin replaces all SCM URLS of
each module with the name of the Everything-pom.xml:
Actually in pom.xml.tag:
scm:svn:.../ModuleA/tags/Everything-1.0/ModuleA/trunk
Expected in pom.xml.tag: scm:svn:.../ModuleA/tags/ModuleA-1.0
> release:prepare should support flat directory multi-module projects
> ---
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
> Environment: linux / maven2 / svn
>Reporter: paul.whe...@gmail.com
>Assignee: Maria Odea Ching
> Fix For: 2.0
>
> Attachments: flatProject.main.patch, flatProject.test.patch,
> maven-release-issue.tar.gz, maven-release-issue.zip,
> MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch,
> MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png,
> PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MDEP-284) Get Mojo ignores the transitive attribute because of a typo in the parameter declaration
Get Mojo ignores the transitive attribute because of a typo in the parameter
declaration
Key: MDEP-284
URL: http://jira.codehaus.org/browse/MDEP-284
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Baptiste MATHUS
Assignee: Brian Fox
Attachments: maven-dependency-get-transitive.patch
[Note : "get" is missing as a component for MDEP jira.]
Due to a typo in the GetMojo code, transitive resolution doesn't work.
@parameter was set to {$transitive} instead of ${transitive}.
Thanks a lot.
PS : I tried providing the corresponding ITs, but didn't really manage to cope
with configuring the (stub) environment. I'm providing the unfinished code
anyway, since I think it might be missing not much. Feel free to wipe all ITs I
tried to initiate if it's simpler. I think I'll have a look at how you do it,
if you find time for that.
--
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: (MDEP-284) Get Mojo ignores the transitive attribute because of a typo in the parameter declaration
[
http://jira.codehaus.org/browse/MDEP-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Baptiste MATHUS updated MDEP-284:
-
Attachment: maven-dependency-get-transitive.patch
> Get Mojo ignores the transitive attribute because of a typo in the parameter
> declaration
>
>
> Key: MDEP-284
> URL: http://jira.codehaus.org/browse/MDEP-284
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Baptiste MATHUS
>Assignee: Brian Fox
> Attachments: maven-dependency-get-transitive.patch
>
>
> [Note : "get" is missing as a component for MDEP jira.]
> Due to a typo in the GetMojo code, transitive resolution doesn't work.
> @parameter was set to {$transitive} instead of ${transitive}.
> Thanks a lot.
> PS : I tried providing the corresponding ITs, but didn't really manage to
> cope with configuring the (stub) environment. I'm providing the unfinished
> code anyway, since I think it might be missing not much. Feel free to wipe
> all ITs I tried to initiate if it's simpler. I think I'll have a look at how
> you do it, if you find time for that.
--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
Passing multiple parameters to Java 6 annotation processors with javac does not
work
Key: MCOMPILER-135
URL: http://jira.codehaus.org/browse/MCOMPILER-135
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1, Windows
Reporter: Sean Patrick Floyd
I have an annotation processor that supports multiple parameters and I have
found that there is no way to set more than one of them at any given time from
the Maven Compiler Plugin,
Here's my setup.
{code:xml}
true
org.apache.maven.plugins
maven-compiler-plugin
2.3.1
1.6
1.6
-AaddResDir=src/main/webapp
-Averbose=true
{code}
Javac needs the parameters added as separate Strings
{code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
but the Compiler Plugin generates this code:
{code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
which Javac will parse as
{code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
The map version "" is of no help either, because this
{code}true
src/main/webapp{code}
will generate the output
{code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
while this
{code}
{code}
is not well-formed XML.
Stepping through the compiler argument generation with the debugger I have not
found a way to post-process the arguments, so please add a way to support
multiple APT parameters because this is a major show-stopper.
--
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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-502:
--
Description:
Attached is a couple of projects showing a problem with the site inheritance.
The projects have the following structure:
parentPom1
-> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
-> projectB (parentPom3)
-> projectC (projectRoot with a submodule 'projectModule')
I ran the following commands:
parentPom1: install
projectA: site site:attach-descriptor install
projectB site install
projectC site install
I added the corresponding target-folders to the zip:
projectA:
generated correctly
projectB:
shows two(!) parent links:
-> to parentPom1 (which is wrong and IMHO inherited out of the attached
site-descriptor)
-> to parentPom2 (which is correct)
projectC (root):
shows two(!) parent links:
-> to parentPom1 (which is wrong and IMHO inherited out of the attached
site-descriptor)
-> to projectB (which is correct)
shows two modules:
-> dummyModule (the one of projectA which is wrong and IMHO inherited out of
the attached site-descriptor)
-> projectModule (correct)
==> I expected the parent-Menu to only contain the direct parent
==> I expected the modules menu to only contain modules of the pom and not the
modules of a parent...
Content of the attached site descriptor:
{code:xml}
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
{code}
I think the problem are the contained item-tags which are included in the sites
of consumer projects.
was:
Attached is a couple of projects showing a problem with the site inheritance.
The projects have the following structure:
parentPom1
-> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
-> projectB (parentPom3)
-> projectC (projectRoot with a submodule 'projectModule')
I ran the following commands:
parentPom1: install
projectA: site site:attach-descriptor install
projectB site install
projectC site install
I added the corresponding target-folders to the zip:
projectA:
generated correctly
projectB:
shows two(!) parent links:
-> to parentPom1 (which is wrong and IMHO inherited out of the attached
site-descriptor)
-> to parentPom2 (which is correct)
projectC (root):
shows two(!) parent links:
-> to parentPom1 (which is wrong and IMHO inherited out of the attached
site-descriptor)
-> to projectB (which is correct)
shows two modules:
-> dummyModule (the one of projectA which is wrong and IMHO inherited out of
the attached site-descriptor)
-> projectModule (correct)
==> I expected the parent-Menu to only contain the direct parent
==> I expected the modules menu to only contain modules of the pom and not the
modules of a parent...
Content of the attached site descriptor:
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
I think the problem are the contained item-tags which are included in the sites
of consumer projects.
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> =
[jira] Closed: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MSITE-502.
-
Resolution: Not A Bug
The plugin is doing exactly what you are telling it to. However I think that
you have misunderstood the usage of "ref"-menus. A ref-menu should not have any
items in it, because the menu will have menu items dynamically inserted into
it. When you add
{code:xml}
{code}
to the ref="parent" menu, you are saying that all parent menus should have the
parentPom1 item in them.
And when you add
{code:xml}
{code}
to the ref="modules" menu, you are saying that all module menus should have the
dummyModule item in them.
Your complete site.xml should look like this:
{code:xml}
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
{code}
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Patrick Floyd updated MCOMPILER-135:
-
Attachment: AbstractCompilerMojo.java.patch
Here is a Patch for org.apache.maven.plugin.AbstractCompilerMojo that enables
the following code:
{code}
src/main/webapp
true
{code}
There should probably be a check whether source version is at least 1.6 and
compiler id is javac, though.
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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] Reopened: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Wenig reopened MSITE-502:
-
Hi Dennis,
I know that there should be no content in menu-refs. This *IS* the bug.
The original site.xml (in projectA:src/site):
http://maven.apache.org/DECORATION/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0
http://maven.apache.org/xsd/decoration-1.0.0.xsd";>
gets attached as:
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
Which leads to the problem!
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235093#action_235093
]
Michael Wenig commented on MSITE-502:
-
I assume that first a site.xml is generated for the content of the project
itself and then gets attached (and not the original site.xml) - please have
alook into the zip contents. I do not think that I did a misconfiguration - and
AFAIR it was working correctly in 2.0.1
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235095#action_235095
]
Pascal Thivent edited comment on MCOMPILER-135 at 9/13/10 12:04 PM:
Looks similar to MCOMPILER-130
was (Author: pthivent):
Looks like http://jira.codehaus.org/browse/MCOMPILER-130
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235095#action_235095
]
Pascal Thivent commented on MCOMPILER-135:
--
Looks like http://jira.codehaus.org/browse/MCOMPILER-130
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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: (MNG-4808) Maven does not resolve variables within a plugin's
Maven does not resolve variables within a plugin's
-
Key: MNG-4808
URL: http://jira.codehaus.org/browse/MNG-4808
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 2.2.1
Environment: Ubuntu 10.04 Lucid, w/ Maven 2.2.1 on 64bit system.
Reporter: Sven Ehlert
Attachments: log, pom.xml
I have a Maven project with a Hudson profile, to be run when run under Hudson
CI. The only relevant part of the Hudson profile is that the build should not
fail when there are checksyle or findbugs errors. To achieve this, I've defined
goal variables for both Checkstyle and Findbugs, see the attached (simplified)
POM.
just run mvn:clean, and you'll get:
'${checkstyle.goal}' was specified in an execution, but not found in the plugin
(and later also for findbugs)
The variable doesn't seem to be properly resolved. What's really strange, if I
do mvn effective-pom, it all looks as I'd expect it, i.e it prints out
check instead of ${checkstyle.goal}
This used to work perfectly under Maven 2.0.9, i.e. it would run
checkstyle:check normally, but checkstyle:checkstyle under Hudson. Seems to be
a regression.
--
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: (MNG-4808) Maven does not resolve variables within a plugin's
[
http://jira.codehaus.org/browse/MNG-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4808.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
> Maven does not resolve variables within a plugin's
> -
>
> Key: MNG-4808
> URL: http://jira.codehaus.org/browse/MNG-4808
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.2.1
> Environment: Ubuntu 10.04 Lucid, w/ Maven 2.2.1 on 64bit system.
>Reporter: Sven Ehlert
>Assignee: Benjamin Bentmann
> Attachments: log, pom.xml
>
>
> I have a Maven project with a Hudson profile, to be run when run under Hudson
> CI. The only relevant part of the Hudson profile is that the build should not
> fail when there are checksyle or findbugs errors. To achieve this, I've
> defined goal variables for both Checkstyle and Findbugs, see the attached
> (simplified) POM.
> just run mvn:clean, and you'll get:
> '${checkstyle.goal}' was specified in an execution, but not found in the
> plugin
> (and later also for findbugs)
> The variable doesn't seem to be properly resolved. What's really strange, if
> I do mvn effective-pom, it all looks as I'd expect it, i.e it prints out
> check instead of ${checkstyle.goal}
> This used to work perfectly under Maven 2.0.9, i.e. it would run
> checkstyle:check normally, but checkstyle:checkstyle under Hudson. Seems to
> be a regression.
--
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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235095#action_235095
]
Pascal Thivent edited comment on MCOMPILER-135 at 9/13/10 12:16 PM:
Looks similar to MCOMPILER-130 (but the map syntax won't help indeed).
was (Author: pthivent):
Looks similar to MCOMPILER-130
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235090#action_235090
]
Michael Wenig edited comment on MSITE-502 at 9/13/10 12:15 PM:
---
Hi Dennis,
I know that there should be no content in menu-refs. This *IS* the bug.
The *original site.xml (in projectA:src/site)*:
http://maven.apache.org/DECORATION/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0
http://maven.apache.org/xsd/decoration-1.0.0.xsd";>
*gets attached* as:
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
Which leads to the problem!
was (Author: micha123):
Hi Dennis,
I know that there should be no content in menu-refs. This *IS* the bug.
The original site.xml (in projectA:src/site):
http://maven.apache.org/DECORATION/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0
http://maven.apache.org/xsd/decoration-1.0.0.xsd";>
gets attached as:
http://maven.apache.org/DECORATION/1.0.1
http://maven.apache.org/xsd/decoration-1.0.1.xsd";
xmlns="http://maven.apache.org/DECORATION/1.0.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
Which leads to the problem!
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (SUREFIRE-646) Overlapping -D's for surefire and failsafe make it hard to control combination
Overlapping -D's for surefire and failsafe make it hard to control combination -- Key: SUREFIRE-646 URL: http://jira.codehaus.org/browse/SUREFIRE-646 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 2.6 Reporter: Benson Margulies I have a project with both surefire unit tests and failsafe integration tests. This works until I try to start controlling things from command line. 1. Both plugins respect -DskipTests. failsafe has skipITs, but surefire does not seem to have a corresponding property that just skips the unit tests, not the integration tests. 2. When I use -Dtest= and specify an integration test, SUREFIRE runs it before failsafe gets a chance, and of course it fails because the pre-integration-test phase hasn't set up. -- 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: (MENFORCER-107) An enforcer rule that demands developers ensure all dependency (and transitive dependency) version numbers converge
An enforcer rule that demands developers ensure all dependency (and transitive dependency) version numbers converge --- Key: MENFORCER-107 URL: http://jira.codehaus.org/browse/MENFORCER-107 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-beta-2 Reporter: Rex Hoffman Attachments: noconflicts.tar.gz Includes it cases. Currently formatted as it's own maven project. No tricks used in the maven compilation, so it should be trivial to merge. Copy the class and src/it cases, though the dependencies will change slightly (don't hard code the enforcer rule version) and remove the other dependency. Included an apt page that explains the rule. Should also be be almost a cut and past. Will have to do the same artifact fixes to the usage section. Marked as major as there is no good existing workaround Marking as a patch, because it's close. If you want me to prep it as a straight patch, please point me to the best branch... All probably between 15 and 30 minutes. -- 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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235108#action_235108
]
Dennis Lundberg commented on MSITE-502:
---
Michael,
I've played around with your sample project and I think I have found the cause
of your problems.
You are not using a standard Maven parent/child layout, where the child is in a
subdirectory of the parent. When using a structure like yours, often referred
to as a flat layout, you need to specify the relative path to the parent. That
is, unless the relative path is ../pom.xml then you should specify it.
For example the POM for projectA have this parent declaration:
{code:xml}
corporateGroup
parentPom1
0.1-SNAPSHOT
../parentPom1/pom.xml
{code}
and for projectB it should look like this:
{code:xml}
corporateGroup
projectA
0.1-SNAPSHOT
../projectA/pom.xml
{code}
and finally for projectC it should look like this:
corporateGroup
projectB
0.1-SNAPSHOT
../projectB/pom.xml
{code}
I think that not having these is messing things up for the Site Plugin. Adding
them seems to solve your issues for me. Could you give it a try?
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235108#action_235108
]
Dennis Lundberg edited comment on MSITE-502 at 9/13/10 3:10 PM:
Michael,
I've played around with your sample project and I think I have found the cause
of your problems.
You are not using a standard Maven parent/child layout, where the child is in a
subdirectory of the parent. When using a structure like yours, often referred
to as a flat layout, you need to specify the relative path to the parent. That
is, unless the relative path is ../pom.xml then you should specify it.
For example the POM for projectA have this parent declaration:
{code:xml}
corporateGroup
parentPom1
0.1-SNAPSHOT
../parentPom1/pom.xml
{code}
and for projectB it should look like this:
{code:xml}
corporateGroup
projectA
0.1-SNAPSHOT
../projectA/pom.xml
{code}
and finally for projectC it should look like this:
{code:xml}
corporateGroup
projectB
0.1-SNAPSHOT
../projectB/pom.xml
{code}
I think that not having these is messing things up for the Site Plugin. Adding
them seems to solve your issues for me. Could you give it a try?
was (Author: dennislundberg):
Michael,
I've played around with your sample project and I think I have found the cause
of your problems.
You are not using a standard Maven parent/child layout, where the child is in a
subdirectory of the parent. When using a structure like yours, often referred
to as a flat layout, you need to specify the relative path to the parent. That
is, unless the relative path is ../pom.xml then you should specify it.
For example the POM for projectA have this parent declaration:
{code:xml}
corporateGroup
parentPom1
0.1-SNAPSHOT
../parentPom1/pom.xml
{code}
and for projectB it should look like this:
{code:xml}
corporateGroup
projectA
0.1-SNAPSHOT
../projectA/pom.xml
{code}
and finally for projectC it should look like this:
corporateGroup
projectB
0.1-SNAPSHOT
../projectB/pom.xml
{code}
I think that not having these is messing things up for the Site Plugin. Adding
them seems to solve your issues for me. Could you give it a try?
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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-503) Site validation doesn't run against xml files processed by velocity
Site validation doesn't run against xml files processed by velocity --- Key: MSITE-503 URL: http://jira.codehaus.org/browse/MSITE-503 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Mike Youngstrom If I turn on "validate" on my site plugin it correctly validates all of my *.xml files. However, if I preprocess that xml file with velocity (files named *.xml.vm). Then validation doesn't appear to run on these velocity processed xdoc files. To reproduce rename an xdoc file to xml.vm, give it a validation error and see if the "validate" configuration catches it. -- 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: (MPDF-41) with maven 3 pdf failure if reporting section is not empty
with maven 3 pdf failure if reporting section is not empty -- Key: MPDF-41 URL: http://jira.codehaus.org/browse/MPDF-41 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.2 Reporter: Olivier Lamy The current mojo use removed methods in maven 3. -- 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: (MPDF-41) with maven 3 pdf failure if reporting section is not empty
[ http://jira.codehaus.org/browse/MPDF-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPDF-41. Resolution: Fixed Fix Version/s: 1.2 fixed [rev 996688|URL: http://svn.apache.org/viewvc?rev=996688&view=rev] > with maven 3 pdf failure if reporting section is not empty > -- > > Key: MPDF-41 > URL: http://jira.codehaus.org/browse/MPDF-41 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.2 > > > The current mojo use removed methods in maven 3. -- 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-4751) Snapshot version not resolved for version range
[ http://jira.codehaus.org/browse/MNG-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235121#action_235121 ] Benjamin Bentmann commented on MNG-4751: FYI, I sent a proposal to the dev thread [Re: snapshot range changes in m3|http://www.mail-archive.com/d...@maven.apache.org/msg85742.html], feedback appreciated. > Snapshot version not resolved for version range > --- > > Key: MNG-4751 > URL: http://jira.codehaus.org/browse/MNG-4751 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0-beta-1 > Environment: linux x86_64, sun java 1.6.0_14 >Reporter: Brian Kramer >Priority: Blocker > Attachments: snapshot_dep.zip > > > Even with a snapshot dependency in the pom, a release version is included in > the classpath for compilation. > This happens when a mid-level dependency and the top-level project both > depend on the same artifact. The mid-level dependency selects a range of > valid versions which includes the snapshot version and the top-level project > depends explicitly on the snapshot version. > This is a regression from 2.2.1 > To reproduce: > 1. Release/deploy/install v1.0 of tlib > 2. deploy v1.1-SNAPSHOT of tlib > 3. Release/deploy/install v1.0 of tlib2 > 4. Try to compile tapp -- 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: (MSITE-423) item hrefs not relativised properly when inherited by child modules
[ http://jira.codehaus.org/browse/MSITE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Huss updated MSITE-423: -- Attachment: doxia-sitetools.patch Added Unit-Test to doxia-sitetools which demonstrates the problem with relative file URLs. > item hrefs not relativised properly when inherited by child modules > --- > > Key: MSITE-423 > URL: http://jira.codehaus.org/browse/MSITE-423 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.1 > Environment: Linux, JDK 1.6.0_07, Maven 2.1.0 >Reporter: Robert Davey > Attachments: doxia-sitetools.patch, site-plugin_link-problem.tar.gz > > > See attachment for reproducible minimal case. > I have a multi-module project, for the sake of argument laid out thus: > * parent > ** pom.xml > * module1 > ** pom.xml > ** src/site/site.xml > ** apt/index.apt > > ** submodule1 >*** pom.xml >*** src/site/site.xml >*** apt/index.apt > I specify some links in our parent POM that I want to be inherited by all > child multi-modules. I would hope these links would always point to the > relevant html files in the super parent project for all children, no matter > the nesting level. > > > > > > These links work fine for the super parent menu. The same problem, outlined > below, is apparent whether the links are prefixed by "/" or "./" > When navigating down to module1, all the href links become: > ../module1 > Navigating again down to submodule1 of module1, the links become (or > something equally wacky): > ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../submodule1 > All the pom.xml files in each module refer to the staged url correctly, and > these don't seem to make any difference to the eventual href whatsoever... > e.g. > parent: http://server/ > module1: http://server/module1 > submodule1: http://server/module1/submodule1 -- 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: (MSITE-423) item hrefs not relativised properly when inherited by child modules
[ http://jira.codehaus.org/browse/MSITE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235122#action_235122 ] Roland Huss commented on MSITE-423: --- I encounter the same problem and I could isolate it to be an issue with PathUtils.getRelativePath() in doxia-sitetools. The issue is, that for *file* URLs, which are used by site:stage to setup the links among sub-modules, the relative path calculations seemed to be flawed. I don't have a fix yet, but I've added a unit test which demonstrates this problem in isolation. The patch attached is against doxia-sitetools, version 1.1.3 (which is used by maven-site-plugin 3.x) > item hrefs not relativised properly when inherited by child modules > --- > > Key: MSITE-423 > URL: http://jira.codehaus.org/browse/MSITE-423 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.1 > Environment: Linux, JDK 1.6.0_07, Maven 2.1.0 >Reporter: Robert Davey > Attachments: doxia-sitetools.patch, site-plugin_link-problem.tar.gz > > > See attachment for reproducible minimal case. > I have a multi-module project, for the sake of argument laid out thus: > * parent > ** pom.xml > * module1 > ** pom.xml > ** src/site/site.xml > ** apt/index.apt > > ** submodule1 >*** pom.xml >*** src/site/site.xml >*** apt/index.apt > I specify some links in our parent POM that I want to be inherited by all > child multi-modules. I would hope these links would always point to the > relevant html files in the super parent project for all children, no matter > the nesting level. > > > > > > These links work fine for the super parent menu. The same problem, outlined > below, is apparent whether the links are prefixed by "/" or "./" > When navigating down to module1, all the href links become: > ../module1 > Navigating again down to submodule1 of module1, the links become (or > something equally wacky): > ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../submodule1 > All the pom.xml files in each module refer to the staged url correctly, and > these don't seem to make any difference to the eventual href whatsoever... > e.g. > parent: http://server/ > module1: http://server/module1 > submodule1: http://server/module1/submodule1 -- 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: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235125#action_235125
]
Per Hedman commented on MCOMPILER-135:
--
I believe that this workaround could work, add this to the configuration:
true
and change this:
-AaddResDir=src/main/webapp"
"-Averbose=true
but I can't confirm right now. I only have 1.5 at home.
It's related to [MCOMPILER-130|http://jira.codehaus.org/browse/MCOMPILER-130]
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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: (ARCHETYPE-202) Can't download archetype-catalog.xml via proxy connection
[
http://jira.codehaus.org/browse/ARCHETYPE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235128#action_235128
]
Herve Boutemy commented on ARCHETYPE-202:
-
real user test is ok:
http://maven.40175.n5.nabble.com/Archetype-plugin-2-0-alpha-6-release-tp2807769p2837741.html
thanks to the reporter
> Can't download archetype-catalog.xml via proxy connection
> -
>
> Key: ARCHETYPE-202
> URL: http://jira.codehaus.org/browse/ARCHETYPE-202
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0-alpha-2
> Environment: Windows XP 2002 SP3, Maven version 2.0.9, Java 1.6.0_06,
> internet connection via proxy.
>Reporter: Leonid E. Egorov
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.0
>
> Attachments: ARCHETYPE-202-archetype-common.patch
>
>
> According "Your first Cocoon application using Maven 2"
> (http://cocoon.apache.org/2.2/1159_1_1.html) after execution:
> {noformat}
> mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org user
> should enter into dialog about selecting archetype but nothing happen. Error
> message:
> D:\MySolutions\java\cocoon\demo>mvn archetype:generate
> -DarchetypeCatalog=http://cocoon.apache.org
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetype:generate] (aggregator-style)
> [INFO]
>
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [archetype:generate]
> [INFO] Generating project in Interactive mode
> [WARNING] Error reading archetype catalog http://cocoon.apache.org
> org.apache.maven.wagon.TransferFailedException: Error transferring file
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104)
> at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
> at
> org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74)
> at
> org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:203)
> at
> org.apache.maven.archetype.ui.DefaultArchetypeSelector.getArchetypesByCatalog(DefaultArchetypeSelector.java:249)
> at
> org.apache.maven.archetype.ui.DefaultArchetypeSelector.selectArchetype(DefaultArchetypeSelector.java:74)
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:180)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227)
> 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:287)
> 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.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: j
[jira] Commented: (MCOMPILER-135) Passing multiple parameters to Java 6 annotation processors with javac does not work
[
http://jira.codehaus.org/browse/MCOMPILER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235159#action_235159
]
Sean Patrick Floyd commented on MCOMPILER-135:
--
Per: yes, I thought of that also, but it would be an ugly option. For one
thing: it would not allow me to debug the annotation processor (not without
lots of additional configuration anyway)
> Passing multiple parameters to Java 6 annotation processors with javac does
> not work
>
>
> Key: MCOMPILER-135
> URL: http://jira.codehaus.org/browse/MCOMPILER-135
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: JDK 1.6, Maven 2.2.1, Maven-Compiler-Plugin 2.3.1,
> Windows
>Reporter: Sean Patrick Floyd
> Attachments: AbstractCompilerMojo.java.patch
>
>
> I have an annotation processor that supports multiple parameters and I have
> found that there is no way to set more than one of them at any given time
> from the Maven Compiler Plugin,
> Here's my setup.
> {code:xml}
>
> true
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.1
>
> 1.6
> 1.6
> -AaddResDir=src/main/webapp
> -Averbose=true
>
>
> {code}
> Javac needs the parameters added as separate Strings
> {code}[ ... , "-AaddResDir=src/main/webapp", "-Averbose=true"]{code}
> but the Compiler Plugin generates this code:
> {code}[ ... , "-AaddResDir=src/main/webapp -Averbose=true"]{code}
> which Javac will parse as
> {code}key:"addResDir" value="src/main/webapp -Averbose=true"{code}
> The map version "" is of no help either, because this
> {code}true
> src/main/webapp{code}
> will generate the output
> {code}[... , "-Averbose", "true", "-AaddResDir", "src/main/webapp"]{code}
> while this
> {code}
> {code}
> is not well-formed XML.
> Stepping through the compiler argument generation with the debugger I have
> not found a way to post-process the arguments, so please add a way to support
> multiple APT parameters because this is a major show-stopper.
--
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
