Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. We'd like to replace and/or modify the contents of generated files. In particular Info.plist and config.ini. 2. Adding the modified copies as root files, they get overwritten by the generated ones or ignored. 3. Setting the custom config.ini the .product file seemed to break the build (having to do with the bundles.info listing). More information: Basically we want to replace the generated Info.plist file with our own Using rootfiles we couldn't achieve this. I resorted to unzipping the binary P2 artifact, overwriting it and then zipping the artifact back up - as part of a postBuild target. We also wanted to append custom property settings to the end of the generated config.ini. I didn't see any easy mechanism for doing so. We used the same process as Info.plist, but instead of replacing the file we just appended to the existing config.ini.
This is really more of a question than a bug. I'm looking for the best way to achieve what we intend here in the most "Eclipse-approved" way in terms of where and how to do this in the build process. I'm pretty sure my hacking the binary p2 artifact is the wrong way to go.
The two files are different 1) config.ini : in a p2 install, this is a managed file and we really shouldn't be shipping this file. I would expect any changes done in a post-build step would simply get lost when p2 generates the file. In a 3.4 based build using p2.generate.metadata, the config.ini is used as input to the metadata generator and the resulting metadata controls the generation of the config.ini at install time. Changes should be made in customTargets/preProcess (on the file in its original location under buildDirectory/features/org.eclipse.pde.build.container.feature/productRootFiles), or in customAssembly.xml/post.gather.bin.parts (on the file whin ${eclipse.base}). This approach wouldn't work in a 3.5 based p2.gathering=true build. These changes are more properly done using the "setProgramProperty" action to the configure phase of some IU. The p2.inf file can be used to add this action, in 3.5 a p2.inf can also be used together with the .product file, or in a feature. 2) Similar to (1), in that changes can be made to the file after it has been gathered using customAssembly/post.gather.bin.parts. This will result in the modified file being in the artifact. Changing the artifact after the fact will alter the MD5 sum so that it no longer matches the artifacts.xml. As with (1), this will only work in a 3.4 based p2.generate.metadata based build. In 3.5 p2.gathering build, root files are instead associated with the feature that contributed them instead of all being in one artifact for the product. In the particular case of files coming from the equinox.executable feature, these artifacts will be branded to match the product and would end up being named something like org.example.rcp.product_root.carbon.macosx.ppc_1.0.0 There currently isn't any way to modify this except after-the-fact, unless you were to not use the equinox.executable feature and instead provide your own feature which provides the executables.
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
