John has started an API cleanup for artifact resolution and one is
slated for maven-project but the second we promote these we are
really bound to support them and the one that are there now are
unsupportable.
>
> 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]
>
>
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]
