New Eclipse Plugin Release 1/7/2014

RokuBradO · November 12, 2013, 11:04pm

A new update to the BrightScript Eclipse Plugin is available via the updates site:
http://rokudev.roku.com/updates/

The build number is: 1.0.0.201312101034

The full Eclipse Plugin Guide can be found here:
http://sdkdocs.roku.com/display/sdkdoc/ … ugin+Guide

Release Notes 1/7/2014:
Minor Bug Fixes with BrightScript Doc parser.

Release Notes 11/12/2014:

Support for the new developer mode username/password authentication is in place, but is not used unless a given Roku box requires it ( i.e. firmware 5.2 or later ).

It is important to note that the plugin now requires Eclipse to be running under Java 1.7 or higher. If Eclipse’s Java version is lower than 1.7, the plugin will be disabled.
Non-compliance with the Java version requirement does not prevent plugin installation or Eclipse startup, but will result in no BrightScript plugin features being visible, including the BrightScript perspective.
If you require an older version of Java as your machine default, you may still point any Eclipse instance to a different Java installation, by using the -vm argument in the eclipse.ini file (see Eclipse’s help for details).

The following items were added or fixed in this release:

Enhancements:

Export Wizard - Added option to automatically open and connect a debug console upon successful install
Code Folding - Added support for anonymous functions

Bugfixes:

Bug fixes to correct exceptions and errors in SSDP discovery routines
Export Wizard - Corrects issue of zip and pkg files saved in “out” dir first time, but root dir all subsequent times
Export Wizard - Corrects issue where current package field is not populated even if there is a current package

vbacct · November 26, 2013, 11:19pm

I am unable to find the bright script perspective when I do windows->open perspective->other. I have the Eclipse Juno SR1 installed, also installed the BrightScript plugin along with these two dependencies http://download.eclipse.org/modeling/em … /releases/ and http://download.eclipse.org/technology/dltk/updates/, and I have the Java 1.7 version. The BS plugin gets installed without any error, but the BS perspective is missing. I just updated the mac OS to 10.9. Eclipse with BrightScript plugin was working fine with the older version of the mac OS. Any help is appreciated.

malloys · November 26, 2013, 11:52pm

“vbacct” wrote:
I am unable to find the bright script perspective when I do windows->open perspective->other. I have the Eclipse Juno SR1 installed, also installed the BrightScript plugin along with these two dependencies http://download.eclipse.org/modeling/em … /releases/ and http://download.eclipse.org/technology/dltk/updates/, and I have the Java 1.7 version. The BS plugin gets installed without any error, but the BS perspective is missing. I just updated the mac OS to 10.9. Eclipse with BrightScript plugin was working fine with the older version of the mac OS. Any help is appreciated.

Just a guess at this point, but it’s likely you installed java 1.7 first, then upgraded to OSX 10.9. If so…
Since apple doesn’t yet distribute java 1.7 themselves, you inadvertently downgraded java to 1.6 when you upgraded OSX to 10.9 (which would cause the BrightScript plugin to be disabled since it requires java 1.7).

To confirm:

run the terminal program, and type java -version.

…or more definitively (since eclipse can use a java install that’s different from the system default)…

Look at eclipse’s internal configuration dump ( Help->About Eclipse->Installation Details->Configuration ) and look for the java.version value.

If (2) says it’s some variant of 1.7, my guess was wrong and so we’ll look for other causes. Otherwise, get the JDK package from here: http://www.oracle.com/technetwork/java/javase/downloads/index.html and re-install java 1.7.

Cheers

vbacct · November 27, 2013, 1:10am

Thanks Malloys! That was the problem, Eclipse was still pointing to 1.6 though I had installed the 1.7. Reinstalled the 1.7 and restarted the IDE and everything looks fine now.

partyk1d24 · December 26, 2013, 10:15pm

I am trying to startup and I believe I am using Kepler w/ Java8EA. I get the following;

java.lang.NullPointerException
at com.roku.brightscript.ide.eclipse.core.model.ast.typedexpressions.BrightScriptTypeReference.(BrightScriptTypeReference.java:16)
at com.roku.brightscript.ide.eclipse.core.model.ast.BrightScriptASTTranslator.exitArgType(BrightScriptASTTranslator.java:359)
at com.roku.brightscript.parser.BrightScriptAnalyzer.exit(BrightScriptAnalyzer.java:1219)
at net.percederberg.grammatica.parser.Parser.exitNode(Parser.java:540)

Any ideas? I tried uninstall/reinstall.

malloys · December 30, 2013, 2:35am

“partyk1d24” wrote:
I am trying to startup and I believe I am using Kepler w/ Java8EA.

There’s the likely cause of your problem.
The “EA” in “Java8EA” stands for early access. So that’s effectively alpha/beta, and not a production-ready release of Java.
And… Eclipse doesn’t officially support Java 8 yet. There is an early access download with preliminary Java8 support - but again, that’s not considered production ready.
Nevertheless… I’m just curious - did you download that and install that?

In any case, the BrightScript plugin is only supported on platforms/environments that Eclipse has tested on as part of their official production releases.
Anything outside of that, and YMMV.

I’d suggest installing the current production release of java 1.7 and pointing eclipse (production release Kepler) to that java instance instead.

Cheers

partyk1d24 · January 1, 2014, 5:24pm

First thanks for your response.

The “EA” in “Java8EA” stands for early access. So that’s effectively alpha/beta, and not a production-ready release of Java.
And… Eclipse doesn’t officially support Java 8 yet.

I was posting because I thought it might be useful to keep track of issues and I couldn’t find the issue repo. Also just because it isn’t officially supported doesn’t mean it doesn’t work. I have been developing all kinds of things (JAX-WS/RS Websphere apps, Android apps, etc) with no problems. Also this is the only error I get when starting up, so all those other plugins (WAS Developer tools, etc) seem to avoid this issue. Again just thought it would help to bring this up I apologize if there was an issue list I missed.

There is an early access download with preliminary Java8 support…did you download that and install that?

No but I am really not sure it is needed unless you are using the actual Java8 jre for your project. Again in my experience everything seems to work fine.

In any case, the BrightScript plugin is only supported on platforms/environments that Eclipse has tested on as part of their official production releases.
Anything outside of that, and YMMV.

Right I get that but this is the developer forum right? Not the support forum? That may sound sarcastic (it isn’t meant to) but I am serious about trying to make the community better and just want to make sure I am posting in the right area. I also get that YMMV but that is why I am bringing it to the attention of people. I mean one day Eclipse will fully support Java8 and the problem will probably still be there. Also the plugin still functions, so it is probably a menial change, I would be happy to look into it if the plugin code is out there somewhere.

malloys · January 1, 2014, 9:18pm

“partyk1d24” wrote:

I was posting because I thought it might be useful to keep track of issues and I couldn’t find the issue repo.
…
Again just thought it would help to bring this up I apologize if there was an issue list I missed.

Unfortunately, there currently is no publicly exposed bug tracking system.
So, this is the right place to bring up issues.

I’ve noted in older developer forum threads that the BrightScript plugin is only supported under the environments listed in Eclipse’s production release target environment matrices, but perhaps we should add that information to the Eclipse plugin guide in the SDK docs for clarity.

“partyk1d24” wrote:

There is an early access download with preliminary Java8 support…did you download that and install that?

No but I am really not sure it is needed unless you are using the actual Java8 jre for your project.

Probably right, but hard to say for sure without combing through the embodied code changes and additions (which I have not done). It’s entirely possible that the early access download includes changes/additions to the core Eclipse platform, not just the java language support elements in the JDT.
In any case, I was just asking about your environment to quickly see if that download could be eliminated as a potential workaround.

“partyk1d24” wrote:

I am serious about trying to make the community better and just want to make sure I am posting in the right area.

That’s appreciated, and yes, this is the right place to post for discussing eclipse plugin issues.

“partyk1d24” wrote:

…one day Eclipse will fully support Java8 and the problem will probably still be there.

Not necessarily.
We’ve seen numerous apparent plugin issues in the past that were ultimately caused by bugs in Eclipse, the dependent plugins (DLTK, EMF), and specific minor releases of the JRE.
Between here and official support by Eclipse of JRE8, it’s likely JRE8 specific bugs in Eclipse and/or DLTK will get fixed, which in turn may eliminate upstream manifestations in 3rd party plugins, such as BrightScript. For the BrightScript plugin, it’s happen before.

Note, I’m not stating definitively that what you are experiencing is a JRE8 related bug. But the first step in tracking down the source of the problem is eliminating the unsupported environment.
The fact that you haven’t seen problems in other eclipse plugins running under jre8 so far is great, but that’s a black swan argument - it doesn’t prove the JRE version you are using isn’t the source of the problem.

“partyk1d24” wrote:

Also the plugin still functions, so it is probably a menial change,

Again, that would assume this is a bug in the plugin, which hasn’t been established.
If you run your eclipse instance in a supported environment - for Eclipse 4.3 (aka Kepler), see: http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments ( but upgraded to 1.7 for any O/S that lists JRE 1.6 ), and you still have the same issue, I’d be happy to continue working with you to track down the source of the problem.

“partyk1d24” wrote:

I would be happy to look into it if the plugin code is out there somewhere.
Thanks for the offer, but the plugin isn’t an open-source project at present. It’s maintained as Roku-owned code in a company-internal repo.

Cheers

ludwig_benitez · January 9, 2014, 5:07am

“malloys” wrote:

“vbacct” wrote:
I am unable to find the bright script perspective when I do windows->open perspective->other. I have the Eclipse Juno SR1 installed, also installed the BrightScript plugin along with these two dependencies http://download.eclipse.org/modeling/em … /releases/ and http://download.eclipse.org/technology/dltk/updates/, and I have the Java 1.7 version. The BS plugin gets installed without any error, but the BS perspective is missing. I just updated the mac OS to 10.9. Eclipse with BrightScript plugin was working fine with the older version of the mac OS. Any help is appreciated.

Just a guess at this point, but it’s likely you installed java 1.7 first, then upgraded to OSX 10.9. If so…
Since apple doesn’t yet distribute java 1.7 themselves, you inadvertently downgraded java to 1.6 when you upgraded OSX to 10.9 (which would cause the BrightScript plugin to be disabled since it requires java 1.7).

To confirm:

run the terminal program, and type java -version.

…or more definitively (since eclipse can use a java install that’s different from the system default)…

Look at eclipse’s internal configuration dump ( Help->About Eclipse->Installation Details->Configuration ) and look for the java.version value.

If (2) says it’s some variant of 1.7, my guess was wrong and so we’ll look for other causes. Otherwise, get the JDK package from here: http://www.oracle.com/technetwork/java/javase/downloads/index.html and re-install java 1.7.

Cheers

I’m tried this, but not found a solution. I installed the version JavaSE7 (JDK y JRE), but eclipse still says “java.version = 1.6.0_65”. I can’t change the version of java in eclipse : ( . Please, excuse my bad english. : (

malloys · January 9, 2014, 6:01am

“ludwig.benitez” wrote:
I installed the version JavaSE7 (JDK y JRE), but eclipse still says “java.version = 1.6.0_65”. I can’t change the version of java in eclipse : ( . Please, excuse my bad english. : (

Sounds like either your machine is not pointing to the new java installation as the default, or your eclipse.ini file has a -vm argument in it that points to java 1.6.

If you open up a terminal window and type: java -version, What do you see?
if you open up your eclipse instance’s eclipse.ini file, do you see a -vm argument value? If so, what is it?

malloys · January 14, 2014, 7:11am

OK, the only remaining possibilities I’m aware of are either:

a) You are launching eclipse with a -vm command line argument that points to a java 1.6 installation
..or…
b) At sometime in the past, someone has installed a 1.6 jre or jdk in a sub-dir under eclipse’s root directory named “jre”.

You may want to take a look at this for reference: http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F#Find_the_JVM

Cheers

EnTerr · March 27, 2014, 8:23pm

“malloys” wrote:
Not trying to hijack the thread but I can’t resist responding…

“NewManLiving” wrote:

No problem except from time to time I have to re-enter the ip address in the deployment wizard (don’t know if this is intentional or just a bug).
That’s probably not a bug, but I’d need to know more details to be 100% sure (add to the semi-permanent eclipse plugin thread if the explanation below doesn’t jibe what you’re seeing).
The IP address combo (in both the deployment wizard and the debug console) gets it’s list from a SSDP listener background thread.
Addresses that haven’t been heard from since their SSDP timeout expired are periodically purged from the list.
Any IP address that you manually enter has a timeout of 20 minutes - If that Roku box does an SSDP broadcast before the initial 20 minute timeout is up, the thread updates the timeout as specified by the SSDP broadcast (and the cleanup process is delayed on subsequent eclipse sessions to give the boxes enough time to do their SSDP broadcasts again).
To me the behavior you described - expiring the IP after timeout - is a bug. It will cause problems when IP multicast does not work in the network and there are routers that do that (i know that from experience). The solution is to stop over-doing it, i.e. do not expire IP, ever.

What’s the worst that can happen if plugin keeps outdated IP - deployment will fail (and developer gets a chance to update IP). If receiving multicast, do update the IP - so getting best of both (network) worlds. I presume you are matching IP to serial number? - that part takes care of “removing” old IP when new IP for specific player is heard of.

malloys · March 27, 2014, 11:53pm

“EnTerr” wrote:

“malloys” wrote:
Not trying to hijack the thread but I can’t resist responding…

“NewManLiving” wrote:

No problem except from time to time I have to re-enter the ip address in the deployment wizard (don’t know if this is intentional or just a bug).
That’s probably not a bug, but I’d need to know more details to be 100% sure (add to the semi-permanent eclipse plugin thread if the explanation below doesn’t jibe what you’re seeing).
The IP address combo (in both the deployment wizard and the debug console) gets it’s list from a SSDP listener background thread.
Addresses that haven’t been heard from since their SSDP timeout expired are periodically purged from the list.
Any IP address that you manually enter has a timeout of 20 minutes - If that Roku box does an SSDP broadcast before the initial 20 minute timeout is up, the thread updates the timeout as specified by the SSDP broadcast (and the cleanup process is delayed on subsequent eclipse sessions to give the boxes enough time to do their SSDP broadcasts again).
To me the behavior you described - expiring the IP after timeout - is a bug.

It will cause problems when IP multicast does not work in the network and there are routers that do that (i know that from experience).

OK, that surprises me - can you list any of those routers?
While I have no doubt a router admin can configure a router to block UDP multicast traffic, I’m unaware of any routers commonly in use that don’t correctly support UDP multicast traffic.
As an extension, I’m also unaware of any common and logical reason to configure a router to block all SSDP specifically (and plenty of reasons why you shouldn’t). If you can think of any, can you cite specific real-world examples?

“EnTerr” wrote:

The solution is to stop over-doing it, i.e. do not expire IP, ever.

What’s the worst that can happen if plugin keeps outdated IP - deployment will fail (and developer gets a chance to update IP).

The reason for removing expired entries is to prevent increasingly polluting the list over time with outdated addresses.
Unless you’ve setup your environment so that your Roku Box(es) always have static or DHCP reserved IP addresses - which AFIK is not particularly common, the list is likely to have more than a few incorrect entries over time if there is no way of removing them.

The only other option for entry removal other than timeouts and automatic culling, is to add a mechanism for explicit manual removal of items from the list.
I’d be more than happy to file the latter as an enhancement request on behalf of anyone using the plugin that believes they need it (although a previous post in this forum strongly implies that you do not use the plugin and instead prefer to use an array of other more simple tools).

“EnTerr” wrote:

If receiving multicast, do update the IP - so getting best of both (network) worlds. I presume you are matching IP to serial number? - that part takes care of “removing” old IP when new IP for specific player is heard of.
My apologies for any confusion caused by my previous over-simplified explanation… The plugin has always used the serial numbers as the primary identifier when determining entry updates when the info is coming from SSDP broadcasts or explicit query responses. Manually entered IP addresses, if an SSDP broadcast is received from a box at that IP address before the timeout , are replaced with the expanded info from the SSDP broadcast (including the new timeout).

cheers

EnTerr · March 28, 2014, 1:06am

“malloys” wrote:
OK, that surprises me - can you list any of those routers?
While I have no doubt a router admin can configure a router to block UDP multicast traffic, I’m unaware of any routers commonly in use that don’t correctly support UDP multicast traffic.
As an extension, I’m also unaware of any common and logical reason to configure a router to block all SSDP specifically (and plenty of reasons why you shouldn’t). If you can think of any, can you cite specific real-world examples?
…
The reason for removing expired entries is to prevent increasingly polluting the list over time with outdated addresses.
Unless you’ve setup your environment so that your Roku Box(es) always have static or DHCP reserved IP addresses - which AFIK is not particularly common, the list is likely to have more than a few incorrect entries over time if there is no way of removing them.
…
My apologies for any confusion caused by my previous over-simplified explanation… The plugin has always used the serial numbers as the primary identifier when determining entry updates when the info is coming from SSDP broadcasts or explicit query responses. Manually entered IP addresses, if an SSDP broadcast is received from a box at that IP address before the timeout , are replaced with the expanded info from the SSDP broadcast (including the new timeout).

Intuitively i also did not expect problems but experience taught me otherwise. I have a Roku remote app with multiple tens of thousands of users and i have received multiple complaints for different home gateways. I investigated the issue over 2 years ago, so have no detailed recollection of all routers screwing the multicast pooch. Some examples i can easily copy&paste from the app description though:

“Remote for Roku” wrote:
There is no configuration needed, as long as your iOS device is WiFi-connected to the same network your Roku player is on. Notable exception are some Qwest/Actiontec routers (e.g. PK5000, M1000, MI424WR, GT701WG, GT724WG), which do not support auto-discovery protocol - …It is not about intentional blocking - rather i think multicast had issues with wireless (i think that was the case in a Netgear one, where multicast worked on Roku wired but not wifi). If you think about it, there could be no datagram broadcast nor multicast as a single packet over the radio because of WAP security; since each client encrypts differently, so router has to send separate packets to each client individually. If you have contacts with whomever writes the remote apps in RokuCo, you can ask them for their experience; they have gone to such lengths in distrusting autodiscovery as to store the list of player IPs for the account on central server.

You said S/N is used as primary key => therefore when particular Roku changes its IP, the new IP will knock the old IP off the list. There will be no case of “increasingly polluting the list over time with outdated addresses” if no expiration.

EnTerr · March 28, 2014, 10:18am

We live in imperfect (networking) world. I object to this:> “malloys” wrote:

… I know of no routers that remove support for SSDP or multicast in general.How about google-ing a little, here is Sonos listing routers with multicast issues, here is Chromecast and HDHomeRun - both give work-arounds for most routers - yet both list SMCD3GNV as hopeless (“broken and will block this traffic regardless of what configuration options are set”).

If you want to dig the Actiontec case, i seem to recollect now that to have that configurable setting in UI, one had to have the right firmware - and that had to be pushed by Qwest, since PK5000 being DSL combo is provisioned by the ISP. Which Qwest would not do at the time. Chromecast Help puts it vaguely: “ActionTec Routers may not support the multicast protocol, which your network must have to detect your Chromecast. If multicast is available, you need to…”

“malloys” wrote:
Two problems with the “no expiration (or manual removal) needed” theory that result in orphans…

It assumes the dev never gets rid of any Roku boxes (sells, gifts, box gets fried, gets smashed against the wall in a fit of rage etc.).

It also assumes SSDP never temporarily fails/gets dropped on the floor
[…] so a busy/congested subnet means SSDP announcements sometimes don’t find their way to the dev box. When this occurs, the dev may choose to manually enter an IP address (which is now an entry without an S/N)
Case #1 is real. Case #2 is a straw-man: SSDP with new IP will have to get lost 3 times in a row (assuming current TTL of 60 mins and renewal every 20) and even then it will “magically” fix itself on the 4th (or N+1) time. But if network conditions are really so bad that multiple datagrams get dropped - that would mean you cannot trust “radio silence” to expire IPs. P.S. Oh i see S/N worried you, that’s real… but one can collect that from UPnP descriptor at http://IP:8060/

It seems clear - you really, really, really like the way you expire the IPs in your plugin and will rather people putz with router configurations or replace the router than change plugin behavior. “You can lead a horse to water, but you can’t make it drink” :?
That’s fine, i have no horse in the eclipse derby. And there are probably what - about hundred people? (3-digit number anyway) - using said plugin. The chance of encountering the issue is low and those are people you can ask to play with router config or replace it. It’s manageable. However, if you have tens of thousands of users to your app, that’s not the right approach - and if you have over a MILLION users (which is the case with RokuCo mobile apps), that’d be absurd. Oh, and the level of sophistication of those users is far removed from a developer’s, i can share as much.

gonzotek · March 28, 2014, 8:03pm

“malloys” wrote:

Excellent point - completely forgot that that info is available from the ECP/REST endpoint on the box.
BTW, is that documented somewhere? I remember accidentally discovering this a while back, but I don’t see it documented in the current ECP guide.
http://sdkdocs.roku.com/display/sdkdoc/ … ryProtocol
The serial is in the USN header(documented above, I know you’re aware of this, just including for future readers), as well as the returned XML. The UPnP docs describe the XML, see section 2.3 here: http://upnp.org/specs/arch/UPnP-arch-De … e-v1.1.pdf

malloys · March 28, 2014, 9:18pm

“gonzotek” wrote:

“malloys” wrote:

Excellent point - completely forgot that that info is available from the ECP/REST endpoint on the box.
BTW, is that documented somewhere? I remember accidentally discovering this a while back, but I don’t see it documented in the current ECP guide.
http://sdkdocs.roku.com/display/sdkdoc/ … ryProtocol
The serial is in the USN header(documented above, I know you’re aware of this, just including for future readers), as well as the returned XML. The UPnP docs describe the XML, see section 2.3 here: http://upnp.org/specs/arch/UPnP-arch-De … e-v1.1.pdf

Thanks for the links gonzotek.
To round it out for the reader:
What’s implied is that the UPnP device description endpoint is at the URL pattern: “http:<ip_address>:8060/”
So with a known IP address (however you get it - SSDP based discovery or not), you should be able to get the UPnP device description (XML in the body of the response) of any Roku box.
That port or URL pattern in general is not required by the UPnP spec, so it’s subject to change by Roku.

Within the returned UPnP device description is the device S/N value.
It should be noted that the UPnP spec states that S/N is recommended but not required, so Roku could in theory remove
the S/N value from the device description XML in the future and still be UPnP compliant.

And finally, with all the talk of device S/N and UPnP/SSDP, I just realized that I’ve been sloppy in talking about a key implementation detail -
Strictly speaking, as per SSDP spec - the plugin is using the device’s advertised USN value, not the S/N, to do unique identification of a device and any cache expiration.
However, according the the ECP guide… for Roku boxes, the S/N is embedded in the USN (again, this was a Roku impl choice and not required by the SSDP spec, so in theory this could change in the future)

Cheers

SoN9ne · April 29, 2014, 9:23pm

I just installed this today. Eclipse is a horrible editor but I wanted to give it another go as this plugin seems very useful.

I installed Eclipse and installed this plugin. I seem to be having a lot of issues and most I worked out but I do get a lot of random errors but I can deal with this as I assume development is ongoing.

My reason for this post is an error I get when running Localization (by right-clicking on the file and selecting localization. Also by selecting the project and selecting localization)

The error I receive is:

java.lang.IllegalArgumentException: No enum constant com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.BrightScriptManifestPropertyName.'
	at java.lang.Enum.valueOf(Unknown Source)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest$BrightScriptManifestPropertyName.valueOf(BrightScriptManifest.java:1)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.getSourceVals(BrightScriptManifest.java:452)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.getLocalizedSourceValsFromMainManifest(BrightScriptManifest.java:208)
	at com.roku.brightscript.ide.eclipse.core.actions.BrightScriptTranslationsAction.run(BrightScriptTranslationsAction.java:28)
	at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251)
	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:1057)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:140)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	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:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)

Now to help isolate this. I do not have an option set to auto translate (could that be the issue?) I was assuming that localization would generate the XML files and I could then do the translations by giving them to actual translators instead of using a service.

I did follow the guide and installed DLTK 2.0. The plugin works for the most part but has many issues. The export to Roku seems flawless but the manifest editor throws errors on none error values (like spash_color not being a hex value although it is) one issue that should be noted is that if you use the manifest editor it will recreate the file. All comments will be omitted.

Window 7 Professional 64-bit
Eclipse Standard/SDK
Version: Kepler Service Release 2
Build id: 20140224-0627

Thanks for any help on this.

malloys · April 30, 2014, 2:17am

“SoN9ne” wrote:

My reason for this post is an error I get when running Localization (by right-clicking on the file and selecting localization. Also by selecting the project and selecting localization)

The error I receive is:

java.lang.IllegalArgumentException: No enum constant com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.BrightScriptManifestPropertyName.'
	at java.lang.Enum.valueOf(Unknown Source)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest$BrightScriptManifestPropertyName.valueOf(BrightScriptManifest.java:1)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.getSourceVals(BrightScriptManifest.java:452)
	at com.roku.brightscript.ide.eclipse.core.BrightScriptManifest.getLocalizedSourceValsFromMainManifest(BrightScriptManifest.java:208)
	at com.roku.brightscript.ide.eclipse.core.actions.BrightScriptTranslationsAction.run(BrightScriptTranslationsAction.java:28)

Auto-translate is not required - precisely because of the use-case you are stating.

The stacktrace indicates that you’ve got what the plugin currently considers to be an invalid main manifest file (and that I need to improve the manifest processor’s error handling).
If you could provide the manifest file in question, I can track down the issue.
However, I’m guessing by the stacktrace that you are using the single quote character to prefix comment lines in the main manifest - this is allowed/correct for .brs files, but not manifest files.

The plugin unofficially allows comment lines in the manifest that begin with “#” or “!” (AFIK, the SDK docs don’t mention any support for comments in the manifest file, so this may go away or change in the future).

“SoN9ne” wrote:

The export to Roku seems flawless but the manifest editor throws errors on none error values (like spash_color not being a hex value although it is)

Again, If you could provide the manifest file in question, I can track down the issues.
For the splash_color value, you need to be sure you’ve prefixed the value with “#”, otherwise it’s invalid.
Using the color picker button to the right of the field in the manifest editor to choose colors will show you the correct format.

FWIW… I’ve just discovered that if you manually enter the splash_color in an incorrect format once, it will subsequently fail to save even if you correct the value in the manifest editor.
You may be running into that bug (which I’m about to file). If so, here’s a temporary workaround:

set the splash_color field value to empty.
save the manifest. (should work now w/o errors)
enter the correctly formatted splash_color field value.
re-save.

“SoN9ne” wrote:

one issue that should be noted is that if you use the manifest editor it will recreate the file. All comments will be omitted.

Yep, that behavior (comments are not preserved across edits via the manfest editor’s overview tab, or generated localized manifests) was stated a long time ago in a thread on this forum , but unfortunately the thread that it was stated in was removed and replaced by this thread.
That behavior probably should be noted in the plugin guide, but isn’t. I’ll ping the doc maintainer to add that in for the next release of the plugin.

Cheers

SoN9ne · April 30, 2014, 2:50pm

“malloys” wrote:

Auto-translate is not required - precisely because of the use-case you are stating.

The stacktrace indicates that you’ve got what the plugin currently considers to be an invalid main manifest file (and that I need to improve the manifest processor’s error handling).
If you could provide the manifest file in question, I can track down the issue.
However, I’m guessing by the stacktrace that you are using the single quote character to prefix comment lines in the main manifest - this is allowed/correct for .brs files, but not manifest files.

The plugin unofficially allows comment lines in the manifest that begin with “#” or “!” (AFIK, the SDK docs don’t mention any support for comments in the manifest file, so this may go away or change in the future).

This was my issue. I am using the comments as

' My Comment

by removing the comments I was able to generate the translation.xml files. Thanks a lot for that

“malloys” wrote:

Again, If you could provide the manifest file in question, I can track down the issues.
For the splash_color value, you need to be sure you’ve prefixed the value with “#”, otherwise it’s invalid.
Using the color picker button to the right of the field in the manifest editor to choose colors will show you the correct format.

FWIW… I’ve just discovered that if you manually enter the splash_color in an incorrect format once, it will subsequently fail to save even if you correct the value in the manifest editor.
You may be running into that bug (which I’m about to file). If so, here’s a temporary workaround:

set the splash_color field value to empty.

save the manifest. (should work now w/o errors)

enter the correctly formatted splash_color field value.

re-save.

Thanks, I actually figure out the work-a-round later in the evening to get that working. I originally set the value omitting the # and that caused the issue.

“malloys” wrote:

Yep, that behavior (comments are not preserved across edits via the manfest editor’s overview tab, or generated localized manifests) was stated a long time ago in a thread on this forum , but unfortunately the thread that it was stated in was removed and replaced by this thread.
That behavior probably should be noted in the plugin guide, but isn’t. I’ll ping the doc maintainer to add that in for the next release of the plugin.

Cheers

Understood. I just started Roku development 2 days ago so I have a bit to learn.

Below is my manifest file with comments. This is not the exact one throwing the error as it has been changed but it throws the same exceptions.

' Channel Details
title=blankTemplate
subtitle=Blank template to be used as a foundation for development

' Channel Version
major_version=1
minor_version=0
build_version=0

' Channel Branding
mm_icon_focus_hd=pkg:/locale/default/images/icon_focus_hd.png
mm_icon_side_hd=pkg:/locale/default/images/icon_side_hd.png
mm_icon_focus_sd=pkg:/locale/default/images/icon_focus_sd.png
mm_icon_side_sd=pkg:/locale/default/images/icon_side_sd.png

' Channel Splash Screen
splash_screen_sd=pkg:/locale/default/images/splash_page_sd.png
splash_screen_hd=pkg:/locale/default/images/splash_page_hd.png
splash_color=#000000
splash_min_time=1600

I am currently in the process of learning Roku development and am commenting my “blankTemplate” to be used with other developers that have no experience. Hence my reason for wanting to comment everything. Removing comments from the manifest isn’t really an issue. I just wanted you to understand my reasoning for using comments on simple items.

Thanks for this great plugin.

One feature request, if possible, would be to allow the plugin to use Eclipse themes. Maybe it’s just be but I use a dark theme for Eclipse and it doesn’t seem to apply any styling to the BrightScript code. Perhaps I am missing something here?

Also, when you delete a file then select update existing translations it doesn’t remove deleted files from the translations.xml

Topic		Views
Eclipse Plugin for Brightscript Archived roku-developer-program	106	June 16, 2012
Eclipse plugin for Brightscript Archived roku-developer-program	145	September 1, 2011
New Eclipse Plugin Release 5/16/2013 Archived roku-developer-program	18	June 26, 2013
New Eclipse Plugin Release 12/17/12 Archived roku-developer-program	12	April 4, 2013
Eclipse 4.5.2 - BrightScript 1.0.0.201603221254 Archived roku-developer-program	6	April 25, 2016

New Eclipse Plugin Release 1/7/2014

Related topics