Closed JamesXNelson closed 6 years ago
We can open source the files but not include them in the distribution jar files yet. If the files are open source'd, you guys can decide how to package them.
Yup. Was going to try to avoid repackaging a very common shared dependency under a new groupId, but doing a dependency swap is at least (super) easy for gradle. Not sure what maven guys will have to do to make it work. cc @mbarkley to see if he can get by using one of a number of workarounds.
I currently hacked it to detect jsinterop jar and then used the links to raw github files to grab them. Obviously not ideal; if it wasn't such a hack I would bother to use a correctly versioned URL as well, but for now, it was good enough to make automated dependency transpilation functional.
If maven guys would prefer, we can push a jszip + jar + j2cl jar to our artifactory for RC1 (there is already a jar + jszip for beta3). It might be worth special casing just the "user requested jsinterop base; go looking for jszip at different coordinate" part, since manually excluding all those dependencies in maven would really suck.
yep that's the idea. We push the files and you guys package them as you want.
The native.js files are already in the repo. The problem of native.js file distribution is a more general issue and is not related to jsinterop-base only. So i'm closing this issue. I invite you guys to discuss this problematic and if you need something on my side, just ping me.
Presently, the RC1 distribution does not contain any native.js files.
This makes life difficult for (external) j2cl plugin developers. If possible, could these files be included in an available archive on the next release? If you don't want to put them in the main jar, perhaps a jar/zip w/ a classifier like
j2cl
would suffice (/ be optimal). We already have to do some unpacking, so the file extension is not relevant to us (at least for gradle; not sure what maven team is doing in this regard).