[jira] (MCOMPILER-202) Plugin dependencies not added to compiler classpath with javax.tools.Compiler
[
https://jira.codehaus.org/browse/MCOMPILER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322547#comment-322547
]
Thomas Broyer commented on MCOMPILER-202:
-
Note: Dagger now workarounds the issue:
https://github.com/square/dagger/pull/190
The steps to reproduce thus become:
1. clone https://github.com/square/dagger/
2. edit {{examples/simple/pom.xml}} and remove {{forceJavacCompilerUse}} (or
set it to {{false}})
3. {{mvn package}}
> Plugin dependencies not added to compiler classpath with javax.tools.Compiler
> -
>
> Key: MCOMPILER-202
> URL: https://jira.codehaus.org/browse/MCOMPILER-202
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Maven 3.0.4, Ubuntu 12.10, OpenJDK 6u27 (Ubuntu
> package), OpenJDK 7u15 (Ubuntu package), Oracle JDK 6u27, Oracle JDK 8
> (1.8.0-ea-b81)
>Reporter: Thomas Broyer
>
> Dependencies added to the maven-compiler-plugin used to be added to the
> compiler classpath with previous versions (tested with 2.4, 2.5 and 2.5.1)
> but no longer are with 3.0. This was very useful for annotation processors,
> that shouldn't affect dependency mediation in downstream projects.
> This seems to be due to the switch to {{javax.tools}} as setting
> {{forceJavacCompilerUse}} to {{true}} works around the issue.
> To reproduce:
> 1. clone https://github.com/square/dagger/
> 2. edit examples/simple/pom.xml and move the {{dagger-compiler}} dependency
> into the {{maven-compiler-plugin}}, and set the m-c-p version to 3.0
> 3. {{mvn package}}
> *Expected behavior:*
> sources should be generated into {{target/generated-sources/annotations}} and
> there should be {{xxx$InjectAdapter}} and {{xxx$ModuleAdapter}} classes in
> {{target/classes}}.
> Now change the m-c-p version to 2.5.1 or set {{forceJavacCompilerUse}} to
> {{true}}: behavior is as expected.
> Ideally, we'd want MCOMPILER-134 with an explicit {{processorpath}}.
> See also the discussion at https://github.com/square/dagger/pull/182 which
> lead me to create this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322545#comment-322545
]
Lennart Jorelid commented on MSITE-669:
---
Folks ... AFAICT this bug prevents anyone from staging a site unless the parent
pom is identical to the reactor parent pom.
Presuming that we have a maintainer on the maven-site-plugin, scheduling this
for release [or commenting on the patch] would be greatly appreciated.
Any takers?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jorelid
>Assignee: Lukas Theussl
> Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
> msite_669_v4.patch, nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322540#comment-322540 ] Sergei Ivanov commented on MNG-3092: @Kunalkumar: can you please illustrate the potential "parent POM" problem with an example? I can't see a problem there, but perhaps I am missing the obvious. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
