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
signature.asc
Description: Digital signature
