Bugzilla – Full Text Bug Listing
| Summary: | [Tips] Tip deploy job | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Wim Jongman <wim.jongman> |
| Component: | User Assistance | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, Lars.Vogel, mistria |
| Version: | 4.7.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/122490 https://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=17355c81a7dc85dd97206a735c95180fe94b38f0 |
||
| Whiteboard: | |||
| Bug Depends on: | 534158 | ||
| Bug Blocks: | 531784, 534073 | ||
|
Description
Wim Jongman
What do you need to change in the deploy job? I need access to the downloads directory. e.g. this works in the e4 builds: rm -rf /home/data/httpd/download.eclipse.org/e4/tips/* cp -r tips/* /home/data/httpd/download.eclipse.org/e4/tips/ But this does not work my platform build (I have created the tips directory manually): rm -rf /home/data/httpd/download.eclipse.org/eclipse/tips/* cp -r tips/* /home/data/httpd/download.eclipse.org/eclipse/tips/ + whoami genie.platform + rm -rf '/home/data/httpd/download.eclipse.org/eclipse/tips/*' + cp -r tips/index.json tips/org.eclipse.jdt.ui tips/org.eclipse.pde.ui tips/org.eclipse.ui.ide.application tips/photon /home/data/httpd/download.eclipse.org/eclipse/tips/ cp: cannot create regular file ‘/home/data/httpd/download.eclipse.org/eclipse/tips/index.json’: Permission denied cp: cannot create directory ‘/home/data/httpd/download.eclipse.org/eclipse/tips/org.eclipse.jdt.ui’: Permission denied cp: cannot create directory ‘/home/data/httpd/download.eclipse.org/eclipse/tips/org.eclipse.pde.ui’: Permission denied cp: cannot create directory ‘/home/data/httpd/download.eclipse.org/eclipse/tips/org.eclipse.ui.ide.application’: Permission denied cp: cannot create directory ‘/home/data/httpd/download.eclipse.org/eclipse/tips/photon’: Permission denied Would it be a blocker if we don't deploy tips as part of 1st release and just stick to included tips at the moment (and don't use updates so far?). As Platform will release every 6 weeks now, it wouldn't be a too big issue IMO, and I believe allowing us more time to think about how we publish tips could make them better integrated and more successful, even if in the end, the result might be the same ;) To be honest, I'm not thrilled about the idea of having a separate job to deploy tips. > To be honest, I'm not thrilled about the idea of having a separate job to deploy tips.
I think you might misunderstand what the deploy does. I sent you an email suggesting to have a conference so that I can explain the implementation.
(In reply to Wim Jongman from comment #4) > I think you might misunderstand what the deploy does. I sent you an email > suggesting to have a conference so that I can explain the implementation. Please explain it publicly on this tracker as it can be of interest for more people than just me;) My interpretation is that the deploy job does deploy some tips files remotely, which is ok. But what I'm afraid of is about creating a new folder structure, a new build schedule and so on for tips, while I'm convinced that tips are just like Platform documentation and should be deployed at the same time as Platform documentation and as part of the same Platform build. I'd rather avoid having a dedicated job for tips as much as possible, because I'm not convinced about the value yet, while I'm convinced that this is additional work, and additional risk of keeping things out of sync by scattering the effort across different repos/jobs. I think I slowly catch up to what you mean. Yes, deploying every 6 weeks looks fine to me. Yes, it is like Platform documentation but much more fluid: someone convinced me to build the Tips for dynamic / streaming content [1] ;) Please let me know how you want it. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=307889#c23 (In reply to Wim Jongman from comment #6) > Please let me know how you want it. One way I imagine it would be something like, in org.eclipse.jdt.doc.user/plugin.xml <extension id="org.eclipse.ua.tipsProvider"> <provider id="org.eclipse.jdt.doc.user.tips" image="jdt-logo.png" description="Java Development Tips" class="org.eclipse.tips.json.JsonTipProvider"> <properties> <initialTipsPath>jdt-tips.json</initialTipsPath> <initialTipsVersion>1.0</initialTipsVersion> <!-- not sure we need real versioning here, or whether just reusing bundle version in some way could suffice> <updateUrl>http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.3a-201803300640/tips/jdt-tips.json</updateUrl> <properties> </provider> </providers> </extension> And the jdt-tips.json would contain the list of tip. That would allow to remove some responsibilities from providers (such as require-bundle, expression...) which are quite hard to handle and for which we already have OSGi and plugin.xml doing it well. Note that if it's an issue for online doc, having it in a different plugin org.eclipse.jdt.tips.user would be fine too IMO. For example, someone willing to enable a full twitter query for Tip could similarly use <extension id="org.eclipse.ua.tipsProvider"> <provider id="my.project.twitter.tips" image="my-project-logo.png" description="My project" class="org.eclipse.tips.json.TwitterTipProvider"> <properties> <twitterQuery>from:EclipseJavaIDE #eclipsetips</twitterQuery> <properties> </provider> </providers> </extension> If it's too hard to specify properties in the extension, then a solution which extends and specializes the provider class and hardcode some values for properties is IMO fine too. (In reply to Mickael Istria from comment #7) > > If it's too hard to specify properties in the extension, then a solution > which extends and specializes the provider class and hardcode some values > for properties is IMO fine too. You suggest that I make an extension point? (In reply to Wim Jongman from comment #8) > You suggest that I make an extension point? Yes, I think for contributing tips inside the IDE, an extension point would be best from contributor POV. Other approaches such as the one fully relying on providers.json files actually introduce a new process for extenders who typically contribute to the IDE looking for extension points in their plugin.xml editor. I'm afraid not so many people would be aware of another specific contribution process and then miss to contribute to tips. Yes an extension point like you describe is already fully implemented [1]. All my examples run through extension points [2]. Fetching tips dynamically is an implementation detail of the provider. [1] https://git.eclipse.org/c/platform/eclipse.platform.ua.git/tree/org.eclipse.tips.core/schema [2] https://git.eclipse.org/c/platform/eclipse.platform.ua.git/tree/org.eclipse.tips.examples/plugin.xml Ok, cool! So do you intend to add such extensions in existing doc.user bundles for the tips you've merged in the repo already? Platform Tip providers are already part of the IDE bundle. I have followed a dynamic schema where we can add/remove providers dynamically. Currently there are 4. We might ship with only 2: JDT Tips (taken from the twitter stream) and Photon new and Noteworthy. We can add workbench and PDE tips as soon as they are ready. (In reply to Wim Jongman from comment #12) > Platform Tip providers are already part of the IDE bundle. Ok, so I think they would better be in the eclipse.platform.common/*.doc.user bundles. @Dani @Lars: what do you think? > I have followed a > dynamic schema where we can add/remove providers dynamically. It's I believe the main thing I'm concerned about. This ability to add providers dynamically from a .json file adds IMO a lot of extra complexity for something that will be not so necessary as Platform will have a faster release cadence after Photon. I would rather see the providers be a list of tips in a JSon file, not having too much metadata like "version" or "require-bundle". Is this way to use json files to declare providers is publix or internal? If it's public (API-like), I would suggest we remove it from API at the moment and make it internal (and even maybe avoid to use it) to not add extra-maintenance effort. > We can add workbench and PDE tips as soon as they are ready. And how will those be added? Three options IMO 1. Totally dynamic like it is currently implemented. Providers can be added dynamically. The list of tips can be dynamic. Maintenance effort: ** update index.json[1] if the list of tips changes ** maintaining the list of tips in provider.json ** publishing the index and the list on downloads.eclipse.org ** publishing the content on downloads.eclipse.org (e.g. html files, images, videos/gifs) 2. Static but content on downloads.eclipse.org The list of tips cannot change dynamically. New tips will only appear if the user upgrades the ide Maintenance effort: ** No index.json but maintenance will be spread over different bundles (e.g. jdt/pde/platform/newandnoteworthy) ** maintaining the list of tips in provider.json for each bundle (sort of the same effort but spread out over different locations) ** publishing the content of the tips on downloads.eclipse.org (same effort) 3. All content is shipped with the IDE The list of tips cannot change dynamically. New tips will only appear if the user upgrades the ide ** No index.json but maintenance will be spread over different bundles (e.g. jdt/pde/platform/newandnoteworthy) ** maintaining the list of tips in provider.json for each bundle (sort of the same effort but spread out over different locations) ** Shipping content (html/movies/gifs) with the IDE > Platform Tip providers are already part of the IDE bundle.
I mean org.eclipse.tips.ide
(In reply to comment #13) > Ok, so I think they would better be in the eclipse.platform.common/*.doc.user To make these providers use the extension point then these bundles need to have a dependency on org.eclipse.tips* is that what you want? (In reply to Wim Jongman from comment #16) > To make these providers use the extension point then these bundles need to > have a dependency on org.eclipse.tips* is that what you want? I don't think that having the dependency is mandatory at runtime. I suggest that we just add the extension in plugin.xml without adding the dependency on org.eclipse.tips (which I guess we don't want to force into in the web help system at the moment). So if tips framework is installed, things get loaded, if not, they get ignored. These bundles are not java projects. Should they be converted to java projects? (In reply to Wim Jongman from comment #18) > These bundles are not java projects. Should they be converted to java > projects? Nope. But if you happen to really need them to be converted, it could be a sign that it'd be better to create new bundles just for tips. But if we can avoid creating new bundles, that'd be great. (In reply to Mickael Istria from comment #19) > (In reply to Wim Jongman from comment #18) > > These bundles are not java projects. Should they be converted to java > > projects? > > Nope. > But if you happen to really need them to be converted, it could be a sign > that it'd be better to create new bundles just for tips. But if we can avoid > creating new bundles, that'd be great. I think we can then better leave it where it is (in org.eclipse.tips.ide). Why put in the extra cycles and maintenance work right? Can you give your ideas on Comment 14? (In reply to Wim Jongman from comment #20) > I think we can then better leave it where it is (in org.eclipse.tips.ide). In which repo is this? In eclipse.platform.ua? eclipse.platform.ua is supposed to only contain the framework and not the help or assistance content at all, which should go into dedicated bundles or -better- in eclipse.platform.common > Why put in the extra cycles and maintenance work right? The tips content shouldn't have been in eclipse.platorm.ua on first place. This is now a bug as it's a layer breaker compared to how Platform repos are structured, and a bug important enough to be a blocker for further progress. I'm sorry that wasn't caught earlier to prevent from asking this to move right now. > Can you give your ideas on Comment 14? I think I'd like something like 2.5 ;) In the IDE, we declare extensions that references a "light" .json files containing a few good tips for people who don't have internet access, and a download.eclipse.org URL where to get an updated version of the tips. The .json would only contain the list of tips (not even need to have logo, title and so on in the .json as those one are fine being updated statically I think). (In reply to comment #21) > I think I'd like something like 2.5 ;) Ok. How about this plan: 1. Create one new tips bundle in UA containing our 4 providers (jdt/pde/workbench/newandnoteworthy) 2. Provider will only be loaded if installed. 3. Without internet we use the local tips from *.doc.user/tips/tipoftheday/provider.json 4. With internet we check for changes in the file. If changed, download (with mirror awareness) 5. Show tips Content will go to: org.eclipse.jdt.doc.user/tips/tipoftheday org.eclipse.pde.doc.user/tips/tipoftheday org.eclipse.platform.doc.user/tips/tipoftheday org.eclipse.platform.doc.user/tips/tipoftheday/whatsnew Now where does this content go? Somewhere on help.eclipse.org. is it mirrored? (In reply to Wim Jongman from comment #22) > 1. Create one new tips bundle in UA containing our 4 providers > (jdt/pde/workbench/newandnoteworthy) The providers should either be in the repo their content is related to, or in the eclipse.platform.common repo with the doc.user. The doc.user bundles are included in related features and part of the EPP package already, so they're available from inside the IDE. > 3. Without internet we use the local tips from > *.doc.user/tips/tipoftheday/provider.json > 4. With internet we check for changes in the file. If changed, download > (with mirror awareness) > 5. Show tips All that seems good. > Now where does this content go? Somewhere on help.eclipse.org. is it > mirrored? I don't think it would be accessible immediately from help.eclipse.org. We'd still need either to change the help.eclipse.org to serve those tips files, but since help is redeployed only for releases, that wouldn't be any better than changing content inside bundle; or we'd still need an additional deploy step to have it somewhere under download.eclipse.org/eclipse . Let's first have tips framework installable into the IDE (published in the p2 repo and the doc moved to the right place before deciding of a target location. (In reply to Wim Jongman from comment #22) > 1. Create one new tips bundle in UA containing our 4 providers > (jdt/pde/workbench/newandnoteworthy) -2. This is a layer breaker. UA must not have *anything* for JDT or PDE. (In reply to comment #24) > (In reply to Wim Jongman from comment #22) > > 1. Create one new tips bundle in UA containing our 4 providers > > (jdt/pde/workbench/newandnoteworthy) > > -2. This is a layer breaker. UA must not have *anything* for JDT or PDE. With UA I mean the repository. It will all be in org.eclipse.tips.* There will be no dependency, only a hardcoded bundle check. Is this Ok? Alternatively jdt and pde would have to create separate tips bundles? (In reply to Wim Jongman from comment #25) > With UA I mean the repository. It will all be in org.eclipse.tips.* The UA repository must contain help frameworks only. No content at all related to PDE or JDT. If you see other occurences of such JDT/PDE specific content in the .ua repo, please open a bug. > There will be no dependency, only a hardcoded bundle check. Why would you need to hardcode a bundle check? I believe we should avoid this. > Alternatively jdt and pde would have to create separate tips bundles? Alternatively, tips about platform could be in some new bundles eclipse.platform.common/org.eclipse.platform.tips.user , those about JDT in eclipse.platform.common/org.eclipse.jdt.tips.user and so on. This would allow to add the right dependency in MANIFEST.MF and remove need to hardcode any bundle check. Ok sounds good. Should the content also be there or leave it where it is now? (In reply to Wim Jongman from comment #27) > Ok sounds good. Should the content also be there or leave it where it is now? As mentioned on the other bug, I believe the content should move in the newer bundles. Does it sound better to you too? (In reply to comment #28) > bundles. Does it sound better to you too? Yes. As the deadline for M7 approaches and feature freeze too, and I'm not sure we'll be able to find a fully working solution to this issue before M7, I'd like us to consider how critical it would be if dynamic deployment of new tips cannot be made for Photon, or at least not in Platform itself? If we go for such extensions in Platform and don't yet have a decision on what's the best approach to deploy them, I think it'd be better to remove everything related to deployment/update of Platform tips in a 1st step and to give it another thought when we are more ready for it (ie when tips start to be visible in EPP). As the Platform release cycle is going to be much faster, it means that once we have a solution for this, it would be a matter of weeks before it gets into mainstream IDEs, not a year. (In reply to Mickael Istria from comment #30) > As the deadline for M7 approaches and feature freeze too, and I'm not sure > we'll be able to find a fully working solution to this issue before M7, I'd > like us to consider how critical it would be if dynamic deployment of new > tips cannot be made for Photon, or at least not in Platform itself? > If we go for such extensions in Platform and don't yet have a decision on > what's the best approach to deploy them, I think it'd be better to remove > everything related to deployment/update of Platform tips in a 1st step and > to give it another thought when we are more ready for it (ie when tips start > to be visible in EPP). > As the Platform release cycle is going to be much faster, it means that once > we have a solution for this, it would be a matter of weeks before it gets > into mainstream IDEs, not a year. +1! (In reply to Mickael Istria from comment #30) > As the deadline for M7 approaches and feature freeze too, I am ready for it. The only thing we need to do is find a place where to store the tip content on download.eclipse.org. Uploading can be a one-time manual process. There is no need for having an automatic deployment job at this moment. (In reply to comment #32) > (In reply to Mickael Istria from comment #30) > > As the deadline for M7 approaches and feature freeze too, > > I am ready for it. The only thing we need to do is find a place where to store > the tip content on download.eclipse.org. > > Uploading can be a one-time manual process. There is no need for having an > automatic deployment job at this moment. Any feedback on this? Maybe I misunderstand comment #30 (In reply to Wim Jongman from comment #32) > I am ready for it. The only thing we need to do is find a place where to > store the tip content on download.eclipse.org. Do we need it right now? Can't we, for Photon, just ship static content and then -when we're less busy and more relaxed in term of deadlines- consider support for updates and deployment of tips? > Uploading can be a one-time manual process. There is no need for having an > automatic deployment job at this moment. Ok, cool. New Gerrit change created: https://git.eclipse.org/r/122490 Gerrit change https://git.eclipse.org/r/122490 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=17355c81a7dc85dd97206a735c95180fe94b38f0 |