Community
Participate
Working Groups
Currently an infamous Source Not Found editor appears, which also says: The JAR of this class file belongs to container 'Plug-in Dependencies' which does not allow modification to source attachnments on its entries. Stopping debug session, attaching sources and restoring the work may take a really long time.
Related to this I have recently come across scenarios where source cannot be supplied by the normal means but needs to come from a "service" of some sort. As a result, it is not available a priori. Being able to dynamically attach source would be great. My vision here is that whenever source is being looked for, there would be a pluggable entity that could say "I have source for that". We could then plug in a source discovery mechanism. Note that this requirement occurs both at debug and development/browsing time. We want to attach source and not mess with the classpath containers such that rebuilds are triggered.
There is enough interest here for this to be considered for 3.7, though it isn't clear who has time to work on it right now. Two possible approaches: 1) Allow source attachments to be modified in the PDE classpath container Currently the user is unable to modify the container contents at all (all managed by PDE code). We do not want the user to be able to add or remove classpath entries, but if we can allow just source attachments to be modified, this would be the better approach. 2) Add a source path computer extension from platform debug PDE has its own source lookup director that manages source for debugging. Platform debug has an extension point to submit source path computers that should be able to add extra content to the source lookup path.
Thanks for considering this. I should be able to spend a bit of time looking around and testing/using such enhancements though am not likely well positioned to create the enhancements without significant guidance. Re option 2, we need to hook source lookup everywhere not just debugging. I don't fully understand the distinction between getting source when debugging and getting it while browsing but regardless, having it one place and not the other is not an interesting solution for our usecases. There also the notion of laziness. Allowing source attachments to be modified is cool if the users proactively knows they want source and then goes and gets it and has it attached. However, if someone wants source and it is not there, it would be interesting to hook that source lookup and then dynamically get/compute/generate/format the source. I'm not sure if this is possible but it sure would be interesting.
Created attachment 189860 [details] Hack to demonstrate approach #1 This patch modifies the classpath container initializer in PDE to support modifying the source attachments on the container. The container is still considered read only, but the source attachments are user modifiable. This was all done using JDT API. Source attachments can be modified by opening the property page for a container entry or when source is not found, there should be a button to modify the source attachment. The changes are not persisted anywhere, so restarting, changing target platforms, or doing anything that recreates the Plug-In Dependencies container will throw away any user changes. I'm thinking that we can reuse the 'additional source' preference to persist some of this information. We will also have to decide whether changing one entry should modify all containers containing that entry. Also, whether we should ever throw away changed attachments (to me it feels like changing target platforms would be a good time).
Created attachment 189861 [details] mylyn/context/zip
Is any help necessary here?
(In reply to comment #6) > Is any help necessary here? Being the end of M6, we are crunched for time, but so far fixing this has not required a lot of code changes. I'll mark this for M7. We need to more clearly define how persistence should work to make sure it covers the cases that Christopher and Jeff are concerned about. My only two requirements are: 1) We need custom source attachments to persist through workspace restart. 2) There needs to be a way to reset the source attachment Should the source attachment be associated with a specific plug-in id/version? If this is the case, then should we clear out any unused custom source attachments when the target platform changes? ex. A 1.0 points to source A.source 1.0, updating the target to A 2.0 would remove the custom source attachment.
I will try out the patch. Source should definitely be kept in sync with the binary. I was hoping however that I could manage the pool of source stuff just be asked for source for a given bundle. Proactively attaching source leads to this kind of cache coherence problems. If that's all we have then some sort of trigger such that I can update the attachments if the target changes should be fine. I can likely comment more usefully once I can look at the patch. As for requirements 1) yes, associations across restarts should work. persistence of this is an issue if the attachments are static/proactive. If they are dynamic (i.e., pde asks someone for source when they need it) then it is the provider's problem (ok with me) 2) not sure quite what resetting means in this context. Really my only requirement is that when source is needed I get a chance to supply it.
I had a look at the patch and am confused a bit. I see that it is enabling the RequiredPluginsInitializer to do stuff with source attachments but the bar to calling requestClasspathContainerUpdate() is way too high. You have to know a list of classpath elements and dig down several layers of object until the word "source" is mentioned. Can you give a sample code snippet that would allow me to say that one of the 50 prereq bundles now has source and it is in c:\foo.source.jar? Door number 2 seems pretty enticing. I put breakpoints all over PDESourceLookupDirector and then opened .class files that were on the classpath of my projects. Unfortunately the breakpoints were never hit. In fact, the class is not even loaded (had breakpoints in the static initializers and they were not hit). Is there some other class you were talking about in comment 2?
Please get this in for M7 if possible, this has been another bane I've had to deal with when using OSGi in Eclipse. It is very frustrating to have to go dig up a source jar for a bundle, open it up and inject the appropriate headers to the manifest, add it to the target, reload the target, restart the app.. etc etc. All for something you probably can debug with the source in far less time than it takes to get, format, and inject the source currently. Thanks!!
I would also find this a big time-saver.
I just want to clarify my interest in the area so we are talking about the same thing. I do not need any manual steps to attach source to jars. While it could be useful, I am trying to build an alternative way of getting and managing source for *bundles* that is completely/mostly automated. So my requirement is simple, open a hook somewhere where my code can get a shot at supplying the source for a given class. Ideally this would be dynamic (i.e., consulted for every source lookup). If it has to be static then we need some API/lifecycle that would allow an external mechanism to say it has source for a given bundle. Note further, I don't understand the separation between source lookup for debug and for browsing or if it even makes a difference. Whatever is going on there, developers need source at both points.
Update: At this point it appears that the approaches being considered here do not solve Jeff's problem. We are waiting on input from other interested parties to decide if the current patch (with no persistence) is satisfactory or what direction to take if that is not the case.
(In reply to comment #13) > Update: At this point it appears that the approaches being considered here do > not solve Jeff's problem. We are waiting on input from other interested > parties to decide if the current patch (with no persistence) is satisfactory or > what direction to take if that is not the case. Is there any particular reason that we cannot persist source code attachment locations as metadata inside the project? I'd much prefer to have a "source code missing prompt" with an "attach source" button, pick the source, then persist that. I also think the hook that Jeff is after is a good idea, but I think at the very least the above path should be available to OSGi developers.
(In reply to comment #14) > Is there any particular reason that we cannot persist source code attachment > locations as metadata inside the project? I'd much prefer to have a "source > code missing prompt" with an "attach source" button, pick the source, then > persist that. I also think the hook that Jeff is after is a good idea, but I > think at the very least the above path should be available to OSGi developers. With the current patch, if you don't have source code for a class file, the opened editor will have a button at the top to change the source attachment. The persistence issue is a matter of where to store the information and when to clear it. If we store it directly in the project classpath file, the settings will get saved to CVS which might not be helpful. If we store it in the pde metadata, the user will have no knowledge/control over what is being stored. The PDE classpath container is dynamic, so its entries may change. The most likely scenario for the change is the target platform being modified. It's not clear when the stored source attachments should be changed and when they should be applied to other projects.
(In reply to comment #15) > (In reply to comment #14) > > Is there any particular reason that we cannot persist source code attachment > > locations as metadata inside the project? I'd much prefer to have a "source > > code missing prompt" with an "attach source" button, pick the source, then > > persist that. I also think the hook that Jeff is after is a good idea, but I > > think at the very least the above path should be available to OSGi developers. > > With the current patch, if you don't have source code for a class file, the > opened editor will have a button at the top to change the source attachment. > > The persistence issue is a matter of where to store the information and when to > clear it. If we store it directly in the project classpath file, the settings > will get saved to CVS which might not be helpful. If we store it in the pde > metadata, the user will have no knowledge/control over what is being stored. > > The PDE classpath container is dynamic, so its entries may change. The most > likely scenario for the change is the target platform being modified. It's not > clear when the stored source attachments should be changed and when they should > be applied to other projects. I tried the patch and verified it works. I also agree it may not be the best idea to persist the mapping into files that will make it into revision control. I think the same problem exists with the target file as we are persisting those into revision control as well. Is it possible to create a new file that could live in the workspace and be ignored by RCS but contain these mappings? It would have the nice side effect that it could persist across targets being changed.
Our adopter confirmed the fix is sufficient. Curtis, can you release it? Jeff's requirement is broader than this one, maybe it deserves a separate bug?
Fixed in HEAD and 3.6.x maintenance branch. Without persistence, my patch did not need any code changes. Jeff or David, if you have further requirements (persistence, etc), please open a new bug to track that work.
Is there already a new bug opened for tracking requirements described by Jeff? I am running into the same problem regarding persistence of source attachments. In our development environment we use couple of OSGified bundles, which however do not have proper corresponding source bundles. So I was basically hoping that for those bundle I could point source attachments to the source jars in a workspace project, where they would have been automatically copied into by our Maven build. It would be fine for me if these settings would be stored in the workspace preferences, since then I can distribute these settings to users and keep them up-to-date. But this is of course quite a special case, so alternatively I would also look into a more general, consistent solution may be involving explicit management of additional source attachments in a pool-like manner.
(In reply to comment #19) > Is there already a new bug opened for tracking requirements described by > Jeff? I am running into the same problem regarding persistence of source > attachments. > > In our development environment we use couple of OSGified bundles, which > however do not have proper corresponding source bundles. So I was basically > hoping that for those bundle I could point source attachments to the source > jars in a workspace project, where they would have been automatically copied > into by our Maven build. It would be fine for me if these settings would be > stored in the workspace preferences, since then I can distribute these > settings to users and keep them up-to-date. But this is of course quite a > special case, so alternatively I would also look into a more general, > consistent solution may be involving explicit management of additional > source attachments in a pool-like manner. I don't think a bug was ever opened. Not sure if it would help, but you can extend a project's classpath with additional source entries via extension. See org.eclipse.pde.core.IBundleClasspathResolver
