On 3/31/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Can you clarify classpath? Is it looking in the current classloader,
> the context classloader, or something else?
>
> Maybe creating a classloader and setting the thread context
> classloader will help:
>
> ClassLoader oldCCL = Thread.getContextClassLoader();
> ClassLoader cl = new URLClassLoader( new URL[] { file.toURL() } );
> Thread.setContextClassLoader( cl );
>
> // call 3rd party code
>
> Thread.setContextClassLoader( oldCCL );This worked. Thanks, Brett! -- Martin Cooper If not, to do it from the mojo, you could probably do it by grabbing > the current classloader and casting it to a RealmClassLoader, then > adding the URL. It's sort of assuming implementation details of Maven, > but they aren't likely to change :) > > HTH, > Brett > > On 3/31/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > I'm writing my own Mojo that needs to be able to read a file that's in > the > > classpath. The catch is that the file must be either dyamically > generated, > > or part of the source tree of the project that's invoking my plugin. > Since > > it's not part of some other artifact, I'm not seeing how I can get the > file > > into the classpath for my plugin. > > > > Is there a way to add a non-artifact (e.g. file system directory) to the > > classpath for a plugin? Either configuring this in the POM (i.e. an > > equivalent to adding a directory as a path location in a taskdef > classpath > > in Ant) or having code in the Mojo do this would be fine, with a slight > > preference for the latter. > > > > BTW, the code that reads the file in question is 3rd party code, and I > don't > > have an alternative way to feed the file to that code, unfortunately. It > has > > to be in the classpath. > > > > Thanks! > > > > -- > > Martin Cooper > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
