[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF remote services support for Eclipse 3.5.x
|
Are you saying that ecf core is not part of ECF but of P2? If so, then
shouldn't p2 be dependend on the ecf core feauture so that it can be
installed an upgraded separately from p2? This instead of including
it? But if it is installed separately, will P2 still work after
upgrading ECF core?
If some core ecf plugins are refactored as OSGi bundles then they
don't have to be singletons.
Trying to understand this. Will there be à conference today?
Regards
Wim
Op 15 feb 2010 om 00:20 heeft Scott Lewis <slewis@xxxxxxxxxxxxx> het
volgende geschreven:\
Hi Folks,
I think the best option will probably be a p2 'feature patch'. This
will allow us to install the new versions of ECF core plugins into
Eclipse 3.5.1...and after the patch is applied then the ECF 3.2 SDK
will be installable/usable.
Scott
Scott Lewis wrote:
Hi Folks,
ECF 3.2...due to be released this week (Feb 19) has some
dependencies on new code/additions to the ECF core bundle (i.e.
org.eclipse.ecf). These additions were/are needed to support the
OSGi 4.2 remote services specification, which I implemented in
December.
Problem is, the ECF core bundle is distributed with the Eclipse
platform rather than the ECF SDK. The reason for this is that
Equinox p2 uses ECF filetransfer (which depends upon and requires
ECF core), and so ECF core and ECF filetransfer bundles are
included in p2 and Eclipse. The version of ECF core bundle in
Eclipse 3.5.1 is fairly old (Sept 2009) and so needs to be updated
for the remote services work to function.
One consequence for this is that once we release the ECF 3.2 SDK
(Feb 19), it will be necessary for people to get/use an Eclipse
milestone (e.g. 3.6M6) in order to fully use the ECF 3.2 remote
services features. Because of the additions to ECF core described
above, they will be unable to install ECF 3.2 sdk into Eclipse
3.5.1 and seemlessly use the new remote services work. This is
obviously undesirable, because it means that it will make it more
difficult for people to use ECF 3.2 remote services (they will need
to get Eclipse 3.6M5+...or get the ECF core bundles separately to
add them to their target platform).
The question is...what to do? There are a couple of possibilities:
1) Require people to use Eclipse 3.6 milestones to fully use the
new ECF remote services
2) Create a new distribution for Eclipse 3.5.1 that includes the
new ECF core bundle.
3) Create a patch for Eclipse 3.5.1
4) Provide some more documentation for people to work-around
5) Do something else that I haven't thought of
The rub here is that I personally do not have any time to work on
the ECF build this week...and there will probably be work necessary
to do 2, 3, 4, or 5.
Thoughts? Comments? Contributions?
Thanks,
Scott
_______________________________________________
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
