Re: [ecf-dev] ECF Feature Restructuring

[Wim Jongman <wim.jongman@xxxxxxxxx>]

Ok thanks. And the org.eclipse.osgi.xxx bundle used by ssl cannot be added to that mix?

On Sat, Dec 7, 2013 at 9:50 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

On 12/7/2013 12:21 PM, Wim Jongman wrote:

There are equinox references all over the place. What equinox bundles run in e.g. Felix and which ones do not? Didn't M. create a Felix ECF installation with PAXRunner a while ago?

Yes, he did.  Here's the ECF4Felix info (this was for pax runner):

https://github.com/ECF/ECF4Felix

As it says here, this has been superseded by the karaf-compatible features as described here

http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg06391.html

Here's the necessary set for OSGi remote services specifically...Markus probably has this common set distinctly defined somewhere...i.e. separate from the karaf features...but he will have to explain where that is/how to access that common set definition:

http://download.ecf-project.org/repo/C-HEAD-osgi.services.feature/lastSuccessful/archive/site.p2/karaf-features.xml

The summary answer to your question about equinox bundles necessary to run in Felix is:

o.eclipse.equinox.supplement
org.eclipse.equinox.common
o.e.e.registry
o.e.e.concurrent
o.eclipse.core.jobs
org.eclipse.osgi.services (OSGi services declarations...e.g. EventAdmin, LogService)
org.eclipse.equinox.event (Equinox EventAdmin...I believe Felix's EventAdmin could now be used but haven't tested)
o.e.e.log (Equinox's LogService implementation...I don't believe this LogService impl is strictly required)

All of these run fine on Felix (older versions of Felix were missing an xml parser required by the registry bundle, but I believe that Felix now has the required xml parser impl by default).

Scott

On Fri, Dec 6, 2013 at 8:50 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Folks,

A little historical background on org.eclipse.ecf.ssl.

First, as Wim has said, it's a fragment, who's host is org.eclipse.ecf (all the org.eclipse.ecf.*.ssl are fragments). 

It was created/contributed by the Equinox team...because it uses the Equinox TrustEngine service (org.eclipse.osgi.service.security.TrustEngine) in combination with the SSLSocketFactory.

I think it would make sense to have the *.ssl fragments in separate features...because then they could be easily excluded for/in non-Equinox installations.

Scott

On 12/6/2013 11:11 AM, Wim Jongman wrote:

sorry not part of oee.core but of oe.ecf 

On Fri, Dec 6, 2013 at 8:09 PM, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:

Well, it is not at the moment. It is a suggestion to add it in.

The reasoning is that oee.ssl is a fragment of oee.core so it always need to go with core somehow. I thought it could go here since it has no additional dependencies, it is part of the framework and it is really small.

On Fri, Dec 6, 2013 at 7:59 PM, Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:

On 12/06/2013 05:32 PM, Wim Jongman wrote:
>
> I took a stab at visualizing the features. I have started with the core
> and the filetransfer features and we can work our way down. I have tried
> to be as complete and componized as possible.
>
> https://docs.google.com/presentation/d/1be8k_HqSqXN2nMHLOiVf6o8mWeLs0mVMNHD4Qnujv80/edit?usp=sharing
>

It might be obvious, but why is o.e.e.ssl part of o.e.e.core.feature?

M.
_______________________________________________
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