[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] shouldn't ECF Remote Services Target Components feature provide org.eclipse.ecf bundle ?
|
Hi Scott,
I'm setting target platform for Equinox (Kepler and Luna), but I'm
creating my own Equinox feature because until Juno
org.eclipse.equinox.core.sdk had a dependency to
org.eclipse.equinox.security.ui. But seems that they fixed it since
kepler. I'm not using p2.
I could find the ECF bundle in the UI
'org.eclipse.equinox.p2.core.feature' and there are lot of other
features that refers to that feature.
Maybe a good approach would be:
- to split the current 'org.eclipse.ecf.core.feature' (it has too much
things and include lot of UI and example bundles);
- to create a real ECF core feature;
- to create a ECF server, ECF examples, etc and let
'org.eclipse.equinox.p2.core.feature' that references the ecf core
feature instead of the ecf bundles;
I could help with that refactoring when you decide that is ready to do.
thanks anyway,
regards,
Cristiano
On 09/09/13 17:08, Scott Lewis wrote:
On 9/9/2013 12:27 PM, Cristiano Gavião wrote:
Hello,
I'm using an Eclipse IDE where I didn't install ECF ('ECF Target
Components for Eclipse') and I'm setting a new "slicer" target
platform definition for a server application.
I noted that after set this definition as the workspace target
platform the ECF bundles contained in that feature are complaining
about a missing required org.eclipse.ecf bundle.
wouldn't the "ECF Remote Services Target Components" feature be
enough for a server (no UI) target definition?
Ideally, yes. But unfortunately this is complicated by p2's
dependency on ECF file transfer...and file transfer is dependent upon
org.eclipse.ecf core and org.eclipse.ecf.identity). Effectively, ECF
core, identity, and filetransfer are distributed as part of p2, which
is distributed as part of Eclipse. This creates a bit of a problem
for us and consumers...as you are experiencing...since remote services
naturally has a dependency on org.eclipse.ecf core and identity. In
effect, core and identity are a part of Equinox rather than part of ECF.
If you are not using Eclipse as your target platform, you will need to
include in your target platform some version of org.eclipse.ecf ...as
well as other parts of OSGi/Equinox that ECF Remote Services Target
Components depend upon (e.g. org.eclipse.equinox.common, equinox
registry, event admin, etc). Here is a full/complete list of all the
RS Equinox dependencies [1].
I'm not sure how you create your target platform, but FWIW I've found
that using a release version of Eclipse (or Equinox SDK) is a good
start, as it includes org.eclipse.ecf (core) and identity.
I would like to set as a goal for ECF 3.8 the refactoring of ECF's
features to provide for an easier/better server build/install
experience...on Felix, Karaf, as well as Equinox. With p2 (and it's
build/releng) in a mature state this should now be doable...it was not
when this packaging was put in place. But I suspect we are going to
need some contributions and/or scenario testing...from either
committers or contributors...to make this happen.
Thanks,
[1]
https://build.ecf-project.org/jenkins/job/C-HEAD-osgi.services.feature/lastSuccessfulBuild/artifact/site.p2/karaf-features.xml
First 9 bundles...as well as org.eclipse.ecf, and
org.eclipse.ecf.identity.
If I add the 'ECF Target Components for Eclipse' into the targe
definition too I have a problem since it has UI dependencies...
regards,
Cristiano
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev