Markus Alexande Kuppe wrote:
Ken Gilmer wrote:
Hi Guys ~
We use jSLP internally and build from source from an internal CVS
server. We build both a pure OSGi bundle and an Eclipse plugin and
reference it via a feature. Assuming it's alright with Jan we'd be
happy to contribute any of these build scripts if it helps. Also note
that it was our experience (3 - 4 months ago) that building from an SVN
repository is not just a matter of changing the Map files, and it was
easier and cleaner for us to stick with CVS. If this is no longer the
case I'd love to know :)
TBH I don't have any experience with fetching from SVN. I've heared
about a fetch provider for PDE though.
But with Jan willing to donate OSGi jSLP to ECF, we luckily don't face
this problem anymore. :)
OK, this is great. Thanks Jan (and Markus)! So I suggest we should
proceed on two threads:
1) In the short term (next week), we (Markus, myself, and Ted) work to
add the SLP provider to the osuosl build, by retriving the current jslp
bundle (at http://downloads.sourceforge.net/jslp/jslp-osgi-1.0_RC1.jar)
during build (via map file http fetch...like we do now with Orbit
httpclient). We will use the current version of jSLP (1.0M2) and
distribute both the jslp jar binary and Markus' SLP provider bundle via
a new osuosl feature (e.g. org.eclipse.ecf.provider.).
Scott: create new feature for ECF SLP and put up on ecf1.osuosl.org
Markus: Add appropriate about.html to ECF SLP bundle, checkin provider
test code (to ecf1.osuosl.org tests module). (bug
Ted (and Scott): Add feature created above to osuosl.org build (and
associated/needed map files of course). And add to those
distributed via http://ecf1.osuosl.org. (bug
2) Proceed with getting both jSLP and the ECF bundle contributed to
dev.eclipse.org. This doesn't have to be done immediately, but rather
over the next several weeks (or longer). So steps here are (don't be
intimidated by this...I just want to describe what needs to happen and
it's not as much work as it might appear):
1) Get jSLP to 1.0 final (make necessary additions and changes). I'm
perfectly willing to help with this if desired (we're all busy after
all), but we all will probably need some technical guidance from Jan to
make this happen. Jan do you have an idea of how much is needed here
and how long it's likely to take?
2) Figure out the licensing strategy that Jan (I assume the only
copyright holder of jSLP) is willing to accept. There are a couple of
a) Dual license under BSD (current) and EPL (dev.eclipse.org).
This is easiest from the Foundation point of view, as contributions
under EPL are *always* easier/faster for the EF legal review.
b) License under BSD only, and submit to eclipse.org as a
contribution under a compatible third-party license (after 1.0 final is
read). This is completely doable, but because BSD is a non-EPL license
this will take the EF longer, once we submit a CQ.
c) License under EPL only. This would mean changing the licensing
on sourceforge...if the codebase is intended to remain at sourceforge.
Jan: What licensing strategy works for you?
3) After 1.0 is ready, and decision for '2' is made, then submit
IPZilla Contribution Questionnaires for
a) jSLP bundle (with 1.0 source and appropriate license)
b) ECF SLP provider code (with current source under EPL)
Scott and/or other committers: Submit CQs for jSLP and ECF SLP
4) Verify the maintenance strategy for jSLP that Jan (and Markus and
Ken I suppose) would like to undertake. That is, once we contribute to
dev.eclipse.org we'll probably have to identify a committer willing to
maintain the code (e.g. bug fixes, etc). I'm willing to take part in
this support, but it will probably require either Jan and/or Markus to
commit to *some small* amount of subsequent support (i.e. fixing of
critical bugs, etc).
Scott, Jan, Markus: Figure out a way to maintain jSLP code.
ecf-dev mailing list