I agree. If we try to refactor everything now, it just means longer term before 2.1 can come out. Committing to a public façade for future compatibility and abstraction from internals is the way to go.
-----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 12:29 PM To: Maven Developers List Subject: The Embedder as our only export interface (was: Re: svn commit: r543671 - in /maven/components/trunk: maven-core/ maven-core/src/main/java/org/apache/maven/core/monitor/event/ maven-core/src/main/java/org/apache/maven/core/monitor/logging/ maven-settings/ Here is my reasoning as the Embedder as the only form we should be exposing in the short term (the emphasis being on short term) http://docs.codehaus.org/display/MAVEN/The+Embedder+for+all+client+use +in+2.1 On 4 Jun 07, at 9:01 PM 4 Jun 07, Carlos Sanchez wrote: > I got this lost between the long list of commits, see below > > > On 6/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> On 1 Jun 07, at 8:06 PM 1 Jun 07, [EMAIL PROTECTED] wrote: >> >> > Author: carlos >> > Date: Fri Jun 1 17:06:11 2007 >> > New Revision: 543671 >> > >> > URL: http://svn.apache.org/viewvc?view=rev&rev=543671 >> > Log: >> > [MNG-2943] Avoid using package names used in other artifacts: add >> > some comments >> > >> >> -1 >> >> Roll all of those back. I'm not if you haven't noticed but we're >> trying to process patches across both the trunk and the branch and >> you: >> >> 1) Making an assumption about how the embedder is going to be >> deployed yourself while I have historically always had clients >> consume a single JAR/Bundle > > I haven't changed in any way how things worked before, completely > backwards compatible, no changes to the embedder, no idea what are you > talking about. You can deploy the embedder however you want, I prefer > it other way that doesn't interfere with yours. > >> 2) Making it difficult for us to patch across the branch and trunk >> for no good reason given the embedder has always been proffered up as >> a single JAR > > I thought about that, two options I had are > - merging my changes to the branch (not my preference to add mor stuff > into 2.0.x) > - doing the backwards compatibility the other way around making the > new classes extend the old ones (this will prevent the patching > problem) > >> 3) Should ask on things you historically have never had anything to >> do with > > eh?, I have been working on the core, and everybody here knows about > my work with Maven and OSGi, it's in the mailing list > >> >> The embedder will continue to be a single bundle/jar as it has always >> been until you convince me (the one who has always done the work and >> released the embedder to anyone using it from its inception) >> otherwise. It might be a great idea for reasons I can't fathom but >> for the love of god stop diddling everything that you historically >> did not start or have had nothing to do with. > > you can consume it however you want, I want all Maven generated jars > to be OSGi enabled. > > I noticed the issue with duplicated packages while playing with OSGi > but is not directly related. > The fact that we have same packages in different modules is just a bad > practice, for architectural and easier development issues. If I see an > org.apache.maven.project class I'd look into maven-project without > having to search all the sources > > So if you have any opinion against doing the same thing with the > second option (- doing the backwards compatibility the other way > around making the new classes extend the old ones (this will prevent > the patching problem)) I'd like to know. > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
