Community
Participate
Working Groups
We would like to add the WindowBuilder Core and Swing to the java-package. What do I have to do to get this done for 3.7M7?
Steffen, any opinion? Size? @Mark: Which feature ID's need to be included?
Feature ID's: org.eclipse.wb.core.feature org.eclipse.wb.core.ui.feature org.eclipse.wb.doc.user.feature org.eclipse.wb.layout.group.feature
I forgot one: org.eclipse.wb.swing.feature
We might want to leave out the docs as they are quite large. They are available on-line in any case, and we could make them a separately installable package. That would drop org.eclipse.wb.doc.user.feature along with the core doc plugin and the swing doc plugin.
+1 Would be great if we can reduce size significantly by making docs optional.
We are working on that and hope to have a drop in the next day.
We have the docs split out into separate features now and are currently in the process of building/testing the new configuration. We might be able to shave another MB or so by splitting off some additional optional pieces (which the user could always load from the update site if they needed them). I'm thinking about things like support for some of the popular 3rd party Swing layout managers like JGoodies FormLayout and MiGLayout.
Current sizes: org.eclipse.wb.core.feature 7.3M org.eclipse.wb.core.ui.feature 128.0K org.eclipse.wb.doc.user.feature 3.8M org.eclipse.wb.layout.group.feature 428.0k org.eclipse.wb.swing.feature 2.4M total size ~= 13.5M
I made a mistake when I did the size post here is the updated post: Current sizes: org.eclipse.wb.core.feature 7.3M org.eclipse.wb.core.ui.feature 128.0K org.eclipse.wb.layout.group.featur 428.0k org.eclipse.wb.swing.feature 2.4M total size ~= 10M
This is the list of features that need to be added to the java-package (In reply to comment #9) > I made a mistake when I did the size post here is the updated post: > Current sizes: > org.eclipse.wb.core.feature 7.3M > org.eclipse.wb.core.ui.feature 128.0K > org.eclipse.wb.layout.group.featur 428.0k > org.eclipse.wb.swing.feature 2.4M > > total size ~= 10M
Do I need to get anything more for this to happen for the Indigo release?
Markus, could we add the features to package and do a nightly build to check what that would look like?
Sure (sure as in "we can add it to the feature", but not so sure if we are currently able to build at all after the crash yesterday). I will add the features mentioned in comment #11.
Created attachment 197036 [details] Additional WindowBuilder Core and Swing features. Added to CVS HEAD.
I played around with WindowBuild a bit and was very impressed! Some nits I noticed: * There is debug output on the console which I suspect comes from WindowBuilder: Parsing...done: 1484 refresh: 207 palette: 322 move overlapping move overlapping Parsing...done: 479 refresh: 286 palette: 174 * Selecting GWT User Interface under Project > New resulted in an NPE and a p2 error beind logged: Missing requirement: Google Plugin for Eclipse 3.6 2.3.1.r36v201105191508 (com.google.gdt.eclipse.suite.e36.feature.feature.group 2.3.1.r36v201105191508) requires 'org.eclipse.wst.css.core 0.0.0' but it could not be found * The org.eclipse.wb.discovery.core and org.eclipse.wb.discovery.ui do not have a provider set. Just out of curiosity is that based on Mylyn's/p2 discovery or a completely different implementation?
One more thing that I noticed is that WindowBuilder contributes 3 startup extensions causing a number of bundles to get activated regardless if WindowBuilder is used in a session or not. Are all of these startup extensions required?
> * Selecting GWT User Interface under Project > New resulted in an NPE and a p2 > error beind logged: > Missing requirement: Google Plugin for Eclipse 3.6 2.3.1.r36v201105191508 > (com.google.gdt.eclipse.suite.e36.feature.feature.group 2.3.1.r36v201105191508) > requires 'org.eclipse.wst.css.core 0.0.0' but it could not be found I added some guard code for this, and some additional checks for when WB toolkits should be available / visible. We had a WB toolkit entry for the GPE, but the GPE does not yet have a 3.7 build. I think this was causing the problem you saw. > * The org.eclipse.wb.discovery.core and org.eclipse.wb.discovery.ui do not have > a provider set. Just out of curiosity is that based on Mylyn's/p2 discovery or > a completely different implementation? The UI was definitely inspired by Mylyn's connector discovery, and much of the actual update code was liberally borrowed from it ;)
(In reply to comment #17) > The UI was definitely inspired by Mylyn's connector discovery, and much of the > actual update code was liberally borrowed from it ;) Can we safely assume that copyright headers remained intact?
(In reply to comment #18) > (In reply to comment #17) > > The UI was definitely inspired by Mylyn's connector discovery, and much of the > > actual update code was liberally borrowed from it ;) > > Can we safely assume that copyright headers remained intact? I referenced sections of one class - our P2Provisioner class - when writing our code to interact with P2. There aren't any copyright headers from the Mylyn code - I didn't take the file wholesale - but I'd be happy to add copyright headers if people think it's warranted.
(In reply to comment #15) > I played around with WindowBuild a bit and was very impressed! Thanks! > Some nits I noticed: > * There is debug output on the console which I suspect comes from > WindowBuilder: > Parsing...done: 1484 > refresh: 207 > palette: 322 > move overlapping > move overlapping > Parsing...done: 479 > refresh: 286 > palette: 174 This debug output has been turned off in the latest build (for 3.7RC4). > * The org.eclipse.wb.discovery.core and org.eclipse.wb.discovery.ui do not have > a provider set. Also fixed.
(In reply to comment #16) > One more thing that I noticed is that WindowBuilder contributes 3 startup > extensions causing a number of bundles to get activated regardless if > WindowBuilder is used in a session or not. Are all of these startup extensions > required? We reviewed them and decided that two were nice to have, but not required, so we turned them off for the latest build. The third is very small, very fast, and well isolated (only activates two small bundles and none of the WB core code), so we kept that one in place.
(In reply to comment #21) > We reviewed them and decided that two were nice to have, but not required, so > we turned them off for the latest build. The third is very small, very fast, > and well isolated (only activates two small bundles and none of the WB core > code), so we kept that one in place. "If it's warranted" is subjective. A few lines of boilerplate code probably doesn't warrant the transfered copyright notice. But if you've taken entire methods, or other novel implementation, then the original copyright holders really deserve a mention in your header at least.
Created attachment 197224 [details] WindowBuilder Compiz Window Manager I am running the Java Package with linux/gtk/x86_64 and I got this dialog when I started it for the first time. Do we want/need to ask that question at that time? Or could/should it be deferred until someone uses WindowBuilder?
Created attachment 197225 [details] About Dialog I would have expected that WindowBuilder contributes an icon with their feature to the About dialog. ;-)
And this seems to me a severe problem, WindowBuilder Core has a dependency to PDE (which should not be pulled into the Java package): WindowBuilder Core org.eclipse.wb.core.feature.feature.group --> Eclipse Plug-in Development Environment org.eclipse.pde.feature.group
(In reply to comment #25) > And this seems to me a severe problem, WindowBuilder Core has a dependency to > PDE (which should not be pulled into the Java package): > > WindowBuilder Core org.eclipse.wb.core.feature.feature.group > --> Eclipse Plug-in Development Environment > org.eclipse.pde.feature.group We have removed this dependency (gracefully degrading if the PDE is not present) and will check in the changes once Eclipse SVN s working again.
(In reply to comment #23) > Created attachment 197224 [details] > WindowBuilder Compiz Window Manager > > I am running the Java Package with linux/gtk/x86_64 and I got this dialog when > I started it for the first time. Do we want/need to ask that question at that > time? Or could/should it be deferred until someone uses WindowBuilder? We changed it to ask when the plugin is first activated (at first use).
(In reply to comment #26) > (In reply to comment #25) > > And this seems to me a severe problem, WindowBuilder Core has a dependency to > > PDE (which should not be pulled into the Java package): > > > > WindowBuilder Core org.eclipse.wb.core.feature.feature.group > > --> Eclipse Plug-in Development Environment > > org.eclipse.pde.feature.group Thanks for catching that, Markus! > We have removed this dependency (gracefully degrading if the PDE is not present) > and will check in the changes once Eclipse SVN s working again. It would be good if we got a package build with a fixed contribution as soon as possible since there are only three days left to make adjustments before RC4.
I'm working on a build.
Any updates on the new build and the PDE dependency? The last package builds (e.g. http://build.eclipse.org/technology/epp/epp_build/indigo/download/20110605-1346/ - will be deleted soon) didn't show any difference. If I can be of any help, please let me know, e.g. if you need a special test build that includes things that are yet contributed to the Simultaneous Release /releases/staging repository.
I'm running a new build now and should have it out soon
(In reply to comment #24) > Created attachment 197225 [details] > About Dialog > > I would have expected that WindowBuilder contributes an icon with their feature > to the About dialog. ;-) We used to do this when WB was a commercial product. Should WB do this now that it is an Eclipse.org project?
(In reply to comment #32) > Should WB do this now that it is an Eclipse.org project? Most projects contribute a branding icon to the about dialog as well as an item to the welcome page. I think it's good practice as it helps users to identify which features are installed and the welcome page is a good entry point to get started or find information about new enhancements.
(In reply to comment #33) > (In reply to comment #32) > > Should WB do this now that it is an Eclipse.org project? > > Most projects contribute a branding icon to the about dialog as well as an item > to the welcome page. I think it's good practice as it helps users to identify > which features are installed and the welcome page is a good entry point to get > started or find information about new enhancements. Do you think that is critical for 3.7 or could it wait for 3.7.1? I am wary about perturbing anything at this point this close to the release (although I suppose this would be fairly benign).
(In reply to comment #34) > Do you think that is critical for 3.7 or could it wait for 3.7.1? I am wary > about perturbing anything at this point this close to the release (although I > suppose this would be fairly benign). No, absolutely not critical but certainly nice to have for the next release.
(In reply to comment #35 and comment #34) It is not criticial at all, it was just an observation and it would be a nice to have for SR1.
(In reply to comment #36) > (In reply to comment #35 and comment #34) > It is not criticial at all, it was just an observation and it would be a nice > to have for SR1. Sounds good. We will put that on our short list :-)
It is looking good in the latest build! I only found one minor remaining nit which I tracked on bug 349028 to fix it for SR1. Thanks everyone for helping to make this happen!
