Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty-9 and aggregates

On 17 July 2012 00:33, 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

But same argument applies to jetty-distribution-X.X.X-tar.gz    This
is merely an aggregation of components already available in maven
central.

I don't think we are alone to have a few duplicates in our artefacts.


> 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

I'm fine with separating them out of the normal project, but I've not
really seen this chaos as the maven integration in IDEs does the right
thing with dependencies so you don't get both the aggregate and the
original on a classpath.


> 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

The aggregate jar for Jetty-9 should be < 2MB  it is not a big thing.
OK it is made larger by the source and javadoc requirements of maven
central, but that is their policy not our wish.

More over, we have totally re-engineered the structure of the project
to suite maven, including breaking down the original single jar into
all the components jars.   I don't think the disk storage of the
aggregate jar is much to ask of maven central.



On 17 July 2012 02:06, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> 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.

This is a real issue,  but it is just a specific case of incompatible
jars of which there are many examples (and hence there exists horrid
things like classloader isolation frameworks).

In reality I do not think it will be common because the consumers of
the aggregate jars are unlikely to be maven users.


> 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).

But aggregate jars is not for users not using maven.


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

Really?  We moved the project to maven so it could build and publish
our artefacts for us.  I didn't realise that the tool came with an
agenda that all downstream users must also be maven users!

An aggregate jar is a valid artefact of our project and our build tool
(maven) should be able to build that artefact and publish it -
regardless if that artefact may be incompatible with further usage of
maven as a build tool for users of that aggregate jar.

> 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.

Why would we not do the same thing with jetty-distribution then?  ie
build it with maven and publish to the eclipse download site but
bypass maven central?

I think maven central is intended to be the repository of all
artefacts built by public maven projects so that they may be used by
other projects to build bigger better things.

There are valid projects that can build on the jetty-distribution
artefacts (codehaus hightide was one!) and I think there are also
valid projects that may want to build on jetty-aggregate.


> 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)

I don't think this would fly.  It's just a jar and people would not
understand why we can't distribute it just like all our other
artefacts.


However, having said all that - I do think we can improve the
aggregates.  Specifically I think:
 + we don't need all the different flavours.  Jetty-all will do fine.
 + they should not be built by default with every call to mvn.  I'm OK
for them to be in a profile or even a separate build (although the
later is a bit of a faff to keep in lock step).
 + I'd be OK with not building source and javadoc artefacts - however
I think that is maven central policy so I guess we had better stick
with it rather than hack around it.



cheers


Back to the top