Community
Participate
Working Groups
The current functionality in p2.inf allows one to add new "instructions" and their associated actions to an IU. See http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instructions#Authoring_touchpoint_data For example: instructions.install = chmod targetDir:@artifact,targetFile:lib/lib.so,permissions:755); We had a further conversation on the equinox-dev call about enhancing this format with some of the use-cases captured here - http://wiki.eclipse.org/Equinox/p2/GeneratingCUs This boils down to two requirements on the p2.inf format: 1) The ability to provide IU advice for more than just the instructions 2) The ability to provide metadata to crete CUs independent from the containing IU. A third requirement is that we don't want to introduce a new format as this will break existing p2.inf users. -- This bug proposes adding support for additional advice as follows: Note: # is a numeric index starting from 0 that we use to handle lists of advice. e.g. some.advice.#.attribute1 --> some.advice.0.attribute1 hostRequirements.#.namespace hostRequirements.#.name hostRequirements.#.range hostRequirements.#.greedy properties.#.name properties.#.value provides.#.namespace provides.#.name provides.#.version requires.#.namespace requires.#.name requires.#.range requires.#.greedy filter artifacts.#.classifier artifacts.#.id artifacts.#.version touchpoint.id touchpoint.version instructions.<phase> instructions.<phase>.import licenses.# copyright -- Note: this leaves out {changes, patchScope, and lifecycle as these are patches} --- If the advice is for a new CU we use the following syntax to define the CU: unit.#.id unit.#.version unit.#.singleton To provide advice for this CU we use "unit.#" as the prefix. For example: unit.[0].instructions.install = chmod targetDir:@artifact,targetFile:lib/lib.so,permissions:755);
Did that get discussed with Andrew ? We don't have much time and we should make sure to only add what we need.
Yes I have talked with Simon about this, I was quite happy to let him run with this :) The large portion of the work here is simply working out the details of the format, parsing the properties file, and actually creating the CUs. Adding extra properties (requires, provides, etc) are easy after that. Simon, just to clarify with an example: say I have org.eclipse.equinox.launcher_1.0.200.v20090209-1900 And I want a CU adding -startup, and I want this to be done from some other feature/product p2.inf. Is this correct: unit.1.id=my.product.launcher unit.1.version=1.0.200.v200209-1900 unit.1.singleton=true unit.1.hostRequirements.1.namespace=osgi.bundle unit.1.hostRequirements.1.name=org.eclipse.equinox.launcher unit.1.hostRequirements.1.range=[1.0.200.v200209-1900, 1.0.200.v200209-1900] unit.1.hostRequirements.1.greedy=false unit.1.instructions.configure=addProgramArg(programArg:-startup); \ addProgramArg(programArg:@artifact); unit.1.instructions.unconfigure=removeProgramArg(programArg:-startup); \ removeProgramArg(programArg:@artifact); One thing I immediately notice is the versions. We will need a mechanism where this can handled automatically so the p2.inf does not need to be changed for each build. Perhaps a value of 'derived' should tell the publisher to insert proper versions according to whatever other advice it has.
What you've got there looks correct. Talking to Jeff he suggested we can maybe use some version/qualifier advice and then some sort of key like {version}/{qualifier} or perhaps some other more consistent substitution token. Extending what we can add to the IU is pretty easy however adding CUs is a bit more tricky since we don't currently have a place to look for this stuff.
Marking FIXED. (finally!) That was a bit more work than I had anticipated. Thanks to Andrew for all of the PDE build test cases and fixes. From the original syntax we have changed "unit" to "units" to be consistent with everything else that holds an array-like structure. The version support is very basic and currently supports only the special keywords $qualifier$ and $version$. These are used for simple string replacement and (currently) no version advice is consulted. For example with host version 1.2.3.v20090225 ... 1.1.1.$qualifier$ becomes 1.2.3.v20090225 [$version$, 2.0) becomes [1.2.3.v20090225, 2.0) The full iu and iufragment syntax is supported and at least until the wiki is updated the best source of precisely all the right names is in org.eclipse.equinox.p2.tests.publisher.actions.AdviceFileParserTests.
The line in the comment above: 1.1.1.$qualifier$ becomes 1.2.3.v20090225 should have been: 1.1.1.$qualifier$ becomes 1.1.1.v20090225 --- I also should that advicefile processing is in place just for bundles, features, and products.
Andrew pointed out a bug where we were using: properties.propertyName=propertyValue instead of what's correctly documented in the initial comment properties.#.name properties.#.value -- This is an obvious mistake as the key portion should not be used to hold an attribute value to avoid escaping problems when a property name contains a '.'. This is now fixed in HEAD along with a couple of tests.
