[
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
|
I had thought of that. The major ids of note are some build
configuration data items that get stored in a file so I left those
particular ids alone in the plugin.xml files. There are some settings
that I was not concerned with preserving as they are either rarely
changed or not inconvenient to do again if necessary. Build
configurations on the other hand can be quite detailed.
Thinking about it, is is also possible to simply move the
plug-ins/features without any name refactoring. The idea is more that
the CDT should ship them by default. Would it be recommended practice
when moving to not perform refactoring? (e.g. I could create a new
feature in the CDT name-space and it removes the old feature/plug-ins
using a dummy IU in the p2.inf file, but it itself refers to old plug-in
ids that are now shipped with the CDT). This would eliminate any update
issues including the minor settings.
-- Jeff J.
On 01/12/2012 09:01 AM, Henrik Lindberg wrote:
One thing to think about is what you need in terms of migration -
changing all of the bundle ids may affect saved meta data (settings
etc.). If you like to preserve those they need to be migrated. p2 can
not do this for you, you need a "one shot bundle" that does this when
activated.
Regards
- henrik
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx <mailto:henrik.lindberg@xxxxxxxxxxxxxx>
On Jan 11, 2012, at 20:58, 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 <mailto: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
