Bugzilla – Full Text Bug Listing
| Summary: | Need names for E4 contributions | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Dave Orme <djo> |
| Component: | E4 | Assignee: | Project Inbox <e4.runtime-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, danrubel, emoffatt, gheorghe, jeffmcaffer, john.arthorne, Mike_Wilson, ob1.eclipse, pascal, pwebster, steffen.pingel, susan, tom.schindl |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Dave Orme
Per our call, I'd like to invite anyone who was present to comment/suggest/criticize/:) Thanks (In reply to comment #0) > > - org.eclipse.e4.metaconfig > > (Yes, I know we hate the word meta; please consider this a challenge to come up > with a better name. :P ) > It's not great, but I'd prefer just "o.e.e4.config" to "metaconfig". Or if we liked acronyms, maybe "o.e.e4.cds" for "Configuration Data Service". If the installer is the only thing using the service, I might even go for "o.e.e4.installer.config". I see these as a set of mostly independent bundles rather than a closely integrated component. I suggest our usual bundle naming of org.eclipse.e4.[core|ui].something. Along those lines I suggest org.eclipse.e4.core.config org.eclipse.e4.core.installer org.eclipse.e4.core.deeplink org.eclipse.e4.ui.deeplink Actually from quickly looking at the "config" piece, it looks like it is really just one class to support loading a properties file from a location with variable substitution. Ideally this would end up as part of another bundle, such as org.eclipse.e4.core.services bundle. But you still need a bundle name in the shorter term so something like org.eclipse.e4.core.config is probably fine. (In reply to comment #3) > I see these as a set of mostly independent bundles rather than a closely > integrated component. I suggest our usual bundle naming of > org.eclipse.e4.[core|ui].something. Along those lines I suggest > > org.eclipse.e4.core.config > org.eclipse.e4.core.installer > org.eclipse.e4.core.deeplink > org.eclipse.e4.ui.deeplink Not to open a can of worms here, and perhaps this belongs in another bug or discussion, but... I worry about naming this "installer" e4, and more generally, associating it with e4. Is this simply to expedite the contribution into some incubator so we can look at it? It gives the impression that there is something special about configuration and install for e4. And as I understand it, it's based on update manager. We don't want people to think update manager is somehow recommended for use with e4, since we are actively trying to reduce dependencies on it and remove it from the SDK. Should this be something for the p2 incubator to evaluate and position relative to the p2 SDK UI, the Mylyn Discovery UI, the Eclipse Marketplace UI, etc... I notice that some of this contribution goes against update manager, and I should point that we are likely to not ship update in e4 (see bug #313792) I agree we have no long term interest in install technology that only runs on Update Manager. We are actively phasing out UM and it should be completely gone in a couple of years (bug 311590). My understanding was that the install would be ported to run on p2 API. So, e4 is really being used as a place to accept the contribution, evolve it into something useful to us, and then possibly graduate in the future (probably to p2). I agree the equinox/p2 incubator is just as good a place for this if Dave and Pascal are interested in doing that. Hi Susan: thanks for your comments. To clarify: (In reply to comment #4) > I worry about naming this "installer" e4, and more generally, associating it > with e4. Is this simply to expedite the contribution into some incubator so we > can look at it? 0) Yes, but there's more too... 1) There's also a practical consideration that the team has limited bandwidth and if we can consolidate our communications channels then we can support everything more efficiently. 2) And there's also:... > It gives the impression that there is something special about configuration and > install for e4. And as I understand it, it's based on update manager. We > don't want people to think update manager is somehow recommended for use with > e4, since we are actively trying to reduce dependencies on it and remove it > from the SDK. The intention is for the API to be abstract enough that it could be (and I'll add--is intended to be) re-implemented on top of P2. This was done on purpose so that downstream could migrate from legacy update manager to P2 with minimal (preferably zero) code changes. > Should this be something for the p2 incubator to evaluate and position relative > to the p2 SDK UI, the Mylyn Discovery UI, the Eclipse Marketplace UI, etc... Possibly. (In reply to comment #3) > I see these as a set of mostly independent bundles rather than a closely > integrated component. I suggest our usual bundle naming of > org.eclipse.e4.[core|ui].something. Along those lines I suggest > > org.eclipse.e4.core.config > org.eclipse.e4.core.installer > org.eclipse.e4.core.deeplink > org.eclipse.e4.ui.deeplink This looks good to me and I'll +1 it. > Actually from quickly looking at the "config" piece, it looks like it is really > just one class to support loading a properties file from a location with > variable substitution. Ideally this would end up as part of another bundle, > such as org.eclipse.e4.core.services bundle. But you still need a bundle name > in the shorter term so something like org.eclipse.e4.core.config is probably > fine. That's nearly 100% correct. To finish the story: There's actually two config files. One lives in the install root (next to eclipse.exe) and just points at the other one via a URL. That URL can be constructed using substitution variables if you like. This is so that the real configuration can live next to the .exe, can live on a network drive, live on an HTTP server, etc... Basically it's all to support the theme of central management. > I agree the equinox/p2 incubator is just as good a place for this if Dave and Pascal are interested in doing that.
I'm all for having the contribution be hosted in the p2 incubator.
(In reply to comment #9) > > I agree the equinox/p2 incubator is just as good a place for this if Dave and Pascal are interested in doing that. > I'm all for having the contribution be hosted in the p2 incubator. I'm okay with that if it's what the community really prefers. In that case, what would you like to name the installer and config bundles? (On the E4 call yesterday I explained that as downstream uses this code in production, I need to get to API-quality names ASAP.) Thanks in advance. (In reply to comment #9) > > I agree the equinox/p2 incubator is just as good a place for this if Dave and Pascal are interested in doing that. > I'm all for having the contribution be hosted in the p2 incubator. I've talked this over with my team. We would like to move to p2 but currently only have legal permission to contribute to E4 (don't ask; it's legals... ;) So we currently would like to plan to migrate to P2 as soon as we can, to use a P2 namespace (so we don't have to change namespaces twice), but to incubate within the E4 project until we get sign-off to migrate. 1) Here's another straw-man for names. Thoughs/suggestions welcomed. org.eclipse.p2.headless.api org.eclipse.p2.headless.config org.eclipse.e4.core.deeplink org.eclpse.e4.ui.deeplink 2) Ideally, we would find a way to inject the Properties object into the p2.headless.api bundle so we could lose the dependency on that entirely. Thoughts/ideas welcome. (In reply to comment #11) > I've talked this over with my team. We would like to move to p2 but currently > only have legal permission to contribute to E4 (don't ask; it's legals... ;) So shall I take silence as consensus that people are OK if we incubate our P2 work inside E4? :) > org.eclipse.p2.headless.api > org.eclipse.p2.headless.config > org.eclipse.e4.core.deeplink > org.eclpse.e4.ui.deeplink Pascal, any thoughts/suggestions on the P2 namespace names? Thanks in advance. > > I've talked this over with my team. We would like to move to p2 but currently > > only have legal permission to contribute to E4 (don't ask; it's legals... ;) > > So shall I take silence as consensus that people are OK if we incubate our P2 > work inside E4? :) I would prefer if it was in the p2 incubator, just for ease of consumption > > org.eclipse.p2.headless.api > > org.eclipse.p2.headless.config > > org.eclipse.e4.core.deeplink > > org.eclpse.e4.ui.deeplink > > Pascal, any thoughts/suggestions on the P2 namespace names? If it is to eventually be hosted under p2 it would have to be in org.eclipse.equinox.p2 prefix. As for the rest, let's first see what it does before deciding on the naming. Personally, I'd be fine with the installer contribution to go into e4 for now if this makes it possible to contribute earlier. But I guess we should ask for guidance on this from the PMC. CC'ing Jeff for Equinox PMC - John and McQ from the Eclipse PMC are already on the cc list. Playing catch up on this thread... My thoughts - While not all provisioning related work at Eclipse has to be at p2, this effort seems relatively independent of e4 and should be part of p2 - I'm fine with the work actually being in the e4 repo for now but in the p2 namespace. There should be a clear timeline for moving for real - For naming o.e.equinox.p2.??? I don't know enough about the particular uniqueness of the function to replace the ???. Superficially "headless" does not fit. The majority of p2 is headless. What is the functional distinction in this function? That should drive the rest of the name. - UM integration is ok but IMHO we have to be emphatic that e4 does NOT have org.eclipse.update.* in it. (In reply to comment #15) > Playing catch up on this thread... My thoughts > > - While not all provisioning related work at Eclipse has to be at p2, this > effort seems relatively independent of e4 and should be part of p2 > > - I'm fine with the work actually being in the e4 repo for now but in the p2 > namespace. There should be a clear timeline for moving for real Agreed. > - For naming o.e.equinox.p2.??? I don't know enough about the particular > uniqueness of the function to replace the ???. Superficially "headless" does > not fit. The majority of p2 is headless. What is the functional distinction > in this function? That should drive the rest of the name. I just spent a bunch of time surfing the p2 repo, trying to distinguish what we've done from what's there. Unfortunately, I wasn't able to make enough sense of the names in the P2 repo from a cursory browsing of the code to generate any good names. Perhaps it would be easier/simpler for me to describe how our API works (since it's really simple) and see if that helps place where this might fit inside P2? Main use-case we solve: The main point is to handle the common case where an RCP application needs to keep itself up to date without any interaction from the user. The most complicated API we have is: public boolean update(URL[] updateSiteURLs, File downloadRootDir, Set<FeatureVersionedIdentifier> featuresRequested) throws InstallError updateSiteURLs is pretty self explanatory. FeatureVersionedIdentifier is an abstraction on top of IFeatureReference for portability to P2. featuresRequested is the set of features the current user is provisioned to be able to access. An application is responsible for computing this set using whatever mechanism makes sense. downloadRootDir is the root directory under which the installer will create its installation sites / P2 repos where it keeps the current configuration. There are convenience versions of this API that supply default values--all the way down to a simple #update() api that gets its data from a Java properties file using the configuration bundle. And that's (almost) all... If you look at our code, you'll also notice a BundleUpdaterHelper class. Its API is the same as above, but it also automatically constructs an IProgressMonitor and passes that along in the right way so that the user gets progress reports in the UI. > - UM integration is ok but IMHO we have to be emphatic that e4 does NOT have > org.eclipse.update.* in it. No problem. We're looking forward to moving to p2. :) Pascal, would it be easiest to sort this out on the phone/Skype and report results here? If so, please email me your phone number at djo <at> coconut-palm-software.com as well as when we could talk. (In reply to comment #17) > Pascal, would it be easiest to sort this out on the phone/Skype and report > results here? If so, please email me your phone number at djo <at> > coconut-palm-software.com as well as when we could talk. Pascal and I spoke yesterday. Here was the outcome (Pascal; feel free to add/amend if you think I got any of this wrong): 1) We don't want to ship a new module in Eclipse based on update manager code because that sends the wrong message and because we don't want to encourage any more update manager adoption. 2) There seems like there might be some significant overlap between the work we have done and the new P2 operations API. 3) As a consequence of 1 and 2, we agreed--rather than contribute our installer code outright--to work to merge our APIs into the new P2 operations API. 4) So for the near term, we will put our code through the IP process so that it is under the EPL and we can all legally talk about it. But we will work with the P2 team to integrate/merge with their work and make sure we provide a unified install/upgrade story to the Eclipse community. So with the previous background, I'll move forward with the CQ using the names we've proposed and the following understanding:
Unless anyone yells now :), the deep linking namespaces will be based around:
> org.eclipse.e4.core.deeplink
> org.eclpse.e4.ui.deeplink
I'll contribute the installer code using the existing namespace, but with the understanding that this will almost certainly change going forward.
(In reply to comment #19) > I'll contribute the installer code using the existing namespace, but with the > understanding that this will almost certainly change going forward. So as part of this you'll add all the copyright notices? I think that was the CQ outstanding issue - http://www.eclipse.org/legal/copyrightandlicensenotice.php PW (In reply to comment #20) > (In reply to comment #19) > > I'll contribute the installer code using the existing namespace, but with the > > understanding that this will almost certainly change going forward. > > So as part of this you'll add all the copyright notices? I think that was the > CQ outstanding issue - > http://www.eclipse.org/legal/copyrightandlicensenotice.php Yep; working on that right now. Thanks for the reminder. :) (In reply to comment #20) > So as part of this you'll add all the copyright notices? I think that was the > CQ outstanding issue - > http://www.eclipse.org/legal/copyrightandlicensenotice.php When I look through Eclipse sources, I only see the copyright notices on .java files; not on MANIFEST.MF or plugin.xml. Are there any files other than .java files that need the copyright headers? (In reply to comment #22) > > When I look through Eclipse sources, I only see the copyright notices on .java > files; not on MANIFEST.MF or plugin.xml. Are there any files other than .java > files that need the copyright headers? According to the eclipse legal doc [1], it is primarily source code that needs copyright headers: .java, .c, etc. Also documentation (.html, etc) should have a copyright header. Files like the MANIFEST.MF don't really contain interesting intellectual property so it is not needed. [1] http://eclipse.org/legal/guidetolegaldoc.php (section 4.4) Closing/fixed. |