Skip to main content

[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



Back to the top