Closed
Issue #13 · created by Sergey Reymerov ·


Use doppio from npm

It's a good idea to use doppiojvm as dependency for JavaPoly.


5 participants
  • No avatar
    Jim Sproch @jimsproch
    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Rooftrellen @coderrooftrellen

    mentioned in issue #11

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Jim Sproch @jimsproch

    mentioned in issue #11

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    Ok, looks like #10 will be tracked upstream and #11 is fixed without needing to fork doppio, so we are completely unblocked on this one :).

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    I know the npm release of doppio includes a listings.json file, and I think that's used to specify native implementations. I don't think this would be blocked by #16, but I thought I'd flag it just in case.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Sergey Reymerov @sergeyreym

    There are lots of deep changes in Doppio that current JavaPoly is depended on. As I understand John Vilk it's not well to run Java-methods the way we use. He said we should use public void main(String args[]) for this (http://github.com/plasma-umass/doppio/issues/390#issuecomment-160701631).

    And I've found that there is no runMethod(...) in the current version of Doppio which we rely on.

    But it's okay. We should write Java wrapper with native code for doing our job. And leave most of the code the same.

    I'll do it regards to this issue.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    Ok, cool. Sounds like things are moving/changing fast :).

    Yeah, I think John wants the doppio interface to be more like a traditional JVM interface (ie. it runs a single java program, terminates after completion). So I think we need to create a Java program that constantly listens for messages from javascript land and uses reflection to invoke the appropriate methods when a new message arrives. I think you've come to the same conclusion I did in #17. Somewhat related to what @akadeev is working on in #12 (centralizing the method invocation call sites).

    Keep up the great work @sergeyreym - I know this issue is turning out to be a bit more complicated than we had originally thought, but I know it will be a huge improvement and if anyone can figure it out, it's you! Thanks!

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Artem Kadeev @akadeev

    Yeah, so I am personally looking forward to see new doppio API that will allow exchanging between JS and Java native application running (in event loop). Updating doppio to actual state will break all existing functionality, but that is ok, we can fix it after that. If there is a way of sending data to Java program, then we can place all methods dispatching there. We can even create instances on Java side, and use it on JS side via some calls, to create some kind of mapping where JS objects will be only proxy to existing native objects managed by JVM. Leaving JS wrappers as thin as possible probably will give us freedom to use any kind of Java reflection while loosing a tie to doppio API (they can change it, but our Java program will run anyway).

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Artem Kadeev @akadeev

    So what is the plan for now? As far as I understand we have to find another way to interact with java program that runs on doppio as we should not invoke any methods. This might be simply not possible in the current doppio API (as it tends to be a usual JVM). And in case of usual JVM that would be something like system output/input stream or some OS descriptor or web interface. I am not sure if any of this possible now.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    @akadeev Yes, that's why this issue is so tricky, and that's what @sergeyreym is working on (if I understand his previous comment correctly). I'm fairly sure that doppio DOES support streams and other communication mechanisms, as evident by their support of TCP and the filesystem APIs.

    Ultimately, this should not affect you, because once the "message" is passed into the JVM, the JVM can just invoke the appropriate method, so it's really not so different from invoking methods directly from outside the JVM. It just requires the running java program to respond to incoming messages.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512 Harshad RJ @hrjet9
    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    So a goal of this bug is to have doppio be installed directly from npm right?

    That is, npm install should fetch the dependency, and no need to manually copy doppio from the doppio-example project?

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    That is my understanding, yes. It would be nice if people could just do npm install instead of worrying about downloading+installing doppio manually. There is, however, the question (at least in my mind) of how you deploy to a server with the npm strategy, since the server needs to be able to serve all the doppio code. But yeah, we want to smooth out the install process for anyone who wants to use JavaPoly, and doppio is one of the more complex dependencies to build/manage.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    One way to handle this could be:

    In Javapoly, we add a dev-dependency on doppiojvm. So developers working on Javapoly can just do an npm install and get it downloaded. The default doppio-url in JavaPoly options will be /node_modules/doppio/dist/...

    The users of Javapoly, will have a choice:

    • Use doppio from node : they will need to add doppiojvm dependency to their package.json
    • Use doppio from elsewhere: they will need to modify the url in Javapoly options

    Something similar can be done for browserfs as well.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    I'm not an npm expert, but my understanding is that most people don't serve their npm_modules via their web server. I think most people use npm to build their application, and the output goes into a build folder or something. This leads me to believe that (as part of the build) the doppio folder should be copied into the build directory, or something.

    Regardless, the default URL for the hosted copy of doppio should be http://javapoly.com/doppio/ (as it is now); we don't want to have node_modules on the production server path.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    Not an npm expert either. Going by your comment, a slighty updated proposal:

    In Javapoly, we add a dev-dependency on doppiojvm. So developers working on Javapoly can just do an npm install and get it downloaded. They can then link test/doppio/ to /node_modules/doppio/dist/...

    For the the users of Javapoly, nothing changes from the current way.

    Alternatively, we needn't do anything further for this issue. Developers can simply install doppiojvm by typing npm install doppiojvm, or use the pre-built copy from doppio-example.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    Yeah, that seems reasonable.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    Though, I kind of wonder if it makes sense to just always use the npm version, and have grunt-build copy it from node_modules into the build directory. Is there a real disadvantage to doing it this way?

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    That sounds good too. To keep the copy in build folder fresh, we would need to either copy the whole directory for every build, or symlink it.

    Copying the whole directory will be slow... symlinking it would be better. But for easier deployment, we could add a new grunt task that creates a final build archive which resolves all symlinks and spits out a build.tar.gz.

    Is that fine?

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    I'm a little worried about symlinks because I don't think symlinks work on windows, right?

    I think node modules generally contain a package.json that specifies the library's version number (and npm doesn't allow you to change package contents without changing version number). Could we compare build/doppio/package.json with node_modules/doppio/package.json, and only do the file-copy if the two files differ?

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    Symlinks seem to be available since Windows Vista. I am not a Windows user though; so can't be sure.

    If we still want to avoid them, then comparing package.json + copying sounds good.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    Yeah, I think my intuition is to just avoid them, especially if there is a reasonable alternative solution. I can't really think of any downsides to doing a copy-if-version-differs, but I've been bitten many times by symlinks. Sometimes symlinks are necessary/useful, but my intuition is to treat them like globals (use them when you must, but generally try to avoid).

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Sergey Reymerov @sergeyreym ·

    I think it's a good idea of comparing 'package.json' and copy files only when they are different.

    Also I think that JavaPoly should be "quick-startable". I mean user should be able to write only 4 command to try it:

    git clone ...
    npm install
    grunt build:test
    npm test
    

    Where "npm install" should solve all dependencies and "grunt build:test" should prepare an environment.

    And I think that it would be better to remove the last command from and add special grunt task: "grunt run:test" which does "grunt build:test" and starts "http-server".

    Actually I tried to run current JavaPoly and it needs some routines to work fine so I'll fix this issue.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Sergey Reymerov @sergeyreym
    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Sergey Reymerov @sergeyreym
    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Sergey Reymerov @sergeyreym

    Status changed to closed by commit 84a048acfab21ce00d73fce053f59b8fd8b5b1ff

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    @sergeyreym The grunt file is copying the release version of doppio to test/ folder. Can it be changed to use the dev version?

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
jimsproch/JavaPoly#13

Assignee: Sergey Reymerov

Milestone: none


Votes
0 up
0 down