Home » Eclipse Projects » Equinox » Re: Classic Update Capability and P2
| Re: Classic Update Capability and P2 [message #112281] |
Fri, 20 June 2008 18:55  |
 Mark Melvin
Messages: 118
Registered: July 2009 |
Senior Member |
|
|
So to answer my own question, it appears that my installer functions fine,
and P2 appears to run fine. However, the update site contained in all of
my installed features is not in the list of sites to query when looking
for updates. Now I don't think this is a matter of generating metadata
and putting it on my site as Eclipse isn't even querying my site for
metadata to begin with. I believe there is something else I am going to
need to do to get it into the list of "blessed URLs" that appear in the
Available Software list by default.
If I click on "Manage Sites..." I can see my update site URL way down at
the bottom of the list, but my question is - why is that all of my
features show up in the "Installed Software" list, but the update site
declared in those features is not in the active list of sites to search?
If I click on "Update..." my site is not queried and thus updates are
never found for my features. However, if I flip over to the "Available
Software" page and manually add my site from the Manage Sites... dialog,
it is then queried. How can I get my site in the list of Available Sites
automatically?
Oh and the other bit of sweetness I just discovered is that because we
base our product on the core platform instead of the full SDK, there is no
preference page available for the "Capabilities", so I can't even turn on
the old update manager manually. It looks like this is contributed by the
SDK feature, which is not in the core platform and is the source of bug
130502 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=130502) - which is a
WONTFIX.
Mark.
--- Original Post ---
Hi There,
For various reasons we are not able to ship our product based on P2 - the
main reason being we heavily depend on install handlers and simply do not
have time to port everything to touchpoints. So, for our upcoming release
to be based on Eclipse 3.4 we are planning on continuing to use the old
Update Manager. Up until now for our internal milestone releases based on
Eclipse 3.4, I have been using the script to manually remove P2 from the
version of the Eclipse platform that we install. Because we would like to
*eventually* move to P2 I would like to leave P2 alone and ship on a
standard Eclipse 3.4 platform runtime. So my question is - will this
create "issues" if I do not remove P2 from the platform, but essentially
use the Update Manager exclusively for the time being?
Secondly, our installer will be calling the update manager from the
command line to do its installation/uninstallation of features. Do I need
to specifically "enable" the update manager to avoid problems or am I
correct in assuming that the Update Manager Capability that is turned off
by default is simply a UI filter and does not prevent the update manager
plugins from loading if required? Also, would it cause problems to enable
this capability while P2 is installed?
Can anyone think of any other issues I may encounter?
Thanks in advance,
Mark.
|
|
| | | |
| Re: Classic Update Capability and P2 [message #112355 is a reply to message #112281] |
Mon, 23 June 2008 14:36  |
Eclipse User |
|
|
|
Originally posted by: eclipseng.arthorne.com
I'm a bit confused, because you said you were using classic update, but
the issues mentioned below in the installed/available software tabs is
in the p2 UI.
To answer your question though, p2 takes a different approach with
repositories from Update Manager. In UM, you performed queries and
install operations against a single repository. p2 instead searches
across all enabled repositories whenever you query for updates or
perform installs. We initially enabled all repositories by default,
but the performance impact of doing this in something like Ganymede with
20+ repositories was too great. So, we were forced to disable
repositories by default and leave it up to the user to enable the
repositories they want to operate on. This of course is not ideal and is
likely something we will revisit in the next release.
--
Mark Melvin wrote:
> So to answer my own question, it appears that my installer functions
> fine, and P2 appears to run fine. However, the update site contained in
> all of my installed features is not in the list of sites to query when
> looking for updates. Now I don't think this is a matter of generating
> metadata and putting it on my site as Eclipse isn't even querying my
> site for metadata to begin with. I believe there is something else I am
> going to need to do to get it into the list of "blessed URLs" that
> appear in the Available Software list by default.
>
> If I click on "Manage Sites..." I can see my update site URL way down at
> the bottom of the list, but my question is - why is that all of my
> features show up in the "Installed Software" list, but the update site
> declared in those features is not in the active list of sites to
> search? If I click on "Update..." my site is not queried and thus
> updates are never found for my features. However, if I flip over to the
> "Available Software" page and manually add my site from the Manage
> Sites... dialog, it is then queried. How can I get my site in the list
> of Available Sites automatically?
>
> Oh and the other bit of sweetness I just discovered is that because we
> base our product on the core platform instead of the full SDK, there is
> no preference page available for the "Capabilities", so I can't even
> turn on the old update manager manually. It looks like this is
> contributed by the SDK feature, which is not in the core platform and is
> the source of bug 130502
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=130502) - which is a
> WONTFIX.
>
> Mark.
>
>
> --- Original Post ---
>
> Hi There,
>
> For various reasons we are not able to ship our product based on P2 -
> the main reason being we heavily depend on install handlers and simply
> do not have time to port everything to touchpoints. So, for our upcoming
> release to be based on Eclipse 3.4 we are planning on continuing to use
> the old Update Manager. Up until now for our internal milestone releases
> based on Eclipse 3.4, I have been using the script to manually remove P2
> from the version of the Eclipse platform that we install. Because we
> would like to *eventually* move to P2 I would like to leave P2 alone and
> ship on a standard Eclipse 3.4 platform runtime. So my question is -
> will this create "issues" if I do not remove P2 from the platform, but
> essentially use the Update Manager exclusively for the time being?
>
> Secondly, our installer will be calling the update manager from the
> command line to do its installation/uninstallation of features. Do I
> need to specifically "enable" the update manager to avoid problems or am
> I correct in assuming that the Update Manager Capability that is turned
> off by default is simply a UI filter and does not prevent the update
> manager plugins from loading if required? Also, would it cause problems
> to enable this capability while P2 is installed?
>
> Can anyone think of any other issues I may encounter?
>
> Thanks in advance,
> Mark.
|
|
|
| Re: Classic Update Capability and P2 [message #112378 is a reply to message #112355] |
Mon, 23 June 2008 16:18 |
Mark Melvin
Messages: 118
Registered: July 2009 |
Senior Member |
|
|
Hi John,
Yes, we are using the classic update manager to install and uninstall our
features (via our installer from the command line) because P2 does not
support install handlers from the command line. However, as I said - we
eventually want to move to P2 so I was hoping that we could still ship our
product based on a standard Eclipse 3.4 platform runtime (meaning we don't
hack it up to physically remove P2), and from the user's perspective (in
UI-mode) it would "just work" if we provided proper P2 metadata on our
update site (they may be prompted to revert to the classic UM when an
install handler kicks in, but it would still "work"). Then, in a future
update, we could magically P2-enable our features (ideally).
With respect to the repositories, I understand why you would not want to
show all possible repositories by default, but shouldn't you *at least*
show the repositories (update sites) that the *installed* features
declare? Otherwise, a naive/new user would install a feature, and never
find any updates to it as they would not know to go into the "Manage
Sites..." area and add that update site to the list of active sites to
search. I kind of assumed that if you installed something, you didn't
have to go in and manually enable its update site to make the "check for
updates" feature work.
If update sites are *supposed* to be shown for installed features, then we
are doing something wrong - hence the reason for my original post. What
do I need to do to make our update site appear by default? Can I control
this via a product-specific preference? Of course, I should say that all
of our features are classic, pre-P2-built features built with a headless
PDE build (using Eclipse 3.4 but without any changes made to account for
P2). I have not had time to update any build scripts to do anything
special to P2-i-size our features at build time (if, indeed anything needs
to be done at all) as I assumed I could run the metadata generator later
on our update site and that was all I needed to do (for now). Aside from
the fact that the official documentation in this area has been a little
late to appear, of course...
Thanks,
Mark.
On Mon, 23 Jun 2008 10:36:47 -0400, John Arthorne <eclipseng@arthorne.com>
wrote:
> I'm a bit confused, because you said you were using classic update, but
> the issues mentioned below in the installed/available software tabs is
> in the p2 UI.
>
> To answer your question though, p2 takes a different approach with
> repositories from Update Manager. In UM, you performed queries and
> install operations against a single repository. p2 instead searches
> across all enabled repositories whenever you query for updates or
> perform installs. We initially enabled all repositories by default,
> but the performance impact of doing this in something like Ganymede with
> 20+ repositories was too great. So, we were forced to disable
> repositories by default and leave it up to the user to enable the
> repositories they want to operate on. This of course is not ideal and is
> likely something we will revisit in the next release.
>
> --
>
> Mark Melvin wrote:
>> So to answer my own question, it appears that my installer functions
>> fine, and P2 appears to run fine. However, the update site contained
>> in all of my installed features is not in the list of sites to query
>> when looking for updates. Now I don't think this is a matter of
>> generating metadata and putting it on my site as Eclipse isn't even
>> querying my site for metadata to begin with. I believe there is
>> something else I am going to need to do to get it into the list of
>> "blessed URLs" that appear in the Available Software list by default.
>> If I click on "Manage Sites..." I can see my update site URL way down
>> at the bottom of the list, but my question is - why is that all of my
>> features show up in the "Installed Software" list, but the update site
>> declared in those features is not in the active list of sites to
>> search? If I click on "Update..." my site is not queried and thus
>> updates are never found for my features. However, if I flip over to
>> the "Available Software" page and manually add my site from the Manage
>> Sites... dialog, it is then queried. How can I get my site in the list
>> of Available Sites automatically?
>> Oh and the other bit of sweetness I just discovered is that because we
>> base our product on the core platform instead of the full SDK, there is
>> no preference page available for the "Capabilities", so I can't even
>> turn on the old update manager manually. It looks like this is
>> contributed by the SDK feature, which is not in the core platform and
>> is the source of bug 130502
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=130502) - which is a
>> WONTFIX.
>> Mark.
>> --- Original Post ---
>> Hi There,
>> For various reasons we are not able to ship our product based on P2 -
>> the main reason being we heavily depend on install handlers and simply
>> do not have time to port everything to touchpoints. So, for our
>> upcoming release to be based on Eclipse 3.4 we are planning on
>> continuing to use the old Update Manager. Up until now for our internal
>> milestone releases based on Eclipse 3.4, I have been using the script
>> to manually remove P2 from the version of the Eclipse platform that we
>> install. Because we would like to *eventually* move to P2 I would like
>> to leave P2 alone and ship on a standard Eclipse 3.4 platform runtime.
>> So my question is - will this create "issues" if I do not remove P2
>> from the platform, but essentially use the Update Manager exclusively
>> for the time being?
>> Secondly, our installer will be calling the update manager from the
>> command line to do its installation/uninstallation of features. Do I
>> need to specifically "enable" the update manager to avoid problems or
>> am I correct in assuming that the Update Manager Capability that is
>> turned off by default is simply a UI filter and does not prevent the
>> update manager plugins from loading if required? Also, would it cause
>> problems to enable this capability while P2 is installed?
>> Can anyone think of any other issues I may encounter?
>> Thanks in advance,
>> Mark.
|
|
| | | |
| Re: Classic Update Capability and P2 [message #113000 is a reply to message #112823] |
Mon, 30 June 2008 14:31 |
Mark Melvin
Messages: 118
Registered: July 2009 |
Senior Member |
|
|
Hey Euclides,
I'm not sure what to tell you. I never figured this out. However, my
step #7 was different than yours - I *could* see my site if I clicked on
"Manage Sites...". It was hard to spot in the huge list of Eclipse sites,
but it was there.
At any rate - we had major state issues with our installer that ultimately
forced us to remove P2 using the method decribed on the wiki for our
3.4-based release. Because we *have* to use install handlers (and they
are only supported by the classic update manager) we *have* to use the
classic update manager from our installer. The problem is it is very easy
to get things into a state where P2 thinks a bunch of features aren't
there, but update manager thinks they are there - and chaos ensues. There
are just too many unknowns for us at this point to try and make this work
at the last minute.
Mark.
On Fri, 27 Jun 2008 15:49:51 -0400, Euclides Arcoverde <euneto@gmail.com>
wrote:
> Hi all,
>
> I'm facing the same problem regarding my product update repository site.
> Following I'll list the steps I've tried.
>
> 1. Generate the repository (using the Eclipse Product export wizard or
> adding p2 metatada generator tags in build.properties for headless build)
> 2. Use director app to install (p2ize) the product (.product) and all
> required features
> 3. Open the just p2ized product
> 4. Go to Help->Software Updates (my product and all features are being
> listed in "Installed Softwares" tab)
> 5. If I select any installed feature/product and then click on
> "Update...", immediately an information dialog opens saying "There is
> nothing to update" (my update site did not received any request as well)
> 6. In "Available Software" tab, there are no URLs listed in order to
> find updates of my product
> 7. In the same tab (Available Software), if I click on "Manage Sites..."
> there is nothing listed as well
>
> I was opened my features.xml contents and verified that the tags "<url>
> <update ... /> <discovery ... /> </url>" seems to be ok.
>
> If I remove p2 of my "p2ized" product (following the steps described in
> http://wiki.eclipse.org/Equinox_p2_Removal), the update sites were
> listed and works fine in the old UM.
>
> I'd like to know if this (steps 6 and 7) is the behavior of "p2ized"
> products, or if this behavior may be an issue.
>
> Thanks,
> -- Euclides
>
|
|
|
| Re: Classic Update Capability and P2 [message #113190 is a reply to message #112378] |
Thu, 03 July 2008 15:37 |
| Eclipse User |
|
|
|
Originally posted by: eclipseng.arthorne.com
What you are seeing is a limitation of p2, not a result of you doing
something wrong. All I can suggest is that you can add extra enabled
sites by editing the files
eclipse/configuration/.settings/org.eclipse.equinox.p2.{arti fact,metdata}.repository.prefs
to add the desired initial sites. That is what we do today in the 3.4
build to enable the Eclipse project update site and Ganymede site by
default. Yes, this is gross.
--
Mark Melvin wrote:
> With respect to the repositories, I understand why you would not want to
> show all possible repositories by default, but shouldn't you *at least*
> show the repositories (update sites) that the *installed* features
> declare? Otherwise, a naive/new user would install a feature, and never
> find any updates to it as they would not know to go into the "Manage
> Sites..." area and add that update site to the list of active sites to
> search. I kind of assumed that if you installed something, you didn't
> have to go in and manually enable its update site to make the "check for
> updates" feature work.
>
> If update sites are *supposed* to be shown for installed features, then
> we are doing something wrong - hence the reason for my original post.
> What do I need to do to make our update site appear by default? Can I
> control this via a product-specific preference? Of course, I should say
> that all of our features are classic, pre-P2-built features built with a
> headless PDE build (using Eclipse 3.4 but without any changes made to
> account for P2). I have not had time to update any build scripts to do
> anything special to P2-i-size our features at build time (if, indeed
> anything needs to be done at all) as I assumed I could run the metadata
> generator later on our update site and that was all I needed to do (for
> now). Aside from the fact that the official documentation in this area
> has been a little late to appear, of course...
|
|
|
| Re: Classic Update Capability and P2 [message #113255 is a reply to message #113190] |
Thu, 03 July 2008 17:30 |
Mark Melvin
Messages: 118
Registered: July 2009 |
Senior Member |
|
|
Thanks for responding, John. I appreciate it.
Mark.
On Thu, 03 Jul 2008 11:37:09 -0400, John Arthorne <eclipseng@arthorne.com>
wrote:
> What you are seeing is a limitation of p2, not a result of you doing
> something wrong. All I can suggest is that you can add extra enabled
> sites by editing the files
> eclipse/configuration/.settings/org.eclipse.equinox.p2.{arti fact,metdata}.repository.prefs
> to add the desired initial sites. That is what we do today in the 3.4
> build to enable the Eclipse project update site and Ganymede site by
> default. Yes, this is gross.
> --
>
>
> Mark Melvin wrote:
>> With respect to the repositories, I understand why you would not want
>> to show all possible repositories by default, but shouldn't you *at
>> least* show the repositories (update sites) that the *installed*
>> features declare? Otherwise, a naive/new user would install a feature,
>> and never find any updates to it as they would not know to go into the
>> "Manage Sites..." area and add that update site to the list of active
>> sites to search. I kind of assumed that if you installed something,
>> you didn't have to go in and manually enable its update site to make
>> the "check for updates" feature work.
>> If update sites are *supposed* to be shown for installed features,
>> then we are doing something wrong - hence the reason for my original
>> post. What do I need to do to make our update site appear by default?
>> Can I control this via a product-specific preference? Of course, I
>> should say that all of our features are classic, pre-P2-built features
>> built with a headless PDE build (using Eclipse 3.4 but without any
>> changes made to account for P2). I have not had time to update any
>> build scripts to do anything special to P2-i-size our features at build
>> time (if, indeed anything needs to be done at all) as I assumed I could
>> run the metadata generator later on our update site and that was all I
>> needed to do (for now). Aside from the fact that the official
>> documentation in this area has been a little late to appear, of
>> course...
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:30:57 GMT 2024
Powered by FUDForum. Page generated in 0.03099 seconds |
] 
Search
Help
Register
Login
Home
