You are mixing again best practices in package naming with the
embedder use. My changes were targeting the first.
Regarding the embedder I don't agree at all, for the same reason then
why don't we just put classes in a source folder and only one maven
project? plugins and any other tool choose what parts of maven they
want to use, and we can't limit that, for reuse and modularity.
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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]
--
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]
