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]
