Bugzilla – Full Text Bug Listing
| Summary: | org.eclipse.jdt.launching uses customBuildCallbacks | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Krzysztof Daniel <krzysztof.daniel> | ||||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, john.arthorne, krzysztof.daniel, Lars.Vogel, Michael_Rennie, pwebster, thanh.ha | ||||||
| Version: | 4.2.1 | Flags: | thanh.ha:
review+
|
||||||
| Target Milestone: | 3.8.2+ | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 372792 | ||||||||
| Attachments: |
|
||||||||
|
Description
Krzysztof Daniel
(In reply to comment #0) > to call scripts/buildLaunchingSupportJAR.xml and builds (apparently) > lib/launchingsupport.jar. > > 1. Some clarification would be welcome here. You are correct we use the buildLaunchingSupportJAR buildfile to create the lib/launchingsupport.jar file during builds and as an external tool builder in the workspace. The purpose of the jar is to allow us to run a small snippet to compute the default library set for a VM install - see /org.eclipse.jdt.launching/support/org/eclipse/jdt/internal/launching/support/LibraryDetector.java if you are curious. Created attachment 221246 [details]
Patch that is used in Fedora
Here is the patch. I was not able to build the internal jar just with tycho tasks, so I used the maven-antrunner.
If there's better way, just let me know, I will update the patch.
Created attachment 221247 [details]
mylyn/context/zip
I believe reliance on ant callbacks will be an impediment in the long run but I am not in the position to tell JDT team what they should or should not do. What would be the ideal solution in this case? The internal jar must be build with very specific java settings (1.1 compatibility), so, refactoring the jar into separate artifact and including it via copy dependencies? I believe this should go into CBI 1.0. Lack of initial jvm libs will make creating new java projects difficult. Michael can you apply this patch in master so we can verify the output. Since the Jar is not being produced at all today in CBI, having something produced would be a start. done: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e1e23de88555fafa7de657e70e512435b69c035c I'll leave the bug open until there is some output to verify. (In reply to comment #8) > done: > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=e1e23de88555fafa7de657e70e512435b69c035c > > I'll leave the bug open until there is some output to verify. I can confirm that with the patch we are able to build launchingsupport.jar now (output of build and contents below). I don't know enough about this jar to confirm if it's complete so please let me know if there's anything I can provide to help verify this. One thing I noticed though is the patch alone won't build launchingsupport.jar. I had to delete the existing lib/launchingsupport.jar file first to force it to build. I think this is due to the line in customcallBacks: <target name="pre.@dot" unless="lib.exists"> Should we have Maven remove this file before running the build? or is it ok that the build by default uses the existing launchingsupport.jar? lib/launchingsupport.jar: [mkdir] Created dir: /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/eclipse.jdt.debug/org.eclipse.jdt.launching/temp.folder/lib/launchingsupport.jar.bin [javac] Compiling 3 source files to /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/eclipse.jdt.debug/org.eclipse.jdt.launching/temp.folder/lib/launchingsupport.jar.bin [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.3 [javac] 1 warning [jar] Building jar: /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/eclipse.jdt.debug/org.eclipse.jdt.launching/lib/launchingsupport.jar [delete] Deleting directory /home/user/Downloads/eclipse2/eclipse.platform.releng.aggregator/eclipse.jdt.debug/org.eclipse.jdt.launching/temp.folder Contents: Archive: launchingsupport.jar creating: META-INF/ inflating: META-INF/MANIFEST.MF creating: org/ creating: org/eclipse/ creating: org/eclipse/jdt/ creating: org/eclipse/jdt/internal/ creating: org/eclipse/jdt/internal/launching/ creating: org/eclipse/jdt/internal/launching/support/ inflating: org/eclipse/jdt/internal/launching/support/LegacySystemProperties.class inflating: org/eclipse/jdt/internal/launching/support/LibraryDetector.class inflating: org/eclipse/jdt/internal/launching/support/SystemProperties.class >
> Should we have Maven remove this file before running the build? or is it ok
> that the build by default uses the existing launchingsupport.jar?
>
Offhand, I'd guess that the "launchingsupport.jar" should be added to .gitignore so the "pre-built" version is not in the Git repo? I'd think someone checking out latest from repo into their workspace would want it "rebuilt"?
Michael, others, sound right? (Can we "do that work" as part of this bug?)
Little that I know ... about this particular jar. :)
(In reply to comment #8) > done: > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=e1e23de88555fafa7de657e70e512435b69c035c > > I'll leave the bug open until there is some output to verify. Can this patch be merged into R3_8_maintenance branch as well? (In reply to comment #10) > Offhand, I'd guess that the "launchingsupport.jar" should be added to > .gitignore so the "pre-built" version is not in the Git repo? I'd think > someone checking out latest from repo into their workspace would want it > "rebuilt"? > > Michael, others, sound right? (Can we "do that work" as part of this bug?) > Currently the jar is in the repo, but if it is correctly being built during the build process I see no reason to have it there - i.e. we could just add it to .gitignore > Little that I know ... about this particular jar. :) This particular jar is run by debug to collect the names / paths of all of the libraries for a JRE / SDK, without it you would not be able to install new JREs / SDKs in Eclipse. > Can this patch be merged into R3_8_maintenance branch as well? done: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?h=R3_8_maintenance&id=d326a7cdb7b46599e21437f809ea8d8b6b349695 See also bug 369480. Just cleaning up some targets. I suggest Kepler M7, instead of 3.8.2, then if anything must be back ported to 3.8.2+ that a separate bug (or clone) be opened on that target. Hope you don't mind ... just trying to help. Feel free to correct if this really was fixed in 3.8.2. Closing this as fixed now, the jar is in the builds and is being built correctly. |