On 6/5/07, John Casey <[EMAIL PROTECTED]> wrote:
I don't think we should be promoting the current APIs for public
consumption. They're a friggin mess. But, we could create some nice
facade classes in each of the main (artifact, project, embedder -
which already has them) subsystem projects, and promote the use of
those. The embedder should embody the aggregate of these facades, so
we could make sure the *.public packages (or whatever) land in the
embedder's public api as well.
adding facades is a good thing, but we'd still need package renaming
and keeping backwards compatibility, i see as a value added thing, not
in conflict with it.
I don't think simply renaming the existing classes is a good
solution. However, I also don't think that - once we get the apis
right - the monolithic embedder artifact is the only one we should
allow people to integrate against.
renaming packages it's part of a bigger solution, and we need to start
at some point
-john
On Jun 5, 2007, at 3:36 PM, Carlos Sanchez wrote:
> 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]
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
--
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]
