Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: Pleas add a SWT-Library tu JDT. With the old Visal Editor came a SWT Library. But now, without VisualEditor... Please add this Library so I can easy a the needed JAR to my projects. Ralph More information:
This certainly doesn't belong to JDT/Core that doesn't know about SWT. This sounds more like an opportunity for a third-party plugin.
Jerome, please consider reopening this, I think what Ralph meant was a classPathContainer for SWT as we already have one for JUnit. With the SWT templates in place in JDT/UI it would make much sense to have a SWT container in place. It would also help new developers to easily add SWT as dependency to plain Java projects. I just hacked something together and it works just fine. Please consider moving this to JDT/UI and if there is interest I would be glad to contribute a clean implementation for this.
Created attachment 110056 [details] SWT library on Eclipse 3.2
(In reply to comment #2) > Jerome, please consider reopening this, > I think what Ralph meant was a classPathContainer for SWT as we already have > one for JUnit. Sorry but I don't know how it is called :-( With the old VisulaEditor came a Library "Standrad Widget Toolkit (SWT)" (see atached pic) and with one click I can add SWT (and JFace support) to my projects. Now, without VE I must add this jar files manually. But with this library I can add realy easy SWT and JFace support to my projects withou knowing witch jar files I need. And I can upload this setting to cvs and it works on all other machins no matter where the jar files are.
Reopening to move to JDT/UI for consideration.
Moving to JDT/UI
Note that it's almost as easy: 1. import SWT bundle and fragment 2. either start to write SWT code and then use the quick fix to setup the Java build path or manually att the SWT project (or library) to your own project
Dani, personally I don't have a problem with the current situation. But thinking of new users it's often hard for them to setup a simple SWT-based project as you need to know the tricks, where SWT lives, etc. And for new users it's really easy to just hit the "Add Library" button and select SWT. I often need to help new developers to just create a simple project and select the right jars of SWT. I think this would be a great addition regarding usability because it's intuitive. And does not cost much effort to achieve this goal.
>But thinking of new users it's often hard for them to setup You don't need my steps. You can just go to http://www.eclipse.org/swt/, get the library and then it is as simple as adding any library. >And does not cost much effort to achieve this goal. We need to make sure that attaching source works from release to release.
>And does not cost much effort to achieve this goal. Feel free to provide a patch but keep in mind that JDT does not depend on PDE and hence the patch must not internally apply corresponding logic. Also, it need to handle the SWT fragments correctly. Regarding source attachment see bug 236719.
Thanks for the hints Dani. I'll try to provide a high quality patch when time permits.
Created attachment 110303 [details] first shot Here is a real basic implementation of a SWT Classpath Container. There are several important things missing like * property page * request handling for cp attribute changes * multiple swt versions * much more :) Just wanted to attach a patch to show what I mean as it makes it really easy for non-plugin devs to include swt in their project. Patch has also not yet high quality (missing externalized strings, etc). It's just a base to discuss. I would really like to extend to patch to have a ready-to-commit version. Just wanted to know if this would be in the interest of the JDT team or if it's just a waste of time and effort.
We are interested but as said the code not only needs to work in the simple case but also in more complex scenarios. For example there might be more than one version and/or OS drop installed. While this is easy to solve for JUnit where we have either have 3.8.3 or 4.4 (and manually update the container code if the version increments) it might be harder to solve for SWT. Other issues to solve are: - should it update when restarting on a newer drop, e.g. if I first start with 3.4 and then 3.5? - do we really only need SWT or maybe also JFace? If so, do we eventually need a more generic container? - sharing via repository needs to work
*** Bug 181741 has been marked as a duplicate of this bug. ***
The following is about WindowBuilder, but it is cetainly related: So Google kindly contributed WindowBuilder. When creating an SWT project, WindowBuilder creates a new Java Project, and adds many JARs from Eclipse's plugins dir to the build path. For that, it uses the absolute path which renders the project files unsharable between project members. Not sure, what happens when SWT is updated. Probably, the paths become invalid - or probably not since Eclipse never deleted any JAR files after an update. While I understand your concerns, and while I understand that you'd like to see a solution better than a plain simple library container, the solution that windowbuilder implements is far worse then that. Don't procrastinate: offer a simpliest most possible library container now, then later implement advanced features (like having the possibility to switch between SWT versions and stuff).
The best solution that is already available today is to use PDE and create a "Plug-in Project" with org.eclipse.swt added as dependency. That takes care of all sharing issues (since the target platform already contains the right SWT), and OSGi also helps managing more dependencies once the project grows. Moreover, a special case just for SWT would not give a good example. By the same argument, we could also have special containers for JFace, Lucene, Jetty, ... .
(In reply to comment #16) > The best solution that is already available today is to use PDE and create a > "Plug-in Project" with org.eclipse.swt added as dependency. IMHO this is an abuse of a plug-in project (which is for developing plug-ins, not standalone Java applications). But a library container that allows you to add plugins as a dependency to ordinary Java projects is probably a good idea. > Moreover, a special case just for SWT would not give a good example. By the > same argument, we could also have special containers for JFace, Lucene, Jetty, > ... . I agree. You can probably add JUnit to the list. However, I don't want to be the one explaining why you have to create a plug-in project to develop a SWT application. Bottom line is, that an improvement of the practice of WindowBuilder (and I hope you understand or probably even share my ciricism) is needed and depends on whatever you come up with to resolve this report.
