You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/06/05 21:29:29 UTC
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/ maven-settings/src/main/java/org/apache/ma
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
Re: The Embedder as our only export interface
Posted by Jason van Zyl <ja...@maven.org>.
On 6 Jun 07, at 11:28 PM 6 Jun 07, Brett Porter wrote:
>
> On 07/06/2007, at 12:09 AM, Jason van Zyl wrote:
>
>>> - we will have to retain runtime compatibility in 2.1, but not
>>> necessarily API compatibility which is fine
>>
>> For plugins yes, for sanity. Not any other APIs. Plugins using
>> older artifact APIs are not my concern for 2.1. Those plugins will
>> have to move forward if they want to take advantage of 2.1
>> features. Any of the project and artifact APIs should be
>> considered dead in 2.1 and work from the embedder api to improve
>> them.
>
> A little confused about what you are saying. Are you saying they
> won't be able to take advantage of 2.1, but will still run in 2.1
> (using a 2.0.x execution context)? Or are you saying that they just
> won't run in 2.1 and will have to be updated?
>
2.0.x plugins in the 2.0.x execution environment
2.1.x plugins in the 2.1.x execution environment
The execution of the plugins using the old components has to be
bridged for 2.0.x components. Plugin in 2.1.x to start will use the
embedder APIs. To contrast artifact resolution capabilities in both
major versions.
>>>
>>> Given that, if Carlos has a use case for using the individual
>>> packages instead of the embedder and can make incremental
>>> improvements in line with that, I think we should look at it on a
>>> case by case basis here and move forward.
>>>
>>
>> But it's not in the card in the short term. As soon as we have
>> something we consider publicly consumable I'm all for it.
>
> I'm not sure what you mean by "short term", but as I understood it
> Carlos only wanted to ensure something was done for the 2.1 release.
>
Carlos alone will not be able to do it. Given all historical
precedent it's highly unlikely and as something we can offer the
community in terms of stability and usability the embedder API is the
most practical solution.
> The only way we are going to get to something publicly consumable
> is by working on it. If Carlos is able to propose and make
> incremental changes towards that, then I don't see the problem. I
> don't agree with the original changes made, but I do agree with the
> need to move forward on a case by case basis towards the goals we
> agree on from my previous mail.
>
As long as they are never supported publicly and that changes that
are made are not subject to compatibility concerns. Carlos alone
cannot decide and work on APIs which is why I suggest the embedder
API as the focus from which other APIs can fall out.
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: The Embedder as our only export interface
Posted by Brett Porter <br...@apache.org>.
On 07/06/2007, at 12:09 AM, Jason van Zyl wrote:
>> - we will have to retain runtime compatibility in 2.1, but not
>> necessarily API compatibility which is fine
>
> For plugins yes, for sanity. Not any other APIs. Plugins using
> older artifact APIs are not my concern for 2.1. Those plugins will
> have to move forward if they want to take advantage of 2.1
> features. Any of the project and artifact APIs should be considered
> dead in 2.1 and work from the embedder api to improve them.
A little confused about what you are saying. Are you saying they
won't be able to take advantage of 2.1, but will still run in 2.1
(using a 2.0.x execution context)? Or are you saying that they just
won't run in 2.1 and will have to be updated?
>>
>> Given that, if Carlos has a use case for using the individual
>> packages instead of the embedder and can make incremental
>> improvements in line with that, I think we should look at it on a
>> case by case basis here and move forward.
>>
>
> But it's not in the card in the short term. As soon as we have
> something we consider publicly consumable I'm all for it.
I'm not sure what you mean by "short term", but as I understood it
Carlos only wanted to ensure something was done for the 2.1 release.
The only way we are going to get to something publicly consumable is
by working on it. If Carlos is able to propose and make incremental
changes towards that, then I don't see the problem. I don't agree
with the original changes made, but I do agree with the need to move
forward on a case by case basis towards the goals we agree on from my
previous mail.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: The Embedder as our only export interface
Posted by Jason van Zyl <ja...@maven.org>.
On 6 Jun 07, at 1:19 AM 6 Jun 07, Brett Porter wrote:
> (Getting annoyed by everyone replying to each other across 3
> threads, so picking this one to move forward from)
>
> On 06/06/2007, at 5:29 AM, Jason van Zyl wrote:
>
>> 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
>>
>
> I think we all have some fundamental points of agreement:
> - the embedder is the only thing we can publish as a documented
> integration point (at this time)
> - we would like a documented artifact and project API aside from
> the embedder in the future (currently an unspecified timeframe)
> - the split packaging we have is a symptom of problems in the
> design and should be resolved somehow
> - we will have to retain runtime compatibility in 2.1, but not
> necessarily API compatibility which is fine
For plugins yes, for sanity. Not any other APIs. Plugins using older
artifact APIs are not my concern for 2.1. Those plugins will have to
move forward if they want to take advantage of 2.1 features. Any of
the project and artifact APIs should be considered dead in 2.1 and
work from the embedder api to improve them.
>
> I agree that making wholesale package changes now is not the right
> way to go - it seemed to be avoiding the real problem in most cases.
>
> However:
> - some things already depend on the artifact code alone, etc., and
> if someone is able to and is prepared to live with adjusting to
> future changes, I don't see a problem with it.
> - John makes a good point that we can try and achieve some small
> wins in this space as well without going the whole hog on redesign
>
> Given that, if Carlos has a use case for using the individual
> packages instead of the embedder and can make incremental
> improvements in line with that, I think we should look at it on a
> case by case basis here and move forward.
>
But it's not in the card in the short term. As soon as we have
something we consider publicly consumable I'm all for it.
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: The Embedder as our only export interface
Posted by Brett Porter <br...@apache.org>.
(Getting annoyed by everyone replying to each other across 3 threads,
so picking this one to move forward from)
On 06/06/2007, at 5:29 AM, Jason van Zyl wrote:
> 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
>
I think we all have some fundamental points of agreement:
- the embedder is the only thing we can publish as a documented
integration point (at this time)
- we would like a documented artifact and project API aside from the
embedder in the future (currently an unspecified timeframe)
- the split packaging we have is a symptom of problems in the design
and should be resolved somehow
- we will have to retain runtime compatibility in 2.1, but not
necessarily API compatibility which is fine
I agree that making wholesale package changes now is not the right
way to go - it seemed to be avoiding the real problem in most cases.
However:
- some things already depend on the artifact code alone, etc., and if
someone is able to and is prepared to live with adjusting to future
changes, I don't see a problem with it.
- John makes a good point that we can try and achieve some small wins
in this space as well without going the whole hog on redesign
Given that, if Carlos has a use case for using the individual
packages instead of the embedder and can make incremental
improvements in line with that, I think we should look at it on a
case by case basis here and move forward.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
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
Posted by "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