Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330517

Summary: Need a feature for core bundles
Product: [RT] ECF Reporter: Wim Jongman <wim.jongman>
Component: ecf.relengAssignee: ecf.core-inbox <ecf.core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bugs.eclipse.org, cvgaviao, krzysztof.daniel, slewis, thatnitind
Version: 3.4.1   
Target Milestone: 3.8.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on:    
Bug Blocks: 409787    

Description Wim Jongman CLA 2010-11-17 15:29:07 EST
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.
Comment 1 Markus Kuppe CLA 2010-11-17 15:32:08 EST
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).
Comment 2 Wim Jongman CLA 2012-12-11 06:50:35 EST
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
Comment 3 Scott Lewis CLA 2012-12-11 15:47:15 EST
I'm +1 for this feature change.   Please coordinate with with me as the changes are made.  Setting target milestone to 3.6.
Comment 4 Scott Lewis CLA 2012-12-11 18:22:18 EST
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?
Comment 5 Wim Jongman CLA 2012-12-12 04:30:02 EST
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.
Comment 6 Scott Lewis CLA 2012-12-12 11:36:59 EST
(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.
Comment 7 Wim Jongman CLA 2012-12-12 11:43:17 EST
> 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.
Comment 8 Wim Jongman CLA 2013-10-08 17:42:36 EDT
(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
Comment 9 Scott Lewis CLA 2013-10-08 20:12:24 EDT
(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.
Comment 10 Scott Lewis CLA 2014-01-27 17:33:29 EST
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