and btw this is the thread where I brought up these changes time ago
http://www.nabble.com/Avoiding-duplicate-packages-in-different-modules-tf3557533s177.html#a9933847
On 6/5/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 6/5/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 5 Jun 07, at 3:36 PM 5 Jun 07, 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.
> >
>
> The modularity is of primary importance for us to develop, but we
> have by no means made anything that is generally consumable on a
> modular level and this is primarily because of poor APIs. If the APIs
> were suitable for export I would be fine with their promoted use as
> per what I wrote in the wiki. But they are far from it.
>
> There is also a difference in modularity at the development level
> versus what it used in practice. What's the most popular form
> consumed by users of Spring? The aggregate JAR. That doesn't mean
> they should jam everything into a single source tree. Client aren't
> necessarily consumers of modularity. I'm not saying that is the case
> with us, I'm mostly saying our APIs are not in a form I am at all
> comfortable making anyone use.
people use what they need, if they want just the IoC container they
don't add all the required dependencies of the whole spring
Our APIs are there and we have to keep backwards compatibility anyway.
>
> 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]
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
--
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]
