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 :)
It would be easier and cleaner for us to stick with CVS as well (I'm a
fan of SVN, personally) but the build...especially PDE build just gets
more complicated when multiple repositories are used.
>We build both a pure OSGi bundle and an Eclipse plugin and
via a feature. Assuming it's alright with Jan we'd be happy to
>contribute any of these build scripts if it helps.
Ken would it be possible for ECF to use this project/projects and
feature over the next few weeks (so that those of us that want to work
on the SLP provider code in our local workspaces can include an Eclipse
project with the jslp bundle?). Any chance that these projects could
be made available via anonymous CVS (via sourceforge CVS or your own
I know this may not be a quick decision for organization, but it would
be nice not to have to redo what you/company has already done...and
it's a great opportunity to contribute to ECF :).
On 10/12/07, Markus Alexande Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
> Hi Markus,
> This looks really good. Some question (for you and/or Jan) to
> out how to add SLP to the ECF osuosl build.
> To incorporate the jSLP bundle we will have to either
> 1) Build it from source
Some time ago I've floated the idea around of having a continuous build
for jSLP. Why not use ecf1/2.osuosl.org as a build server for jSLP? I
guess it would be as easy adding the SVN url to the map file to fetch
the source from sf.net.
It'd only require minor changes to make jSLP
buildable with PDE rather than Maven (missing build.properties, version
number (.qualifier), ...)
> 2) Copy some version of the jSLP bundle jar into the build area
> the build.
> I would suggest that for now, we do 2, and simply download the
> previously built jSLP bundle jar from some web location at build
> This is easy to do...we do it now for the apache httpclient bundle
> (provided by Orbit project).
+1 as a quick and simple solution for the moment
> One difficulty this introduces, however, is working on
> org.eclipse.ecf.provider.jslp within an Eclipse workspace...as
> no Eclipse project at sourceforge (or is there?) that is loadable
> developer's workspace. Currently you can take the jslp jar and
> to the target platform to get it to compile, but this is not
> you can't do source debugging, etc. Is there some way that an
> plugin project with the jSLP source could be created so that we
> access it via anonymous CVS?
sf.net contains a project usable from inside Eclipse (IIRC
build.properties is missing to turn it into a working bundle). But even
as a precompiled binary project source can still be attached. The source
just has to be included in the bundle.
> If we want to move the jSLP bundle over to dev.eclipse.org,
> point we will have to submit a contribution questionnaire, along
> particular version of the source code to Eclipse Foundation's IP
> review...so at that point, we will have to use a stable version of
> source (since a change in version will trigger an additional legal
> Also, after jSLP has been through this legal review, it might make
> to contribute it to the Orbit project (third party bundles)...and
> the Orbit build would take care of auto-creation of the bundle for
I'm not sure if Jan is really into this, but theoretically it would be
possible to move the whole OSGi jSLP to dev.eclipse.org and license it
under the EPL? Then we would be allowed to continue development directly
ecf-dev mailing list
ecf-dev mailing list