[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Preserving update path for feature that is moved/refactored
|
Further information. We use tycho for our build and I am also testing
this via PDE export deployable feature.
The following is my p2.inf file:
units.0.id=org.eclipse.linuxtools.gprof.feature.group
units.0.version=0.8.0
units.0.touchpoint.id=org.eclipse.equinox.p2.osgi
units.0.touchpoint.version=1.0.0
units.0.singleton=true
units.0.update.id=org.eclipse.linuxtools.gprof.feature.group
units.0.update.range=[0.0.0,0.8.0)
units.0.update.severity=0
units.0.properties.1.name=org.eclipse.equinox.p2.name
units.0.properties.1.value=%featureName
units.0.properties.2.name=org.eclipse.equinox.p2.description
units.0.properties.2.value=%description
units.0.properties.3.name=org.eclipse.equinox.p2.provider
units.0.properties.3.value=%provider
units.0.properties.4.name=org.eclipse.equinox.p2.type.group
units.0.properties.4.value=true
units.0.provides.1.namespace=org.eclipse.equinox.p2.iu
units.0.provides.1.name=org.eclipse.linuxtools.gprof.feature.group
units.0.provides.1.version=0.8.0
units.0.provides.2.namespace=org.eclipse.update.feature
units.0.provides.2.name=org.eclipse.linuxtools.gprof
units.0.provides.2.version=0.8.0
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=org.eclipse.linuxtools.gprof.feature.group
requires.1.range=[0.8.0,0.8.0]
instructions.configure=\
org.eclipse.equinox.p2.touchpoint.eclipse.addRepository(location:http${#58}//download.eclipse.org/technology/linuxtools/update,type:0,name:Linux
Tools,enabled:false); \
org.eclipse.equinox.p2.touchpoint.eclipse.addRepository(location:http${#58}//download.eclipse.org/technology/linuxtools/update,type:1,name:Linux
Tools,enabled:false);
I find that without the lines starting with "requires.1", the unit
referring to the old feature group does not get added to the content.xml
file. With the requires statement, it does. Is there anything wrong
with this approach?
On 02/13/2012 03:36 PM, Jeff Johnston wrote:
Actually, I am having problems getting this to work as specified.
Do I need to create a dummy feature as well with no plug-ins with the
aforementioned lines in its p2.inf file or should I add these lines to
the current feature with the new name? I tried adding the lines to the
current feature with the new name. I tried using the old feature id as
well as its group id in separate builds.
In one particular case, the old feature name was
org.eclipse.linuxtools.gprof and the new feature is
org.eclipse.linuxtools.gprof.feature.
I tried adding the lines into the p2.inf for
org.eclipse.linuxtools.gprof.feature and didn't see anything listed in
either content.xml or artifacts.xml. I tried specifying
org.eclipse.linuxtools.gprof (old feature id) and
org.eclipse.linuxtools.gprof.feature.group just in case. No difference.
Should I see something in either artifacts.xml or content.xml?
I originally tried testing with an old update SR1 update site to install
and the new one to update to see if Search for Updates would find
anything. None of the features I added these lines to showed up, but I
got an error on gprof trying to resolve its dependencies claiming it
couldn't have both version x and y installed at the same time where x
was the old version and y was the newer version. The feature does not
restrict the version of its dependency features and just says 0.0.0.
Any ideas?
-- Jeff J.
On 01/12/2012 02:39 PM, Jeff Johnston wrote:
Thanks, that was exactly what I was looking for.
-- Jeff J.
On 01/12/2012 01:25 AM, Mengxin Zhu wrote:
Looks like you want to remove the old version of Autotools feature when
installing new Autotools feature that will be moved to CDT. I guess the
moving will rename the plug-ins, so it won't be an updating of old
Autotools. It might cause duplicated UI widgets.
You can use p2.inf to create some dummy IUs of old plug-ins. P2 will
update the existing old Autotools feature to the dummy version when
installing new Autotools.
For example,
The name of old Autotools feature is
'org.eclipse.linuxtools.somefeature', its version is 2.0. Create a dummy
IU for it with version 3.0, but it doesn't have the actual plug-ins.
After updating old feature to this dummy one, the old feature and its
plug-ins will be removed.
units.0.id=org.eclipse.linuxtools.somefeature
units.0.version=3.0.0
units.0.touchpoint.id=org.eclipse.equinox.p2.osgi
units.0.touchpoint.version=1.0.0
units.0.singleton=true
units.0.update.id=org.eclipse.linuxtools.somefeature
units.0.update.range=[0.0.0,3.0.0)
units.0.update.severity=0
units.0.provides.1.namespace=org.eclipse.equinox.p2.iu
units.0.provides.1.name=org.eclipse.linuxtools.somefeature
units.0.provides.1.version=3.0.0
Mengxin Zhu
On 01/12/2012 03:58 AM, Jeff Johnston wrote:
Hello,
I posted to the p2-dev forum and didn't see any response so I thought
I would try here as well.
I am in the midst of moving a feature and its plug-ins (Autotools)
from the Linux Tools project into the CDT. I have looked into
supporting old projects created with the old pre-refactored plug-ins
and it is feasible. Supporting old projects would be desirable since
there can be a number of configurations associated with the project
and currently converting the project over destroys this data.
What I am thinking of doing is to create a shell Autotools feature
that requires the new CDT version of the plug-ins. When a user tries
to update via the Linux Tools update site, they will end up requiring
the new version of CDT that contains the Autotools functionality. I
need to create a shell plug-in as well that specifies the previous
builder id and ties this to the new CDT class as the builder extension
automatically adds in the plug-in portion of the id.
Conceivably I could include the shell feature and plug-in both in CDT
itself and with Linux Tools so that there would be no way of ending up
with both old and new versions present at the same time (duplicate UI
widgets such as menus).
Is there a better p2 way of doing this to ensure updating works
properly?
Regards,
-- Jeff J.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
