[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Juno Retrospective
|
Hi Jesse and everyone,
A bit of controversy is good to move things along.
So here is my take: a bit of a controversy killer.
TL;DR;
======
There is value in making jetty easy to consume by other projects on the train.
Let's contribute what the other projects are consuming: the jetty bundles.
Doing that is really easier than contributing the web-starter kit repo.
Long story:
=========
Jetty's vision is to be the HTTP-RT library for java; not a framework and not an application server either.
This puts us in an uncomfortable situation when we ship a product. We do need to ship one though.
As a consequence, it has a minimal set of dependencies; and OSGi is not one of them.
The web-starter kit was our take on making a server out of jetty running in equinox.
But history shows that between gyrex, virgo etc we are better off with the community building a product.
What do you think?
Would it be acceptable to only contribute the jetty bundles to the train?
Is it something that will make everyone more comfortable?
Cheers,
Hugues
On Thu, Aug 23, 2012 at 12:11 AM, Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx> wrote:
Am 22.08.2012 16:36, schrieb Mike Milinkovich:
> [..] Gemini is not on the release train either. Virgo wasn't exactly
> enthusiastic about the idea as far as I could tell.
Gemini JPA is actually in the release train repo. They do not
participate but I brought them in because it's a Gyrex dependency. Thus,
even if Jetty drops of the train, I can imagine they'll end up in the
release train repo somehow...
I think there are two things in the release train which are commonly
thrown together in the same bowl but which really are two distinct
things. (AFAIR)
1) Common p2 repo
2) Release on the same date
AFAIK, only point 2 is the really important here but point 1 is the one
that can cause headache.
Am 22.08.2012 16:43, schrieb Jesse McConnell:
> - the process is bothersome, it takes time to maintain the files (and
> go re-figure out what we needed to do when the time came), build
> metadata, p2
> repositories, release docuware, etc
Release docuware is necessary for a release anyway. Producing p2 repos
is also a very important goal to improve adoption. I won't consider
those (and other stuff like IP log, etc.) specific to the release train.
They have to be done for a release anyway. I know that EMO is really
onto reducing the bulk of additional administrative work to make a
release (hint: automation).
Simply put (if you don't aim for option 1), the only additional overhead
of participating in the train is the gazillion lines long questionnaire
in the portal. Frankly, a bunch of questions in this form don't make any
sense at all for RT projects.
However, participating in the common p2 repo is indeed a bit of
overhead. There are also some technical issues which won't help. But
from chats at EclipseCon I recall that this is not necessary
participating in the train.
Thinking about this myself, the only reason Gyrex wants to be in the
common repo is because of those "Target Components". However, especially
if you do (frequent) releases in between (like Jetty does), then those
contributions are outdated very fast anyway.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
