Community
Participate
Working Groups
I'm creating an RCP (Rich Client Platform) application. I want to be able to view the error log view (for serviceability and while debugging). However I notice the error log's id is in the pde.runtime package. I do not wish to include the PDE in my runtime. Can the error log be moved to the platform level?
Jim, the log view and the registry view are the only two things that are contained in the pde.runtime plug-in. They are part of PDE because we are the ones who implemented them, but they are not necessarily PDE-specific. Should they be moved down to the platform?
Wassim: Do these views really depend on org.eclipse.update.ui.forms? Nick: Would it be reasonable to treat these views like the other optional views that can be used with the generic workbench?
The error log is undergoing some enhancements. Part of the work will remove the dependency on org.eclipse.update.ui.forms.
Also note that the dependency on core.resources can be easily removed also.
Based on the comments about dependencies above, it sounds like their PDE dependencies can easily be factored out. However, I don't think they should be moved into org.eclipse.ui.views (which currently contains just the Outline and Properties views) as the error log and registry view are really developer and debugging tools, not intended for use by regular end users. I think it makes sense to keep them as part of the PDE component (since they are in aid of developing plug-ins), but move them to their a separate plugin without dependencies on the rest of PDE.
Nick, these views are already in their own lightweight plug-in (org.eclipse.pde.runtime), whose list of dependencies can be reduced to core.runtime.compatibility, org.eclipse.ui and org.eclipse.ui.views. The question is of course whether this plug-in should remain part of the PDE feature. Contents and use of the registry and the log views is not necessarily restricted to plug-in developers. Applicaiton users are often asked to report the content of the log, and it would be better if they did not have to dig into their metadata directory to find it.
Wassim: Is the dependency on org.eclipse.ui.views necessary? That plug-in only contains the Outline and Properties views. Do the registry and error views use either?
The registry view (the other view in the plug-in) uses the property sheet and hence the dependency on the ui.views. Maybe we should consider whether these views should be moved down to the platform separately: 1. Log view: only requires org.eclipse.ui and core.runtime.compatibility. 2. Registry view: requires org.eclipse.ui, ui.views and core.runtime.compatibility. This view is planned to undergo a major facelift to make it more useful, and the dependency on ui.views could go away as a result. The log view seems a reasonable candidate for being pushed down to the platform, as it is pretty useful for your day-to-day Eclipse activities. The registry view on the other hand can be viewed as development-specific, and should remain part of PDE.
Matt, can you give your opinion here from the perspective of a non-IDE product group? Would you have any use for either a log view or a registry view?
One further consideration: to be maximally useful in RCP configurations we would probably want no eliminate the dependency on core.runtime.compatibility as we will for the other RCP components. Would there be significant work involved in moving these views to use only core.runtime?
All the classes that we use from core.runtime.compatibility are in fact coming from core.runtime. So we could clean up the dependency list. However, if we do so, the JDT compiler starts complaining that org.eclipse.osgi has to be on the classpath for the plug-in to compile. (bug 50117)
The log view is staying where it is in 3.0. Will revisit the issue post-3.0
*** Bug 105585 has been marked as a duplicate of this bug. ***
*** Bug 107396 has been marked as a duplicate of this bug. ***
Reopening... This issue keeps coming up, and I think we should reconsider the more general issue of what the granularity of a feature should be.
The word is that the log view stays where it is in the PDE feature. If people want, they can just drop/package the plug-in on its own in their product and it will work fine as it has minimal dependencies.
(In reply to comment #16) > If people want, they can just drop/package the plug-in on its own in their > product and it will work fine as it has minimal dependencies. I guess it depends on what your definition of "minimal" is. :) Perhaps it has grown in the intervening years, but including optional dependencies you get pde.ui, jdt.ui, help, forms, etc.. That's a crazy amount of stuff to add in in order to get one piece of functionality that's of really broad use. I've stated a new bug 319802 to try to see if Platform is willing to steal it, because it is still lost on me why this is a PDE exclusive thing. But perhaps a refactoring of the pde runtime dependencies would be worth a look?
Umm...never mind. See my comment on bug 319802 if you have time to kill..
*** Bug 543120 has been marked as a duplicate of this bug. ***
We have discussed this and we are going to investigate this for the next milestone.
New Gerrit change created: https://git.eclipse.org/r/134915
New Gerrit change created: https://git.eclipse.org/r/134918
I think I am done, all builds complete normally. However, there might be some releng things that I might have missed. Status update: * I have created three bugs to track the changes in three different repositories. * The view is self-contained which means that there are no outside references. * Any unknown outside references should be done with the view id. Therefore, the view id does not change but will be kept in the pde domain: org.eclipse.pde.runtime.LogView Changes: PDE (https://git.eclipse.org/r/#/c/134915/) * Removed the view from the PDE feature * Removed the view code * Removed the entry in the PDE pom.xml * PDE build completes normally Platform.releng (https://git.eclipse.org/r/#/c/134920/) * Added the bundle to the platform feature * Releng build completes normally Platform.ui (https://git.eclipse.org/r/#/c/134918/) * Added the view code * Changed the view's pom.xml to use the correct parent * Bumped the last segment of the version number * Added the module to the bundles' pom * Platform build completes normally
(In reply to Wim Jongman from comment #24) > I think I am done, all builds complete normally. However, there might be > some releng things that I might have missed. > > Status update: > > * I have created three bugs to track the changes in three different > repositories. > * The view is self-contained which means that there are no outside > references. > * Any unknown outside references should be done with the view id. Therefore, > the view id does not change but will be kept in the pde domain: > org.eclipse.pde.runtime.LogView > > Changes: > > PDE (https://git.eclipse.org/r/#/c/134915/) > * Removed the view from the PDE feature > * Removed the view code > * Removed the entry in the PDE pom.xml > * PDE build completes normally > > Platform.releng (https://git.eclipse.org/r/#/c/134920/) > * Added the bundle to the platform feature > * Releng build completes normally > > Platform.ui (https://git.eclipse.org/r/#/c/134918/) > * Added the view code > * Changed the view's pom.xml to use the correct parent > * Bumped the last segment of the version number > * Added the module to the bundles' pom > * Platform build completes normally Wim. As you also moved some icons you should also move them in the images repository https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images
(In reply to Matthias Becker from comment #25) > Wim. As you also moved some icons you should also move them in the images > repository > https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images Good point! Luckily, the documentation itself is already in the Platform Doc and not in the PDE Doc. Regarding the timing: The India team is away today and tomorrow, so, most likely they won't be available to fix any build related problems.
> (In reply to Matthias Becker from comment #25) > > Wim. As you also moved some icons you should also move them in the images > > repository > > https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images Thanks Matthias. I looked at it and there is no change needed. The images are already in the correct place. (In reply to Dani Megert from comment #26) > Regarding the timing: The India team is away today and tomorrow, so, most > likely they won't be available to fix any build related problems. Ok. In this case, I suggest doing the move to tomorrow evening instead. This will give the India team to resolve any issues or rollback the changes during their day on Wednesday. Lars, ok for you?
(In reply to Wim Jongman from comment #27) > > (In reply to Matthias Becker from comment #25) > > > Wim. As you also moved some icons you should also move them in the images > > > repository > > > https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images > > Thanks Matthias. I looked at it and there is no change needed. The images > are already in the correct place. > > > > (In reply to Dani Megert from comment #26) > > Regarding the timing: The India team is away today and tomorrow, so, most > > likely they won't be available to fix any build related problems. > > Ok. In this case, I suggest doing the move to tomorrow evening instead. This > will give the India team to resolve any issues or rollback the changes > during their day on Wednesday. I have an agreement with Sravan that I cover build issues this week. So from that point of view there is no need for delays for releng help if needed. > > Lars, ok for you?
(In reply to Alexander Kurtakov from comment #28) > > I have an agreement with Sravan that I cover build issues this week. So from > that point of view there is no need for delays for releng help if needed. Cheers Alexander. Then we will stick to the original plan of releasing tomorrow morning.
We have moved the error log view from PDE to Platform. It was trivial really because the original authors had already written the view in such a way that it was just an ordinary move. Very elegant. I could not track them down in git but a tip of the hat to them. I'm closing as resolved but it still needs to be verified. Just in time for the SLA window of 15 years!
I suggest to add an entry to the N&N.
New Gerrit change created: https://git.eclipse.org/r/135089
Gerrit change https://git.eclipse.org/r/135089 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=a8cec37b436d836484a2f62eb43443820b4ea5c4
New Gerrit change created: https://git.eclipse.org/r/135092
Gerrit change https://git.eclipse.org/r/135092 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=c59cf9b2c9d6e39ddade4a30c6f85f9c9f52d018
Verified in eclipse-SDK-I20190115-1800-win32-x86_64
New Gerrit change created: https://git.eclipse.org/r/136303
Gerrit change https://git.eclipse.org/r/136303 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=5e461b865c30beb69cda9b8234223800e7943ef8
Thanks Wim. And congrats for tackling the older bug for this upcoming release! (unless bug 38016 finds its way in).
