Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » 3.2 to 3.4 migration
3.2 to 3.4 migration [message #126203] Sat, 21 February 2009 20:13 Go to next message
Eclipse UserFriend
Originally posted by: none.gmail.com

Hello all,

I am trying to move our product from the 3.2 platform to the 3.4.1
classic platform.

Background:
The 3.2 product file is feature based and uses the
org.eclipse.ide.workbench application as it is not intended to be
standalone. My headless build system creates a zip containing the
features, plugins, and branding components. I extract this zip into a
3.2 base where I also extracted the delta pack and dependencies. This
approach has worked successfully for some time.

Work so far:
For the 3.4 build I followed the same process after a bit of refactoring
of my plugins of course. Everything went fine until I launched my newly
built product. A number of problems occurred including a long load time,
a number of "Could not install bundle..." errors in the log, and the
Update UI failed to launch due to a configuration problem.

After doing some research that honestly I should have done first, I
discovered that I was not provisioning my product. So I updated my
build.properties to create the necessary metadata, artifacts, and
binaries but pretty much kept everything else the same. I also created a
site.xml for my repository. Here is the set of things I tried next:

Attempt 1:
I tried the BFMI (Brute Force Massive Ignorance) way first. I attempted
to call the director from the 3.4 I had extracted everything to using
the "Running inside the target application" style from the wiki. This
produced a large number of errors during provisioning that I found were
caused by the extracted config.ini. I replaced it with the original and
called the director with a successful result.

I forgot to copy the generated config.ini over, but when I started
Eclipse everything seemed to work except that my update site was
pointing to my repository and not the site in the feature. After copying
back over my config.ini and restarting, I was back to my original problem.

Attempt 2:
I extracted a clean 3.4 and followed the "Running inside the target
application" again this time using the "clean" environment. Everything
was good except for the update site, and I had none of my branding. I
figured it was a good start though. The update site from my feature was
there but it wasn't selected, but one pointing to my local repository
was selected. (By the way, I love how I didn't have to install the
dependencies first!)

For kicks I added the splash location and product id of my product to
the config.ini and got branding working. I was then able to copy over
the branded launcher and .eclipseProduct file. This came pretty close to
a very workable solution except for the update site problem.

Attempt 3:
My third attempt was to follow the "Provisioning without running the
target application". For this I continued to use the repository I built
previously, but I extracted a new 3.4 to use as the builder and a 3.4 to
use as the target.

The result here was very interesting. My feature showed as installed in
the update UI of the target but the actual feature and plugin bundles
were not copied to the target. They also were not shown in the about
page under features and plugins. I did find them copied to the builder's
features and plugins directories, which I found to be very odd.

I haven't looked in bugzilla to see if there is an open issue for this
problem, and I just decided to move on to the next type of provision.

Attempt 4:
My fourth attempt was to follow the "Installing a complete product"
method. Although, I didn't feel this was really what I needed as this
seemed to be geared for creating a fully running rcp from a product file
as opposed to installing a product into a 3.4.1 classic build.

The result of this attempt was about the same as attempt 3.

I decided also to see what happened if I ran attempt 4 with an empty
destination directory. This gave me the plugins, featues, p2, and
config. So I zipped it and extracted it over a fresh 3.4, which didn't
help any.

Conclusion:
So it seems the most promising solution is to use the Attempt 2 process,
with my config.ini hack, but I will also need to find a way to change
the update site url before delivery.

I feel that their should be an easier way for me to accomplish what I am
trying here. Has anyone had experience using this type of product
build with p2?

One possible solution that has been suggested was to include in my
product all the features delivered in the 3.4.1 basic and try building
like an RCP. My first attempt at this was not very successful.

Thanks,
Scott
Re: 3.2 to 3.4 migration [message #126216 is a reply to message #126203] Sat, 21 February 2009 20:30 Go to previous message
Eclipse UserFriend
Originally posted by: none.gmail.com

Scott Hathaway wrote:
> Hello all,
>
> I am trying to move our product from the 3.2 platform to the 3.4.1
> classic platform.
>
> Background:
> The 3.2 product file is feature based and uses the
> org.eclipse.ide.workbench application as it is not intended to be
> standalone. My headless build system creates a zip containing the
> features, plugins, and branding components. I extract this zip into a
> 3.2 base where I also extracted the delta pack and dependencies. This
> approach has worked successfully for some time.
>
> Work so far:
> For the 3.4 build I followed the same process after a bit of refactoring
> of my plugins of course. Everything went fine until I launched my newly
> built product. A number of problems occurred including a long load time,
> a number of "Could not install bundle..." errors in the log, and the
> Update UI failed to launch due to a configuration problem.
>
> After doing some research that honestly I should have done first, I
> discovered that I was not provisioning my product. So I updated my
> build.properties to create the necessary metadata, artifacts, and
> binaries but pretty much kept everything else the same. I also created a
> site.xml for my repository. Here is the set of things I tried next:
>
> Attempt 1:
> I tried the BFMI (Brute Force Massive Ignorance) way first. I attempted
> to call the director from the 3.4 I had extracted everything to using
> the "Running inside the target application" style from the wiki. This
> produced a large number of errors during provisioning that I found were
> caused by the extracted config.ini. I replaced it with the original and
> called the director with a successful result.
>
> I forgot to copy the generated config.ini over, but when I started
> Eclipse everything seemed to work except that my update site was
> pointing to my repository and not the site in the feature. After copying
> back over my config.ini and restarting, I was back to my original problem.
>
> Attempt 2:
> I extracted a clean 3.4 and followed the "Running inside the target
> application" again this time using the "clean" environment. Everything
> was good except for the update site, and I had none of my branding. I
> figured it was a good start though. The update site from my feature was
> there but it wasn't selected, but one pointing to my local repository
> was selected. (By the way, I love how I didn't have to install the
> dependencies first!)
>
> For kicks I added the splash location and product id of my product to
> the config.ini and got branding working. I was then able to copy over
> the branded launcher and .eclipseProduct file. This came pretty close to
> a very workable solution except for the update site problem.
>
> Attempt 3:
> My third attempt was to follow the "Provisioning without running the
> target application". For this I continued to use the repository I built
> previously, but I extracted a new 3.4 to use as the builder and a 3.4 to
> use as the target.
>
I found an answer to my update site question in an earlier thread:
news://news.eclipse.org:80/6021a0c14b5caec0956c1991bfed307b$ 1@www.eclipse.org



> The result here was very interesting. My feature showed as installed in
> the update UI of the target but the actual feature and plugin bundles
> were not copied to the target. They also were not shown in the about
> page under features and plugins. I did find them copied to the builder's
> features and plugins directories, which I found to be very odd.
>
> I haven't looked in bugzilla to see if there is an open issue for this
> problem, and I just decided to move on to the next type of provision.
>
> Attempt 4:
> My fourth attempt was to follow the "Installing a complete product"
> method. Although, I didn't feel this was really what I needed as this
> seemed to be geared for creating a fully running rcp from a product file
> as opposed to installing a product into a 3.4.1 classic build.
>
> The result of this attempt was about the same as attempt 3.
>
> I decided also to see what happened if I ran attempt 4 with an empty
> destination directory. This gave me the plugins, featues, p2, and
> config. So I zipped it and extracted it over a fresh 3.4, which didn't
> help any.
>
> Conclusion:
> So it seems the most promising solution is to use the Attempt 2 process,
> with my config.ini hack, but I will also need to find a way to change
> the update site url before delivery.
>
> I feel that their should be an easier way for me to accomplish what I am
> trying here. Has anyone had experience using this type of product build
> with p2?
>
> One possible solution that has been suggested was to include in my
> product all the features delivered in the 3.4.1 basic and try building
> like an RCP. My first attempt at this was not very successful.
>
> Thanks,
> Scott
>
>
>
>
>
>
>
>
Previous Topic:P2. Non feature can be updated
Next Topic:[P2] How to make P2 re-read dropins?
Goto Forum:
  


Current Time: Tue Mar 19 06:18:40 GMT 2024

Powered by FUDForum. Page generated in 0.02927 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top