Re: [M2] Adding a non-artifact to a plugin's classpath

[Brett Porter <br...@gmail.com>]

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 );

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 <ma...@apache.org> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [M2] Adding a non-artifact to a plugin's classpath

[Martin Cooper <ma...@apache.org>]

On 3/31/06, Brett Porter <br...@gmail.com> 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 <ma...@apache.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>