Looks to be the maven-shade-plugin that is doing the property substitution. They built with Maven 3.1.0 (I had been worried it was a 2.1.0 or 2.2.0 issue)
On 21 August 2013 14:05, Olivier Lamy <[email protected]> wrote: > On 20 August 2013 22:16, Arnaud Héritier <[email protected]> wrote: > > Transitively it won't be propagated AFAIK. You want to reuse it by > > inheritance (and from a Pom out of your current project) ? > > ?? No it's resolved. > Sample: > git clone https://code.google.com/r/alexeagle-guava/ guava > cd guava > > guava module has a dependency to: > > <dependency> > <groupId>com.google.errorprone</groupId> > <artifactId>error_prone_core</artifactId> > <version>1.0</version> > </dependency> > > See the pom here: > > https://oss.sonatype.org/content/repositories/comgoogleerrorprone-1000/com/google/errorprone/error_prone_core/1.0/error_prone_core-1.0.pom > > He has a dependency to: > > <dependency> > <groupId>openjdk</groupId> > <artifactId>tools</artifactId> > <version>1.6</version> > <scope>system</scope> > <systemPath> > /usr/local/buildtools/java/jdk7-google-v5-32/jre/../lib/tools.jar > </systemPath> > </dependency> > > whereas the original pom ( > https://code.google.com/p/error-prone/source/browse/core/pom.xml ) > says: > > <profile> > <id>tools.jar</id> > <activation> > <!-- Our release turns the systemPath into an absolute path, > which doesn't resolve > for downstream dependent projects. So just drop this dep > in that case. > See issue #18 --> > <file> > <exists>${java.home}/../lib/tools.jar</exists> > </file> > </activation> > <dependencies> > <dependency> > <groupId>openjdk</groupId> > <artifactId>tools</artifactId> > <version>1.6</version> > <scope>system</scope> > <systemPath>${java.home}/../lib/tools.jar</systemPath> > </dependency> > </dependencies> > </profile> > > So except adding an exclusion to openjdk:tools it doesn't work. > which is pain > > Any solutions for that? > > > > > > > I always used / saw such system dep usage in low level module. I don't > > know how we could allow this but I already had such issue with the > > java.home interpolation in the past. It is annoying to not be able to > > control what we filter. > > > > --------- > > Arnaud > > > > Le 20 août 2013 à 13:43, Olivier Lamy <[email protected]> a écrit : > > > >> Hi, > >> I have an issue I don't know how to fix :-( > >> > >> The goal is to have a dependency on tools.jar. > >> This activated by a profile > >> > >> <profile> > >> <id>tools.jar</id> > >> <activation> > >> <file> > >> <exists>${java.home}/../lib/tools.jar</exists> > >> </file> > >> </activation> > >> <dependencies> > >> <dependency> > >> <groupId>openjdk</groupId> > >> <artifactId>tools</artifactId> > >> <version>1.6</version> > >> <scope>system</scope> > >> <systemPath>${java.home}/../lib/tools.jar</systemPath> > >> </dependency> > >> </dependencies> > >> </profile> > >> > >> So all is fine at this point. > >> > >> But now the installed/deployed pom add this dependency in the > >> dependencies section. > >> That's something I definitely don't want because the ${java.home} is > >> interpolated so except everybody use the same as me that won't work > >> and furthermore I don't need it for using this library. > >> > >> Any idea? > >> > >> Thanks > >> -- > >> Olivier Lamy > >> Ecetera: http://ecetera.com.au > >> http://twitter.com/olamy | http://linkedin.com/in/olamy > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
