[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[rt-pmc] [Fwd: Re: [jetty-dev] Eclipse and JSP]
|
Forwarding to the rt-pmc list too ...
-------- Original Message --------
Subject: Re: [jetty-dev] Eclipse and JSP
Date: Fri, 07 Aug 2009 16:53:05 +1000
From: Jan Bartel <janb@xxxxxxxxxxx>
Reply-To: janb@xxxxxxxxxxx
Organization: Webtide
To: Jetty @ Eclipse developer discussion list <jetty-dev@xxxxxxxxxxx>
CC: Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>
References: <a43524d00907290857i4c42ab82r236e0da65df64de1@xxxxxxxxxxxxxx> <2103740B-985E-4317-98C8-182E94769693@xxxxxxxxxxxxxxxxx>
Hi Jeff,
As you are probably aware now, jetty has chosen the glassfish jasper
fork as the core source that we minorly patch and release artifacts
for use in jetty. The CQ's related to this are pending now so that we
can review this approach and perhaps adopt a more eclipse wide
solution that more folks can make use of.
To that end my initial recommendation would be to have the glassfish
source that we use run through the IP process
+1
and then setup a project
in eclipse svn (org.eclipse.jsp under RT perhaps) that we then import
the source into and massage into the format we want.
I suggest that we just put it in the Jetty project. No real need to
start a new project for this. It is logically part of Jetty in the
Eclipse context and is indeed, your cut on JSP support so...
Before we moved to Eclipse, we had factored the JSP code out of the jetty
project and put it into its own sub-project with its own svn root. We did
that because the life cycle of the JSP code can be different to that of
jetty. We periodically update the glassfish JSP tag that we checkout, but
it is not the case that the tag changes with each and every jetty release.
This arrangement meant that we could consume the same already-released
JSP artifacts across multiple jetty releases, without having to rebuild
and re-release unchanged code with an updated version number for each
jetty release. I'd hope we'd be able to achieve something similar at
Eclipse?
I would be more
then happy to make sure these things could be built and deployed in
the existing maven infrastructure in the short term while the eclipse
organization comes to terms with how it will support maven projects
better, so long as someone else could volunteer to help in making the
eclipse orbit oriented artifacts as well.
If you are getting source from someplace, hacking on it, building it and
shipping it, it does not need to come from or be put in Orbit. You
would have Jetty that *produces* JSP support. (period). That is one of
the outputs of the Jetty project. The fact that you did that by getting
source code from somewhere else, hacking on it etc is immaterial (as
long as the acquisition of the third party source was approved through
the IP process).
I'm very happy for Jetty to act as the stewards of the JSP support at
Eclipse, but I'm cautious about what you mean by making it "part" of
the Jetty project? Would we be able to separately build and release
the JSP code as described above? Ideally Jetty wants to be a consumer
of JSP, not a producer :)
cheers
Jan
With this sort of structure
in place I would suggest that we keep it incrementally updated with
new tags as glassfish folks patch and update their jasper fork until
such time there is some global unified effort to bring all the jasper
forks back under home, should that ever happen of course.
You are essentially driving your own fork of the glassfish JSP support
now and would continue to do so. You would, as you do now, periodically
get updates from glassfish and merge them all or in part into your code
stream. The difference is that before getting the new glassfish stuff
you have to do a CQ for the new code.
Make sense?
Jeff
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev
--
Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
--
Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
