Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

The embedder should be used for all client use in 2.1 to protect any clients from internal changes in Maven. People will generally want to use Maven code to:

<ul>
	<li>Execute Maven</li>
	<li>Read/Write POMs</li>
	<li>Artifact Resolution</li>
</ul>

In the short term, these should be provided via the embedder to give a unified facade for client code allowing us to restructure the internals of Maven. Right now anyone attempting to use the maven-artifact, or maven-project have an incredibly difficult time because the APIs are frankly terrible. There will always be cases where people want the functionality of the components but in the short term I think the only option is promoting the Embedder with documentation and work diligently to improve the APIs of the core components.

Given the activity in the core there is no way that the refactoring of the APIs of maven-artifact, and maven-project can be resolved in the timeframe of 2.1. I think the only API we can reasonably commit to is the Embedder API. People are free to use the components but they use them at their own risk. I think it is reasonable that if we provide for the majority of use cases using the Embedder then I think we will be doing a service. The difference in size in the artifacts required for artifact resolution versus the full embedder is not something that is a great concern to most consumers.

I think the plan should be to flesh out the embedder API to a usable state and commit to maintaining compatibility. It will allow us to decouple from the core and vary independently while we figure out the exact internals. Provided we maintain the Embedder API and clearly state this is the only supported externalized form for consumption then we are free to pursue cleaning up the core to point where later on in the 2.1 lifespan we have the components in a form we can safely tell people to use.

This is why I think it is a bad idea to generally promote the use of the individual components at this time. People are still free to use the components but given the resources committed to the core I don't think this is something we can reasonably support. All the IDE integration uses the embedder, the Ant Tasks can use the embedder and I don't see any client use that can't use the embedder. Yes there is a reasonable hit in the size of embedder but is the best way forward with respect to giving people a usable externalized form while giving us the chance to improve upon the internal APIs that we would ultimately like to expose.

<h4>(jdcasey)</h4>

I don't think it's impossible to start promoting these three APIs in their proper place right now. It would take us all of 30 minutes to wire up an aspect to the maven build which would &quot;hide&quot; the ugly apis from the outside world, and only expose those apis we have written to be entry points. We don't need to restrict a &quot;Read/Write POM&quot; public API to the maven-embedder project right now, for instance. We could easily aggregate all *.public packages into the eventual embedder jar, too, so this is available from there...but it doesn't need to be restricted to there.