Liferay Control Panel Plugin for Vaadin 7

Vaadin 6 / 7 / 8
1

Hi,

first development version of a Vaadin 7 compatible Liferay Control panel plugin is now
available in GitHub
. It’s still under heavy development and
should not be installed in production systems
.

It should be okay to install this version side-by-side with the old control panel plugin, but
multiple Vaadin versions per Liferay are not yet supported
. It means that you can’t leave the old version 6 vaadin.jar nor its widgetsets / themes installed in Liferay’s ROOT context.

Happy hacking!

w/ BR, Mikko

2

10x a lot for the efforts!
Lack of this plugin is one of the reasons we are still using vaadin 6.

3

The URL, http://vaadin.com/download/VERSIONS_ALL?source=liferay&version=@VERSION@, does not list any versions higher than 7.0.0. So 7.0.1, 7.0.2, all nightly and prerelease of said versions, are all missing.

Not necessarily a bug in the code, but a bug in the vaadin.com website certainly. Could be related to the move to git, but not sure…

4

In it’s current form, it can’t be used in any systems…

I’m running 6.1.1 GA2 plus the LCE patches, and I get the same error for the control panel (which isn’t anymore since it’s missing the liferay-portlet.xml file, but hey, it’s still in dev) that I mentioned
here
.

5

There are some known issues (mainly in the build process) and the team is working hard to get those fixed, so please be patient :slight_smile: Actually it should already run on vanilla Liferay 6.1.1 (ce-ga2), but if that’s not the case, I recommend you to wait until the dev team pushes next version(s) to GitHub. I’ll post updates to this forum as soon as we get more information about the situation.

6

The version updater implementation will be changed before release of 1.0, most probably so that Vaadin / dependency jars will be fetched from a Maven repository.

7

Replacing VERSIONS_ALL with VERSIONS_7 currently gives the versions available in Maven repositories.
VERSIONS_ALL only contains directly downloadable single-JAR versions if I remember correctly.

8

Well, it’s this URL that is used to populate the versions in the control panel. I’m not sure the current implementation (still under development) knows that it needs to switch up the version that way, just noticed the missing artifacts…

9

The VCP allows for switching between many different versions, including nightly and pre-release. Personally I never use these guys, but I guess it comes back to whether the current V6CP functionality will continue to be supported going forward.

10

Will VERSIONS_7 or maybe another file contain the same format as VERSIONS_ALL? I mean [release type]
, [version]
[url for download ]
to support prerelease and nightly builds?

11

FYI Mikko, the vaadin-client-compiler.jar file cannot be put into Liferay’s ROOT/WEB-INF/lib directory. The jar contains a bunch of dependency stuff that conflict w/ Liferay’s ability to compile and use JSPs based upon the JSTL.

I’d suggest following the V6 method of using a separate folder in ROOT/WEB-INF for this and the vaadin-client jar (V6 has a separate folder in WEB-INF for the GWT dependencies).

The V7 widgetset compile would need to include the jars for compiling the widgetset, but they cannot be part of WEB-INF/lib or they will cause failures…

12

Yes, this bug has been fixed and will be included in the next version.

13

Dave, thanks for your advice on Liferay classpath issues. As Igor already mentioned, those should already be fixed in the current development branch, which will be merged to the main branch within few days. Meanwhile I’ve made some minor changes to the project structure and build process so that it should now work on a clean Liferay instance (I’ve tested w/ 6.1.1-ce-ga2). If you wish, you can review those changes already in my GitHub fork: https://github.com/mtaivai/liferay-vaadin-plugin

14

Noticed the change for latest version URL is now http://vaadin.com/download/release/7.0/LATEST?source=liferay&version=@VERSION@.

What happens when Vaadin 7.1 comes out? Will that require a separate VCP that knows about the new link?

This isn’t really a jib against you, Mikka, or Igor. I know you’re working w/ what you’re given…

This really is something that the Vaadin.com site should figure out and square away.

15

FYI, another bug from the old version that has been carried forward into the newer version…

com.arcusys.liferay.vaadinplugin.util.WidgetsetCompiler.getJava() method assumes that the code is running on a Unix system.

The method should actually be something like:


private String getJava() {
  String javaHome = System.getenv("JAVA_HOME");
  String path = javaHome + "/bin/java";

  File file = new File(path);
  if (file.exists()) return path;

  path = path + ".exe";
  file = new File(path);
  if (file.exists()) return path;

  return "java";
}
16

Thanks for reporting. We’ve been testing mainly in Mac / Ubuntu environments (since those are what we use), but of course we need to support Windows as well. But you know the famous Java slogan "Write Once,
Debug Everywhere
"…

17

A couple of other things…

I like what you guys did for pulling the available versions as it should make the code handle future versions correctly (i.e. the future 7.1). I would suggest, however, caching the patterns, matchers, and DateTimeFormatter in the LinkParser rather than re-creating them for every call.

Also I noticed that you’ve replaced the natural “/” separator for file systems with File.SEPARATOR. This should not be necessary because java should handle it correctly on the platform being used (i.e. on a Windoze system it should automagically treat “/” as "").

18

Here’s another one…

com.arcusys.liferay.vaadinplugin.ControlPanelUI.WarningWindow.isVaadinPortlet() looks like it is still coded for V6. V7 portlets would use the com.vaadin.server.VaadinPortlet class.

19

Thanks for the advice on caching patterns, I agree that it could improve the performance in some conditions. You’re right about the file separator, but otoh, although “/” would work on Windows platforms, it’s more convenient for sysadmins and users if we use platform’s native separator (i.e. File.SEPARATOR). Some paths are actually displayed in logs and even in the UI and I think Igor is following a good practice in here (altough it makes the code just a little bit more vebose).

By the way, you can use public GitHub issue tracker to file findings and / or feature requests: https://github.com/arcusys/liferay-vaadin-plugin/issues.

20

Thanks for reporting this. I created a bug report here: https://github.com/arcusys/liferay-vaadin-plugin/issues/10