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\330080
838\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.ja
va:70)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec
tion.java:161)
at
org.eclipse.ecf.provider.filetransfer.retrieve.UrlConnectionRetrieveFile
Transfer.openStreams(UrlConnectionRetrieveFileTransfer.java:237)
at
org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTrans
fer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:639)
at
org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTrans
fer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:381)
at
org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdap
ter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:95)
at
org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.transfe
r(ECFTransport.java:167)
at
org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.perform
Download(ECFTransport.java:120)
at
org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.downloa
d(ECFTransport.java:100)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifac
tRepository.downloadArtifact(SimpleArtifactRepository.java:440)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifac
tRepository.downloadArtifact(SimpleArtifactRepository.java:423)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifac
tRepository.getArtifact(SimpleArtifactRepository.java:490)
at
org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transf
erSingle(MirrorRequest.java:162)
at
org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transf
er(MirrorRequest.java:146)
at
org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.perfor
m(MirrorRequest.java:94)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifac
tRepository.getArtifact(SimpleArtifactRepository.java:479)
at
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifac
tRepository.getArtifacts(SimpleArtifactRepository.java:536)
at
org.eclipse.equinox.internal.p2.extensionlocation.ExtensionLocationArtif
actRepository.getArtifacts(ExtensionLocationArtifactRepository.java:171)
at
org.eclipse.equinox.internal.p2.engine.DownloadManager.fetch(DownloadMan
ager.java:105)
at
org.eclipse.equinox.internal.p2.engine.DownloadManager.start(DownloadMan
ager.java:93)
at
org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect.comple
teInstallableUnitPhase(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(Pha
se.java:143)
at
org.eclipse.equinox.internal.provisional.p2.engine.Phase.perform(Phase.j
ava: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.j
ava:46)
at
org.eclipse.equinox.internal.provisional.p2.engine.PhaseSet.perform(Phas
eSet.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(Applicati
on.java:423)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.j
ava:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplicat
ion(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Eclip
seAppLauncher.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.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext
[EMAIL PROTECTED]
Sent: Friday, June 13, 2008 9:36 AM
To: [email protected]
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.
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
