there are a number of ways around this though, so if you have a
legitimate need to have access it can be done with a minimum of
hassle.
care should be taken to avoid it if you don't need it, but there are
certainly circumstances where it is unavoidable.
maven-jdbc-plugin and maven-execute-plugin in the mojo-sandbox are
examples where you need to muck around with the classpath.
the jdbc one uses the <extensions/> system to bring in the db driver
code it needs at plugin execution time, and the execute plugin uses
its own classloader to load in the dependencies and the compiled
classpath so it can instantiate the object and exec a method on it.
if you need to go down that path and need some help just yell, a few
of us have had to do it a lot, I have 3 custom plugins for our system
that needed to do it. :)
cheers,
Jesse
On 8/19/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> Was that necessary? I assume you now have BeanDocClient as a dep on
> your plugin, which should make the classloader current anyway, without
> switching the context class loader.
>
> - Brett
>
> On 8/19/05, Van Steenberghe Mario (GFDI) <[EMAIL PROTECTED]> wrote:
> > Thanks.
> >
> > In fact my plugin calls a library that loads some resources inside these
> > libraries, so I had to switch the context classloader as follows:
> >
> > public void executeReport(final Locale locale) throws MavenReportException {
> > final Thread current = Thread.currentThread();
> > final ClassLoader oldLoader = current.getContextClassLoader();
> >
> > try {
> > current.setContextClassLoader(BeanDocClient.class.getClassLoader());
> >
> > // ... call library code here ...
> > }
> > catch (Exception e) {
> > throw new MavenReportException("Unable to generate beandoc: " +
> > e.getMessage(), e);
> > }
> > finally {
> > current.setContextClassLoader(oldLoader);
> > }
> > }
> >
> > Regards,
> > Mario.
> >
> > -----Original Message-----
> > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > Sent: Fri 8/19/2005 11:01 AM
> > To: Maven Users List
> > Subject: Re: [m2] plugin classpath question
> >
> > The plugin gets the plugin's dependencies, not the project's.
> >
> > Also, it uses a separate class loader, so the system classpath only
> > reflects what was used to bootstrap Maven (classworlds).
> >
> > You can get the JARs for the project's artifacts using the
> > ${project.artifacts} expression.
> >
> > - Brett
> >
> > On 8/19/05, Van Steenberghe Mario (GFDI) <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > Is there anyone who knows how the classpath is defined when a maven2
> > > plug-in is run ?
> > >
> > > I expected that all the dependent jars, defined in my POM should be on
> > > the classpath, but when I print out the classpath inside my plug-in, I
> > > get:
> > >
> > > /**
> > > * @see
> > > org.apache.maven.reporting.AbstractMavenReport#executeReport(java.util.Locale)
> > > */
> > >
> > > public void executeReport(final Locale locale) throws
> > > MavenReportException {
> > > ...
> > > getLog().info(" - classpath : " +
> > > System.getProperty("java.class.path"));
> > > ...
> > > }
> > >
> > > output:
> > >
> > > - classpath :
> > > /opt/maven2-SNAPSHOT/core/boot/classworlds-1.1-alpha-2.jar
> > >
> > >
> > > Thanks,
> > > Mario.
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
--
jesse mcconnell
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
