Community
Participate
Working Groups
Build for proposed change is failing because Maven can't find EMF 2.8. Please see: https://hudson.eclipse.org/sandbox/job/mylyn-reviews-gerrit/463/console Steffen, any ideas what we need to change to bring this version in? We've confirmed that 2.8 can be used w/ 3.8 dependency. Perhaps an upstream build is committing Maven to 2.5?
You would have to add the specific EMF site to the list of repositories to fix the trigger build or switch to an explicit target that brings in the required version. As you point out the release build targets would also need to get changed. Since this requires effort and will make it significantly more difficult for users to install Mylyn unless we re-distribute EMF I am wondering if this is worth the benefit that 2.8 provides. Can you summarize why we need it (or point me to the bug that discusses that)?
(In reply to comment #1) > You would have to add the specific EMF site to the list of repositories to fix > the trigger build or switch to an explicit target that brings in the required > version. As you point out the release build targets would also need to get > changed. Since this requires effort and will make it significantly more > difficult for users to install Mylyn unless we re-distribute EMF I am wondering > if this is worth the benefit that 2.8 provides. Well, the Kepler and Juno sites will provide 2.8.0 so there shouldn't be any impact on users >= 3.7. Does Maven actually force an explicit update for all the built features, not just the ones that actually request that version? (!) > Can you summarize why we need it (or point me to the bug that discusses that)? Sure, bug 40006 comment 6. (We'd also discussed this earlier informally as part of decision making for 3.7, but decided we didn't need to bump to 3.7 because we could use 2.8 w/ 3.5+.) See https://git.eclipse.org/r/#/c/12229/5/org.eclipse.mylyn.reviews.edit/src/org/eclipse/mylyn/reviews/spi/edit/remote/AbstractRemoteEditFactoryProvider.java L 83 for key usage. This was actually quite involved to work out and would impact delivery if we needed to revisit.
(In reply to comment #2) > Well, the Kepler and Juno sites will provide 2.8.0 so there shouldn't be any > impact on users >= 3.7. Yes, but we still have a bunch of users on 3.7 and integrators who ship based on 3.7. > Does Maven actually force an explicit update for all the > built features, not just the ones that actually request that version? (!) No, but the target won't resolve if we add multiple EMF versions. We could split targets but again that increases maintenance further. > > Can you summarize why we need it (or point me to the bug that discusses that)? > > Sure, bug 40006 comment 6. Did the bug ID get mangled? > (We'd also discussed this earlier informally as part > of decision making for 3.7, but decided we didn't need to bump to 3.7 because we > could use 2.8 w/ 3.5+.) Yes, but we didn't commit to EMF 2.8 just yet. > See > https://git.eclipse.org/r/#/c/12229/5/org.eclipse.mylyn.reviews.edit/src/org/eclipse/mylyn/reviews/spi/edit/remote/AbstractRemoteEditFactoryProvider.java > L 83 for key usage. This was actually quite involved to work out and would > impact delivery if we needed to revisit. Can you summarize why that code needs EMF 2.8?
(In reply to comment #3) > > Does Maven actually force an explicit update for all the > > built features, not just the ones that actually request that version? (!) > > No, but the target won't resolve if we add multiple EMF versions. We could split > targets but again that increases maintenance further. What I guess I'm asking is does Maven require all users to use the same target dependencies as the build?! Seems awfully weak if so -- just because the build consumes 2.8 for some of the dependencies, that shouldn't require all features that end up being built from that build to use those dependencies. > Did the bug ID get mangled? Yep, missing a 0 bug 400006 comment 6 Also See bug 394020 comment 1. > > (We'd also discussed this earlier informally as part > > of decision making for 3.7, but decided we didn't need to bump to 3.7 because > we > > could use 2.8 w/ 3.5+.) > > Yes, but we didn't commit to EMF 2.8 just yet. > > > See > > > https://git.eclipse.org/r/#/c/12229/5/org.eclipse.mylyn.reviews.edit/src/org/eclipse/mylyn/reviews/spi/edit/remote/AbstractRemoteEditFactoryProvider.java > > L 83 for key usage. This was actually quite involved to work out and would > > impact delivery if we needed to revisit. > > Can you summarize why that code needs EMF 2.8? > Can you summarize why that code needs EMF 2.8? See bug 394020. But essentially, because the API for Resource Locators didn't exist prior to that. There wasn't any way to override the resource location for a ResourceSet and we need to do that to provide good support for the data implementation. (Stuff like bug 394020 comment 10).(In reply to comment #3)
So, if I understand correctly we have one big model that we are persisting across several files? Can you estimate roughly how difficult it would be to do the same with EMF 2.5? I'm not even quite understanding why we use one big model instead of one model per review. (In reply to comment #4) > (In reply to comment #3) > > > > Does Maven actually force an explicit update for all the > > > built features, not just the ones that actually request that version? (!) > > > > No, but the target won't resolve if we add multiple EMF versions. We could > split > > targets but again that increases maintenance further. > > What I guess I'm asking is does Maven require all users to use the same target > dependencies as the build?! Seems awfully weak if so -- just because the build > consumes 2.8 for some of the dependencies, that shouldn't require all features > that end up being built from that build to use those dependencies. No it doesn't but if we want to publish to site the content has to resolve. The same applies to the integration tests that run all tests combined in one module.
(In reply to comment #5) > So, if I understand correctly we have one big model that we are persisting > across several files? Can you estimate roughly how difficult it would be to do > the same with EMF 2.5? I'm not even quite understanding why we use one big model > instead of one model per review. Well, there is a shared repository, which contains the users, metadata about the repos itself, etc.. and then one file per Review. The repos model "contains" the reviews, but only the open ones. But you're right in that we don't have any cross references, which greatly simplifes things. I was hoping for a more general solution, but.. Anyway, while it's not ideal, looks like I can get it working for w/o the 2.8 dependencies, so as this sounds like a much bigger deal than I'd hoped I guess we can drop it.
Thanks, that's great to hear.
In light of clear improvements seen in bug 409427 comment 25, as well as other gains from tracking latest EMF, I'd like to reopen consideration for version 2.9. This is *not* something we need to tackle right away, just something to think about (perhaps for Mylyn Luna release?)
We are still targeting Eclipse 3.6 and the corresponding EMF 2.6 version as a baseline. I'm not convinced that the benefits justify the potential for install conflicts for users running distributions based on older Eclipse versions (e.g. RTC). In essence, we don't have plans to do this in the the short term. I'll mark this bug as closed and we can reopen once we move up to Eclipse 4.x.
Note that EMF 2.9 is built with and tested with Eclipse 3.6.
