On 4 Jun 07, at 9:01 PM 4 Jun 07, Carlos Sanchez wrote:
>
>
> 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.
The Maven functionality should be deployed as a single bundle. Things
like providers I could see being provided separately but historically
the pattern has been the one artifact for:
- Eclipse integration
- IDEA integration
- Netbeans Integration
- Ant use is totally like the embedder with the artifact + Maven
capabilities
> You can deploy the embedder however you want, I prefer
> it other way that doesn't interfere with yours.
>
I don't want the tooling to be fractured with the entry points used
by client code. The functionality is a single unit and has always
been integrated as such. The use of maven-artifact is a perfect
example of the complete mess we get our selves into by exposing
internals from something other then a single point of entry. Those
interfaces have leaked out all over the place requiring people to
understand a handful of components and some voodoo to make it
actually work. There is no Maven functionality that can't be used
from a single interface.
>> 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)
>
For embedding 2.0.x is a lost cause
>> 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.
This is what I'm opposed to. This is a critical issue for
consumption. I don't want two ways. I want one well supported way.
What benefit do you see to providing more then one single point of
entry?
>
> 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 don't see any benefit at all in exposing Maven as more then a
single bundle. Again with the exception of providers which should
ultimately be decoupled from the embedder.
>
>
>
> --
> 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]
