Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] RE: Need help building a product with p2

I'm still having no luck getting the headless product build to find my launcher icon.  I tried setting launcherIcons in my build.properties file of my product config as well but no luck.  When I run the p2 director, I get an error that the launcher isn't found.  It's looking in the repo/binary directory.  This directory doesn't exist though.  I'm not sure if it's related to the missing icon or not.  I do get the binary directory when when exporting the same product from the UI.
 
I removed all references to the launcher from the artifacts.xml and content.xml files and ran the director again.  It completes successfully and gives me a working p2 directory.  I can launch the IDE and the updates dialog comes up showing my product name.  The only problem is that it puts a path in the config.ini to the bundles.info from the build server.
 
This is what the product export generated for me:
 
#Product Runtime Configuration File
osgi.splashPath=platform:/base/plugins/com.nokia.carbide.cpp
eclipse.application=org.eclipse.ui.ide.workbench
eclipse.product=com.nokia.carbide.cpp.product
osgi.bundles=org.eclipse.equinox.simpleconfigurator@1:start
org.eclipse.equinox.simpleconfigurator.configUrl=file:org.eclipse.equinox.simpleconfigurator/bundles.info
osgi.bundles.defaultStartLevel=4
 
and this is what it looks like after running the director:
 
#This configuration file was written by: org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxFwConfigFileParser
#Mon Jun 16 16:52:07 CDT 2008
eclipse.p2.profile="">osgi.framework=file\:plugins\\org.eclipse.osgi_3.4.0.v20080605-1900.jar
osgi.bundles=reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.0.v20080604.jar@1\:start
org.eclipse.equinox.simpleconfigurator.configUrl=file\:../../../build_cpp\\debug\\eclipse\\workspace\\tmp\\eclipse\\win32.win32.x86\\eclipse\\configuration\\org.eclipse.equinox.simpleconfigurator\\bundles.info
eclipse.product=com.nokia.carbide.cpp.product
osgi.splashPath=platform\:/base/plugins/com.nokia.carbide.cpp
eclipse.p2.data.area=@config.dir/../p2
osgi.bundles.defaultStartLevel=4
eclipse.application=org.eclipse.ui.ide.workbench
 
 
Note that I am passing -roaming to the director.
 
I'm also not sure what to pass for -profile.  The values I've seen are SDKProfile and PlatformProfile.  I tried PlatformProfile, and CarbideProfile for good measure.  What exactly does this do, and what should I be passing?
 
Thanks,
Warren


From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Warren.Paul@xxxxxxxxx
Sent: Friday, June 13, 2008 5:47 PM
To: equinox-dev@xxxxxxxxxxx
Subject: RE: [equinox-dev] RE: Need help building a product with p2

OK, figured out that problem.  We had a plugin without a manifest file from way back when.  Whatever jar'ed it up created a manifest file for it, and I think that's why had a lock on it.  The eclipse instance used to build the product would have to exit for it to release it.  I'm not sure if it was eclipse, ant, or the jre.  Anyway, I changed our plugin and now it generates the metadata along with the product.  Yeah!
 
I still have a few more issues though.
 
1) The launcher is generated without our icon.  I've read some questions and answers from Andrew on the web but I still can't get it to work.  Our icon is in a plugin and I specify the icon path like this:
 
   <launcher name="Carbide.c++">
      <solaris/>
      <win useIco="true">
         <ico path="/com.nokia.carbide.cpp/icons/Carbide_c_flat.ico"/>
         <bmp/>
      </win>
   </launcher>
This plugin and icon path exist under the buildDirectory/plugins directory.  I've tried several variations of the path, trying to put it under the config directory alongside the .product file, but no luck.
 
 
2) The product build generated a config.ini file which is good.  The only thing missing that we need to set is osgi.instance.area.default.  I didn't see anywhere in the .product file to specify this, and it says using an existing config file will just copy it as is (not adding osgi.bundles, etc.)  Maybe I can pass it as a program argument?
 
3) I'm still not sure what to do with the p2 director.  I have a full product layout generated by the product build (everything but p2 that is).  I also have the repo generated by the product build.  Now I need the full product layout along with the p2 directory, and the p2 modification made to the config.ini file.  I've played around with several variations but haven't had any success yet.
 
I thought I'd generate a complete product based on what the docs said:
 
eclipsec.exe -nosplash -application org.eclipse.equinox.p2.director.app.application -metadataRepository file:D:/generated_repo -artifactRepository file:D:/generated_repo -installIU com.nokia.carbide.cpp.product -destination D:/test_layout -profile PlatformProfile -profileProperties org.eclipse.update.install.features=true -bundlepool D:/test_layout -p2.os win32 -p2.ws win32 -p2.arch x86 -roaming -vmargs -Declipse.p2.data.area=D:/test_layout/p2
I run this from the Eclipse 3.4 RC4 SDK installation directory.  Does that sound right?  I guess it isn't because I get an error like this for each plugin:
 
java.io.FileNotFoundException: D:\Eclipse_3.4RC4\configuration\org.eclipse.osgi\bundles\112\data\330080838\plugins\com.nokia.bugreport_2.0.0.200806131501.jar (The system cannot find the path specified)
 at java.io.FileInputStream.open(Native Method)
 at java.io.FileInputStream.<init>(FileInputStream.java:106)
 at java.io.FileInputStream.<init>(FileInputStream.java:66)
 at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
 at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
 at org.eclipse.ecf.provider.filetransfer.retrieve.UrlConnectionRetrieveFileTransfer.openStreams(UrlConnectionRetrieveFileTransfer.java:237)
 at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:639)
 at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:381)
 at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:95)
 at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.transfer(ECFTransport.java:167)
 at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.performDownload(ECFTransport.java:120)
 at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.download(ECFTransport.java:100)
 at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:440)
 at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:423)
 at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:490)
 at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transferSingle(MirrorRequest.java:162)
 at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transfer(MirrorRequest.java:146)
 at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.perform(MirrorRequest.java:94)
 at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:479)
 at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:536)
 at org.eclipse.equinox.internal.p2.extensionlocation.ExtensionLocationArtifactRepository.getArtifacts(ExtensionLocationArtifactRepository.java:171)
 at org.eclipse.equinox.internal.p2.engine.DownloadManager.fetch(DownloadManager.java:105)
 at org.eclipse.equinox.internal.p2.engine.DownloadManager.start(DownloadManager.java:93)
 at org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect.completeInstallableUnitPhase(Collect.java:56)
 at org.eclipse.equinox.internal.provisional.p2.engine.InstallableUnitPhase.completePhase(InstallableUnitPhase.java:79)
 at org.eclipse.equinox.internal.provisional.p2.engine.Phase.postPerform(Phase.java:143)
 at org.eclipse.equinox.internal.provisional.p2.engine.Phase.perform(Phase.java:85)
 at org.eclipse.equinox.internal.provisional.p2.engine.InstallableUnitPhase.perform(InstallableUnitPhase.java:53)
 at org.eclipse.equinox.internal.provisional.p2.engine.Phase.perform(Phase.java:46)
 at org.eclipse.equinox.internal.provisional.p2.engine.PhaseSet.perform(PhaseSet.java:38)
 at org.eclipse.equinox.internal.provisional.p2.engine.Engine.perform(Engine.java:53)
 at org.eclipse.equinox.internal.p2.director.app.Application.planAndExecute(Application.java:213)
 at org.eclipse.equinox.internal.p2.director.app.Application.run(Application.java:365)
 at org.eclipse.equinox.internal.p2.director.app.Application.start(Application.java:423)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
 
It's looking in the Eclipse 3.4 RC4 SDK for the plugins.  it also changes the eclipse.p2.data.area in the Eclipse 3.4RC4 SDK config.ini to point to D:/test_layout/p2.  So I figure I need to run eclipsec.exe from the generated product layout.  Then I get a bunch of errors like ... already installed...
 
 
Please help.  We have to be getty close here.  :)
 
Thanks,
Warren
 


From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Warren.Paul@xxxxxxxxx
Sent: Friday, June 13, 2008 9:36 AM
To: equinox-dev@xxxxxxxxxxx
Subject: RE: [equinox-dev] RE: Need help building a product with p2

It's coming from assemble.org.eclipse.pde.build.container.feature.win32.win32.x86.xml.  It create the jars, generates the metadata, calls pre.archive, then zips everything up and deletes the tmp directory:
 
  <delete dir="${assemblyTempDir}"/>
This delete fails because the plugins are still in use by something.  It has to be either the p2 generator or zip I would imagine.  I added a customAssembly.xml file and added a sleep to the pre.archive target.  We'll see if that helps.
 
BTW, the product build is finally working on our build server now.  We used to build one of the platform plugins a few products ago, and the map file for it was still hanging around and getting checked out with all of the others.  This caused all the weird missing dependency *_0.0.0 errors.  I guess it didn't matter if that map was there when we were just building features, but the product build concats everything together.  That was a booger to track down.  :) 
 
Thanks for the help Andrew.
 
 
 
--------------------------------------------------------------------------
 
 
 Doing the metadata generation from the product build seems to generate good data, but I think there's a timing bug.  When I run that on our build server, I get an error during a cleanup ant task in the generated ant scripts.  It's   trying to delete some stuff that's still in use.  if I wait a few seconds it would work, but I don't control the call to the cleanup task.  It seems the metadata generation completes but hasn't released all of the plugins yet for some reason.
 [AN] We have not seen this kind of issue in our own builds, can you please raise a bug with the details.  I'm not sure which clean task you are refering to, if it is the one in the customTargets.xml, you can define "noclean=true" to turn it off.  Another possibility would be to use the custom Assembly steps ("Customizing a Headless Build" in the RC4 help).  The pre.archive task will be called after metadata generation, as well there is more metadata generation done at the end of the package phase and customTargets.xml/postPackag occurs immediately afterward.  You could try putting custom ant in these tasks to introduce a delay if necessary.


Back to the top