On Jun 5, 2007, at 10:27 PM, Carlos Sanchez wrote:
> 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
Why do we need to rename the packages? Is this a stylistic preference
on your part that makes this so urgent, or a shortcoming of a
container you're working with outside of Maven? I see no urgency
here; we have clear delineation of projects according to their binary
artifacts and source trees...what does all that effort buy us right
now, except a lot of exposure to new bugs??
-j
>
>>
>> -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]
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
