Re: [ecf-dev] shouldn't ECF Remote Services Target Components feature pr

[Cristiano Gavião <cvgaviao@xxxxxxxxx>]

Yep Win, a tool for that would be life safer :)

But the best tool that I've been using for a long time is the one provided by Igor here [1] .

It is a RCP where you can load any p2 and search for features, packages or capabilities. That help me a lot.

regards,

Cristiano

[1] - https://github.com/ifedorenko/p2-browser

2013/9/10 Wim Jongman <wim.jongman@xxxxxxxxx>

Some more background in https://bugs.eclipse.org/bugs/show_bug.cgi?id=330517

I wish there was some tool to manage features and bundles. It is such a pain to manage it correctly.

I am happy to work with you refactoring the features.

On Tue, Sep 10, 2013 at 2:07 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Cristiano,

On 9/9/2013 4:38 PM, Cristiano Gavião wrote:

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.

Yeah...we/ECF don't get to tell p2 or Eclipse how to structure their features.  FWIW, it's not how we would have chosen to structure things.

I'm assuming that you can create a target platform that has the necessary bundles, however.  I've done this several times myself for server configurations, so if you would like examples I can provide them.   I have used p2 on various servers, although there is no requirement that it be present (i.e. ECF doesn't have any requirements on p2).   For remote services, you should only need org.eclipse.ecf.identity and org.eclipse.ecf bundles (as opposed to all of filetransfer that comes with p2 and Eclipse).

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;

This seems eminently reasonable to me...assuming we can convince the p2 consumers to restructure their features as needed.

I could help with that refactoring when you decide that is ready to do.

Wonderful, thanks very much!  We've been using this bug [1] to communicate about the possible refactorings...would you please copy/paste your above observations into that bug and thereby join it also?

Thanks,

Scott

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=409787

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

_______________________________________________
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

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

--
"Tudo vale a pena se a alma não é pequena..."