You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alexander Azarov <az...@mobilae.ru> on 2005/08/12 17:17:47 UTC

[m2] Mojo development: need ClassWorld

How may I get a ClassWorld instance from Mojo execute method?

Regards,
Alexander.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Sat, Aug 13, 2005 at 10:33:51AM -0400, Andy Glick wrote:
> Trygve Laugstøl wrote:
> 
> >
> >The reason as to why you can't get access to the classloader of the core
> >is that the Mojos are supposed to be independent of their enviroment and
> >they should be executed independently in separate class loaders. Giving
> >the Mojos access to the root class loader will conflict with these ideas.
> >
> 
> Trygve,
> 
> In the Springframework documentation they talk about 2 different types 
> of beans, those that are not container aware and those that are. They 
> always make cautionary statements when talking about container aware 
> beans, but they didn't write Spring with an apriori knowledge of all 
> future Spring use cases, so they made allowances for this "odd" behavior.

There are always ways around this, one way is to write a Plexus component
and have a @parameter on that in the Mojo. Any Plexus component can get
access to the container which should solve the problem. That solution
would still not break the Mojo API and if you're using the Mojo in another
container the container would either have to provide the component or
gently fail because of the missing requirement.

It's worth noticing that the Mojo API is more of a bridge between existing
code and the execution enviroment (be it Maven, any IDE or tool) so the
API it pretty limited and specific.

> It seems to me that attempting to define and enforce conventions like 
> these simply reduces the chance that developers will want to adopt Maven.
> 
> I see in the Maven User's list that the Maven developers are continually 
> requesting use cases from the developers who use the framework in ways 
> not "intended" or at least "unexpected" by the developers. Well, a 
> successful tool/framework takes its users likely use cases into account 
> up front, and or expands its list of use cases as they are presented. 
> I'm not trying to say that you guys don't do that, but I will suggest 
> that you tend to express reluctance.

Maven has always been about creating build patterns to make it easier to
perform builds and maintaining builds. Maven should cover most use cases
you have when it comes to building software but it might not be the way
you expect and you might have to change your exising build. That is why
that we sometimes are reluctant to 

> You guys aren't referred to as "Mavenites" by the rest of the community 
> for no reason. ;-)
> 
> If you think about Ant's success for a minute, I think that you can see 
> that it allows a developer to do almost anything, including shoot 
> him/her self in both feet. By reducing the "possible" Maven throws up 
> steep hills for newbies, like I once was, to climb.

By making everything possible with Maven wouldn't that make Maven the same
thing as Ant? If Maven doesn't do the job, Ant will.

As for the steep hills, that seems to be mostly comments from Ant people,
which is understandable given the two different ways stuff is done. The
site is pretty good now and it should be pretty easy to get started with
Maven.

--
Trygve

RE: [m2] Mojo development: need ClassWorld

Posted by Alexander Azarov <az...@mobilae.ru>.
> -----Original Message-----
> From: Kenney Westerhof [mailto:forge@neonics.com] 
> Sent: Saturday, August 13, 2005 6:51 PM
> 
> If you want to access the ClassRealm, just add a private 
> field of type ClassRealm to the mojo, marking it as a @parameter.

Thank you. Do I have to specify an 'expression'?

I tried this way:

    /**
     * @parameter
     */
    private ClassRealm realm;

It is null in 'execute'.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Kenney Westerhof <fo...@neonics.com>.
On Sat, 13 Aug 2005, Andy Glick wrote:

If you want to access the ClassRealm, just add a private field of type
ClassRealm to the mojo, marking it as a @parameter.

I needed this to construct a classpath string since the classloading
of the app I embedded didn't implement classloading properly.

I would rather not have the need for a classrealm too.

-- Kenney

> Trygve Laugstøl wrote:
>
> >
> > The reason as to why you can't get access to the classloader of the core
> > is that the Mojos are supposed to be independent of their enviroment and
> > they should be executed independently in separate class loaders. Giving
> > the Mojos access to the root class loader will conflict with these ideas.
> >
>
> Trygve,
>
> In the Springframework documentation they talk about 2 different types
> of beans, those that are not container aware and those that are. They
> always make cautionary statements when talking about container aware
> beans, but they didn't write Spring with an apriori knowledge of all
> future Spring use cases, so they made allowances for this "odd" behavior.
>
> It seems to me that attempting to define and enforce conventions like
> these simply reduces the chance that developers will want to adopt Maven.
>
> I see in the Maven User's list that the Maven developers are continually
> requesting use cases from the developers who use the framework in ways
> not "intended" or at least "unexpected" by the developers. Well, a
> successful tool/framework takes its users likely use cases into account
> up front, and or expands its list of use cases as they are presented.
> I'm not trying to say that you guys don't do that, but I will suggest
> that you tend to express reluctance.
>
> You guys aren't referred to as "Mavenites" by the rest of the community
> for no reason. ;-)
>
> If you think about Ant's success for a minute, I think that you can see
> that it allows a developer to do almost anything, including shoot
> him/her self in both feet. By reducing the "possible" Maven throws up
> steep hills for newbies, like I once was, to climb.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Andy Glick <an...@acm.org>.
Trygve Laugstøl wrote:

> 
> The reason as to why you can't get access to the classloader of the core
> is that the Mojos are supposed to be independent of their enviroment and
> they should be executed independently in separate class loaders. Giving
> the Mojos access to the root class loader will conflict with these ideas.
> 

Trygve,

In the Springframework documentation they talk about 2 different types 
of beans, those that are not container aware and those that are. They 
always make cautionary statements when talking about container aware 
beans, but they didn't write Spring with an apriori knowledge of all 
future Spring use cases, so they made allowances for this "odd" behavior.

It seems to me that attempting to define and enforce conventions like 
these simply reduces the chance that developers will want to adopt Maven.

I see in the Maven User's list that the Maven developers are continually 
requesting use cases from the developers who use the framework in ways 
not "intended" or at least "unexpected" by the developers. Well, a 
successful tool/framework takes its users likely use cases into account 
up front, and or expands its list of use cases as they are presented. 
I'm not trying to say that you guys don't do that, but I will suggest 
that you tend to express reluctance.

You guys aren't referred to as "Mavenites" by the rest of the community 
for no reason. ;-)

If you think about Ant's success for a minute, I think that you can see 
that it allows a developer to do almost anything, including shoot 
him/her self in both feet. By reducing the "possible" Maven throws up 
steep hills for newbies, like I once was, to climb.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Roadmap for Maven2

Posted by Brett Porter <br...@gmail.com>.
We're definitely running behind - a few other things have come up.
We're looking at a late September release. We expect Maven to be
stable by the end of the month, then spend time making cosmetic
changes, plugins, documentation, etc.

Cheers,
Brett

On 8/15/05, Michael Owen <mi...@hotmail.com> wrote:
> Hi,
> 
> Just wondering if anybody knows whether the road map for Maven2
> (http://maven.apache.org/maven2/roadmap.html) is still correct, and
> therefore a stable release can be expected in September?
> 
> Mike
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


[m2] Roadmap for Maven2

Posted by Michael Owen <mi...@hotmail.com>.
Hi,

Just wondering if anybody knows whether the road map for Maven2 
(http://maven.apache.org/maven2/roadmap.html) is still correct, and 
therefore a stable release can be expected in September?

Mike



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Aleksey Studnev <Al...@exigengroup.com>.
Milos Kleint <Mi...@Sun.COM> wrote on 08/15/2005 01:21:58 PM:

> Alexander Azarov wrote:
> 
> >>-----Original Message-----
> >>From: Trygve Laugstшl [mailto:trygvis@codehaus.org] 
> >>Sent: Friday, August 12, 2005 7:44 PM
> >>
> >>On Fri, Aug 12, 2005 at 07:36:32PM +0400, Alexander Azarov wrote:
> >> 
> >>
> >>>I.e. I am trying to embed Maven2 into another application 
> >>> 
> >>>
> >>and I would 
> >> 
> >>
> >>>like to get access to that application's ClassLoader in my 
> >>> 
> >>>
> >>Mojo. Still 
> >> 
> >>
> >>>cannot figure out how to do that.
> >>> 
> >>>
> >>Why do you need it, a concrete example would be good. If you 
> >> 
> >>
> >
> >We are running Maven2 from Eclipse (in the same VM) and our Mojos must 
have
> >an access to Eclipse infrastructure.
> > 
> >
> similar approach is taken by the netbeans ant integration. There are 
> special ant tasks tha work within the IDE and have access to IDE's 
> classes and perform specific inside IDE tasks (like stating a debugger, 
> profiler etc..)
> 
> Milos


... and in eclipse as well. ANT integrated in eclipse pretty easy because 
ANT does not
use own classloader features. From other hand, it is quite clear that 
Maven implies more
infrastructure.

I have the same trouble as Alexander integrating Maven in eclipse and 
would like to know
if it is possible at all. Eclipse currently does not have any good 
approach to setting up a 
production environment and Maven may play its role here. This requires 
Maven to be run and 
controlled in a hosted environemnt, not its own and this is not just a set 
of properties.

> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


Re: [m2] Mojo development: need ClassWorld

Posted by Milos Kleint <Mi...@Sun.COM>.
Alexander Azarov wrote:

>>-----Original Message-----
>>From: Trygve Laugstшl [mailto:trygvis@codehaus.org] 
>>Sent: Friday, August 12, 2005 7:44 PM
>>
>>On Fri, Aug 12, 2005 at 07:36:32PM +0400, Alexander Azarov wrote:
>>    
>>
>>>I.e. I am trying to embed Maven2 into another application 
>>>      
>>>
>>and I would 
>>    
>>
>>>like to get access to that application's ClassLoader in my 
>>>      
>>>
>>Mojo. Still 
>>    
>>
>>>cannot figure out how to do that.
>>>      
>>>
>>Why do you need it, a concrete example would be good. If you 
>>    
>>
>
>We are running Maven2 from Eclipse (in the same VM) and our Mojos must have
>an access to Eclipse infrastructure.
>  
>
similar approach is taken by the netbeans ant integration. There are 
special ant tasks tha work within the IDE and have access to IDE's 
classes and perform specific inside IDE tasks (like stating a debugger, 
profiler etc..)

Milos



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: [m2] Mojo development: need ClassWorld

Posted by Alexander Azarov <az...@mobilae.ru>.
> -----Original Message-----
> From: Trygve Laugstшl [mailto:trygvis@codehaus.org] 
> Sent: Friday, August 12, 2005 7:44 PM
> 
> On Fri, Aug 12, 2005 at 07:36:32PM +0400, Alexander Azarov wrote:
> > I.e. I am trying to embed Maven2 into another application 
> and I would 
> > like to get access to that application's ClassLoader in my 
> Mojo. Still 
> > cannot figure out how to do that.
> 
> Why do you need it, a concrete example would be good. If you 

We are running Maven2 from Eclipse (in the same VM) and our Mojos must have
an access to Eclipse infrastructure.

Another way would be running Eclipse from Maven2 as a container for all the
Mojos and I do have serious doubts this way is simpler and even possible.

> are trying embed Maven you can add Plexus components to the 
> root class realm and in your Mojo have a paremeter with an 
> expression like this:
> 
>  @parameter expression=${component.my.role}

Well, will it help me in my task (using Eclipse classloader from the my
Mojos)? Could you please suggest how I can get it? I am not experienced with
ClassWorlds and Plexus in fact (yet).

> The reason as to why you can't get access to the classloader 
> of the core is that the Mojos are supposed to be independent 
> of their enviroment and they should be executed independently 
> in separate class loaders. Giving the Mojos access to the 
> root class loader will conflict with these ideas.

I see, but our build environment is developed on assumption that we run
under Eclipse. We are trying to move to Maven2, but we can avoid Eclipse in
no way.

Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Trygve Laugstøl <tr...@codehaus.org>.
Please to not top-post when replying to mails.

On Fri, Aug 12, 2005 at 07:36:32PM +0400, Alexander Azarov wrote:
> Yes, my problem is exactly that Mojo runs in its own ClassLoader while I
> would like to get another, specified on top of embedded Maven2.

As a Mojo you don't know anything about your execution enviroment except
the parementers you're requiring to be set.

> I.e. I am trying to embed Maven2 into another application and I would like
> to get access to that application's ClassLoader in my Mojo. Still cannot
> figure out how to do that.

Why do you need it, a concrete example would be good. If you are trying
embed Maven you can add Plexus components to the root class realm and in
your Mojo have a paremeter with an expression like this:

 @parameter expression=${component.my.role}

The reason as to why you can't get access to the classloader of the core
is that the Mojos are supposed to be independent of their enviroment and
they should be executed independently in separate class loaders. Giving
the Mojos access to the root class loader will conflict with these ideas.

--
Trygve

RE: [m2] Mojo development: need ClassWorld

Posted by Alexander Azarov <az...@mobilae.ru>.
Yes, my problem is exactly that Mojo runs in its own ClassLoader while I
would like to get another, specified on top of embedded Maven2.

I.e. I am trying to embed Maven2 into another application and I would like
to get access to that application's ClassLoader in my Mojo. Still cannot
figure out how to do that.

Alexander

> -----Original Message-----
> From: Trygve Laugstшl [mailto:trygvis@codehaus.org] 
> Sent: Friday, August 12, 2005 7:21 PM
> To: Maven Users List
> Subject: Re: [m2] Mojo development: need ClassWorld
> 
> 
> On Fri, Aug 12, 2005 at 07:17:47PM +0400, Alexander Azarov wrote:
> > How may I get a ClassWorld instance from Mojo execute method?
> 
> There is no standard way of getting an instance of a 
> ClassWorld. What are you trying to do? The Mojo itself should 
> probably construct a new ClassLoader and use either 
> this.getClass().getClassLoader() or
> Thread.currentThread.getContextClassLoader() as the parent 
> class loader.
> 
> Creating a sub-class of URLClassLoader is often a good start.
> 
> --
> Trygve
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Mojo development: need ClassWorld

Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Fri, Aug 12, 2005 at 07:17:47PM +0400, Alexander Azarov wrote:
> How may I get a ClassWorld instance from Mojo execute method?

There is no standard way of getting an instance of a ClassWorld. What are
you trying to do? The Mojo itself should probably construct a new
ClassLoader and use either this.getClass().getClassLoader() or
Thread.currentThread.getContextClassLoader() as the parent class loader.

Creating a sub-class of URLClassLoader is often a good start.

--
Trygve