Giter Site home page Giter Site logo

eclipse-plugin's People

Contributors

ahie avatar alvarezguille avatar anssit avatar artur- avatar emarc avatar enver-haase avatar hesara avatar johndevs avatar jouni avatar juusovalli avatar makoivis avatar mstahv avatar ollitietavainenvaadin avatar szolo avatar tanbt avatar tatulund avatar tsuoanttila avatar zch avatar zhesun88 avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

vdussault denis-anisimov makoivis nicolasdmit afiller yixiaotian clkj1989 alejandro-du

eclipse-plugin's Issues

The widgetset should be built automatically

Reported by Artur Signell on 22 Oct 2009 10:40 UTC
Currently there is a popup asking "Do you want to build" when you add a jar to the project. If you edit widgets in the project you must build the widgetset manually using the build icon in the toolbar. This is not nearly the optimal solution. What options do we have? I would say most commonly you want to build the widgetset before/when:

  • Exporting the project
  • Publishing the project to a server
  • At any random time (still provide the build button for this)
    Exporting the project (to a Directory package) is done using the exporter (#3572) so it should be easy to hook into. For publishing there are probably extension points that can be used.

Comments or better solutions?

The widgetset should be built when exporting a WAR

Reported by Henri Sara on 4 Nov 2009 12:12 UTC
The user should be asked if he wants to recompile the widgetset when exporting a WAR file and the widgetset is dirty.

This was split off from #3573, where a similar feature was added when publishing a project to a server.

Use human-readable labels for GWT compilation style selection

Reported by Joonas Lehtinen on 6 Nov 2009 12:48 UTC
Now there are three JavaScipt styles to chosse from in the eclipse plugin. Maybe we should call the first one OBFUSCATED instead of OBF (Even though GWT calls it OBF). Why? OBF might be quite confusing if you are not familiar with GWT compiler command line options already (and I am sure, most of the users are not).

Vaadin plug-in does not install to latest "Eclipse IDE for Java Developers" package

Reported by Jani Laakso on 25 Oct 2009 08:45 UTC
I am using Eclipse IDE for Java Developers, Build id: 20090920-1017. See http://www.eclipse.org/downloads/ and from there the second Eclipse bundle called "Eclipse IDE for Java Developers (91 MB)". Verified that Vaadin plug-in cannot be installed to this package, see attached image.

I have not customized my Eclipse in any way, except that subclipse is installed. I run and debug my Vaadin applications using Eclipse's "Run as" and "Debug as" and Eclipse automatically executes my applications using the integrated Eclipse Servlet Container (http://www.eclipse.org/jetty/). Every (Java) Eclipse contains integrated Servlet Container. No separate installation of e.g. Tomcat is required and configuration in Eclipse.

My "Eclipse IDE for Java Developers" contains "Eclipse Web Tools Platform" (WTP Version: 3.1.1.v200907161031-7H6FM_DxtkM-7aeTHKEBbQqcZOZ2) but it does not contain org.eclipse.jst which is a requirement for Vaadin Eclipse Integration for a reason that I do not understand.

Not all people wish to download "Eclipse IDE for Java EE Developers (188 MB)". Plain Java version is faster and more "responsive" to use for the end user. JEE version is also bloated with many features that people cannot disable and do not wish to use.

If org.eclipse.jst is absolute requirement and Eclipse's standard Servlet Container cannot be used now for some reason, then mention to end users that they need to download Eclipse JEE version to ensure that Vaadin Plug-in installs. Do this both in our web pages and the manual.

Update Eclipse plugin facet version

Reported by Henri Sara on 1 Oct 2009 10:11 UTC
The facet version of the Vaadin facet should be 1.0, not 0.1 .

The plugin should support changing the facet version for old projects, and new projects should automatically use the new version.

The old version 0.1 can be removed (leading to warnings on the project facets page but full functionality) or still included in the plugin.

Old project compatibility

Reported by Artur Signell on 22 Oct 2009 11:09 UTC
Updating old projects MUST work seamlessly. Current problems:

  • Updating an old project to 6.2.0.nightly will cause it not to compile: "Select a widgetset file or a Vaadin project to compile". This even though the project is selected.
  • Updating to 6.2.0.nightly before upgrading to the new plugin version will not enable the Vaadin builder for the project. The build button should check if the Builder is enabled and if it is not, enable it. Also it should upgrade the facet version to 1.0 to avoid future problems.

Plan OOPHM support for Eclipse plugin

Reported by Joonas Lehtinen on 25 Oct 2009 19:09 UTC
Now use of OOPHM requires manual replacement of GWT jar:s in buildpath, rebuilding widgetset with OOPHM version of the compiler and manually configuring OOPHM launch config. This should not be this hard. Maybe eclipse plugin could make this simpler...

Plugin should be signed (experimental and release)

Reported by Artur Signell on 5 Oct 2009 08:09 UTC
The newest Eclipse version Galileo SR1 complains that plugins (Vaadin and others) are not signed. Check what it would require to sign the plugins and get rid of the warning.

Plug-in brakes Project Explorer view, contains duplicate items

Reported by Jani Laakso on 3 Nov 2009 22:12 UTC
See attached picture.

  1. Created new Vaadin Project called MyWidget
  2. Created new Widgetset
  3. Created new Widget

I'm using Eclipse Java EE IDE for Web Developers. Build id: 20090920-1017

=> See duplicates attached image (Project Explorer view)

As I side note: I saw same kind of behavior with plain "Create new Vaadin project" in a customer's machine. He did not use Widget(set) wizards at all.

Maybe this is a bug in Eclipse?

Customer was using Eclipse JEE (Windows platform) too..

Should the liferay-plugin-package.properties file be created for portlets?

Reported by Teemu Pontelin on 7 Oct 2009 08:20 UTC
Currently the Eclipse plugin doesn't create the liferay-plugin-package.properties file for portlet projects.

Should this file be created and should it automatically contain a dependency to the vaadin.jar? If I understood correctly, this is the correct way of defining a dependency to Vaadin.

...
portal-dependency-jars=\
    vaadin.jar
...

Add mapping for /VAADIN/* to web.xml in portlet projects

Reported by Artur Signell on 8 Oct 2009 09:38 UTC
If Vaadin is not integrated into the Liferay portal then the widgetset is not found as only "/MyServlet/" is mapped to the servlet. The portlet tries to load the widgetset from "/portletcontextpath/VAADIN/" so a mapping for "/VAADIN/" must be added to web.xml (when creating a portlet).

This also enables deploying the portlet project to a servlet container without modifications.

If Vaadin is integrated into the portal then this extra mapping is just never used.

Better icon for compiling widget set

Reported by Marko Gronroos on 10 Nov 2009 15:15 UTC
I suppose the button with the Vaadin logo is not the final?

I need a more final button for taking a screenshot.

Document how to use OOPHM libraries with the widgetset builder

Reported by Artur Signell on 22 Oct 2009 10:47 UTC
Until GWT 2.0 arrives we must provide documentation for how to use our OOPHM packages with the widgetset builder. This is very critical as OOPHM is the only way to debug widgets on certain platforms. It should be documented somewhere in the plugin where people find it, not hidden in a wiki.

datanucleus-appengine-1.0.3.jar twice in classpath with Vaadin & GAE Ecplise Plugins

Reported by Sami Ekblad on 4 Nov 2009 21:56 UTC
Vaadin Eclipse Plugin configures automatic include from all jar files from WEB-INF/lib. This mixes up classpath with GAE plugin (more precisely DataNucleus Enhancer) that adds the jar there, but does not include it to classpath.

At least then using any JDO classes an exception like this is generated:

java.lang.RuntimeException: Unexpected exception
at com.google.appengine.tools.enhancer.Enhancer.execute(Enhancer.java:59)
at com.google.appengine.tools.enhancer.Enhance.(Enhance.java:60)
at com.google.appengine.tools.enhancer.Enhance.main(Enhance.java:41)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.google.appengine.tools.enhancer.Enhancer.execute(Enhancer.java:57)
... 2 more
Caused by: org.datanucleus.exceptions.NucleusException: Plugin (Bundle) "org.datanucleus.store.appengine" is already registered. Ensure you dont have multiple JAR versions of the same plugin in the classpath. The URL "file:/Applications/eclipse/plugins/com.google.appengine.eclipse.sdkbundle_1.2.6.v200910131704/appengine-java-sdk-1.2.6/lib/user/orm/datanucleus-appengine-1.0.3.jar" is already registered, and you are trying to register an identical plugin located at URL "file:/Users/sganyo/dev/workspace/pt/war/WEB-INF/lib/datanucleus-appengine-1.0.3.jar."

This makes it impossible to create any Google App Engine / JDO project using the Vaadin Plugin without first manually re-configuring the project classpath.

See also discussion here: http://vaadin.com/forum/-/message_boards/message/76408

Workaround is to remove automatic addition of WEB-INF/lib ("Web App Libraries" class path entry) and add Vaadin jar files from there separately to classpath.

One fix would be that if GAE deployment is selected when creating the project, the plugin should leave out the "Web App Libraries" classpath entry (and add Vaadin jar as separate entry). This is what effectively must be currently done as manual workaround.

Exception when changing Vaadin jar versions

Reported by Artur Signell on 1 Oct 2009 13:23 UTC
On the first attempt to change jar version (in project properties) from 6.1.1 to 6.1.nightly-20090930-c8998.jar I got:

java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421)
at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507)
at com.vaadin.integration.eclipse.properties.VaadinVersionPropertyPage.performOk(Unknown Source)
at org.eclipse.jface.preference.PreferenceDialog$13.run(PreferenceDialog.java:964)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.runtime.Platform.run(Platform.java:888)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
at org.eclipse.jface.preference.PreferenceDialog.okPressed(PreferenceDialog.java:944)
at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.okPressed(FilteredPreferenceDialog.java:453)
at org.eclipse.jface.preference.PreferenceDialog.buttonPressed(PreferenceDialog.java:233)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.dialogs.PropertyDialogAction.run(PropertyDialogAction.java:157)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Caused by: org.eclipse.jdt.internal.core.ClasspathEntry$AssertionFailedException: Library path cannot be null
at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:4034)
at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:3917)
at org.eclipse.jdt.launching.JavaRuntime.newArchiveRuntimeClasspathEntry(JavaRuntime.java:628)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateLaunchClassPath(Unknown Source)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateLaunchClassPath(Unknown Source)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateVaadinLibraries(Unknown Source)
at com.vaadin.integration.eclipse.properties.VaadinVersionPropertyPage$1.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Root exception:
org.eclipse.jdt.internal.core.ClasspathEntry$AssertionFailedException: Library path cannot be null
at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:4034)
at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:3917)
at org.eclipse.jdt.launching.JavaRuntime.newArchiveRuntimeClasspathEntry(JavaRuntime.java:628)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateLaunchClassPath(Unknown Source)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateLaunchClassPath(Unknown Source)
at com.vaadin.integration.eclipse.util.VaadinPluginUtil.updateVaadinLibraries(Unknown Source)
at com.vaadin.integration.eclipse.properties.VaadinVersionPropertyPage$1.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

On the second attempt (just clicking ok again) it went fine.

Widgetset compiler should search non-vaadin GWT modules better

Reported by Matti Tahvonen on 23 Oct 2009 06:50 UTC
Currently seeks web-inf/lib jars and uses jar file if it contains gwt modules (.gwt.xml files).

It should not be necessary to add inherited gwt modules to web-inf/lib (like gwt-maps.jar). Adding manually to build path should be enough.

Seeking for modules may become slow in large projects (needs to seek all files in all jar files for .gwt.xml files). Consider just adding possibility to define them manually.

The unnecessary extra level in the project preferences page should be removed

Reported by Jonatan Kronqvist on 27 Oct 2009 12:47 UTC
Currently the eclipse plugin has a main view in the project preferences which just states to open the tree to access settings. When opening the tree, however, there is only one view with settings (which version of Vaadin to use).

These should, IMO, be merged to allow for a better user experience.

Eclipse plug-in should default to Java 1.5 Facet

Reported by Jani Laakso on 3 Nov 2009 12:57 UTC
Users should not be required to downgrade their Facet from 1.6 to 1.5 just to make class compatibility from 1.6 to 1.5.

Could "Create Vaadin Project" with Portlet option on default to 1.5 instead of 1.6?

Nightly version list is too long

Reported by Artur Signell on 22 Oct 2009 11:19 UTC
The nightly version list is confusing as it contains too many items. Filtering out all but the latest nightly by default would be a way of shortening the list. It should still be possible to find an older nightly version though.

Vaadin plug-in more easier with Eclipse integrated Servlet Container

Reported by Jani Laakso on 25 Oct 2009 11:08 UTC
Idea how to enhance Vaadin experience for newbies. All Eclipse's include Servlet Container, there is no need to download Tomcat and configure it.

Perhaps Vaadin plug-in could use the Launcher.java code below like this:

  • either plug-in adds Launcher.java to end-user project's src path
  • or plug-in adds launch configuration which executes vaadin/src/com/vaadin/launcher/Launcher.java

This would make even simpler for the newbies to try out Vaadin as no Tomcat installation and configuration is required and Plug-in works without org.eclipse.jst requirement (works with other Eclipse packages aswell).

For now, this is the only "nuisance" for the end-user that is required to use integrated Eclipse Servlet Container, user needs to add single Java class to their project, such as this:

import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.nio.SelectChannelConnector;
import org.mortbay.jetty.webapp.WebAppContext;

public class MyAppLauncher {

    private static String context = "/MyContext";
    private static String webroot = "WebContent";
    private static int httpPort = 8080;

    public static void main(final String[args) throws Exception {
        final Server server = new Server();
        final Connector connector = new SelectChannelConnector();
        connector.setPort(httpPort);
        server.setConnectors(new Connector[](]) { connector });
        final WebAppContext webappcontext = new WebAppContext();
        webappcontext.setClassLoader(MyAppLauncher.class.getClassLoader());
        webappcontext.setContextPath(context);
        webappcontext.setWar(webroot);
        server.setHandler(webappcontext);
        server.start();
    }
}

I even think this would be more closer to our ideology "Do all in Java", even Servlet Container configuration. Developer has a better feeling of more control in Servlet Container too. Whereas Tomcat container uses XML files that need to be modified if context, webroot or http port is changed, but of course Eclipse WST contains tools to configure these using Eclipse so people do not actually see XML here, but it doesn't change the fact that Tomcat is more complex. Using Tomcat requires more steps, this is a pain for most newbies.

Check out also latest Eclipse wiki: http://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty

Projects not located in workspace dir cannot be compiled

Reported by Matti Tahvonen on 29 Oct 2009 08:58 UTC
If project is in workspace, but project directory does not locate in workspace folder, widgetset compilation does not work. Utility method gives invalid paths as classpath.

Parameters for the widgetset builder

Reported by Artur Signell on 22 Oct 2009 10:27 UTC
It must be possible to give parameters to the widgetset builder.
Most important currently would be "style" to enable building of non-obfuscated widgetsets.

Create a widgetset exporter

Reported by Artur Signell on 22 Oct 2009 10:37 UTC
The jar export function in Eclipse is very confusing. Additionally there is no good way to specify the metadata using that and editing the manifest by hand is tedious.

Create a simple widgetset exporter that offers

  • A file selector
    • Pre-select the most common values, i.e. src+classes
  • A manifest editor for the Vaadin attributes
    • Manifest file
      • The user can select a MANIFEST.MF to use if he has other metadata
      • Otherwise the default is /META-INF/MANIFEST.MF
      • Changing manifest values in the editor updates the manifest file in the project.
      • No pre-existing data must be removed from the manifest
      • Existing Vaadin-attributes are used as defaults in the editor

Create New Widgetset wizard has "Source folder" empty

Reported by Jani Laakso on 4 Nov 2009 09:59 UTC
See attached picture. Do not know what happens this but workaround was to hit "Browse..." and select "Project/src" folder, then all the other fields were filled aswell.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.