Re: 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-

[Carlos Sanchez <ca...@apache.org>]

That's a separate discussion, if you want to release 2.1 tomorrow I'm
all for it, but I don't see how my changes refactor everything. I kept
the old classes deprecated and they extend the new ones so behavior is
exactly the same, of all the changes in trunk this is not the riskiest
one by far. But as I said if you want 2.1-alpha1 tomorrow and push my
changes to alpha 2 I'm more than happy to do it like that.

On 6/5/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> 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:jason@maven.org]
> 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 <ja...@maven.org> wrote:
> >>
> >> On 1 Jun 07, at 8:06 PM 1 Jun 07, carlos@apache.org 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org