Community
Participate
Working Groups
we need a feature with only ecf and ecf.identity or else we need to include ecf and ecf.identity in all other features. The current ecf.core feature pulls in everything. I suggest to make an o.e.ecf feature with everything and a o.e.ecf.core with the ecf and identity bundles.
An o.e.ecf feature might collide with the o.e.ecf bundle. Thus it might be better to move o.e.ecf and o.e.ecf.identity into o.e.ecf.base (which isn't used right now).
This is biting us again. Looking at the current features there is: org.eclipse.ecf.base which contains o.e.ecf, o.e.ecf.identity and filetransfer bundles org.eclipse.ecf.filetransfer.feature which contains the same as the base feature I would like to propose the following change: base: only contains ecf and identity (and possible ssl if applicable) filetransfer: only contains filetransfer bundles and depends on base http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/releng/features
I'm +1 for this feature change. Please coordinate with with me as the changes are made. Setting target milestone to 3.6.
I would like to understand better what's needed here. Is the use case the need to get/install ecf core and identity bundles without ecf filetransfer?
Scott, in short: yes. We are building a minimal discovery server and we need to include the ECF core and discovery features. We are also getting the filetransfer bundles. The reason why this is unwanted is 1. If some institutions install a server component, they can be really worried about the filetransfer component being in there as this would enable the server to put and get files from the local filesystem. 2. To deploy the minimal set of components as possible. I know that the convenience of feature based install comes with some inconveniences like getting more than you want. Apart from this, I don't think file transfer belongs in the base feature but in its own set. Te disadvantage for the current user base can be that install will not work without first uninstalling the old features. This is something that we need to test or document.
(In reply to comment #5) > Scott, in short: yes. > > We are building a minimal discovery server and we need to include the ECF > core and discovery features. We are also getting the filetransfer bundles. > > The reason why this is unwanted is > > 1. If some institutions install a server component, they can be really > worried about the filetransfer component being in there as this would enable > the server to put and get files from the local filesystem. > > 2. To deploy the minimal set of components as possible. > > I know that the convenience of feature based install comes with some > inconveniences like getting more than you want. > > Apart from this, I don't think file transfer belongs in the base feature but > in its own set. > > > Te disadvantage for the current user base can be that install will not work > without first uninstalling the old features. This is something that we need > to test or document. Ok, seems reasonable. Thanks. If we get the opportunity (i.e. resources again), I would like to broaden this to refactor the ECF features, so as to make easier to consume ECF and ECF remote services for server usage.
> If we get the opportunity (i.e. resources again), I would like to broaden > this to refactor the ECF features, so as to make easier to consume ECF and > ECF remote services for server usage. I will make a plan.
(In reply to Wim Jongman from comment #7) Let's first start with an org.eclipse.ecf.core.feature feature that only includes org.eclipse.ecf org.eclipse.ecf.identity Can we get this in for 3.7
(In reply to Wim Jongman from comment #8) > (In reply to Wim Jongman from comment #7) > > Let's first start with an org.eclipse.ecf.core.feature feature that only > includes > > org.eclipse.ecf > org.eclipse.ecf.identity Pushed a new feature project: org.eclipse.ecf.core.feature in releng/features http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=4fa931109187c894b8293b92d0ebfecc7a8f61fc > > > Can we get this in for 3.7 I don't really think so. Because of p2's/Eclipse's inclusion of the org.eclipse.ecf and org.eclipse.ecf.identity plugins in a p2 feature, adding these plugins could cause significant problems for ECF's install into Eclipse.
Resolving as fixed, as org.eclipse.ecf.core.feature now exists. See also bug 409787 for info about the ECF 3.8 refactoring changes to core feature
