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-setti

["Brian E. Fox" <br...@reply.infinity.nu>]

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