Home » Eclipse Projects » Equinox » Generating Configuration Metadata
| |
| Re: Generating Configuration Metadata [message #130247 is a reply to message #130119] |
Thu, 30 April 2009 09:16   |
Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Thanks, Simon. Yes - I found that and had picked it apart. It seems to
show how you would package a custom action and something that
"meta-requires" it, but doesn't illustrate the concepts covered in the
http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
scaring me about this wiki page is this:
"""
Other Considerations
If we expect people to simply include the configured features in the
products/features then this requires actual configured.feature jars for
build purposes. If the configured features are simply IUs in the metadata
without an actual jar artifact, then people need to be able to specify
includes/requires on IUs directly.
"""
That makes it sound like there is currently no way to build or use these
conceptual configured features. Is this page just out of date, or is it
really still a theoretical feature at this point?
Mark.
Simon Kaegi wrote:
> Mark,
> I posted an archive of a few project to do "installer actions" with
> metarequirements that should help.
> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
> -Simon
> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>> Can someone confirm whether or not the information on this wiki page is
>> relevant:
>>
>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>
>> As I posted in this newsgroup posting while back
>>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>> I am trying to replace our legacy install handlers with P2 equivalents,
>> but I am still no farther along. I assume I need to wrap them in
>> "configuration features", and then nest these features somehow to express
>> my dependency relationships.
>>
>> If I am barking up the wrong tree or this wiki page is an out-of-date red
>> herring it would be nice to know now. I also would appreciate any
>> pointers to additional examples or documentation on this stuff (even
>> existing features I can look at in source form would help!).
>>
>> Thanks,
>> Mark.
>>
|
|
|
| Re: Generating Configuration Metadata [message #130270 is a reply to message #130247] |
Thu, 30 April 2009 14:07 |
| Eclipse User |
|
|
|
The concepts look roughly correct but the proposed syntax is a little off.
Some of the ideas being thrown around on that page were preliminary and
AFAIK everything is still buildable as usual.
For a configured feature (vs. unconfigured feature) "include" the
unconfigured feature and then supply a p2.inf to do your customizations. If
you author new IUFragments in the feature's p2.inf you will in most cases
have to also add the related require to your feature's IU but with that done
everything will get built correctly. Sorry if that is baffling, I'll work on
some examples once things calm down a bit.
-Simon
"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
> Thanks, Simon. Yes - I found that and had picked it apart. It seems to
> show how you would package a custom action and something that
> "meta-requires" it, but doesn't illustrate the concepts covered in the
> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
> scaring me about this wiki page is this:
>
> """
> Other Considerations
> If we expect people to simply include the configured features in the
> products/features then this requires actual configured.feature jars for
> build purposes. If the configured features are simply IUs in the metadata
> without an actual jar artifact, then people need to be able to specify
> includes/requires on IUs directly.
> """
>
> That makes it sound like there is currently no way to build or use these
> conceptual configured features. Is this page just out of date, or is it
> really still a theoretical feature at this point?
>
> Mark.
>
> Simon Kaegi wrote:
>
>> Mark,
>> I posted an archive of a few project to do "installer actions" with
>> metarequirements that should help.
>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>
>> -Simon
>
>
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>> Can someone confirm whether or not the information on this wiki page is
>>> relevant:
>>>
>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>
>>> As I posted in this newsgroup posting while back
> ( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>> I am trying to replace our legacy install handlers with P2 equivalents,
>>> but I am still no farther along. I assume I need to wrap them in
>>> "configuration features", and then nest these features somehow to
>>> express my dependency relationships.
>>>
>>> If I am barking up the wrong tree or this wiki page is an out-of-date
>>> red herring it would be nice to know now. I also would appreciate any
>>> pointers to additional examples or documentation on this stuff (even
>>> existing features I can look at in source form would help!).
>>>
>>> Thanks,
>>> Mark.
>>>
>
|
|
|
| Re: Generating Configuration Metadata [message #130311 is a reply to message #130270] |
Thu, 30 April 2009 17:29 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Thanks, Simon. It *is* baffling, but I'll keep staring at it until it
makes sense. ;)
M.
Simon Kaegi wrote:
> The concepts look roughly correct but the proposed syntax is a little off.
> Some of the ideas being thrown around on that page were preliminary and
> AFAIK everything is still buildable as usual.
> For a configured feature (vs. unconfigured feature) "include" the
> unconfigured feature and then supply a p2.inf to do your customizations. If
> you author new IUFragments in the feature's p2.inf you will in most cases
> have to also add the related require to your feature's IU but with that done
> everything will get built correctly. Sorry if that is baffling, I'll work on
> some examples once things calm down a bit.
> -Simon
> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>> Thanks, Simon. Yes - I found that and had picked it apart. It seems to
>> show how you would package a custom action and something that
>> "meta-requires" it, but doesn't illustrate the concepts covered in the
>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
>> scaring me about this wiki page is this:
>>
>> """
>> Other Considerations
>> If we expect people to simply include the configured features in the
>> products/features then this requires actual configured.feature jars for
>> build purposes. If the configured features are simply IUs in the metadata
>> without an actual jar artifact, then people need to be able to specify
>> includes/requires on IUs directly.
>> """
>>
>> That makes it sound like there is currently no way to build or use these
>> conceptual configured features. Is this page just out of date, or is it
>> really still a theoretical feature at this point?
>>
>> Mark.
>>
>> Simon Kaegi wrote:
>>
>>> Mark,
>>> I posted an archive of a few project to do "installer actions" with
>>> metarequirements that should help.
>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>
>>> -Simon
>>
>>
>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>> Can someone confirm whether or not the information on this wiki page is
>>>> relevant:
>>>>
>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>
>>>> As I posted in this newsgroup posting while back
>>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>> I am trying to replace our legacy install handlers with P2 equivalents,
>>>> but I am still no farther along. I assume I need to wrap them in
>>>> "configuration features", and then nest these features somehow to
>>>> express my dependency relationships.
>>>>
>>>> If I am barking up the wrong tree or this wiki page is an out-of-date
>>>> red herring it would be nice to know now. I also would appreciate any
>>>> pointers to additional examples or documentation on this stuff (even
>>>> existing features I can look at in source form would help!).
>>>>
>>>> Thanks,
>>>> Mark.
>>>>
>>
|
|
|
| Re: Generating Configuration Metadata [message #130377 is a reply to message #130311] |
Fri, 01 May 2009 15:30 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
OK, after a few more hours of trial and error, what you are saying is
starting to make sense. But I still can't make it work. :( If I
understand correctly, I *can* author installation units in my p2.inf. I
take this to mean that I can create complete <unit></unit> blocks in the
metadata, correct?
Here is what a p2.inf looks like that I have been mucking with:
properties.0.name=foo
properties.0.value=bar
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=testid0
requires.0.range=(1.2.3,1.2.4)
requires.0.greedy=true
units.0.id=testid0
units.0.version=1.2.3
This is inside a feature called my.feature. As far as I can tell, the PDE
should generate three IUs for me for this feature like so:
my.feature.group
+-my.feature.jar
+-testid0
The problem is, I can't seem to ever get past these two IUs:
my.feature.group
+-my.feature.jar
It generates the appropriate properties and requires lines, but I can't
seem to create my own IUs from p2.inf. Am I misunderstanding something?
Also, if I am creating a wrapper feature that has no content except
metadata dependencies and linked binary artifacts, do I actually need a
feature.jar? I can't seem to make the PDE stop generating that child IU.
Thanks,
Mark.
> Simon Kaegi wrote:
>> The concepts look roughly correct but the proposed syntax is a little off.
>> Some of the ideas being thrown around on that page were preliminary and
>> AFAIK everything is still buildable as usual.
>> For a configured feature (vs. unconfigured feature) "include" the
>> unconfigured feature and then supply a p2.inf to do your customizations. If
>> you author new IUFragments in the feature's p2.inf you will in most cases
>> have to also add the related require to your feature's IU but with that
done
>> everything will get built correctly. Sorry if that is baffling, I'll work
on
>> some examples once things calm down a bit.
>> -Simon
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems to
>>> show how you would package a custom action and something that
>>> "meta-requires" it, but doesn't illustrate the concepts covered in the
>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
>>> scaring me about this wiki page is this:
>>>
>>> """
>>> Other Considerations
>>> If we expect people to simply include the configured features in the
>>> products/features then this requires actual configured.feature jars for
>>> build purposes. If the configured features are simply IUs in the metadata
>>> without an actual jar artifact, then people need to be able to specify
>>> includes/requires on IUs directly.
>>> """
>>>
>>> That makes it sound like there is currently no way to build or use these
>>> conceptual configured features. Is this page just out of date, or is it
>>> really still a theoretical feature at this point?
>>>
>>> Mark.
>>>
>>> Simon Kaegi wrote:
>>>
>>>> Mark,
>>>> I posted an archive of a few project to do "installer actions" with
>>>> metarequirements that should help.
>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>
>>>> -Simon
>>>
>>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>> Can someone confirm whether or not the information on this wiki page is
>>>>> relevant:
>>>>>
>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>
>>>>> As I posted in this newsgroup posting while back
>>>
>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>> I am trying to replace our legacy install handlers with P2 equivalents,
>>>>> but I am still no farther along. I assume I need to wrap them in
>>>>> "configuration features", and then nest these features somehow to
>>>>> express my dependency relationships.
>>>>>
>>>>> If I am barking up the wrong tree or this wiki page is an out-of-date
>>>>> red herring it would be nice to know now. I also would appreciate any
>>>>> pointers to additional examples or documentation on this stuff (even
>>>>> existing features I can look at in source form would help!).
>>>>>
>>>>> Thanks,
>>>>> Mark.
>>>>>
>>>
|
|
|
| Re: Generating Configuration Metadata [message #130426 is a reply to message #130377] |
Fri, 01 May 2009 16:52 |
| Eclipse User |
|
|
|
Mark,
I tried out your example and think you've found a new bug in the Feature
exporter when its being over aggresive on what it trims. What I saw was your
new IU get created in the temp repo but then was trimmed when we created the
final result repo.I'll log it and chase this down.
Incidentally, the temp repo is in:
{workspace}\.metadata\.plugins\org.eclipse.pde.core\tempp2me tadata
If you want to walk through the creation take a look at
FeatureAction.generateIU
-Simon
"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:4205aa3e1d10987b31926b1234ed8c4a$1@www.eclipse.org...
> OK, after a few more hours of trial and error, what you are saying is
> starting to make sense. But I still can't make it work. :( If I
> understand correctly, I *can* author installation units in my p2.inf. I
> take this to mean that I can create complete <unit></unit> blocks in the
> metadata, correct?
>
> Here is what a p2.inf looks like that I have been mucking with:
>
> properties.0.name=foo
> properties.0.value=bar
>
> requires.0.namespace=org.eclipse.equinox.p2.iu
> requires.0.name=testid0
> requires.0.range=(1.2.3,1.2.4)
> requires.0.greedy=true
>
> units.0.id=testid0
> units.0.version=1.2.3
>
> This is inside a feature called my.feature. As far as I can tell, the PDE
> should generate three IUs for me for this feature like so:
>
> my.feature.group
> +-my.feature.jar
> +-testid0
>
> The problem is, I can't seem to ever get past these two IUs:
>
> my.feature.group
> +-my.feature.jar
>
> It generates the appropriate properties and requires lines, but I can't
> seem to create my own IUs from p2.inf. Am I misunderstanding something?
>
> Also, if I am creating a wrapper feature that has no content except
> metadata dependencies and linked binary artifacts, do I actually need a
> feature.jar? I can't seem to make the PDE stop generating that child IU.
>
> Thanks,
> Mark.
>
>
>> Simon Kaegi wrote:
>
>>> The concepts look roughly correct but the proposed syntax is a little
>>> off. Some of the ideas being thrown around on that page were preliminary
>>> and AFAIK everything is still buildable as usual.
>
>>> For a configured feature (vs. unconfigured feature) "include" the
>>> unconfigured feature and then supply a p2.inf to do your customizations.
>>> If you author new IUFragments in the feature's p2.inf you will in most
>>> cases have to also add the related require to your feature's IU but with
>>> that
> done
>>> everything will get built correctly. Sorry if that is baffling, I'll
>>> work
> on
>>> some examples once things calm down a bit.
>
>>> -Simon
>
>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>>> to show how you would package a custom action and something that
>>>> "meta-requires" it, but doesn't illustrate the concepts covered in the
>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
>>>> scaring me about this wiki page is this:
>>>>
>>>> """
>>>> Other Considerations
>>>> If we expect people to simply include the configured features in the
>>>> products/features then this requires actual configured.feature jars for
>>>> build purposes. If the configured features are simply IUs in the
>>>> metadata without an actual jar artifact, then people need to be able to
>>>> specify includes/requires on IUs directly.
>>>> """
>>>>
>>>> That makes it sound like there is currently no way to build or use
>>>> these conceptual configured features. Is this page just out of date,
>>>> or is it really still a theoretical feature at this point?
>>>>
>>>> Mark.
>>>>
>>>> Simon Kaegi wrote:
>>>>
>>>>> Mark,
>>>>> I posted an archive of a few project to do "installer actions" with
>>>>> metarequirements that should help.
>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>
>>>>> -Simon
>>>>
>>>>
>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>> Can someone confirm whether or not the information on this wiki page
>>>>>> is relevant:
>>>>>>
>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>
>>>>>> As I posted in this newsgroup posting while back
>>>>
>>
> ( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>> wrap them in "configuration features", and then nest these features
>>>>>> somehow to express my dependency relationships.
>>>>>>
>>>>>> If I am barking up the wrong tree or this wiki page is an out-of-date
>>>>>> red herring it would be nice to know now. I also would appreciate
>>>>>> any pointers to additional examples or documentation on this stuff
>>>>>> (even existing features I can look at in source form would help!).
>>>>>>
>>>>>> Thanks,
>>>>>> Mark.
>>>>>>
>>>>
>
|
|
|
| Re: Generating Configuration Metadata [message #130440 is a reply to message #130426] |
Fri, 01 May 2009 17:01 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
THANK YOU!
I was wondering about this because if I changed my unit.id to be
"my.feature.jar", the main feature.jar IU would disappear from the
metadata. This was driving me nuts!
OK, if you want me to file a bug let me know. Otherwise, if you have
already filed one, please CC me. My bugzilla email address is
mark UNDERSCORE melvin AT amis DOT com.
Thanks,
Mark.
Simon Kaegi wrote:
> Mark,
> I tried out your example and think you've found a new bug in the Feature
> exporter when its being over aggresive on what it trims. What I saw was your
> new IU get created in the temp repo but then was trimmed when we created the
> final result repo.I'll log it and chase this down.
> Incidentally, the temp repo is in:
> {workspace}.metadata.pluginsorg.eclipse.pde.coretempp2metada ta
> If you want to walk through the creation take a look at
> FeatureAction.generateIU
> -Simon
> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:4205aa3e1d10987b31926b1234ed8c4a$1@www.eclipse.org...
>> OK, after a few more hours of trial and error, what you are saying is
>> starting to make sense. But I still can't make it work. :( If I
>> understand correctly, I *can* author installation units in my p2.inf. I
>> take this to mean that I can create complete <unit></unit> blocks in the
>> metadata, correct?
>>
>> Here is what a p2.inf looks like that I have been mucking with:
>>
>> properties.0.name=foo
>> properties.0.value=bar
>>
>> requires.0.namespace=org.eclipse.equinox.p2.iu
>> requires.0.name=testid0
>> requires.0.range=(1.2.3,1.2.4)
>> requires.0.greedy=true
>>
>> units.0.id=testid0
>> units.0.version=1.2.3
>>
>> This is inside a feature called my.feature. As far as I can tell, the PDE
>> should generate three IUs for me for this feature like so:
>>
>> my.feature.group
>> +-my.feature.jar
>> +-testid0
>>
>> The problem is, I can't seem to ever get past these two IUs:
>>
>> my.feature.group
>> +-my.feature.jar
>>
>> It generates the appropriate properties and requires lines, but I can't
>> seem to create my own IUs from p2.inf. Am I misunderstanding something?
>>
>> Also, if I am creating a wrapper feature that has no content except
>> metadata dependencies and linked binary artifacts, do I actually need a
>> feature.jar? I can't seem to make the PDE stop generating that child IU.
>>
>> Thanks,
>> Mark.
>>
>>
>>> Simon Kaegi wrote:
>>
>>>> The concepts look roughly correct but the proposed syntax is a little
>>>> off. Some of the ideas being thrown around on that page were preliminary
>>>> and AFAIK everything is still buildable as usual.
>>
>>>> For a configured feature (vs. unconfigured feature) "include" the
>>>> unconfigured feature and then supply a p2.inf to do your customizations.
>>>> If you author new IUFragments in the feature's p2.inf you will in most
>>>> cases have to also add the related require to your feature's IU but with
>>>> that
>> done
>>>> everything will get built correctly. Sorry if that is baffling, I'll
>>>> work
>> on
>>>> some examples once things calm down a bit.
>>
>>>> -Simon
>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>>>> to show how you would package a custom action and something that
>>>>> "meta-requires" it, but doesn't illustrate the concepts covered in the
>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess what is
>>>>> scaring me about this wiki page is this:
>>>>>
>>>>> """
>>>>> Other Considerations
>>>>> If we expect people to simply include the configured features in the
>>>>> products/features then this requires actual configured.feature jars for
>>>>> build purposes. If the configured features are simply IUs in the
>>>>> metadata without an actual jar artifact, then people need to be able to
>>>>> specify includes/requires on IUs directly.
>>>>> """
>>>>>
>>>>> That makes it sound like there is currently no way to build or use
>>>>> these conceptual configured features. Is this page just out of date,
>>>>> or is it really still a theoretical feature at this point?
>>>>>
>>>>> Mark.
>>>>>
>>>>> Simon Kaegi wrote:
>>>>>
>>>>>> Mark,
>>>>>> I posted an archive of a few project to do "installer actions" with
>>>>>> metarequirements that should help.
>>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>>
>>>>>> -Simon
>>>>>
>>>>>
>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>>> Can someone confirm whether or not the information on this wiki page
>>>>>>> is relevant:
>>>>>>>
>>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>>
>>>>>>> As I posted in this newsgroup posting while back
>>>>>
>>>
>>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>>> wrap them in "configuration features", and then nest these features
>>>>>>> somehow to express my dependency relationships.
>>>>>>>
>>>>>>> If I am barking up the wrong tree or this wiki page is an out-of-date
>>>>>>> red herring it would be nice to know now. I also would appreciate
>>>>>>> any pointers to additional examples or documentation on this stuff
>>>>>>> (even existing features I can look at in source form would help!).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mark.
>>>>>>>
>>>>>
>>
|
|
|
| Re: Generating Configuration Metadata [message #130468 is a reply to message #130311] |
Fri, 01 May 2009 17:44 |
| Eclipse User |
|
|
|
The best source of "docs" on the p2.inf format right now is the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=265217
For M7 we just finished porting the eclipse releng process to use the
publisher. Below is an attempted explanation for how it works,
hopefully it will help you.
A lot of this is handled automatically by pde.build when doing product
builds with p2.gathering=true, but for the SDK we do things a little
more "manually" :)
Get the org.eclipse.releng.eclipsebuilder project from cvs
(dev.eclipse.org/cvsroot/eclipse). And also perhaps look at the
metadata from a recent build (the most recent .profile file under
eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\SDK Profile.profile
in an SDK download will do).
The build first does a feature build using p2.gathering=true. There is
nothing particularly special about this part. The feature is a "master"
feature and includes absolutely everything. Once that master build is
done we have a repo with the normal artifacts and metadata for our
features and bundles. We get that signed by shipping it to eclipse.org.
(The build configuration for this is
eclipsebuilder/eclipse/buildConfigs/master).
Once we get that repo back from signing, we generate more product metadata.
The eclipsebuilder project contains an sdk.product file defining the
org.eclipse.sdk.ide product (eclipse/buildConfigs/sdk/packager/sdk.product).
This is a feature based product which includes the org.eclipse.sdk,
org.eclipse.equinox.p2.user.ui and org.eclipse.rcp.configuration
features. (More on rcp.configuration later).
If you look at the .xml of the .product file, you'll see a
<configurations> element that defines start levels and properties. (The
UI editor does not yet handle the properties).
When publishing this product file, the publisher will generate a
'toolingorg.eclipse.sdk.ide.configuration' IU based on these start
levels and properties as well as the product and vm arguments. You'll
also notice a p2.inf for the product, it adds default repository
locations, and also generates IUs to set platform specific values for
osgi.instance.area.default.
The product is published automatically in a product build, for the SDK
we make a specific <p2.publish.product> call in the ant script,
everything else included by the product (features/bundles) is already in
the repo. (see buildAll.xml/packageEclipseDistributables, we are
publishing 6 products this way).
This gets us all our start levels, program args, vm args and config.ini
properties. However, we still don't have launchers properly included in
our product. Normal product builds do launchers for you by branding
the org.eclipse.equinox.executable feature.
We get our launchers using the org.eclipse.rcp.configuration feature.
This part is not for the feint of heart :)
Look under
org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/rcp.c onfig.
There is a feature.xml there, it includes nothing. This feature
contributes root files with a build.properties file. It is grabbing the
launchers from the executable.feature. This will get us the files, but
we still need CUs to set -startup and --launcher.library. We get the
CUs using a p2.inf file. However, that p2.inf would need specific
versions referring to the launcher.jar and fragments and would be
difficult to write.
For normal product builds, pde.build generates a p2.inf for these CUs.
So we do that here, we have a config.product file that includes nothing
except the executable feature (which pulls in the launcher bundle and
fragments). See the buildConfiguration.xml, we don't run a full product
build, only just enough to get the p2.inf file generated. The p2.inf we
start with tells pde.build not to generate default start levels (we
already have them from the sdk.product). The result of the product
script generation adds more properties to this p2.inf. We copy that
generated p2.inf file and use it for our feature.
We then publish our feature the way it would have been published as part
of a normal build using the publisher if you wrote the p2.inf by hand.
(Using <eclipse.gatherFeature>). The result of this is pure metadata,
there is no associated feature.jar for the rcp.configuration feature.
The rcp.configuration feature must be published before publishing the
products that include it.
Later in the build we then do director installs and archive up the resuls.
Mark Melvin wrote:
> Thanks, Simon. It *is* baffling, but I'll keep staring at it until it
> makes sense. ;)
>
> M.
>
> Simon Kaegi wrote:
>
>> The concepts look roughly correct but the proposed syntax is a little
>> off. Some of the ideas being thrown around on that page were
>> preliminary and AFAIK everything is still buildable as usual.
>
>> For a configured feature (vs. unconfigured feature) "include" the
>> unconfigured feature and then supply a p2.inf to do your
>> customizations. If you author new IUFragments in the feature's p2.inf
>> you will in most cases have to also add the related require to your
>> feature's IU but with that done everything will get built correctly.
>> Sorry if that is baffling, I'll work on some examples once things calm
>> down a bit.
>
>> -Simon
>
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>> to show how you would package a custom action and something that
>>> "meta-requires" it, but doesn't illustrate the concepts covered in
>>> the http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess
>>> what is scaring me about this wiki page is this:
>>>
>>> """
>>> Other Considerations
>>> If we expect people to simply include the configured features in the
>>> products/features then this requires actual configured.feature jars
>>> for build purposes. If the configured features are simply IUs in the
>>> metadata without an actual jar artifact, then people need to be able
>>> to specify includes/requires on IUs directly.
>>> """
>>>
>>> That makes it sound like there is currently no way to build or use
>>> these conceptual configured features. Is this page just out of date,
>>> or is it really still a theoretical feature at this point?
>>>
>>> Mark.
>>>
>>> Simon Kaegi wrote:
>>>
>>>> Mark,
>>>> I posted an archive of a few project to do "installer actions" with
>>>> metarequirements that should help.
>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>
>>>> -Simon
>>>
>>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>> Can someone confirm whether or not the information on this wiki
>>>>> page is relevant:
>>>>>
>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>
>>>>> As I posted in this newsgroup posting while back
>>>
> ( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>
>>>>> I am trying to replace our legacy install handlers with P2
>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>> wrap them in "configuration features", and then nest these features
>>>>> somehow to express my dependency relationships.
>>>>>
>>>>> If I am barking up the wrong tree or this wiki page is an
>>>>> out-of-date red herring it would be nice to know now. I also would
>>>>> appreciate any pointers to additional examples or documentation on
>>>>> this stuff (even existing features I can look at in source form
>>>>> would help!).
>>>>>
>>>>> Thanks,
>>>>> Mark.
>>>>>
>>>
>
|
|
|
| Re: Generating Configuration Metadata [message #130481 is a reply to message #130440] |
Fri, 01 May 2009 17:51 |
| Eclipse User |
|
|
|
Hi Mark,
Here's a working p2.inf based on what you sent
--------------------------
properties.0.name=foo
properties.0.value=bar
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=testid0
requires.0.range=[1.2.3,1.2.3]
requires.0.greedy=true
units.0.id=testid0
units.0.version=1.2.3
units.0.provides.0.name=testid0
units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
units.0.provides.0.version=1.2.3
--
The bug was in our handling of the requires.0.range which has to be a strict
match right now (m7) [1.2.3,1.2.3]
Ideally you should be able to use [1.2.3, 1.2.4) and hopefully this will get
fixed in RC1
Also note that the IU that gets produced is bare bones and you even have to
add the iu provides.
"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:e40bfe9f9a442f325f9e563aff970762$1@www.eclipse.org...
> THANK YOU!
>
> I was wondering about this because if I changed my unit.id to be
> "my.feature.jar", the main feature.jar IU would disappear from the
> metadata. This was driving me nuts!
>
> OK, if you want me to file a bug let me know. Otherwise, if you have
> already filed one, please CC me. My bugzilla email address is
>
> mark UNDERSCORE melvin AT amis DOT com.
>
> Thanks,
> Mark.
>
>
> Simon Kaegi wrote:
>
>> Mark,
>> I tried out your example and think you've found a new bug in the Feature
>> exporter when its being over aggresive on what it trims. What I saw was
>> your new IU get created in the temp repo but then was trimmed when we
>> created the final result repo.I'll log it and chase this down.
>
>> Incidentally, the temp repo is in:
>> {workspace}.metadata.pluginsorg.eclipse.pde.coretempp2metada ta
>> If you want to walk through the creation take a look at
>> FeatureAction.generateIU
>
>> -Simon
>
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:4205aa3e1d10987b31926b1234ed8c4a$1@www.eclipse.org...
>>> OK, after a few more hours of trial and error, what you are saying is
>>> starting to make sense. But I still can't make it work. :( If I
>>> understand correctly, I *can* author installation units in my p2.inf. I
>>> take this to mean that I can create complete <unit></unit> blocks in the
>>> metadata, correct?
>>>
>>> Here is what a p2.inf looks like that I have been mucking with:
>>>
>>> properties.0.name=foo
>>> properties.0.value=bar
>>>
>>> requires.0.namespace=org.eclipse.equinox.p2.iu
>>> requires.0.name=testid0
>>> requires.0.range=(1.2.3,1.2.4)
>>> requires.0.greedy=true
>>>
>>> units.0.id=testid0
>>> units.0.version=1.2.3
>>>
>>> This is inside a feature called my.feature. As far as I can tell, the
>>> PDE should generate three IUs for me for this feature like so:
>>>
>>> my.feature.group
>>> +-my.feature.jar
>>> +-testid0
>>>
>>> The problem is, I can't seem to ever get past these two IUs:
>>>
>>> my.feature.group
>>> +-my.feature.jar
>>>
>>> It generates the appropriate properties and requires lines, but I can't
>>> seem to create my own IUs from p2.inf. Am I misunderstanding something?
>>>
>>> Also, if I am creating a wrapper feature that has no content except
>>> metadata dependencies and linked binary artifacts, do I actually need a
>>> feature.jar? I can't seem to make the PDE stop generating that child
>>> IU.
>>>
>>> Thanks,
>>> Mark.
>>>
>>>
>>>> Simon Kaegi wrote:
>>>
>>>>> The concepts look roughly correct but the proposed syntax is a little
>>>>> off. Some of the ideas being thrown around on that page were
>>>>> preliminary and AFAIK everything is still buildable as usual.
>>>
>>>>> For a configured feature (vs. unconfigured feature) "include" the
>>>>> unconfigured feature and then supply a p2.inf to do your
>>>>> customizations. If you author new IUFragments in the feature's p2.inf
>>>>> you will in most cases have to also add the related require to your
>>>>> feature's IU but with that
>>> done
>>>>> everything will get built correctly. Sorry if that is baffling, I'll
>>>>> work
>>> on
>>>>> some examples once things calm down a bit.
>>>
>>>>> -Simon
>>>
>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>>>>> to show how you would package a custom action and something that
>>>>>> "meta-requires" it, but doesn't illustrate the concepts covered in
>>>>>> the http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess
>>>>>> what is scaring me about this wiki page is this:
>>>>>>
>>>>>> """
>>>>>> Other Considerations
>>>>>> If we expect people to simply include the configured features in the
>>>>>> products/features then this requires actual configured.feature jars
>>>>>> for build purposes. If the configured features are simply IUs in the
>>>>>> metadata without an actual jar artifact, then people need to be able
>>>>>> to specify includes/requires on IUs directly.
>>>>>> """
>>>>>>
>>>>>> That makes it sound like there is currently no way to build or use
>>>>>> these conceptual configured features. Is this page just out of date,
>>>>>> or is it really still a theoretical feature at this point?
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Simon Kaegi wrote:
>>>>>>
>>>>>>> Mark,
>>>>>>> I posted an archive of a few project to do "installer actions" with
>>>>>>> metarequirements that should help.
>>>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>>>
>>>>>>> -Simon
>>>>>>
>>>>>>
>>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>>>> Can someone confirm whether or not the information on this wiki
>>>>>>>> page is relevant:
>>>>>>>>
>>>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>>>
>>>>>>>> As I posted in this newsgroup posting while back
>>>>>>
>>>>
>>>
> ( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>>>> wrap them in "configuration features", and then nest these features
>>>>>>>> somehow to express my dependency relationships.
>>>>>>>>
>>>>>>>> If I am barking up the wrong tree or this wiki page is an
>>>>>>>> out-of-date red herring it would be nice to know now. I also would
>>>>>>>> appreciate any pointers to additional examples or documentation on
>>>>>>>> this stuff (even existing features I can look at in source form
>>>>>>>> would help!).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mark.
>>>>>>>>
>>>>>>
>>>
>
|
|
|
| Re: Generating Configuration Metadata [message #130611 is a reply to message #130468] |
Mon, 04 May 2009 15:45 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Thanks for the effort you put into typing all of this out, Andrew. There
are some useful nuggets in here. It looks like some of the new (and as
yet undocument) PDE Ant tasks such as eclipse.gatherFeature may help me a
lot.
And it is good to know where to find the source for all of the bits of the
overall Eclipse build (and how it works!).
Regards,
Mark.
Andrew Niefer wrote:
> The best source of "docs" on the p2.inf format right now is the bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=265217
> For M7 we just finished porting the eclipse releng process to use the
> publisher. Below is an attempted explanation for how it works,
> hopefully it will help you.
> A lot of this is handled automatically by pde.build when doing product
> builds with p2.gathering=true, but for the SDK we do things a little
> more "manually" :)
> Get the org.eclipse.releng.eclipsebuilder project from cvs
> (dev.eclipse.org/cvsroot/eclipse). And also perhaps look at the
> metadata from a recent build (the most recent .profile file under
> eclipsep2org.eclipse.equinox.p2.engineprofileRegistrySDKProf ile.profile
> in an SDK download will do).
> The build first does a feature build using p2.gathering=true. There is
> nothing particularly special about this part. The feature is a "master"
> feature and includes absolutely everything. Once that master build is
> done we have a repo with the normal artifacts and metadata for our
> features and bundles. We get that signed by shipping it to eclipse.org.
> (The build configuration for this is
> eclipsebuilder/eclipse/buildConfigs/master).
> Once we get that repo back from signing, we generate more product metadata.
> The eclipsebuilder project contains an sdk.product file defining the
> org.eclipse.sdk.ide product (eclipse/buildConfigs/sdk/packager/sdk.product).
> This is a feature based product which includes the org.eclipse.sdk,
> org.eclipse.equinox.p2.user.ui and org.eclipse.rcp.configuration
> features. (More on rcp.configuration later).
> If you look at the .xml of the .product file, you'll see a
> <configurations> element that defines start levels and properties. (The
> UI editor does not yet handle the properties).
> When publishing this product file, the publisher will generate a
> 'toolingorg.eclipse.sdk.ide.configuration' IU based on these start
> levels and properties as well as the product and vm arguments. You'll
> also notice a p2.inf for the product, it adds default repository
> locations, and also generates IUs to set platform specific values for
> osgi.instance.area.default.
> The product is published automatically in a product build, for the SDK
> we make a specific <p2.publish.product> call in the ant script,
> everything else included by the product (features/bundles) is already in
> the repo. (see buildAll.xml/packageEclipseDistributables, we are
> publishing 6 products this way).
> This gets us all our start levels, program args, vm args and config.ini
> properties. However, we still don't have launchers properly included in
> our product. Normal product builds do launchers for you by branding
> the org.eclipse.equinox.executable feature.
> We get our launchers using the org.eclipse.rcp.configuration feature.
> This part is not for the feint of heart :)
> Look under
> org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/rcp.c onfig.
> There is a feature.xml there, it includes nothing. This feature
> contributes root files with a build.properties file. It is grabbing the
> launchers from the executable.feature. This will get us the files, but
> we still need CUs to set -startup and --launcher.library. We get the
> CUs using a p2.inf file. However, that p2.inf would need specific
> versions referring to the launcher.jar and fragments and would be
> difficult to write.
> For normal product builds, pde.build generates a p2.inf for these CUs.
> So we do that here, we have a config.product file that includes nothing
> except the executable feature (which pulls in the launcher bundle and
> fragments). See the buildConfiguration.xml, we don't run a full product
> build, only just enough to get the p2.inf file generated. The p2.inf we
> start with tells pde.build not to generate default start levels (we
> already have them from the sdk.product). The result of the product
> script generation adds more properties to this p2.inf. We copy that
> generated p2.inf file and use it for our feature.
> We then publish our feature the way it would have been published as part
> of a normal build using the publisher if you wrote the p2.inf by hand.
> (Using <eclipse.gatherFeature>). The result of this is pure metadata,
> there is no associated feature.jar for the rcp.configuration feature.
> The rcp.configuration feature must be published before publishing the
> products that include it.
> Later in the build we then do director installs and archive up the resuls.
> Mark Melvin wrote:
>> Thanks, Simon. It *is* baffling, but I'll keep staring at it until it
>> makes sense. ;)
>>
>> M.
>>
>> Simon Kaegi wrote:
>>
>>> The concepts look roughly correct but the proposed syntax is a little
>>> off. Some of the ideas being thrown around on that page were
>>> preliminary and AFAIK everything is still buildable as usual.
>>
>>> For a configured feature (vs. unconfigured feature) "include" the
>>> unconfigured feature and then supply a p2.inf to do your
>>> customizations. If you author new IUFragments in the feature's p2.inf
>>> you will in most cases have to also add the related require to your
>>> feature's IU but with that done everything will get built correctly.
>>> Sorry if that is baffling, I'll work on some examples once things calm
>>> down a bit.
>>
>>> -Simon
>>
>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>>> to show how you would package a custom action and something that
>>>> "meta-requires" it, but doesn't illustrate the concepts covered in
>>>> the http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess
>>>> what is scaring me about this wiki page is this:
>>>>
>>>> """
>>>> Other Considerations
>>>> If we expect people to simply include the configured features in the
>>>> products/features then this requires actual configured.feature jars
>>>> for build purposes. If the configured features are simply IUs in the
>>>> metadata without an actual jar artifact, then people need to be able
>>>> to specify includes/requires on IUs directly.
>>>> """
>>>>
>>>> That makes it sound like there is currently no way to build or use
>>>> these conceptual configured features. Is this page just out of date,
>>>> or is it really still a theoretical feature at this point?
>>>>
>>>> Mark.
>>>>
>>>> Simon Kaegi wrote:
>>>>
>>>>> Mark,
>>>>> I posted an archive of a few project to do "installer actions" with
>>>>> metarequirements that should help.
>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>
>>>>> -Simon
>>>>
>>>>
>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>> Can someone confirm whether or not the information on this wiki
>>>>>> page is relevant:
>>>>>>
>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>
>>>>>> As I posted in this newsgroup posting while back
>>>>
>>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>
>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>> wrap them in "configuration features", and then nest these features
>>>>>> somehow to express my dependency relationships.
>>>>>>
>>>>>> If I am barking up the wrong tree or this wiki page is an
>>>>>> out-of-date red herring it would be nice to know now. I also would
>>>>>> appreciate any pointers to additional examples or documentation on
>>>>>> this stuff (even existing features I can look at in source form
>>>>>> would help!).
>>>>>>
>>>>>> Thanks,
>>>>>> Mark.
>>>>>>
>>>>
>>
|
|
|
| Re: Generating Configuration Metadata [message #130626 is a reply to message #130481] |
Mon, 04 May 2009 15:55 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Thanks again, Simon. This works for me.
One more question... ;)
What is it that causes the artifacts.jar to be properly generated? If I
write a p2.inf that results in an IU that declares an artifact, it seems
that the artifact declared never gets placed into artifacts.xml. For
example, let's say I have the following:
----
properties.0.name=foo
properties.0.value=bar
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=testid0
requires.0.range=[1.2.3,1.2.3]
requires.0.greedy=true
units.0.id=testid0
units.0.version=1.2.3
units.0.provides.0.name=testid0
units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
units.0.provides.0.version=1.2.3
units.0.artifacts.0.classifier=binary
units.0.artifacts.0.id=my.binary.artifact
units.0.artifacts.0.version=1.0.0
----
This results in a proper IU in my metadata declaring the binary artifact.
However, nothing is done in artifacts.jar (well...artifacts.xml inside
artifacts.jar, but you know what I mean). All the filters are generated,
but no entry is present for my binary that I declared, even if I
pre-populate the "binary" folder of my repository with the appropriate
file (my.binary.artifact_1.0.0).
What generates the artifacts.xml, and what is it based on?
Oh, and by the way - what does the "requires.greedy" flag mean (sorry
that's two questions...)?
Thanks again,
Mark.
Simon Kaegi wrote:
> Hi Mark,
> Here's a working p2.inf based on what you sent
> --------------------------
> properties.0.name=foo
> properties.0.value=bar
> requires.0.namespace=org.eclipse.equinox.p2.iu
> requires.0.name=testid0
> requires.0.range=[1.2.3,1.2.3]
> requires.0.greedy=true
> units.0.id=testid0
> units.0.version=1.2.3
> units.0.provides.0.name=testid0
> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
> units.0.provides.0.version=1.2.3
> --
> The bug was in our handling of the requires.0.range which has to be a strict
> match right now (m7) [1.2.3,1.2.3]
> Ideally you should be able to use [1.2.3, 1.2.4) and hopefully this will get
> fixed in RC1
> Also note that the IU that gets produced is bare bones and you even have to
> add the iu provides.
> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:e40bfe9f9a442f325f9e563aff970762$1@www.eclipse.org...
>> THANK YOU!
>>
>> I was wondering about this because if I changed my unit.id to be
>> "my.feature.jar", the main feature.jar IU would disappear from the
>> metadata. This was driving me nuts!
>>
>> OK, if you want me to file a bug let me know. Otherwise, if you have
>> already filed one, please CC me. My bugzilla email address is
>>
>> mark UNDERSCORE melvin AT amis DOT com.
>>
>> Thanks,
>> Mark.
>>
>>
>> Simon Kaegi wrote:
>>
>>> Mark,
>>> I tried out your example and think you've found a new bug in the Feature
>>> exporter when its being over aggresive on what it trims. What I saw was
>>> your new IU get created in the temp repo but then was trimmed when we
>>> created the final result repo.I'll log it and chase this down.
>>
>>> Incidentally, the temp repo is in:
>>> {workspace}.metadata.pluginsorg.eclipse.pde.coretempp2metada ta
>>> If you want to walk through the creation take a look at
>>> FeatureAction.generateIU
>>
>>> -Simon
>>
>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>> news:4205aa3e1d10987b31926b1234ed8c4a$1@www.eclipse.org...
>>>> OK, after a few more hours of trial and error, what you are saying is
>>>> starting to make sense. But I still can't make it work. :( If I
>>>> understand correctly, I *can* author installation units in my p2.inf. I
>>>> take this to mean that I can create complete <unit></unit> blocks in the
>>>> metadata, correct?
>>>>
>>>> Here is what a p2.inf looks like that I have been mucking with:
>>>>
>>>> properties.0.name=foo
>>>> properties.0.value=bar
>>>>
>>>> requires.0.namespace=org.eclipse.equinox.p2.iu
>>>> requires.0.name=testid0
>>>> requires.0.range=(1.2.3,1.2.4)
>>>> requires.0.greedy=true
>>>>
>>>> units.0.id=testid0
>>>> units.0.version=1.2.3
>>>>
>>>> This is inside a feature called my.feature. As far as I can tell, the
>>>> PDE should generate three IUs for me for this feature like so:
>>>>
>>>> my.feature.group
>>>> +-my.feature.jar
>>>> +-testid0
>>>>
>>>> The problem is, I can't seem to ever get past these two IUs:
>>>>
>>>> my.feature.group
>>>> +-my.feature.jar
>>>>
>>>> It generates the appropriate properties and requires lines, but I can't
>>>> seem to create my own IUs from p2.inf. Am I misunderstanding something?
>>>>
>>>> Also, if I am creating a wrapper feature that has no content except
>>>> metadata dependencies and linked binary artifacts, do I actually need a
>>>> feature.jar? I can't seem to make the PDE stop generating that child
>>>> IU.
>>>>
>>>> Thanks,
>>>> Mark.
>>>>
>>>>
>>>>> Simon Kaegi wrote:
>>>>
>>>>>> The concepts look roughly correct but the proposed syntax is a little
>>>>>> off. Some of the ideas being thrown around on that page were
>>>>>> preliminary and AFAIK everything is still buildable as usual.
>>>>
>>>>>> For a configured feature (vs. unconfigured feature) "include" the
>>>>>> unconfigured feature and then supply a p2.inf to do your
>>>>>> customizations. If you author new IUFragments in the feature's p2.inf
>>>>>> you will in most cases have to also add the related require to your
>>>>>> feature's IU but with that
>>>> done
>>>>>> everything will get built correctly. Sorry if that is baffling, I'll
>>>>>> work
>>>> on
>>>>>> some examples once things calm down a bit.
>>>>
>>>>>> -Simon
>>>>
>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>>>>> Thanks, Simon. Yes - I found that and had picked it apart. It seems
>>>>>>> to show how you would package a custom action and something that
>>>>>>> "meta-requires" it, but doesn't illustrate the concepts covered in
>>>>>>> the http://wiki.eclipse.org/Equinox/p2/GeneratingCUs page. I guess
>>>>>>> what is scaring me about this wiki page is this:
>>>>>>>
>>>>>>> """
>>>>>>> Other Considerations
>>>>>>> If we expect people to simply include the configured features in the
>>>>>>> products/features then this requires actual configured.feature jars
>>>>>>> for build purposes. If the configured features are simply IUs in the
>>>>>>> metadata without an actual jar artifact, then people need to be able
>>>>>>> to specify includes/requires on IUs directly.
>>>>>>> """
>>>>>>>
>>>>>>> That makes it sound like there is currently no way to build or use
>>>>>>> these conceptual configured features. Is this page just out of date,
>>>>>>> or is it really still a theoretical feature at this point?
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> Simon Kaegi wrote:
>>>>>>>
>>>>>>>> Mark,
>>>>>>>> I posted an archive of a few project to do "installer actions" with
>>>>>>>> metarequirements that should help.
>>>>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>>>>
>>>>>>>> -Simon
>>>>>>>
>>>>>>>
>>>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>>>>> Can someone confirm whether or not the information on this wiki
>>>>>>>>> page is relevant:
>>>>>>>>>
>>>>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>>>>
>>>>>>>>> As I posted in this newsgroup posting while back
>>>>>>>
>>>>>
>>>>
>>
( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>>>>> wrap them in "configuration features", and then nest these features
>>>>>>>>> somehow to express my dependency relationships.
>>>>>>>>>
>>>>>>>>> If I am barking up the wrong tree or this wiki page is an
>>>>>>>>> out-of-date red herring it would be nice to know now. I also would
>>>>>>>>> appreciate any pointers to additional examples or documentation on
>>>>>>>>> this stuff (even existing features I can look at in source form
>>>>>>>>> would help!).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mark.
>>>>>>>>>
>>>>>>>
>>>>
>>
|
|
|
| Re: Generating Configuration Metadata [message #130639 is a reply to message #130626] |
Mon, 04 May 2009 16:17 |
| Eclipse User |
|
|
|
re: artifacts -- Good question.
p2.inf is purely a metadata authoring tool so generating a "new" artifact
description is not currently supported via p2.inf. You can only "reference"
an existing artifact. If you can describe your use-case we can look at doing
something in 3.6.
re: greedy
This sets the relationship as a nice to have vs. really want (but not quite
must have). It's generally of most interest when you have something optional
where we want to decide if we should bring the optional piece in. If the
relationship is greedy we're going to try to bring it into the system if we
can and still resolve the system.
-Simon
"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:9c1191c9f8936719d439614f92d9f7e4$1@www.eclipse.org...
> Thanks again, Simon. This works for me.
>
> One more question... ;)
>
> What is it that causes the artifacts.jar to be properly generated? If I
> write a p2.inf that results in an IU that declares an artifact, it seems
> that the artifact declared never gets placed into artifacts.xml. For
> example, let's say I have the following:
>
> ----
> properties.0.name=foo
> properties.0.value=bar
>
> requires.0.namespace=org.eclipse.equinox.p2.iu
> requires.0.name=testid0
> requires.0.range=[1.2.3,1.2.3]
> requires.0.greedy=true
>
> units.0.id=testid0
> units.0.version=1.2.3
> units.0.provides.0.name=testid0
> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
> units.0.provides.0.version=1.2.3
>
> units.0.artifacts.0.classifier=binary
> units.0.artifacts.0.id=my.binary.artifact
> units.0.artifacts.0.version=1.0.0
> ----
>
> This results in a proper IU in my metadata declaring the binary artifact.
> However, nothing is done in artifacts.jar (well...artifacts.xml inside
> artifacts.jar, but you know what I mean). All the filters are generated,
> but no entry is present for my binary that I declared, even if I
> pre-populate the "binary" folder of my repository with the appropriate
> file (my.binary.artifact_1.0.0).
>
> What generates the artifacts.xml, and what is it based on?
>
> Oh, and by the way - what does the "requires.greedy" flag mean (sorry
> that's two questions...)?
>
> Thanks again,
> Mark.
>
>
> Simon Kaegi wrote:
>
>> Hi Mark,
>
>> Here's a working p2.inf based on what you sent
>> --------------------------
>> properties.0.name=foo
>> properties.0.value=bar
>
>> requires.0.namespace=org.eclipse.equinox.p2.iu
>> requires.0.name=testid0
>> requires.0.range=[1.2.3,1.2.3]
>> requires.0.greedy=true
>
>> units.0.id=testid0
>> units.0.version=1.2.3
>> units.0.provides.0.name=testid0
>> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
>> units.0.provides.0.version=1.2.3
>
>> --
>> The bug was in our handling of the requires.0.range which has to be a
>> strict match right now (m7) [1.2.3,1.2.3]
>> Ideally you should be able to use [1.2.3, 1.2.4) and hopefully this will
>> get fixed in RC1
>
>> Also note that the IU that gets produced is bare bones and you even have
>> to add the iu provides.
>
>
>
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:e40bfe9f9a442f325f9e563aff970762$1@www.eclipse.org...
>>> THANK YOU!
>>>
>>> I was wondering about this because if I changed my unit.id to be
>>> "my.feature.jar", the main feature.jar IU would disappear from the
>>> metadata. This was driving me nuts!
>>>
>>> OK, if you want me to file a bug let me know. Otherwise, if you have
>>> already filed one, please CC me. My bugzilla email address is
>>>
>>> mark UNDERSCORE melvin AT amis DOT com.
>>>
>>> Thanks,
>>> Mark.
>>>
>>>
>>> Simon Kaegi wrote:
>>>
>>>> Mark,
>>>> I tried out your example and think you've found a new bug in the
>>>> Feature exporter when its being over aggresive on what it trims. What I
>>>> saw was your new IU get created in the temp repo but then was trimmed
>>>> when we created the final result repo.I'll log it and chase this down.
>>>
>>>> Incidentally, the temp repo is in:
>>>> {workspace}.metadata.pluginsorg.eclipse.pde.coretempp2metada ta
>>>> If you want to walk through the creation take a look at
>>>> FeatureAction.generateIU
>>>
>>>> -Simon
>>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:4205aa3e1d10987b31926b1234ed8c4a$1@www.eclipse.org...
>>>>> OK, after a few more hours of trial and error, what you are saying is
>>>>> starting to make sense. But I still can't make it work. :( If I
>>>>> understand correctly, I *can* author installation units in my p2.inf.
>>>>> I take this to mean that I can create complete <unit></unit> blocks in
>>>>> the metadata, correct?
>>>>>
>>>>> Here is what a p2.inf looks like that I have been mucking with:
>>>>>
>>>>> properties.0.name=foo
>>>>> properties.0.value=bar
>>>>>
>>>>> requires.0.namespace=org.eclipse.equinox.p2.iu
>>>>> requires.0.name=testid0
>>>>> requires.0.range=(1.2.3,1.2.4)
>>>>> requires.0.greedy=true
>>>>>
>>>>> units.0.id=testid0
>>>>> units.0.version=1.2.3
>>>>>
>>>>> This is inside a feature called my.feature. As far as I can tell, the
>>>>> PDE should generate three IUs for me for this feature like so:
>>>>>
>>>>> my.feature.group
>>>>> +-my.feature.jar
>>>>> +-testid0
>>>>>
>>>>> The problem is, I can't seem to ever get past these two IUs:
>>>>>
>>>>> my.feature.group
>>>>> +-my.feature.jar
>>>>>
>>>>> It generates the appropriate properties and requires lines, but I
>>>>> can't seem to create my own IUs from p2.inf. Am I misunderstanding
>>>>> something?
>>>>>
>>>>> Also, if I am creating a wrapper feature that has no content except
>>>>> metadata dependencies and linked binary artifacts, do I actually need
>>>>> a feature.jar? I can't seem to make the PDE stop generating that
>>>>> child IU.
>>>>>
>>>>> Thanks,
>>>>> Mark.
>>>>>
>>>>>
>>>>>> Simon Kaegi wrote:
>>>>>
>>>>>>> The concepts look roughly correct but the proposed syntax is a
>>>>>>> little off. Some of the ideas being thrown around on that page were
>>>>>>> preliminary and AFAIK everything is still buildable as usual.
>>>>>
>>>>>>> For a configured feature (vs. unconfigured feature) "include" the
>>>>>>> unconfigured feature and then supply a p2.inf to do your
>>>>>>> customizations. If you author new IUFragments in the feature's
>>>>>>> p2.inf you will in most cases have to also add the related require
>>>>>>> to your feature's IU but with that
>>>>> done
>>>>>>> everything will get built correctly. Sorry if that is baffling, I'll
>>>>>>> work
>>>>> on
>>>>>>> some examples once things calm down a bit.
>>>>>
>>>>>>> -Simon
>>>>>
>>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>>> news:b61fcb8a9f0934ad4b599f36c5221189$1@www.eclipse.org...
>>>>>>>> Thanks, Simon. Yes - I found that and had picked it apart. It
>>>>>>>> seems to show how you would package a custom action and something
>>>>>>>> that "meta-requires" it, but doesn't illustrate the concepts
>>>>>>>> covered in the http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>>> page. I guess what is scaring me about this wiki page is this:
>>>>>>>>
>>>>>>>> """
>>>>>>>> Other Considerations
>>>>>>>> If we expect people to simply include the configured features in
>>>>>>>> the products/features then this requires actual configured.feature
>>>>>>>> jars for build purposes. If the configured features are simply IUs
>>>>>>>> in the metadata without an actual jar artifact, then people need to
>>>>>>>> be able to specify includes/requires on IUs directly.
>>>>>>>> """
>>>>>>>>
>>>>>>>> That makes it sound like there is currently no way to build or use
>>>>>>>> these conceptual configured features. Is this page just out of
>>>>>>>> date, or is it really still a theoretical feature at this point?
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> Simon Kaegi wrote:
>>>>>>>>
>>>>>>>>> Mark,
>>>>>>>>> I posted an archive of a few project to do "installer actions"
>>>>>>>>> with metarequirements that should help.
>>>>>>>>> http://dev.eclipse.org/mhonarc/lists/p2-dev/msg01379.html
>>>>>>>>
>>>>>>>>> -Simon
>>>>>>>>
>>>>>>>>
>>>>>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>>>>>> news:01ad8d9a2219e5d0cfd8c3586e2c801d$1@www.eclipse.org...
>>>>>>>>>> Can someone confirm whether or not the information on this wiki
>>>>>>>>>> page is relevant:
>>>>>>>>>>
>>>>>>>>>> http://wiki.eclipse.org/Equinox/p2/GeneratingCUs
>>>>>>>>>>
>>>>>>>>>> As I posted in this newsgroup posting while back
>>>>>>>>
>>>>>>
>>>>>
>>>
> ( http://www.eclipse.org/newsportal/article.php?id=6117&gr oup=eclipse.technology.equinox#6117),
>>>>>>>>>> I am trying to replace our legacy install handlers with P2
>>>>>>>>>> equivalents, but I am still no farther along. I assume I need to
>>>>>>>>>> wrap them in "configuration features", and then nest these
>>>>>>>>>> features somehow to express my dependency relationships.
>>>>>>>>>>
>>>>>>>>>> If I am barking up the wrong tree or this wiki page is an
>>>>>>>>>> out-of-date red herring it would be nice to know now. I also
>>>>>>>>>> would appreciate any pointers to additional examples or
>>>>>>>>>> documentation on this stuff (even existing features I can look at
>>>>>>>>>> in source form would help!).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mark.
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
|
|
| |
| Re: Generating Configuration Metadata [message #130704 is a reply to message #130651] |
Tue, 05 May 2009 12:46 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Mark Melvin wrote:
> Simon Kaegi wrote:
>> re: artifacts -- Good question.
>> p2.inf is purely a metadata authoring tool so generating a "new" artifact
>> description is not currently supported via p2.inf. You can only "reference"
>> an existing artifact. If you can describe your use-case we can look at
doing
>> something in 3.6.
> OK. But what generates it now, and when? If I am going to have to create
> my own artifact descriptions I guess I need to know where and how I can
> hook this into the process so I can merge things. Or perhaps I should
> keep all my manually maintained stuff separate and look at composite
> repositories?
> My use case is basically that I am trying to use p2.inf to create IUs for
> zip files of external files that will be installed with certain features.
> It looks like I can create the metadata for the IUs but I am unclear as to
> how to get those zip files into the "binary" folder of a repository, and
> get them into the artifacts.xml file. How/when is this done for feature
> and bundle JARs?
> (Yes I know about the "root files" thing, but I need to go beyond that
> functionality...)
>> re: greedy
>> This sets the relationship as a nice to have vs. really want (but not quite
>> must have). It's generally of most interest when you have something
optional
>> where we want to decide if we should bring the optional piece in. If the
>> relationship is greedy we're going to try to bring it into the system if we
>> can and still resolve the system.
> OK. So does "nice to have" = false, or is it the other way around? ;) I
> can't think of a scenario where I would not want a requires to mean
> "absolutely I need it". I'm still a little unclear on this one. Do you
> have an example?
Hey Simon,
Back to my use case for creating my own artifact declarations. I have
been mucking around with the "root files" feature because it seems that is
the only crack you can squeeze through to have PDE generate the
artifacts.xml and zip up the files for you (thanks to Andrew's pointer as
well).
It turns out, this *almost* does what I need it to do. I am trying to
achieve something very similar, in particular, have a feature I can
include in other features that ships binaries for me. However, unless I
am missing something it seems to me that there is no possible way to place
the files anywhere other than in or below the root "eclipse" folder. Most
of the time I want to simply place the files in directories up one level
from the root "eclipse" folder, and other times I would like to place them
elsewhere on the machine (Program Files\Common\blah).
This is very easily achievable with a simple native touchpoint action
specification, but again, unless I am missing something, you can't
override the touchpoint action used for a "root files" binary artifact.
If I had the power to re-declare the touchpoint action used by feature
shipping the root files, I would be a happy camper. Then the PDE could
create my zipfiles for me, *and* generate the artifacts.xml as well as the
metadata.
I have tried overriding the root files behaviour in my p2.inf, but it ends
up confused, or just truncating or pruning things out similar to bug
#274702. Here is an example of what I tried:
My build.properties contains:
root=some_folder
And my p2.inf contains:
properties.0.name=foo
properties.0.value=bar
requires.0.namespace=org.eclipse.equinox.p2.iu
requires.0.name=com.signaklara.artifact.cat1.image_root
requires.0.range=[1.0.1.$qualifier$,1.0.1.$qualifier$]
requires.0.greedy=true
units.0.id=com.signaklara.artifact.cat1.image_root
units.0.version=1.0.1.$qualifier$
units.0.singleton=true
units.0.provides.0.name=com.signaklara.artifact.cat1.image_r oot
units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
units.0.provides.0.version=1.0.1.$qualifier$
units.0.artifacts.0.classifier=binary
units.0.artifacts.0.id=com.signaklara.artifact.cat1.image_ro ot
units.0.artifacts.0.version=1.0.1.$qualifier$
units.0.touchpoint.id=org.eclipse.equinox.p2.native
units.0.touchpoint.version=1.0.0
units.0.instructions.install=unzip(source:@artifact,
target:${installFolder}/../);
units.0.instructions.uninstall=cleanupzip(source:@artifact,
target:${installFolder}/../);
This ends up removing the <artifacts> clause from my IU and the binary
folder disappears. It almost works, but as I approach completeness in my
p2.inf above, things start to disappear. However, if I look in the
temporary work area of my workspace, it looks like precisely the
information I was trying to generate is there. Perhaps bug #274702 is
more widespread?
Mark.
|
|
|
| Re: Generating Configuration Metadata [message #130717 is a reply to message #130704] |
Tue, 05 May 2009 13:07 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Mark Melvin wrote:
> Mark Melvin wrote:
>> Simon Kaegi wrote:
>>> re: artifacts -- Good question.
>>> p2.inf is purely a metadata authoring tool so generating a "new" artifact
>>> description is not currently supported via p2.inf. You can only
"reference"
>>> an existing artifact. If you can describe your use-case we can look at
> doing
>>> something in 3.6.
>> OK. But what generates it now, and when? If I am going to have to create
>> my own artifact descriptions I guess I need to know where and how I can
>> hook this into the process so I can merge things. Or perhaps I should
>> keep all my manually maintained stuff separate and look at composite
>> repositories?
>> My use case is basically that I am trying to use p2.inf to create IUs for
>> zip files of external files that will be installed with certain features.
>> It looks like I can create the metadata for the IUs but I am unclear as to
>> how to get those zip files into the "binary" folder of a repository, and
>> get them into the artifacts.xml file. How/when is this done for feature
>> and bundle JARs?
>> (Yes I know about the "root files" thing, but I need to go beyond that
>> functionality...)
>>> re: greedy
>>> This sets the relationship as a nice to have vs. really want (but not
quite
>>> must have). It's generally of most interest when you have something
> optional
>>> where we want to decide if we should bring the optional piece in. If the
>>> relationship is greedy we're going to try to bring it into the system if
we
>>> can and still resolve the system.
>> OK. So does "nice to have" = false, or is it the other way around? ;) I
>> can't think of a scenario where I would not want a requires to mean
>> "absolutely I need it". I'm still a little unclear on this one. Do you
>> have an example?
> Hey Simon,
> Back to my use case for creating my own artifact declarations. I have
> been mucking around with the "root files" feature because it seems that is
> the only crack you can squeeze through to have PDE generate the
> artifacts.xml and zip up the files for you (thanks to Andrew's pointer as
> well).
> It turns out, this *almost* does what I need it to do. I am trying to
> achieve something very similar, in particular, have a feature I can
> include in other features that ships binaries for me. However, unless I
> am missing something it seems to me that there is no possible way to place
> the files anywhere other than in or below the root "eclipse" folder. Most
> of the time I want to simply place the files in directories up one level
> from the root "eclipse" folder, and other times I would like to place them
> elsewhere on the machine (Program FilesCommonblah).
> This is very easily achievable with a simple native touchpoint action
> specification, but again, unless I am missing something, you can't
> override the touchpoint action used for a "root files" binary artifact.
> If I had the power to re-declare the touchpoint action used by feature
> shipping the root files, I would be a happy camper. Then the PDE could
> create my zipfiles for me, *and* generate the artifacts.xml as well as the
> metadata.
> I have tried overriding the root files behaviour in my p2.inf, but it ends
> up confused, or just truncating or pruning things out similar to bug
> #274702. Here is an example of what I tried:
> My build.properties contains:
> root=some_folder
> And my p2.inf contains:
> properties.0.name=foo
> properties.0.value=bar
> requires.0.namespace=org.eclipse.equinox.p2.iu
> requires.0.name=com.signaklara.artifact.cat1.image_root
> requires.0.range=[1.0.1.$qualifier$,1.0.1.$qualifier$]
> requires.0.greedy=true
> units.0.id=com.signaklara.artifact.cat1.image_root
> units.0.version=1.0.1.$qualifier$
> units.0.singleton=true
> units.0.provides.0.name=com.signaklara.artifact.cat1.image_r oot
> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
> units.0.provides.0.version=1.0.1.$qualifier$
> units.0.artifacts.0.classifier=binary
> units.0.artifacts.0.id=com.signaklara.artifact.cat1.image_ro ot
> units.0.artifacts.0.version=1.0.1.$qualifier$
> units.0.touchpoint.id=org.eclipse.equinox.p2.native
> units.0.touchpoint.version=1.0.0
> units.0.instructions.install=unzip(source:@artifact,
> target:${installFolder}/../);
> units.0.instructions.uninstall=cleanupzip(source:@artifact,
> target:${installFolder}/../);
> This ends up removing the <artifacts> clause from my IU and the binary
> folder disappears. It almost works, but as I approach completeness in my
> p2.inf above, things start to disappear. However, if I look in the
> temporary work area of my workspace, it looks like precisely the
> information I was trying to generate is there. Perhaps bug #274702 is
> more widespread?
Actually I just figured out the problem - my feature version did not match
my declared artifact/IU versions. I updated my response in the bug.
I hope I am not totally buggering with the system doing this. It seems to
do almost what I want. It allows me to hookup custom touchpoint actions
as root file installers, and I think I could even generate the p2.inf as
part of a build process.
Mark.
M.
|
|
|
| Re: Generating Configuration Metadata [message #130766 is a reply to message #130717] |
Tue, 05 May 2009 23:11 |
| Eclipse User |
|
|
|
Nice!
You've done what I was a bit scared to suggest ;)
This is the approach I'm going to experiment with when I get the chance but
you're breaking new ground (but from the sounds of it the right ground).
-Simon
"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:581af5a95fe54b171f7816ec06ede1cc$1@www.eclipse.org...
> Mark Melvin wrote:
>
>> Mark Melvin wrote:
>
>>> Simon Kaegi wrote:
>
>>>> re: artifacts -- Good question.
>>>> p2.inf is purely a metadata authoring tool so generating a "new"
>>>> artifact description is not currently supported via p2.inf. You can
>>>> only
> "reference"
>>>> an existing artifact. If you can describe your use-case we can look at
>> doing
>>>> something in 3.6.
>
>>> OK. But what generates it now, and when? If I am going to have to
>>> create my own artifact descriptions I guess I need to know where and how
>>> I can hook this into the process so I can merge things. Or perhaps I
>>> should keep all my manually maintained stuff separate and look at
>>> composite repositories?
>
>>> My use case is basically that I am trying to use p2.inf to create IUs
>>> for zip files of external files that will be installed with certain
>>> features. It looks like I can create the metadata for the IUs but I am
>>> unclear as to how to get those zip files into the "binary" folder of a
>>> repository, and get them into the artifacts.xml file. How/when is this
>>> done for feature and bundle JARs?
>
>>> (Yes I know about the "root files" thing, but I need to go beyond that
>>> functionality...)
>
>
>>>> re: greedy
>>>> This sets the relationship as a nice to have vs. really want (but not
> quite
>>>> must have). It's generally of most interest when you have something
>> optional
>>>> where we want to decide if we should bring the optional piece in. If
>>>> the relationship is greedy we're going to try to bring it into the
>>>> system if
> we
>>>> can and still resolve the system.
>
>>> OK. So does "nice to have" = false, or is it the other way around? ;)
>>> I can't think of a scenario where I would not want a requires to mean
>>> "absolutely I need it". I'm still a little unclear on this one. Do you
>>> have an example?
>
>
>> Hey Simon,
>
>> Back to my use case for creating my own artifact declarations. I have
>> been mucking around with the "root files" feature because it seems that
>> is the only crack you can squeeze through to have PDE generate the
>> artifacts.xml and zip up the files for you (thanks to Andrew's pointer as
>> well).
>
>> It turns out, this *almost* does what I need it to do. I am trying to
>> achieve something very similar, in particular, have a feature I can
>> include in other features that ships binaries for me. However, unless I
>> am missing something it seems to me that there is no possible way to
>> place the files anywhere other than in or below the root "eclipse"
>> folder. Most of the time I want to simply place the files in directories
>> up one level from the root "eclipse" folder, and other times I would like
>> to place them elsewhere on the machine (Program FilesCommonblah).
>
>> This is very easily achievable with a simple native touchpoint action
>> specification, but again, unless I am missing something, you can't
>> override the touchpoint action used for a "root files" binary artifact.
>> If I had the power to re-declare the touchpoint action used by feature
>> shipping the root files, I would be a happy camper. Then the PDE could
>> create my zipfiles for me, *and* generate the artifacts.xml as well as
>> the metadata.
>
>> I have tried overriding the root files behaviour in my p2.inf, but it
>> ends up confused, or just truncating or pruning things out similar to bug
>> #274702. Here is an example of what I tried:
>
>> My build.properties contains:
>
>> root=some_folder
>
>> And my p2.inf contains:
>
>> properties.0.name=foo
>> properties.0.value=bar
>
>> requires.0.namespace=org.eclipse.equinox.p2.iu
>> requires.0.name=com.signaklara.artifact.cat1.image_root
>> requires.0.range=[1.0.1.$qualifier$,1.0.1.$qualifier$]
>> requires.0.greedy=true
>
>> units.0.id=com.signaklara.artifact.cat1.image_root
>> units.0.version=1.0.1.$qualifier$
>> units.0.singleton=true
>> units.0.provides.0.name=com.signaklara.artifact.cat1.image_r oot
>> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
>> units.0.provides.0.version=1.0.1.$qualifier$
>> units.0.artifacts.0.classifier=binary
>> units.0.artifacts.0.id=com.signaklara.artifact.cat1.image_ro ot
>> units.0.artifacts.0.version=1.0.1.$qualifier$
>> units.0.touchpoint.id=org.eclipse.equinox.p2.native
>> units.0.touchpoint.version=1.0.0
>> units.0.instructions.install=unzip(source:@artifact,
>> target:${installFolder}/../);
>> units.0.instructions.uninstall=cleanupzip(source:@artifact,
>> target:${installFolder}/../);
>
>> This ends up removing the <artifacts> clause from my IU and the binary
>> folder disappears. It almost works, but as I approach completeness in my
>> p2.inf above, things start to disappear. However, if I look in the
>> temporary work area of my workspace, it looks like precisely the
>> information I was trying to generate is there. Perhaps bug #274702 is
>> more widespread?
>
> Actually I just figured out the problem - my feature version did not match
> my declared artifact/IU versions. I updated my response in the bug.
>
> I hope I am not totally buggering with the system doing this. It seems to
> do almost what I want. It allows me to hookup custom touchpoint actions
> as root file installers, and I think I could even generate the p2.inf as
> part of a build process.
>
> Mark.
> M.
>
|
|
|
| Re: Generating Configuration Metadata [message #130890 is a reply to message #130468] |
Wed, 06 May 2009 17:14 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Andrew Niefer wrote:
> The best source of "docs" on the p2.inf format right now is the bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=265217
> For M7 we just finished porting the eclipse releng process to use the
> publisher. Below is an attempted explanation for how it works,
> hopefully it will help you.
> A lot of this is handled automatically by pde.build when doing product
> builds with p2.gathering=true, but for the SDK we do things a little
> more "manually" :)
> Get the org.eclipse.releng.eclipsebuilder project from cvs
> (dev.eclipse.org/cvsroot/eclipse). And also perhaps look at the
> metadata from a recent build (the most recent .profile file under
> eclipsep2org.eclipse.equinox.p2.engineprofileRegistrySDKProf ile.profile
> in an SDK download will do).
> The build first does a feature build using p2.gathering=true. There is
> nothing particularly special about this part. The feature is a "master"
> feature and includes absolutely everything. Once that master build is
> done we have a repo with the normal artifacts and metadata for our
> features and bundles. We get that signed by shipping it to eclipse.org.
> (The build configuration for this is
> eclipsebuilder/eclipse/buildConfigs/master).
> Once we get that repo back from signing, we generate more product metadata.
> The eclipsebuilder project contains an sdk.product file defining the
> org.eclipse.sdk.ide product (eclipse/buildConfigs/sdk/packager/sdk.product).
> This is a feature based product which includes the org.eclipse.sdk,
> org.eclipse.equinox.p2.user.ui and org.eclipse.rcp.configuration
> features. (More on rcp.configuration later).
> If you look at the .xml of the .product file, you'll see a
> <configurations> element that defines start levels and properties. (The
> UI editor does not yet handle the properties).
> When publishing this product file, the publisher will generate a
> 'toolingorg.eclipse.sdk.ide.configuration' IU based on these start
> levels and properties as well as the product and vm arguments. You'll
> also notice a p2.inf for the product, it adds default repository
> locations, and also generates IUs to set platform specific values for
> osgi.instance.area.default.
> The product is published automatically in a product build, for the SDK
> we make a specific <p2.publish.product> call in the ant script,
> everything else included by the product (features/bundles) is already in
> the repo. (see buildAll.xml/packageEclipseDistributables, we are
> publishing 6 products this way).
> This gets us all our start levels, program args, vm args and config.ini
> properties. However, we still don't have launchers properly included in
> our product. Normal product builds do launchers for you by branding
> the org.eclipse.equinox.executable feature.
> We get our launchers using the org.eclipse.rcp.configuration feature.
> This part is not for the feint of heart :)
> Look under
> org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/rcp.c onfig.
> There is a feature.xml there, it includes nothing. This feature
> contributes root files with a build.properties file. It is grabbing the
> launchers from the executable.feature. This will get us the files, but
> we still need CUs to set -startup and --launcher.library. We get the
> CUs using a p2.inf file. However, that p2.inf would need specific
> versions referring to the launcher.jar and fragments and would be
> difficult to write.
> For normal product builds, pde.build generates a p2.inf for these CUs.
> So we do that here, we have a config.product file that includes nothing
> except the executable feature (which pulls in the launcher bundle and
> fragments). See the buildConfiguration.xml, we don't run a full product
> build, only just enough to get the p2.inf file generated. The p2.inf we
> start with tells pde.build not to generate default start levels (we
> already have them from the sdk.product). The result of the product
> script generation adds more properties to this p2.inf. We copy that
> generated p2.inf file and use it for our feature.
> We then publish our feature the way it would have been published as part
> of a normal build using the publisher if you wrote the p2.inf by hand.
> (Using <eclipse.gatherFeature>). The result of this is pure metadata,
> there is no associated feature.jar for the rcp.configuration feature.
> The rcp.configuration feature must be published before publishing the
> products that include it.
> Later in the build we then do director installs and archive up the resuls.
Hey Andrew,
Looking at the p2.inf included in
org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/rcp.c onfig I see
the following:
properties.1.name=org.eclipse.equinox.p2.type.group
properties.1.value=false
What is the point of this property being set? I am trying to do it on my
feature and it appears to do nothing at all. The property
"org.eclipse.equinox.p2.type.group" always ends up as "true" in my
metadata.
Thanks,
Mark.
|
|
| | |
| Re: Generating Configuration Metadata [message #130956 is a reply to message #130766] |
Fri, 08 May 2009 08:49 |
| Eclipse User |
|
|
|
Mark,
I did a bit of digging into your approach and although the replacement of
the root iu works it feels a bit random and potentially hard to support
going forward. I think the underlying problem is that we don't have a good
way to refer to artifacts in features. I've opened up
https://bugs.eclipse.org/bugs/show_bug.cgi?id=275404 to look at improving
the syntax we can use to refer to artifact paths. We'll see what happens for
3.5 but that might be a good bug to follow.
-Simon
"Simon Kaegi" <simon_kaegi@ca.ibm.com> wrote in message
news:gtqv4v$718$1@build.eclipse.org...
> Nice!
> You've done what I was a bit scared to suggest ;)
> This is the approach I'm going to experiment with when I get the chance
> but you're breaking new ground (but from the sounds of it the right
> ground).
> -Simon
>
> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:581af5a95fe54b171f7816ec06ede1cc$1@www.eclipse.org...
>> Mark Melvin wrote:
>>
>>> Mark Melvin wrote:
>>
>>>> Simon Kaegi wrote:
>>
>>>>> re: artifacts -- Good question.
>>>>> p2.inf is purely a metadata authoring tool so generating a "new"
>>>>> artifact description is not currently supported via p2.inf. You can
>>>>> only
>> "reference"
>>>>> an existing artifact. If you can describe your use-case we can look at
>>> doing
>>>>> something in 3.6.
>>
>>>> OK. But what generates it now, and when? If I am going to have to
>>>> create my own artifact descriptions I guess I need to know where and
>>>> how I can hook this into the process so I can merge things. Or perhaps
>>>> I should keep all my manually maintained stuff separate and look at
>>>> composite repositories?
>>
>>>> My use case is basically that I am trying to use p2.inf to create IUs
>>>> for zip files of external files that will be installed with certain
>>>> features. It looks like I can create the metadata for the IUs but I am
>>>> unclear as to how to get those zip files into the "binary" folder of a
>>>> repository, and get them into the artifacts.xml file. How/when is this
>>>> done for feature and bundle JARs?
>>
>>>> (Yes I know about the "root files" thing, but I need to go beyond that
>>>> functionality...)
>>
>>
>>>>> re: greedy
>>>>> This sets the relationship as a nice to have vs. really want (but not
>> quite
>>>>> must have). It's generally of most interest when you have something
>>> optional
>>>>> where we want to decide if we should bring the optional piece in. If
>>>>> the relationship is greedy we're going to try to bring it into the
>>>>> system if
>> we
>>>>> can and still resolve the system.
>>
>>>> OK. So does "nice to have" = false, or is it the other way around? ;)
>>>> I can't think of a scenario where I would not want a requires to mean
>>>> "absolutely I need it". I'm still a little unclear on this one. Do
>>>> you have an example?
>>
>>
>>> Hey Simon,
>>
>>> Back to my use case for creating my own artifact declarations. I have
>>> been mucking around with the "root files" feature because it seems that
>>> is the only crack you can squeeze through to have PDE generate the
>>> artifacts.xml and zip up the files for you (thanks to Andrew's pointer
>>> as well).
>>
>>> It turns out, this *almost* does what I need it to do. I am trying to
>>> achieve something very similar, in particular, have a feature I can
>>> include in other features that ships binaries for me. However, unless I
>>> am missing something it seems to me that there is no possible way to
>>> place the files anywhere other than in or below the root "eclipse"
>>> folder. Most of the time I want to simply place the files in
>>> directories up one level from the root "eclipse" folder, and other times
>>> I would like to place them elsewhere on the machine (Program
>>> FilesCommonblah).
>>
>>> This is very easily achievable with a simple native touchpoint action
>>> specification, but again, unless I am missing something, you can't
>>> override the touchpoint action used for a "root files" binary artifact.
>>> If I had the power to re-declare the touchpoint action used by feature
>>> shipping the root files, I would be a happy camper. Then the PDE could
>>> create my zipfiles for me, *and* generate the artifacts.xml as well as
>>> the metadata.
>>
>>> I have tried overriding the root files behaviour in my p2.inf, but it
>>> ends up confused, or just truncating or pruning things out similar to
>>> bug #274702. Here is an example of what I tried:
>>
>>> My build.properties contains:
>>
>>> root=some_folder
>>
>>> And my p2.inf contains:
>>
>>> properties.0.name=foo
>>> properties.0.value=bar
>>
>>> requires.0.namespace=org.eclipse.equinox.p2.iu
>>> requires.0.name=com.signaklara.artifact.cat1.image_root
>>> requires.0.range=[1.0.1.$qualifier$,1.0.1.$qualifier$]
>>> requires.0.greedy=true
>>
>>> units.0.id=com.signaklara.artifact.cat1.image_root
>>> units.0.version=1.0.1.$qualifier$
>>> units.0.singleton=true
>>> units.0.provides.0.name=com.signaklara.artifact.cat1.image_r oot
>>> units.0.provides.0.namespace=org.eclipse.equinox.p2.iu
>>> units.0.provides.0.version=1.0.1.$qualifier$
>>> units.0.artifacts.0.classifier=binary
>>> units.0.artifacts.0.id=com.signaklara.artifact.cat1.image_ro ot
>>> units.0.artifacts.0.version=1.0.1.$qualifier$
>>> units.0.touchpoint.id=org.eclipse.equinox.p2.native
>>> units.0.touchpoint.version=1.0.0
>>> units.0.instructions.install=unzip(source:@artifact,
>>> target:${installFolder}/../);
>>> units.0.instructions.uninstall=cleanupzip(source:@artifact,
>>> target:${installFolder}/../);
>>
>>> This ends up removing the <artifacts> clause from my IU and the binary
>>> folder disappears. It almost works, but as I approach completeness in
>>> my p2.inf above, things start to disappear. However, if I look in the
>>> temporary work area of my workspace, it looks like precisely the
>>> information I was trying to generate is there. Perhaps bug #274702 is
>>> more widespread?
>>
>> Actually I just figured out the problem - my feature version did not
>> match my declared artifact/IU versions. I updated my response in the
>> bug.
>>
>> I hope I am not totally buggering with the system doing this. It seems
>> to do almost what I want. It allows me to hookup custom touchpoint
>> actions as root file installers, and I think I could even generate the
>> p2.inf as part of a build process.
>>
>> Mark.
>> M.
>>
>
>
|
|
|
Goto Forum:
Current Time: Wed May 07 19:43:22 EDT 2025
Powered by FUDForum. Page generated in 0.05571 seconds |
Home