[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[rt-pmc] Re: [jetty-dev] Eclipse and JSP
|
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 suspect miscommunication here... When I say "project" here I mean
Eclipse Foundation Project as per the development process
documentation. In this case, something that would be a peer of Jetty.
I am saying that that is NOT needed. It would imply a separate mailing
list, newsgroup, bug list, repo, ... You may be talking about
projects in SVN or the Eclipse IDE or even Operating Projects under
Jetty. If that is the case, sure, whatever works for you.
In any event, if I understand the essence of this, there is a build or
SVN related issue that drives you to want a completely separate SVN
repo to hold the JSP code. The issue is not clear to me but I don't
really need to know. If there is an infrastructure requirement for
another SVN repo then we should talk to the webmaster to get another
repo. That should not drive the creation of another Project.
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 :)
You touch it, you own it. Stewardship of third party code happens in
Orbit where people get binaries, pimp them a tad and reship. As I
understand it, you get source, change it, build it and then ship it.
You are the producer. The fact that 99.999% of the source comes from
somewhere else is an implementation efficiency.
As to your build questions, sure, build whatever you like. You can
ship/release things on whatever frequency and partitioning you like as
well (still need release reviews). Nothing about the project
structure or content should force a particular build or release
structure.
So, to be concrete, my recommendation...
- create an Operating Subproject under Jetty for "JSP support". You
may or may not want to have a distinct mailing list and news group,
website, ... (I suggest not). You should likely have a distinct
bugzilla bucket under Jetty.
- seek to setup whatever repo structure makes sense (I am tangentially
interested in how the need to change infrequently would drive the need
for a separate repo but if its what you need, +1)
- Get the JSP source from wherever (subject to CQs of course) and put
it in the JSP subproject's SVN repo location in the structure of your
choosing
- patch, hack, twist, fold and perforate as desired
- Build what you need when you need it
- Release what you want when you want.
Make sense?
Jeff
