[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse
|
I'll respond to all the various points in one go. (at least I hope I
get them all)
First, I and I believe the rest of the RT PMC are sympathetic to the
situation and quite appreciate that the Jetty team is taking the time
to work out a solution. Thanks!
It might help to talk about code as different types.
1) source you write at Eclipse
This is well understood by all I think
2) source you didn't write but is at eclipse for whatever reason
This has to be IP cleared and is essentially adopted and becomes like #1
3) binary that you get from somewhere else and reship at eclipse
This has to be IP cleared
4) binary that you expect users to get somewhere else
This dependency needs to be classified as either a works with or a
hard dependency. In the former, most of the time you are good. In
the latter case either things are good or you need an exemption (e.g.,
gcc fails the test but is the only reasonable c compiler).
5) binary/source that you compile against but do not ship from eclipse
This is like the Java class libs. not sure anyone cares about this
other than as it pertains to #4
Greg's characterization below gives
a) ship the stuff that jetty@eclipse produces = #1 and perhaps #2.
great
b) ship all of what people typically consume that is "Jetty".
Desirable but frankly I don't think this is feasible from an IP
perspective nor is it particularly required at this point.
c) ship jetty@eclipse plus things like JSP = #1 and (#2 or #3)
Personally I am after c). It is clear that Eclipse needs JSP support
and there may be a few other little things that make sense. In the
JSP case in particula, it would be goofy if we have Jetty@Eclipse and
yet continue to ship the JSP support from Tomcat. Especially is if it
deemed inferior. So how do we get there. I really don't know how big
a mess this is from an IP point of view but I'm willing to back
putting the "right" JSP support code in a CQ and starting in on it.
We should work with the IP team to understand if it is better to do #2
or #3 but frankly, as a consumer, I don't really care. As long as we
can get it from Eclipse.org and it has been IP approved, we're golden.
Now, the build topic. I have three main concerns and one non-concern.
0) It should not matter where you get stuff that you compile against
as long as the same or equivalent content is available to others in
the community so they too can participate in the project (see form #5
above). So you can fetch from maven central, host your own maven
repo, ... doesn't matter. However!
1) We must ensure that the code (and I mean the actual bytes, not just
"yeah, someone said it was the same version") you actually *ship* from
Eclipse servers is IP cleared. Here the concern is not what you
compile against etc but what you ship off eclipse.org. The concern is
where did the bytes come from, when and are do they match what was
cleared. AFAICT the only way to deal with that is to have a copy on
eclipse.org and use that. Relying on the maven central repo feels
problematic in general. There may be particular cases where exactly
the *bundle* (you are shipping bundles right?!) you need and have
cleared is there and you are able to spec in your Maven metadata the
particular version but that does not seem to be the norm today.
2) Related is whether or not the thing being shipped off eclipse.org
has been tested in the configuration shipped (i.e., the set of bytes
shipped has been tested together). If your build gets stuff from all
over, compiles, tests and then ends up shipping with some JARs (oops,
bundles) replaced, you are shipping untested configurations.
3) No eclipse project is an island. For example, to have Jetty in
Helios we would like to have some level of coordination between the
third party bundles used by Jetty and those used by the rest of
Eclipse. If Jetty is getting and shipping/expecting code/bundles from
various other places it is unlikely that these will match up with the
rest of Eclipse and there will be issues.
Good news is that I think there are reasonable paths on all these
fronts.
Having a maven repo at eclipse.org is trivial. Maven repos are just
disk layouts. When you get some code approved for use in Jetty, put
it in the right spot on your part of eclipse.org and away you go.
(hmmm, I could be naive about that but it "should" work no?). It
should be easy to have the Orbit build spit out a maven repo format.
This effectively addresses all issues no?
Jeff
On 14-Jul-09, at 9:59 PM, Greg Wilkins wrote:
All,
I'd just like to follow up on Jesse's email with a little more
information.
It may be convenient to think of jetty in two ways.
Firstly there is the Jetty as a code base which includes the
core HTTP server/client and a servlet container. This core
is available as jars either from the central maven repository
or from the eclipse update site that we build.
Secondly there is Jetty as an application server, which includes
the jetty code base, but is bundled with other third party
code into something that can be downloaded and used with
"the usual" services associated with an application server.
These include JSP engine, clustering support, tools integrations,
transaction managers, JDBC drivers etc.
So for the core jetty code base, we are close to being OK.
We have CQs (or are getting CQs) for all of our dependencies
and there are no really difficult ones in there (other than
some standard APIs that have not yet been actually released
yet). The only real issue here is that we consume these
dependencies from the central maven store and not from
eclipse servers.
If eclispe could provided these CQ'd dependencies in a
maven repository, then jetty could consume them from there.
However, if these jars are processed into eclipse bundles,
then they will need to be identified slightly differently
to the artefacts from the central maven repository (perhaps
with an -eclipse classifier).
I think this is most necessary for the dependencies of
the core code base: servlet-api, slf4j etc.
It is the application server download that is the difficult
one. It would be considerable effort to IP clear all
the common inclusions in such a bundle: JSP, clustering,
JTA etc.
So I see we have several choices:
a) Don't make such a download available from eclipse. Only
the jetty components would be available. For the
application server style download, you would either
need to get additional components or an optioned up
download from codehaus. This is the path that we
originally intended to take when we asked to move
the core to eclipse.
b) Put the full application server dependencies through
the standard eclipse IP process and eventually produce
an IP cleared application server. While possibly
the "correct" route, this may be confusing as it could
be seen as THE eclipse application server, even though
it is not using OSGi. It would also raise questions
about certification of the server as either a servlet
container, or JEE container etc.
c) Take a pragmatic middle ground. JSP is the key
additional dependency that many users would like in
both app server and embedded environments. Find
some way to IP clear the bundling of the JSP component
with the Jetty download so that many/most users would
be content with just that. For clustering, JTA, etc.
users would still be directed to codehaus for those
additional modules - but there could be ongoing efforts
to IP clear them and bring the code to eclipse.
We are continuing to work towards a)
But we have received feedback from eclipse members that
they really would like JSP to be included - so that is
suggesting we should aim for c)
If anybody wants b), then I think significant extra
resources need to be found to work on that.
cheers
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
