android: Static binding generator fails when using Webpack + Workers

Example case: Setup - project with web worker file where the worker imports ‘globals’. If you webpack the project, a bundle named [hash].worker.js will be generated and it will contain the whole tns-core-modules package. Since tns-core-modules is also contained in the vendor chunk, the static binding generator will fail:

Warning: there already is an extend called com.tns.FragmentClass.
Warning: The static binding generator will generate extend from:b8fc197268e0dd59663c.worker.js implementation
:asbg:generateBindings
Exception in thread "main" java.io.IOException: File already exists. This may lead to undesired behavior. Building 55% > :asbg:generateBindings
Please change the name of one of the extended classes.
/home/svlaeva@bedford.progress.com/nativescript-webpack-workers-issue/platforms/android/src/main/java/com/tns/FragmentClass.java
        at org.nativescript.staticbindinggenerator.Generator.writeBindings(Generator.java:59)
        at org.nativescript.staticbindinggenerator.Main.main(Main.java:15)
:asbg:generateBindings FAILED

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 2
Comments: 45 (13 by maintainers)

Most upvoted comments

Hi,

I believe I am having the same problem as @sis0k0 , trying to webpack an {N} app with a web worker:

Exception in thread "main" java.io.IOException: File already exists. This may lead to undesired behavior.
Please change the name of one of the extended classes.
File:/home/quentin/Projects/hubup-nativescript-clover/platforms/android/src/main/java/com/tns/FragmentClass.java Class: com.tns.FragmentClass
        at org.nativescript.staticbindinggenerator.Generator.writeBindings(Generator.java:68)
        at org.nativescript.staticbindinggenerator.Main.main(Main.java:15)
:asbg:generateBindings FAILED

I waited a few weeks before migrating to {N} V3, but now, it is becoming more and more pressing that I keep my app up to date 😃

So is there a workaround for workers, or is there a release where this prob is fixed ?

Thanks

quentinor on Jul 19, 2017

@Pip3r4o thanks for the reply. As far as I understand, I encounter this issue due to a web worker that I am using in my plugin as is explained in this issue. Shouldn’t web workers be supported out of the box?

I see that @sis0k0 explains that “you don’t really need to import globals in your worker” so I tried not to include the globals in the worker, but even then I am getting the same error:

Running full build
finished with reading lines with js files
Warning: there already is an extend called com.tns.FragmentClass.
Warning: The static binding generator will generate extend from:vendor.js implementation
:asbg:generateBindings
Exception in thread "main" java.io.IOException: File already exists. This may lead to undesired behavior.
Please change the name of one of the extended classes.
File:/Users/joni/projects/nativescript-webpack-error-app/platforms/android/src/main/java/com/tns/FragmentClass.java Class: com.tns.FragmentClass
        at org.nativescript.staticbindinggenerator.Generator.writeBindings(Generator.java:68)
        at org.nativescript.staticbindinggenerator.Main.main(Main.java:15)
:asbg:generateBindings FAILED

abhayastudios on Jul 1, 2017

@Pip3r4o - thanks for getting back to me and taking the time to create the test project.

I solved the problem.

The problem was that in my bundle-config.ts file, I had

global.registerModule("nativescript-telerik-ui/sidedrawer", function () { return require("nativescript-telerik-ui/sidedrawer"); });

global.registerModule("nativescript-telerik-ui/sidedrawer/drawerpage", () => require("nativescript-telerik-ui/sidedrawer/drawerpage"));

I was getting the multiple definition of FragmentClass.

If I comment out the second line - then it works.

Weird because I got those two lines from some sample projects on github.

Hopefully this will help someone else…

erjdriver on Oct 12, 2017

@Pip3r4o seems you are correct. It could have been something specific to the specific version that was used in the PR. With the resubmited PR with @next there is no error 👍

PeterStaev on Oct 12, 2017

Starting off I’d like to point something out - that behavior IS expected.

The build-time exception is often a sign that something isn’t quite right with the files - you have dupes, or you extend the same class, with the same name, meaning if the build was uninterrupted - only one of the two extended classes will pass, which may result in unexpected behavior/bugs runtime.

I think we can make it so the sbg will spit out a warning message when two of the same classes have the same content, and not throw, while still throwing an exception with that particular error message if contents of the two files differs.

petekanev on Jun 8, 2017