Message-ID: <969284201.21955.1417011591439.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_21954_2098731968.1417011591438" ------=_Part_21954_2098731968.1417011591438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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:=20
In the short term, these should be provided via the embedder to give a u= nified facade for client code allowing us to restructure the internals of M= aven. Right now anyone attempting to use the maven-artifact, or maven-proje= ct have an incredibly difficult time because the APIs are frankly terrible.= There will always be cases where people want the functionality of the comp= onents but in the short term I think the only option is promoting the Embed= der with documentation and work diligently to improve the APIs of the core = components.=20
Given the activity in the core there is no way that the refactoring of t= he APIs of maven-artifact, and maven-project can be resolved in the timefra= me 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 c= ases using the Embedder then I think we will be doing a service. The differ= ence in size in the artifacts required for artifact resolution versus the f= ull embedder is not something that is a great concern to most consumers.=20
I think the plan should be to flesh out the embedder API to a usable sta= te and commit to maintaining compatibility. It will allow us to decouple fr= om 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 s= upported externalized form for consumption then we are free to pursue clean= ing up the core to point where later on in the 2.1 lifespan we have the com= ponents in a form we can safely tell people to use.=20
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 compo= nents but given the resources committed to the core I don't think this is s= omething we can reasonably support. All the IDE integration uses the embedd= er, 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 embedd= er but is the best way forward with respect to giving people a usable exter= nalized form while giving us the chance to improve upon the internal APIs t= hat we would ultimately like to expose.=20
I don't think it's impossible to start promoting these three APIs in the= ir proper place right now. It would take us all of 30 minutes to wire up an= aspect to the maven build which would "hide" the ugly apis from = the outside world, and only expose those apis we have written to be entry p= oints. We don't need to restrict a "Read/Write POM" public API to= the maven-embedder project right now, for instance. We could easily aggreg= ate all *.public packages into the eventual embedder jar, too, so this is a= vailable from there...but it doesn't need to be restricted to there.