[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [p2-dev] Avoiding JRE IUs and Generator Mode?
- From: "Mark Melvin" <Mark.Melvin@xxxxxxxxxx>
- Date: Tue, 12 May 2009 07:52:35 -0700
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcnSgX2PlqFXuTGcQ0ySeejUqxTi/QAj4Zqw
- Thread-topic: [p2-dev] Avoiding JRE IUs and Generator Mode?
Thanks, Ian - but following the directions I can't make
it work. I tried the first format and I get empty metadata and artifacts
in my repository, with a .log file dumped into my Eclipse configuration
directory with the following contents:
!SESSION 2009-05-12 10:50:27.551
BootLoader constants: OS=win32, ARCH=x86, WS=win32,
Framework arguments: -application
Command-line arguments: -os win32 -ws win32 -arch x86
-artifactRepository file:C:/Temp/p2/testing_publisher/repository -source
!ENTRY org.eclipse.equinox.p2.repository 4 0 2009-05-12
!MESSAGE ProvisioningEventBus could not be obtained. Metadata
caches may not be cleaned up properly.
I'm starting the publisher docs here:
is still long way to go, but it's a start.
This brings up a good
question. Andrew, should I include the PDE Build publishing related
tasks (the ones contributed by build) in this
On Mon, May 11, 2009 at 2:26 PM, Andrew Niefer <aniefer@xxxxxxxxxx>
There are these:
Contributed by org.eclipse.pde.build:
eclipse.gatherFeature : publish a feature from source
(ie feature has build.properties), also does the root properties.
implemented by GatherFeatureTask.
eclipse.gatherBundle : publish a bundle from source (.class files
have been compiled), implemented by GatherBundleTask
eclipse.publish.featuresAndBundles : publishes binary
features/bundles. Also does categories. implemented by
eclipse.brand.p2.artifacts : brands launcher artifacts for a product
(normally provided by org.eclipse.equinox.executable), changes launcher
name/icon, etc. Republishes them under a new IU matching the
The two eclipse.gather*
tasks are used by pde.build to create the jars from source during a
publish.bin.parts target in the generated build.xml, this replaces the
gather.bin.parts from before.
Contributed by org.eclipse.equinox.p2.publisher:
p2.publish.featuresAndBundles : just like
eclipse.publish.featuresAndBundles above, but doesn't do categories.
implemented by FeaturesAndBundlesPublisherTask
p2.publish.product : publish a .product file assuming
required things are already in the repo, implemented by
ProductPublisherTask. This will publish a JRE IU, which will be
required if your product includes bundles that import packages that are
provided by the system.
: I don't know about this one, might not be tested. probably a
replacement of p2.generator, implemented by PublisherTask
p2.repo2runnable : transform repositories into "runnable" form which
can be compiled against., Repo2RunnableTask
p2.mirror : mirroring for artifacts and metadata, with slicing and
p2.process.artifacts : optionally sign/condition/pack jars using the
jarprocessor task. Also update the artifact repo with new descriptors
for pack200 and update the MD5 sums to match the artifacts.
p2.composite.repository: create composite repositories.
Both the build and publisher tasks above support the p2.inf file.
For bundles and features, the difference is the pde.build gather tasks
publish directly from source at build time. For these tasks, you don't
actually need to include the p2.inf in your binary bundles (although you
can), it just needs to be there with the source. The publisher
featuresAndBundles task publishes from binary jars, so you do need to
included the p2.inf in the jar if you are using it.
(Note, in all of the above, when I say source, I mean
your project checked out from CVS, not a generated source bundle
Aha - well I
didn't realize that was an old task. So, the tasks I can use that are
not documented - where are they located source-wise? I'm fine digging
through source. I have found that the PDE call to
"eclipse.gatherFeature" seems to work without the JRE cruft as well.
However, the "p2.publish.featuresAndBundles" task seems to be what I
need. Does this handle p2.inf when it is called? I'm a little
confused as to when this file is needed. Is it just a "publish-time"
thing, or is it needed at build time as well. I guess what I am asking
is - should I just build my features and plugins the way I always did, but
include the p2.inf file in my JAR, then later use it as part of a publish or
metadata generation step? Mark.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew
Sent: May 11, 2009 1:26 PM
To: P2 developer
Subject: Re: [p2-dev] Avoiding JRE IUs and Generator
I don't see any way to turn off the generation of this IU using
The incremental mode keeps the results of the generation around
in memory so that the next invocation of the task will add to them.
Mode "final" will then clear those accumulated results and also
generate a parent container IU if a .product file is used or root id is
Note that this "p2.generator" task is the 3.4 based metadata
generator. 3.5 has a new publisher which supports more customization
(through the p2.inf file) that the generator didn't. There are
publisher tasks that could be used to avoid the jre IU if you were only
doing features, unfortunately they aren't yet documented.
"p2.publish.featuresAndBundles" task will publish built feature and plugin
jars. It supports a "source" attribute specifying a directory
containing features and plugins subfolders. It also supports nested
<features> and <bundles> elements which are ant Filesets
specifying features and bundles to publish. It also has the following
attributes that should correspond to the same thing on the p2.generator
task: artifactRepository, metadataRepository, artifactRepositoryName,
metadataRepositoryName, append, compress, publishArtifacts. Using this
task won't create jre IUs.
I am trying to
integrate the P2 stuff into my build and I am getting
entries in my
metadata for individual features like this:
id='a.jre' version='1.6.0' singleton='false'>
am calling the "p2.generator" Ant task with noDefaultIUs set to
(which avoids generating a whole pile of cruft), but the JRE stuff
gets in there. Is there any way to avoid the JRE stuff?
I plan on
merging all of my metadata at the end when I combine all
of my features
into one large repository.
Also, what is the
difference between "incremental" mode and "final"
mode? I build my
features individually using a custom set of scripts
and I think I want
mode="final", but I'd like to know that the
difference is between the
R. Ian Bull | EclipseSource Victoria | +1 250 477
http://eclipsesource.com | http://twitter.com/eclipsesource