Re: [jetty-dev] Jetty-9 and aggregates

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

There's also ...

4. the duplicate classes exist at a different Maven coordinate space.

    Now that we have jetty-client, jetty-websockets, jetty-spdy, jetty-npn, jetty-servlets, all usable by other projects, that means if you decide to use the maven aggregate JAR file in maven and use a separate dependency that pulls in other parts of jetty, you will have duplicate classes, even at different versions.

    We are currently seeing this with our orbit dependencies, which will also be addressed by the Eclipse side IP folks now that Juno is out.

What I want to re-emphasize, is that having a POM (with <packaging>pom</packaging>) for the aggregates is fine, and perfectly reasonable, and will address all of the type 1 users (those using maven).

Having the aggregate JAR files isn't appropriate for maven or maven central. 

To support type 2 users (those not using the maven repository system), we can still generate the aggregate JAR files, on release, for distribution to our downloads directory on eclipse.org.  That is also a reasonable thing to do.

Choice #2 for type 2 users is to provide a means to build the aggregates themselves via some tooling in the distribution (the tooling doesn't have to be that complicated, an ant build script, or shell/bat script should be sufficient)

--

Joakim Erdfelt <joakim@xxxxxxxxxxx>

www.webtide.com

Developer advice, services and support
from the Jetty & CometD experts.

On Mon, Jul 16, 2012 at 7:33 AM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:

I have three issues with them as they currently stand:

1 - they are duplication of content already pushed into central,
merely an aggregation of already decomposed artifacts that a maven
plugin/ant target/shell script could be used to build a local
aggregation of the same content

2 - when importing into an IDE you really have to disable them or you
end up getting chaos with duplicated classes/source all over the place

3 - I largely feel it is an abuse of the service that maven central
provides us...each release we are dumping effectively another 70meg (i
ball-parked 8.1.4 and then x2 it) of this assembly content out there

I am largely fine with maintaining this process for jetty7 and 8
because they should not be _that_ many more releases of them...but
future wise I think we would be well served to reduce this footprint

cheers,

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx

On Sun, Jul 15, 2012 at 6:58 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> Can someone explain the issue with having them in maven central?
>
> Jan
>
> On 14 July 2012 01:51, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
>> point is to get rid of them as entities in maven central
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>>
>>
>> On Fri, Jul 13, 2012 at 10:50 AM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> On Fri, Jul 13, 2012 at 5:47 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
>>>> I want to eliminate the building of jetty-aggregate jars in jetty-9.
>>>>
>>>> Here's my proposal.
>>>>
>>>> Leave jetty-aggregates modules in the build.
>>>> Change all jetty-aggregate modules to be <packaging>pom</packaging>
>>>>
>>>> This satisfies those users that want to continue to use maven and the
>>>> aggregate dependencies.
>>>>
>>>> Now to support the non-maven folks, who would download the aggregates and
>>>> use them.
>>>>
>>>> We create in the jetty-distribution a contrib/build-aggregates.xml (ant
>>>> build script) that creates all of the various aggregate flavors for them,
>>>> from the contents of the distribution lib directory.
>>>
>>> It is not simpler to just put them into a profile, and build them only
>>> on release/deploy ?
>>>
>>> Simon
>>> --
>>> http://cometd.org
>>> http://webtide.com
>>> Developer advice, services and support
>>> from the Jetty & CometD experts.
>>> ----
>>> Finally, no matter how good the architecture and design are,
>>> to deliver bug-free software with optimal performance and reliability,
>>> the implementation technique must be flawless.   Victoria Livschitz
>>> _______________________________________________
>>> jetty-dev mailing list
>>> jetty-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> --
> Jan Bartel <janb@xxxxxxxxxxx>
> www.webtide.com – Developer advice, services and support
> from the Jetty & CometD experts.
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev