Yes, then it is probably appropriate for the Maven Compiler plugin to support endorsed libraries. I can't remember if it always forks, but if forking isn't specified, an error should be thrown when endorsed libraries are used.
Paul On Thu, Nov 12, 2009 at 3:19 PM, Daniel Kulp <dk...@apache.org> wrote: > On Thu November 12 2009 2:22:51 pm Paul Benedict wrote: >> Is it possible to add endorsed libraries programatically? I thought >> the JDK grabbed all its endorsements from jdk_home\lib\ext > > When you fork a jvm (javac fork or surefire set to fork), you can specify a > system property of other places to look. Thus, then endorsed stuff would > only apply when those are set to fork. > > Dan > > >> >> Paul >> >> On Thu, Nov 12, 2009 at 12:48 PM, Daniel Kulp <dk...@apache.org> wrote: >> > Just to follow up on this, it looks like the two main options are: >> > >> > 1) Add an "endorsed" scope. What would be involved with that? What >> > would happen when a 2.0.10/2.2.1 maven version hits such a scope? This >> > seems to be a "maven core" thing with updates needed to a bunch of core >> > things. Not a BAD thing, especially for 3.0 or something, but increases >> > the complexity. >> > >> > 2) maven-endorsed-plugin - similar to the toolchains thing, but provides >> > special endorsing capabilities. Would be done in parts. The plugin >> > plus updates to surefire and compiler (and others that may need it). >> > >> > >> > (2) can definitely be made to work with existing versions of maven, but >> > (1) definitely seems "cleaner". (1) would also allow endorsements to be >> > handled from transitive deps, although I'm not sure if that's a good >> > thing or not. >> > >> > :-) >> > >> > Anyway, what are peoples thoughts? I think after thanksgiving, I may >> > need to start working on bits of this so I'd like to get peoples thoughts >> > and ideas before then. >> > >> > Dan >> > >> > On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: >> >> While at ApacheCon last week, I talked to Jarek Gawor a bit and then >> >> followed up with a quick conversation with Brett about a problem that >> >> is soon going to hit CXF/Axis2/Geronimo. >> >> >> >> Basically, we're going to need a mechanism to easily "endorse" a few api >> >> jars when we call javac and when surefire runs. I'm ok with >> >> limiting the endorsing to when those plugins are in their "fork" mode. >> >> There are a few options that could be pursued: >> >> >> >> 1) Require all developers to drop some jars in jre/lib/endorsed. That >> >> really sucks. Not exactly viable, IMO. >> >> >> >> 2) Require all devs to copy the jars someplace and add >> >> -Djava.endorsed.dirs=.. to their MAVEN_OPTS. Also sucks. >> >> >> >> 3) In all modules, configure dependency:copy to copy the artifacts into >> >> a dir in target, then add the -D thing as system flags for compiler >> >> plugin and surefire. This is better than (2) as it can be all automatic >> >> in the poms, but it's a ton of configuration if dealing with a lot of >> >> poms and projects and such. >> >> >> >> 4) Add some mechanism to compiler and surefire (and maybe others) to do >> >> some of (3) automatically. I'm thinking something like: >> >> >> >> <plugin> >> >> <groupId>org.apache.maven.plugins</groupId> >> >> <artifactId>maven-compiler-plugin</artifactId> >> >> <configuration> >> >> <endorsedArtifacts> >> >> <endorsedArtifact> >> >> <groupId>...</groupId> >> >> <artifactId>...</artifactId> >> >> <version>....</version> >> >> </endorsedArtifact> >> >> </endorsedArtifacts> >> >> </configuration> >> >> </plugin> >> >> >> >> and similar configuration for surefire. Maybe make <version> optional >> >> and it would pick up a version from a dependency. >> >> >> >> 5) Maybe some extension to the ToolChains stuff (which I don't know >> >> enough about, need to dig further if this is viable) to handle this. >> >> >> >> Anyway, does anyone have any other thoughts? >> > >> > -- >> > Daniel Kulp >> > dk...@apache.org >> > http://www.dankulp.com/blog >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
