Community
Participate
Working Groups
I am opening this bug to discuss if we *need* a (public) 4.5.2a build due to a regression introduced via bug 378811. The issue is in some ways "small" because it only affects those that want to use "e4" but without the SWT widgets. But, on the other hand, "huge" since it blocks those adopters completely and was a long promised design principle of e4. At first, I thought we did need a new build and repository because the issue originally reported in Tycho bug 488725 had to do with "the repository" -- and those that specify "noenv" (which I had never heard of before :). But, upon second reading, it seems that it was only related to using a composite repository for a build -- that a simple repository still worked (even though it had the wrong feature and dependencies). And, using a composite repository for "builds" is not a good practice anyway. Not to mention, if the composite is "broken" due to conflicting "filters" then there is no way to fix it by adding to it -- there will still be conflicting filters in the composite. So, if we do not do a 4.5.2a build, then how to deliver the fix for 378811? Will a "feature patch do"? Or do we do a "quite" 4.5.2a, since as far as I know this only affects one adopter: e(fx)clipse. Does anyone know of others that use "noenv"?
the noenv filter is a "trick" used by e(fx)clipse e4 application builds to get a predefined location where product assembly are written to (as there are post production steps eg to build an msi/dmg/pkg/deb/rpm-installer). As e4 on JavaFX applications don't contain ANY platform-specific bundles this noenv filter is not causing any problems. Why Mark in bug 488725 builds against the Mars.2 repo is out of control to me. e(x)clipse delivers a self-contained p2-repo (http://download.eclipse.org/efxclipse/runtime-nightly/site) people normally build against, at least we guide them to do it this way. So I think it is not necessary to respin everything but if e(fx)clipse could get access to a patched version of e4.ui.workbench, I could include that into our self-contained p2 repo and most.
(In reply to Thomas Schindl from comment #1) > the noenv filter is a "trick" used by e(fx)clipse e4 application builds to > get a predefined location where product assembly are written to (as there > are post production steps eg to build an msi/dmg/pkg/deb/rpm-installer). > > As e4 on JavaFX applications don't contain ANY platform-specific bundles > this noenv filter is not causing any problems. > > Why Mark in bug 488725 builds against the Mars.2 repo is out of control to > me. > > e(x)clipse delivers a self-contained p2-repo > (http://download.eclipse.org/efxclipse/runtime-nightly/site) people normally > build against, at least we guide them to do it this way. > > So I think it is not necessary to respin everything but if e(fx)clipse could > get access to a patched version of e4.ui.workbench, I could include that > into our self-contained p2 repo and most. Thanks, Thomas. This gives a lot of helpful information. I'll admit being confused about "e(fx)eclipse" and "JavaFX" mentioned in bug. So that's not "you" building against the composite. Given this "new" information, I do not think we need a 4.5.2a build. Now I think the question for the platform team is: If we provide this fix in a patch build, is that adequate for our long-term support of 4.5.2? I think it would be -- just wanted to confirm. I assume whatever the fix is, will also go into master?
(In reply to David Williams from comment #2) > (In reply to Thomas Schindl from comment #1) > > the noenv filter is a "trick" used by e(fx)clipse e4 application builds to > > get a predefined location where product assembly are written to (as there > > are post production steps eg to build an msi/dmg/pkg/deb/rpm-installer). > > > > As e4 on JavaFX applications don't contain ANY platform-specific bundles > > this noenv filter is not causing any problems. > > > > Why Mark in bug 488725 builds against the Mars.2 repo is out of control to > > me. > > > > e(x)clipse delivers a self-contained p2-repo > > (http://download.eclipse.org/efxclipse/runtime-nightly/site) people normally > > build against, at least we guide them to do it this way. > > > > So I think it is not necessary to respin everything but if e(fx)clipse could > > get access to a patched version of e4.ui.workbench, I could include that > > into our self-contained p2 repo and most. > > Thanks, Thomas. This gives a lot of helpful information. I'll admit being > confused about "e(fx)eclipse" and "JavaFX" mentioned in bug. So that's not > "you" building against the composite. > > Given this "new" information, I do not think we need a 4.5.2a build. +1. > Now I think the question for the platform team is: If we provide this fix in > a patch build, is that adequate for our long-term support of 4.5.2? I think > it would be -- just wanted to confirm. I assume whatever the fix is, will > also go into master? Yes, it will go into all streams where the problem got introduced.
Good that we don't need a 4.5.2a. I would suggest, though, we provide it as a "patched feature" just for long term clarity or hygiene. In my view, we would not make this an "automatic" update for users, but anyone who needed it, could go directly to the URL to get it. It just affects one bundle?
(In reply to David Williams from comment #4) > It just affects one bundle? The latest proposed fix in https://git.eclipse.org/r/#/c/67585/ touches two: - org.eclipse.e4.ui.workbench - org.eclipse.ui.workbench
(In reply to Dani Megert from comment #5) > (In reply to David Williams from comment #4) > > It just affects one bundle? > > The latest proposed fix in https://git.eclipse.org/r/#/c/67585/ touches two: > - org.eclipse.e4.ui.workbench > - org.eclipse.ui.workbench Ok, that's good. Same repository. But, hmmm, two features. org.eclipse.e4.rcp, to include patched org.eclipse.e4.ui.workbench, and org.eclipse.rcp, to include org.eclipse.ui.workbench AND the patched feature, I'd guess. I was thinking I could easily create a "patch build" for this case just like we do for the BETA_JAVA9 branch patches. But there, there is only one feature that is "patched". I'm sure I still could, but will be a little less easy. :) I would prefer that, though, that the "manually" created ones we create sometimes. (Assuming everyone agrees with me spending time on it). The strongest assumption, though, is that the fixes to the bundles are in the same branch of the repository. R4_5_maintenance would work ... if those are the only changes there. I *think* the committers would not have to do anything with "features". One it was just one feature, anyway, I could "fake it out" in small releng project.
(In reply to Dani Megert from comment #5) > - org.eclipse.e4.ui.workbench > - org.eclipse.ui.workbench The fixes to these two bundles have been pushed to master, R4_5_maintenance, and R4_4_maintenance. AFAIK, the e(fx)clipse use case only needs a patched org.eclipse.e4.ui.workbench JAR, but not the org.eclipse.ui.workbench. I.e. we can avoid creating and testing a feature patch, etc. LTS and other consumers can take the fixes directly from the maintenance branches.
(In reply to Markus Keller from comment #7) > (In reply to Dani Megert from comment #5) > > - org.eclipse.e4.ui.workbench > > - org.eclipse.ui.workbench > > The fixes to these two bundles have been pushed to master, R4_5_maintenance, > and R4_4_maintenance. > > AFAIK, the e(fx)clipse use case only needs a patched > org.eclipse.e4.ui.workbench JAR, but not the org.eclipse.ui.workbench. I.e. > we can avoid creating and testing a feature patch, etc. > > LTS and other consumers can take the fixes directly from the maintenance > branches. Suits me. Will they then build that one jar? Will someone build it from their workspace? Or, is a new "M-build" desired which we just "throw away" after getting that one jar from it? (And not even run unit tests on it?) Sorry to ask so many questions ... just wanted to be sure I know what's expected or needed from me.
(In reply to David Williams from comment #8) > Or, is a new "M-build" desired which we just "throw away" > after getting that one jar from it? Yes, that's what I would do, unless Tom or anyone else needs anything more.
(In reply to Markus Keller from comment #7) > (In reply to Dani Megert from comment #5) > > - org.eclipse.e4.ui.workbench > > - org.eclipse.ui.workbench > > The fixes to these two bundles have been pushed to master, R4_5_maintenance, > and R4_4_maintenance. > > AFAIK, the e(fx)clipse use case only needs a patched > org.eclipse.e4.ui.workbench JAR, but not the org.eclipse.ui.workbench. I.e. > we can avoid creating and testing a feature patch, etc. > Right all i need is a repo with the patched org.eclipse.e4.ui.workbench. > LTS and other consumers can take the fixes directly from the maintenance > branches.
Sorry to come back so late but has an M-Build so that I can consume the change from bug 378811?
(In reply to Thomas Schindl from comment #11) > Sorry to come back so late but has an M-Build so that I can consume the > change from bug 378811? No, sorry. I put it on the back burner, since didn't hear much, and now thick in M7. Will prioritize to get to it soon (say, within a week).
My plan is to change the .../streams/repositories.txt file, to use R4_5_2 tags for all repositories except for platform.eclipse.ui and there will attempt to use the R_4_5_maintenance branch. This will be a "one time" build, and will be left "invisible" in general, and only documented here where to "get the fix". Can anyone confirm that the R_4_5_maintenance branch of platform.eclipse.ui has the fix -- and only the fix required here?
Created attachment 261398 [details] changes in R4_5_maintenance since R4_5_2 Attached is a git diff R4_5_2..R4_5_maintenance There are two bundles changed. Once class in each. Plus increment in service field to both. Let me know if that is not correct for this need.
The "drop site" for this 4.5.2A build remains on the build machine, at http://build.eclipse.org/eclipse/builds/4M/siteDir/eclipse/downloads/drops4/M20160501-1430/ There is no "index" page to display things in a nice table. (I think due to other changes made in that sort of processing?) The unit tests were not ran on it. = = = = = = = = = Similarly, the p2 repository for the site is on the build machine only: http://build.eclipse.org/eclipse/builds/4M/siteDir/updates/4.5-M-builds/M20160501-1430/ = = = = = = = = = Let us know either way if things are ok or if any problems with it. Thanks,
