Community
Participate
Working Groups
Build ID: 3.3 Steps To Reproduce: 1. Fire up an Eclipse w/o PDE 2. Try to find out whether Eclipse is reporting any errors 3. ... More information: The issue is older than myself, check these bzs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=50517 https://bugs.eclipse.org/bugs/show_bug.cgi?id=107396 The general issue is this: Everybody needs the visual representation of the .log file, why would that file be there at all if not? .log could be provided in pde.core otherwise as well, would be more consistent... The original bz suggests to bundle pde.runtime in our own feature to include it nonetheless which is what we do. However, if the customer adds PDE later on there are errors regarding a duplicate pde.runtime. That's really a nuisance but IMHO avoidable.
Moving to PDE for consideration (creating a new feature with just pde.runtime). Platform UI does not plan to add the Error Log view to the list of standard views in the Workbench or IDE.
would be interesting to know how much the error log view drags in. Is it really dependent on PDE? Or is it just there cause thats where all the cool kids hang? I would hesitate to say that we should start shipping pde.runtime in RCP apps. It would be more appealing to separate out the error log into its own bundle (assuming minimal dependencies). BTW, solving this problem is in line with the servicability plan items.
Ciao Guys :) I'm completely fine with moving the Error Log into a separate (In reply to comment #2) > would be interesting to know how much the error log view drags in. Is it > really dependent on PDE? Or is it just there cause thats where all the cool > kids hang? I would hesitate to say that we should start shipping pde.runtime > in RCP apps. It would be more appealing to separate out the error log into its > own bundle (assuming minimal dependencies). > > BTW, solving this problem is in line with the servicability plan items. > This sounds great, I'm supporting that move into a separate bundle! :)
(In reply to comment #2) > would be interesting to know how much the error log view drags in. Is it > really dependent on PDE? Or is it just there cause thats where all the cool > kids hang? I would hesitate to say that we should start shipping pde.runtime > in RCP apps. It would be more appealing to separate out the error log into its > own bundle (assuming minimal dependencies). These are the classes necessary for the LogView class to _compile_: EventDetailsDialog EventDetailsDialogAction FilterDialog IHelpContextIds LogEntry LogReader LogSession LogView LogViewContentProvider LogViewLabelProvider OpenIDELogFileAction OpenLogDialog PDERuntimeMessages PDERuntimePlugin PDERuntimePluginImages TailInputStream Essentially, you need everything in the runtime plug-in minus org.eclipse.pde.internal.runtime.OverlayIcon and the contents of the org.eclipse.pde.internal.runtime.registry package. The plug-in itself declares dependencies on: org.eclipse.core.runtime org.eclipse.ui org.eclipse.core.filesystem org.eclipse.ui.ide The filesystem and ide plug-in dependency is caused by the OpenIDELogFileAction which retrieves the log file as an IFileStore and then subsequently invokes the IDE.openEditorOnFileStore(IWorkbenchPage, IFileStore) method.
This was actually brought up in the past in bug 50517 (thanks Wassim for the post). Maybe it is time we revisit this issue. As for dependencies, the log view doesn't have many dependencies (really any) on PDE. PDE does need to reference it as an x-friend, but that is the only real dependency. I don't think it would be a huge undertaking in refactoring this piece out. That being said, I think this is a good idea only if the view moves out of PDE. I understand other users wish to ship this plug-in with their product. I am glad, that means people like what we have created :) But right now, I am hesitant to single out the Log View for its own PDE feature.
Note, this fits under the Consumability item in 3.4 plan imho: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_4.html#Consumability
Jeff, do you approve of a new bundle and possibly a new feature for this (to aid consumability)?
making a new bundle is cool. I am bummed by the dependency on IDE. Making a new feature is less exciting. We should cue that up with the help feature etc to have a coherent approach. It would be a bad thing if we ended up with a haphazard hodge podge of horrendous half-baked features.
cool, I'll make a new plug-in... I like new plug-ins. I'll consider this PMC approved. Hey Mik, this may break you for that Report as Bug object contribution you do in Mylyn. I'm thinking the new plug-in name is org.eclipse.pde.runtime.log
(In reply to comment #8) > making a new bundle is cool. I am bummed by the dependency on IDE. The dependencies on IDE and filesystem are optional.
refactoring is cool, refactoring out NLS strings and images from plug-ins, not so cool.
(In reply to comment #9) > cool, I'll make a new plug-in... I like new plug-ins. I'll consider this PMC > approved. > > Hey Mik, this may break you for that Report as Bug object contribution you do > in Mylyn. > > I'm thinking the new plug-in name is org.eclipse.pde.runtime.log > Ciao Guys :) I don't really see the need to name this one after pde, why not use a more simple and accurate name like "org.eclipse.ui.log"? Never heard anyone say "Hey, I've seen this error in the PDE log view", it's always "the log view" ... ;)
With the log view being applicable to all users (developers, administrators, end users), I think it would make sense to move it away from the pde realm where we focus mainly on development tooling. I know this will probably get shot down, but would Platform be interested in the Log View? This seems to go along with comment #12.
Creating a plug-in with a non-PDE name is a good idea. Having PDE developers maintain the plug-in is also acceptable. This happened in debug with the console (org.eclipse.ui.console plug-in).
ok, I can roll with "org.eclipse.ui.log" I'll do that. I'll even more it to the "General" category now. It's sad to see our little baby all grown up, moving up a namespace. I assume it will still be in PDE's feature's for now.
Ideally, we'll move it to the platform feature. I presume this refactoring will be post M2? Are there any API issues when changing namespaces - i.e. View ids, package names that are API?
everything was considered internal (and marked so) with the log view so people who used it before, will have to be aware of the naming change. A public announcement and mention in the N&N should be good. I still think we should keep things internal.
(In reply to comment #16) > Ideally, we'll move it to the platform feature. I presume this refactoring will > be post M2? Are there any API issues when changing namespaces - i.e. View ids, > package names that are API? The view ID can/must remain the same if you want the transition to be transparent. Since 3.2, the namespace of an extension does not have to match the ID of the bundle that contains it. Package names etc. can change since they are all internal packages.
(In reply to comment #15) > ok, I can roll with "org.eclipse.ui.log" Can you make that org.eclipse.ui.views.log?
Is there a need for retaining the old view id? It is good to update as much as possible in these refactorings but of course, not at the expense of real usecases. As for feature location, the platform feature is an ok home. also, what would be the Bundle-RequiredExecutionEnvironment for this bundle? on another note, all the cool kids call them "bundles" now. :-)
(In reply to comment #20) > Is there a need for retaining the old view id? It is good to update as much as > possible in these refactorings but of course, not at the expense of real > usecases. My OCD says yes to the rename. The only clients of the log view I know are Mylyn but they use an objectContribution to add an action. I'm sure there may be others out there. > also, what would be the Bundle-RequiredExecutionEnvironment for this bundle? J2SE 1.4 > on another note, all the cool kids call them "bundles" now. :-) I thought the cool kids talked about "IUs"
(In reply to comment #20) > Is there a need for retaining the old view id? It is good to update as much as > possible in these refactorings but of course, not at the expense of real > usecases. At minimum, if the view ID changes, and you start Eclipse on an existing workspace that contains the view, you will get an error. In general, as yo know, IDs like view IDs become implicit API. There are clients out there, who add this view to their perspective and thus reference the log view id in markup and/or code, the moment you change it, they all have to update. I know such clients.
So, I need someone to create a org.eclipse.ui.views.log stub directory within CVS. I'm going to attach my first cut.
Created attachment 78343 [details] org.eclipse.ui.views.log.zip
With the log view being pushed down, it seems inappropriate now for its plugin.xml to have perspective extensions to JDT perspectives. In fact, I suggest removing all perspective extensions from the plugin.xml. Any client wanting to include that view should do it at their end.
fair enough, that will be done once the code is alive in a CVS tree somewhere
Chris, regarding comment #23 and cc'ing me on the bug.. I don't have root on the servers to create new directories...you will have to ask the webmaster to do this and cc a PMC member.
Thanks Kim!
> With the log view being pushed down, it seems inappropriate now for its > plugin.xml to have perspective extensions to JDT perspectives. > > In fact, I suggest removing all perspective extensions from the plugin.xml. > Any client wanting to include that view should do it at their end. Oh no! The PDE perspective is my favorite perspective. It gives me a warm fuzzy feeling when I am using it :(
That is not what I meant, Brian. The PDE perspective is not affected by this. Take at a look at the perspectiveExtensions extensions in the attached plugin's plugin.xml to see what I am talking about. The log view currently adds itself as a view shortcut in JDT/Debug/Resource perspectives. This knowledge of downstream clients needs to stop if the view gets pushed down.
The main argument that seems to be given for pushing the log view down is that the error log cannot be accessed from the UI. I just wanted to point out this isn't true, since the log can already be viewed via Help > About > Configuration Details > View Error Log. To me it seems unfortunate to be cluttering the platform with another view for this - the error log is really intended for consumption by developers rather than end users, hence the fact that strings in the log are not translated.
I think the real issue is that its a pain to see the log without PDE and its viewer. If this were in the platform, apps that use only it could provide this view much more easily. While I think that the ideal solution is providing a view targeted at end users which apps could tailor somewhat to their needs, this is a huge improvement over whats there now. Currently, I believe many tools just create their own. (In reply to comment #31) > The main argument that seems to be given for pushing the log view down is that > the error log cannot be accessed from the UI. I just wanted to point out this > isn't true, since the log can already be viewed via Help > About > > Configuration Details > View Error Log. To me it seems unfortunate to be > cluttering the platform with another view for this - the error log is really > intended for consumption by developers rather than end users, hence the fact > that strings in the log are not translated. >
(In reply to comment #31) > The main argument that seems to be given for pushing the log view down is that > the error log cannot be accessed from the UI. I just wanted to point out this > isn't true, since the log can already be viewed via Help > About > > Configuration Details > View Error Log. To me it seems unfortunate to be > cluttering the platform with another view for this - the error log is really > intended for consumption by developers rather than end users, hence the fact > that strings in the log are not translated. > Hi John :) Help > About > Configuration Details > View Error Log opens up some log file (not even .metadata/.log???) in a browser, outside of Eclipse, trying to display txt as html, without any sorting possible, without any chance to see log entry dependencies etc. I would not consider this an alternative to the pde's version of viewing the .log... As said before, if the log view is not platform functionality, why is the log mechanism at all then? That's incoherent. The argument that users are not really taking advantage of the error log may be true in an ideal world where no errors happen at all but as soon as there is an issue clever users will look at the error log while not so clever users will call support (if there is any for their product ;)) and the support guy will ask them to look at the error log view and tell him what (s)he sees... This bugzilla arose from the need of packaging the pde.runtime plug-in with our product. We certainly don't target plug-in developers which is why we leave out PDE (and JDT for that matter) but we certainly need the log view. One final thing: error log seems the wrong name for a view that displays many stati: Error, Warning, even Info (that could be used for showing important progress messages etc.)...
(In reply to comment #21) > My OCD says yes to the rename. The only clients of the log view I know are Mylyn > but they use an objectContribution to add an action. I'm sure there may be > others out there. Thanks for the heads-up, but don't worry about breaking Mylyn since and we have two streams (3.3 and 3.4 latest Milestone) and are generally happy to see this change. Previously this functionality was only available in EPP distributions that included PDE and now everyone else will be able to use this too. Which reminds me that we should beef up our duplicate detection ;) bug 161877 (In reply to comment #31) > The main argument that seems to be given for pushing the log view down is that > the error log cannot be accessed from the UI. I just wanted to point out this > isn't true, since the log can already be viewed via Help > About > Configuration > Details > View Error Log. To me it seems unfortunate to be cluttering the > platform with another view for this - the error log is really intended for > consumption by developers rather than end users, hence the fact that strings in > the log are not translated. While I haven't heard the other arguments for retaining the Log View, and I'm all for reducing the number of views, I'm leaning towards some of the other points made above. This is largely because I think that having integrated functionality for reporting bugs with contents inserted is important, and Note Pad (or other plain text viewers) do not take object contributions ;) There is an argument that the right place to integrate the functionality could be the Error Dialog (e.g. bug 144035, bug 124964) but that has the limitation that warnings and info messages can't be used for reporting errors. So while I agree that the Log View is advanced and is probably best left somewhat hidden (and made discoverable by the Error Dialog) there could be more benefit in adding it than leaving it out. I wonder if there is any usage data on this from the Java EPP distribution, which does not include the Error Log view (e.g. are people complaining that it's missing?)
Not sure if you know, there are also some enhancements awaiting (at least bug 202584 and bug 202583) that would make Error Log view more flexible for general log analysis - now main use case for me is loading external logs. There would be also place for comparing logs, concatenating them (with respect to dates), etc. I am not against moving it to eclipse.ui, but would be really sad to hear, that my patches can't be applied because log viewer is just simple log viewer and not a developer tool :)
Helmut, clearly you are a power user, likely even a plugin developer, if you can make any sense of what you see in the error log file. I suspect the vast majority of end users (the millions of users who don't participate in conversations in this bugzilla), wouldn't learn anything by looking at the log, or worse still, may misinterpret what they see and inundate their help desk or product support line with all the scary messages they find in there. Imagine if another application that you use but don't develop, such as Word or Notepad, provided tools to allow you to analyze the errors that occurred in it - how much use would it be for you? To me it's a sad statement about our software if we really think a substantial number of end users need tools for managing and organizing all the errors that occur in it. I'm not even convinced it's particularly useful for product support. I'm occasionally called in for product support, and I simply say "Tell the user to send their log file". Is it easier for me to say, "Tell the user to open the error log view. Double-click on each entry in the view, and paste what they see into a file and send it to me".
(In reply to comment #36) John, The error log is the first base for every Eclipse user who experiences a problem with Eclipse. I'm supporting many plug-in developers in my company and that's safe to say. "Any errors in the error log?" is my first question when somebody experiences odd behaviour ("Hey, help is not coming up! "Hey, the action does NOTHING" etc.). . However, most of the time the errors are not PDE related. The point is that the error log view should be moved down to the level where the error log file is situated, that's it. I'm completely on your page in terms of who can and who can't make use of the view, millions won't, but many thousands will. If there is a set of views that clasify like this the platform should create a feature "org.eclipse.platform.powerusers" and ship them in there ;)
John, +1 One thing though, if we manage to quickly go to a knowledge base with the error and tell the user if this is a known issue or not, that would be great. Let's say, I am creating an App using Eclipse. At some point I am getting some issues either in the problem view or the log view. I can click f1 or open the dynamic help and then I can see that it is a known issue or even better, I can get a cheat sheet that will help me troubleshoot and fix the issue. That would be great no ? :) [is the error log view extensible by the UA DynaHelp ?] I think we are ok with the problem view, meaning products can extend it. For the log view, I am also thinking we could keep a simple viewer in the About dialog, but I agree with you.. if all we do is 'show the issue', this is useless. The power will come from the 'rediscovery' extension one product can put in. What you mentioned about support could also be done. If I am a user, and I get some issue, I could go to 'help', see a menu that states: 'notify my support organization' and this menu could collect the log(s) and send them to the appropriate email/ftp or what ever. I think we have all the extensions to implement that (and by we I mean the products based on eclipse) .. thoughts ? So I think a 'simple yet extensible' : 'tell me what is wrong with my eclipse' view from the about dialog is desirable :) If we can extend the text in the about dialog, I think we are good :) (but I think we lose the fact it is a IStatus and we can do some smart stuff with IStatuses :) PS: For full analysis of the log, I am looking at TPTP Log Analyzer. This is what I want my support to use. PS2: IBM (yeah me :) released a remote troublehooter for Eclipse issues called Rational Diagnostic Tool For Eclipse. We could see about retrieving the log and analyzing it.
@Christophe: Is the "Rational Diagnostic Tool For Eclipse" a product of IBM? I couldn't find anything on the web. Can you provide me a pointer? Thanks.
Gorge, Yes it is an IBM free tool Download IBM Support Assistant (https://www14.software.ibm.com/webapp/iwm/web/reg/pick.do?source=isa&lang=en_US) Pick up the IBM Support Assistant and Electronic Service Agent and install the IBM Support Assistant only Then go to the updater, download an eclipse 3.2 plugin (i.e Rational Application Developer v7) - no worry , you do not need to have it installed Then download the tool Ping me directly if you have issues, so we do not discussit here :)
This bug makes me sad. The request for moving the error log into something more consumable (like a separate plug-in) has been a request for years. I don't think it is up to us to judge what people want to use the log view for, they just want it in their application... whether it is an IDE-based product or a simpler application. Moving it into a separate plug-in makes sense. The decision of where it lives (ie., within the platform feature or pde) could be debated. We can even create a new bug for that one... for now, we can leave it within the PDE family. Jacek, contributions are always welcome... I like your contributions.
My comments were only on putting it in the platform feature. By all means, put it in a separate plug-in and let others decide if they want to consume it. Make ten new plug-ins if it makes zx happy ;)
Created attachment 79510 [details] Updated Chris's patch with a fix from Janek Updated the source zip with the patch from Janek on bug 135633.
code checked into CVS. Will do some further cleanup and testing before releasing to the public.
Chris, can you please add the appropriate version of org.eclipse.ui.views.log to the releng map file so I can update the rcp feature and include this change in a test build. thanks!
org.eclipse.ui.views.log added to rcp feature, will run a test build for this and other changes today.
done. > 20071003. Log view is now in org.eclipse.ui.views.log and is part of the Platform feature. opened bug 205298 to deal with perspective extensions being pushed down to JDT,Debug,PlatformUI
just an update, Log View is in PDE feature now, still named org.eclipse.ui.views.log and that's how it will remain for >=3.4
I'm not satisfied here, my original issue still remains unsolved.
what's your original issue?
open another bug if you want something more specific done or if you feel like arguing with the Platform team about adding the plug-in to another feature. The purpose of this bug was to refactor out the log view into another plug-in, and it was done (org.eclipse.ui.views.log). It's still part of the PDE feature, but nothing prevents you from adding the plug-in to your own custom feature and including it in your build. This way, you just get the log view without any of the other pde.runtime baggage.
I agree with Helmut that the problem for which he opened the bug report was not resolved. And now we are asking him to open yet another bug report. I bet I know what would happen if he did open another one. Rewind to comment 1.
Ciao Guys :) I raised this bugzilla to get you guys to move the pde runtime features "error log view" into a separate plug-in (check), and add that plug-in to the platform or RCP feature (fail). That's what the Description of the bug says and that's what was discussed heavily in the 50+ comments. I'm not saying you guys need to do what I propose in this bugzilla (I certainly want you to, though ;)), all I'm saying is that if you won't refactor the plug-in into platform or RCP this bug needs to be closed "WONT FIX", not "RESOLVED" ;) HTH, Ciao, hh
I suggest that this bug be confined to what the title says (Refactor LogView into a new plug-in), and be marked FIXED. Since some action was taken, it's useful to have a FIXED bug to track those changes, for purpose of verification, etc. I realize the action taken isn't exactly what the originator asked for. A separate bug was filed for moving the new log view plug-in out of the PDE feature and into platform or RCP (bug 205229). That bug was not fixed, but the title was changed to the reverse of the original request and marked FIXED. I'll change that bug back to its original title and mark it as WONTFIX.
see bug 205229 for the wontfix resolution of moving the log view to the RCP feature. This bug tracked the successful refactoring of the log view into a separate plug-in, org.eclipse.ui.views. *PHEW*
(In reply to comment #55) > see bug 205229 for the wontfix resolution of moving the log view to the RCP > feature. > > This bug tracked the successful refactoring of the log view into a separate > plug-in, org.eclipse.ui.views. > > > *PHEW* > Hei Chris :) It's weird that if I, the bug creator, tell you that I'm not satisfied you are responding with something similar to "yes you are satisfied". I mean, just take the steps to reproduce down there, did anything change in the behaviour? Nope. You guys just took a whole month to split one view out of a plug-in, well, that's great, but not nearly enough for what I created this bugzilla for. However, as this is looking to become a flame war with me setting the bug to open and you to resolved I'm gonna leave it at it's state now, turning away from this one in disgust and reporting more important things again :)
Helmut, I love you like a brother and understand your issue. However, go to bug 205229 and complain to the Platform team of why they don't want the log view into the RCP feature. I got denied when I filed the request. In essence, I split your request into two parts, (a) refactor log view into new plug-in (bug 202044) - DONE (b) move log view into RCP feature (bug 205229) - DENIED The platform team are a lively bunch and will entertain your requests.
(In reply to comment #57) > Helmut, I love you like a brother and understand your issue. However, go to bug > 205229 and complain to the Platform team of why they don't want the log view > into the RCP feature. I got denied when I filed the request. In essence, I > split your request into two parts, > > (a) refactor log view into new plug-in (bug 202044) - DONE > (b) move log view into RCP feature (bug 205229) - DENIED > > The platform team are a lively bunch and will entertain your requests. > Thanks for that, looks like this has become a family dispute then ;). I'm honestly no longer interested in getting this one any further, took too much of my time to explain matters and the fact that you guys split the view into a separate plug-in along with the future possibility of a bundle-centered installation rather than a feature-based one makes me think I can live with the little error message and strange location of the view. The alternative is thousands of lines of discussion and I'm not going to participate in that any more ;) So long Brother, cu in another life :)
(In reply to comment #58) On the bright side, I almost got it in the feature when they weren't looking Helmut ;) Next time we'll have to make it a trojan horse... dress it up as something cool and when noone is looking slip in the log view. This is similar to how governments work too :D
Install/update in 3.4 shouldn't cause the same errors to appear when the same bundle is provided by multiple features. I have opened bug 205581 to track that issue.
Created attachment 79919 [details] org.eclipse.ui.examples.rcp.browser.patch A simple patch against the RCP Browser Example demonstrating how to call the log view.
(In reply to comment #61) > Created an attachment (id=79919) [details] > org.eclipse.ui.examples.rcp.browser.patch > > A simple patch against the RCP Browser Example demonstrating how to call the > log view. > Chris, would this code spawn an error if PDE was not installed?
Verified.
