Re: [jetty-dev] too many jars? jetty-util jetty-io jetty-http ???

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

I don't think we ought to rename the artifacts at all for client and
server....just add in a package space for deployment of them..

org.eclipse.jetty.bundle:jetty-client
org.eclipse.jetty.bundle:jetty-server

then they are segmented off from the normal artifacts in their own
'bundle' directory (which is not to be confused with the eclipse
bundles...unless we decided to make these the specific artifacts
feeding the p2 repo which is not a terrible idea...maybe, have to give
it some thought

this would look the same way as the toolchain would in the repo,
artifacts that we depend on (or produce) for the project but are not
polluting the main project space in the repo..

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Tue, May 26, 2009 at 00:00, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
> Jesse McConnell wrote:
>> I'll expand tomorrow but I am of the mind that if we want to allow for
>> an aggregate mechanism for people to consume jetty other then through
>> the maven dependency resolution or normal download bundles...we need
>> to take a step back a bit and look at all the different ways it is
>> consumed and look for the natural breaks.
>
> That's what I was trying to do :)
>
>
> I think you (and dyu) are advocating my option c:
>
>>> c) leave io,http,continuation separate, but have a jetty-common
>>> aggregation module that builds an combined jar.
>
> and that is indeed my preferred option - to leave the
> current modules more or less as they are.  So
> jetty-foo contains org.eclipse.jetty.foo   and nothing
> else.
>
>
>
>> personally, I think we ought to stick with what we have in svn right
>> now...and then let users as us for aggregations that they might want
>> or need down the road.  It is super easy to make aggregation
>> assemblies, but once we start making 2,3,10 of these different
>> aggregations, coupled with debs, rpms, p2 update sites, distribution
>> downloads (zip, tgz, etc), yadda yadda yadda...most people will be
>> consuming through one of these mechanisms anyway...
>
> So at this stage, I'd like to start defining the conventions for
> aggregates - as there is already some demand for them (specially
> the client jar).
>
> What I want to avoid is what we've already done with jetty-runner,
> which is an aggregate, but it is not clear that it is.
>
> As we get more and more aggregates, it will be very important that
> we keep them distinct from the core modules, so that when
> jetty-kitchensink comes along, we don't have to rely on interpretation
> of the name to guess if it is an aggregate or not.
>
> Note that I've already started distinguishing names - as I've
> renamed:
>
>   jetty-embedded-examples   -> example-jetty-embedded
>   jetty-test-webapp         -> test-jetty-webapp
>
> So now there are example-* and test-* modules that are
> distinct from the core jetty-* modules
>
>
> So I'm still looking for a good naming convention to
> distinguish aggregates:
>
> jetty-client-aggregate    // too long and aggregates. doesn't sort nice
> jetty-client-all          // "all" is overloaded. doesn't sort nice
> jetty-all-client          // "all" is overloaded. does sort nice  - but not bad
> jetty-deps-client         // deps implies client not included.  does sort nice
> jetty--client             // too subtle.  does sort nice
> JETTY-client              // even more subtle and does not sort on windows
> jetty-combined-client     // hmmmmm
>
>
>
> currently my favourite is probably -- still  , so we would have:
>
> jetty--http-client    # just the HTTP client
> jetty--http-server    # just the HTTP server
> jetty--server         # The server + bells + whistle
> jetty--all            # everything
>
>
> but I'm very open to be convinced about better names and/or boundaries
>
>
> thoughts
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>