On Nov 6, 2007 4:35 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 6 Nov 07, at 4:00 AM 6 Nov 07, Milos Kleint wrote: > > > Hello, > > > > I've got a working prototype of the toolchains proposal. I'm able to > > define > > the jdk toolchains and have them used in a project. Works with patched > > compiler, surefire, javadoc plugins. > > details are at http://docs.codehaus.org/display/MAVEN/Toolchains > > > > issues for resolution: > > 1. currently using build-context, I heard stories about it going away. > > My only concern with the build-context, and John can counters as he > deems fit, but it's hard to tell where through the core of Maven the > context actually pops out. You still need to inspect the session, but > the session would be the one place that you could look to see what is > changing as it passes through the core. The rub right now is that many > components internally are not setup to use a session. That's my > opinion: that the session passing through the core could just as > easily serve as a build context it's just architecturally the context > is easier to wormhole through the code.
Possibly true. In order to move the toolchains code to session, we would need a way to serialize/deserialize Objects. The actual live instances cannot be used due to plugun classloading. > > > > > > 2. due to 1. only works in 2.1, need to make sure it works in 2.0.x > > as well. > > With all the parts of the internals that you might need to touch even > if we weren't using the build context I think it would be hard in 2.0.x. >From Maven internals, I'm using just the buildcontext which also doesn't have many dependencies on maven internals. it seems to require a newer version of plexus though. For this reason the buildcontext sounds like an ideal backward compatible solution, unlike the dependency on MavenSession enhancements because that one deems toolchains in 2.0.x impossible. small part also using maven-artifact, in order to do version matching properly. > > > > > > 3. docs largely missing > > Well then, it will currently fit fight in :-) > > > > > 4. should have at least one other implementation of the toolchain, > > next to > > jdk to make the api more stable.. > > I think the JDK detection and use is the biggy. Is this in any way > hooked up profile activators? For example, are you using the JDK > profile activator to tell the toolchain how it is to behave? Just > curious. Not sure I follow the question. This is how it currently works. Toolchains are injected into the build by the maven-toolchains-plugin. That one is responsible for reading persisted, defined user toolchains. And it matches them against the requirements by the project. The requirements are configuration of the toolchains-plugin. If a match is found, it's used and added to build-context, if not the build fails. That's approximately the same as the enforcer-plugin. Any toolchain-enabled plugin down the road just queries the build context for a toolchain it understands and uses. If found, it's used. If not, it keeps processing like it does now. Milos
