Skip to main content
[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 take this in reverse order:


Aussies....


Jeff McAffer wrote:

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.


A maven repository is indeed technically trivial and should be easy to
setup, specially if we can have some form or repository manager to help.
But the important part of a repository is the process and reproducibility of it. For example, the central maven repository goes to some lengths to make sure that it is write only and you can trust that something that 
was called version 1.2.3.4 will never ever ever change.

So we would need to make sure that the eclipse repository was
protected with similar processes (procedural and technical) to
ensure the repository is good.  As mike has suggested, this
can be based on the existing Orbit process so should be moderately
easy.
Interestingly my Eclipse-centric point of view held that stuff from eclipse.org was much more trusted in this regard. The management policies for the maven repo are unknown to me. It might be interesting to see if the Eclipse foundation/community could come to trust the maven repo and infrastructure. Until such time it seems implausible that eclipse.org would ship bytes that come from an "as yet" untrusted source on a regular basis without review. It is much more realistic to say that projects identify bytes they want to ship, get them cleared and then host them on eclipse.org. 


But importantly, the jars available from the eclipse repository
might differ from those available elsewhere, because they may
have been through eclipse conditioning.   It is very important
that this difference be flagged in the either groupId, artefact
ID, classifier or version.    So for example a jar available
from maven central repository as


sure. See my reply to David related to this.


Also, it would be good to leverage the capabilities of maven
to associate source, javadoc and xref with entries in a repository.
After all it is the source that is audited and maven will allow
that source to be in the repository and tools (such as m2eclipse)
automatically download and navigate into that source as you
develop and/or debug with these jars.
Is all this captured in the POM? Is anything else needed other than more data in there 


But there is still an issue with the JSP short term.


Trouble-maker


We aspire to have a quality JSP implementation available in the
eclipse repository.  However, we can't say how long that process
will take as Jasper is a project with a chequered history.
It has been forked and forked again, maintainers have moved about
and contributions have been done under several different systems.

We cannot see how JSP can be cleared in the time frame in which we
wish to make a Jetty-7 release, so our options are:

  0) don't include JSP in the downloads from eclipse.  Point users
     at the codehaus for JSP.

This may be the near term solution.


  1) Give the JSP jars some special consideration so that they
     are included in the jetty@eclipse downloads, but they are
     explicitly excluded as not audited by eclipse.
Not sure we have a structure for doing that. Perhaps if the JSP support were in "incubation" but even then... 

  2) Delay Jetty-7 until JSP is audited.
Personally I do NOT think that we should do this. The broader Eclipse community will ship again in year. This needs to be sorted out by then. Prior to that there will certainly be some projects wanting to adopt Jetty@eclipse and JSPs but this will be rare. 


Maybe we are wrong about the time it will take to CQ JSP.

So let's at least start the CQ process for JSP.  We'll submit one
in the next day or so.    Maybe it will pass moderately painlessly
and option 2) above will be possible.


here's hoping


But in parallel, it would be good if we could have some opinions
if option 1) is even an option?
As mentioned, I'm not sure it is an option. AFAIK eclipse only ships approved stuff. Incubating is the only way we have of marking something as "not quite up to normal standards". The IP team might be able to advise. Perhaps there is something I'm missing. 


Failing that, once we get Jetty-7 ready and option 2) is not
ready, then we can decide to go option 0)
Yeah, I suggest identify the end goal and then full steam ahead. IMHO the end goal is Jetty core with JSP support shipping from Eclipse.org in June 2010 all CQ'd and tidy. 

Make sense?
Jeff

Back to the top