Thanks! I believe I have to look into this project that has a dependency to tools.jar. Most likely they should execute on a JDK (and not a JRE) instead of bundling the tools jar.
/Anders On Sun, Dec 23, 2012 at 10:32 PM, Benson Margulies <[email protected]>wrote: > 1. As Jeff says, it won't work. > > 2. It violates the terms of the JDK license, most likely. > > > > On Sun, Dec 23, 2012 at 1:17 PM, Jeff MAURY <[email protected]> > wrote: > > I don't think you should as there are probably some differences between > > versions of the JDK > > > > Regards > > Jeff MAURY > > > > > > > > On Fri, Dec 21, 2012 at 11:20 AM, Anders Hammar <[email protected]> > wrote: > > > >> So far I've managed the few situations where tools.jar (included in the > >> JDK) is needed by using the deprecated system scope and point at a local > >> tools.jar file. Up until now it's just been used in build time by > plugins, > >> but now I've run into a case where it's an actual dependency and > therefore > >> it could cause issues. > >> > >> Normally, artifacts should be in the repo but I'm wondering if there are > >> any problems adding this one to an internal repo? Is it platform neutral > >> for example? > >> It's a strictly internal repo so I think we can ignore any license > problems > >> by adding it to the repo. > >> > >> /Anders > >> > > > > > > > > -- > > Jeff MAURY > > > > > > "Legacy code" often differs from its suggested alternative by actually > > working and scaling. > > - Bjarne Stroustrup > > > > http://www.jeffmaury.com > > http://riadiscuss.jeffmaury.com > > http://www.twitter.com/jeffmaury > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
