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]
