Community
Participate
Working Groups
This bug opened in response to mailing list request: https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg25014.html
It is not exactly a super-simple thing and depends on several "tricks" to get around the lack of support for it in Tycho. I think the "Tycho recommendation" is to do it in two steps. First "build everything" with the desired fix, and save away the repository locally (by which I think they mean the maven repository). So you'd need to do some sort of mvn clean deploy, instead of a simple mvn clean verify as we normally do. Then, second step, do a completely separate build of your feature patch, which makes use of the locally deployed maven repo from the first step so it "picks up" only what you need. = = = = = = = Not being satisfied with that two pass approach, I "trial-and-errored" my way to a method that works for our BETA-JAVA9 patch which in theory should work for a wide variety of cases, but, may not work for all cases. I could not find any prose documentation I wrote for it -- might be in some past bug, probably for the BETA-JAVA8 patch -- but I'll point you to the critical pieces, and if you get it to work for your case, perhaps you could write up a nice "how to" wiki page. - The part that does the main work: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/java9patch46 The "root pom" in that project becomes *the* pom we build in our mvn clean command, using -f ${ALTERNATE_POM} (or, similar name). Note it has two "dummy" pieces, a feature and bundle that "stand in" for the original feature we are patching (i.e. their "version and qualifier must "match" the feature we want to patch). Then the real feature (patch) we desire as output. And of course a little p2 repo that contains the output. - Critical setup done in parent pom: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-platform-parent/pom.xml#n645 We use this "java9patch" profile to set up the critical variables and "reference repository" that the first part depends on. By "reference repository" I mean the p2 repository that the feature-patch-build can pull from, for anything that is required by the feature patch, but that we are not rebuilding. Typically this is the repository that the original install would come from -- such as a "release" that has the feature (same version/qualifier) we are patching. - Control variable Much of what happens depends on this variable in our bootstrap file: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/sdk/bootstrap/mb4P_hudson.sh#n87 export PATCH_BUILD=java9patch46 [NOTE: we actually need to work on a "new set" that will be named "java9patch47" so we can build patches for both our 4.6 Update Releaeses and our 4.7 Milestones.] In some cases, this variable is just used to branch certain logic (such as which "Profile" to use on mvn command line. In other cases, it literally becomes part of the name of critical files, such as http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/streams/repositories_java9patch46.txt which defines the repositories and branches that are used to build the patch. [The "aggregator", BTW, all comes from 'master'].
As if that wasn't enough tricks already, we use another "trick" when creating the repository. p2 not longer published feature patches so that they will install (replace) on only one exact version of a feature. So we use some XSL transforms to add that the the content metadata. You can use a very tight range, if desired, which is what you would do if creating a patch for a product in production. But we often use a range for development, so that the Beta Java 9 patch requires some minimum version of install, such as "Neon Release" but will continue to be able to be applied as we produce M-builds for Neon. = = = = = = Hope these notes help. Feel free to report progress or ask questions here in this bug.
Where is the hudson job for the java9 patch build? Is it possible to look at this jobs console output?
Ok I have succeeded in adapting the java9 patch build system for my own case and the patch builds fine. (Not that I fully understand why though, especially these dummy projects are an unsolved mystery.. If I find time I'll try to see what happens if they are missing) What bothers a bit is that one needs to update the featureToPatchVersion in all these files by hand over time, but maybe it can easily be done "semi-automatically" with some git/patch magic, given that one has a reference commit/patch that I can just reapply after replacing the older with the newer version. I'll think a bit more about what could be generalized to make it easier to setup other patch builds in the future and come back if I have something.
(In reply to Felix Dorner from comment #4) > Ok I have succeeded in adapting the java9 patch build system for my own case > and the patch builds fine. (Not that I fully understand why though, > especially these dummy projects are an unsolved mystery.. If I find time > I'll try to see what happens if they are missing) The "dummy feature" exists to "substitute" during the build, for the feature that is being patched. If we do not use a dummy feature, then the "real" feature is pulled from the repository named in the profile (including all its included bundles, I believe) and all those "real" features and bundles "interfere" with the "new" ones we want to compile. So, having the dummy feature prevents Tycho from simply pulling the "already built" feature and bundles from the repo and instead will "build" this dummy feature. The "dummy bundle" exists because a feature must contain at least one bundle, or else Tycho will not build the feature at all (as I recall). Then during the "create repository" part of Tycho, the "dummy feature" and "dummy bundle" are not included (if I recall correctly) so they do not interfere when actually installing the patch feature. > What bothers a bit is that one needs to update the featureToPatchVersion in > all these files by hand over time, but maybe it can easily be done > "semi-automatically" with some git/patch magic, given that one has a > reference commit/patch that I can just reapply after replacing the older > with the newer version. And semi-automatic git patch might work. I tried to handle as much as I could via "variables", but there is only so much you can do. (Such as pom's (and I believe Manifests and feature.xml files) can not have the versions be a variable. Perhaps, in theory, some "artificial" IUs could be created with the right p2.inf files and perhaps that might help? But, with so many "maybes" and "mights" it was not worth the effort, to me. A global find and replace works fairly well. > I'll think a bit more about what could be generalized to make it easier to > setup other patch builds in the future and come back if I have something. Sounds good.
