I agree also, publicising a restricted API has got to be a useful
thing for outside developers.
I was trying to do the same with the plexus container but clearly
that did not go so well!
Andy
On 15 Aug 2007, at 16:13, John Casey wrote:
The only problem here is that the expression evaluator
I'm definitely +1 on the idea.
I'm not sure whether aggregating them in one artifact makes sense
though (it sounds a bit like the embedder API too). It could be a
good way (in the interim) to start exposing safe functionality,
though I feel in the long term the public API of the individual
That would be really nice. The hardest part about writing mojos is
trying to figure out what you _can_ do and get access to. We'll probably
never be able to enumerate all the available components, but being able
to have a list of the standard ones would be handy. The
expressionEvaluator already
I suppose maven-artifact is a bad example here, since it's now
officially moving into its own structure in SVN. Perhaps a better one
would be the build planner/lifecycle APIs, or even the plugin-
resolution/management features. These aren't likely to separate from
the main Maven release
The only problem here is that the expression evaluator is meant to
give access to build state, not components in the system...which is
why the @component annotation is handled in a completely parallel
subsystem.
Obviously, plugins _can_ access basically any component in the
container
On 15 Aug 07, at 4:42 PM 15 Aug 07, John Casey wrote:
Hi,
I'd like to propose that for Maven trunk/2.1 we capture all plugin-
facing APIs and facades inside a single maven-api artifact. This
would enumerate in a very clear fashion the public APIs that we
need to support. We're
I was planning to let this discussion mature a little bit before I
wrote up anything formal. This is just something that occurred to me
this morning (maybe a little slower than others), and I wanted to
start a real discussion.
-john
On Aug 15, 2007, at 12:36 PM, Jason van Zyl wrote:
On
