Hard-won lessons: Five years with Node.js

Re:Hard-won lessons: Five years with Node.js by lmm on Friday April 21, 2017 @07:01AM (#14164467)

I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it.

The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... . That shows what the minimum looks like - a pom.xml, and application source code in src/main/java (under its package structure). (The unit test isn't strictly necessary but is good practice).

The pom's XML header and modelVersion are boilerplate, but the rest is pretty clear and self-explanatory (though admittedly verbose).

At that point for a library project you're sorted, for an application you can run your program via "mvn exec:java" which is adequate for development. To actually package up your application for distribution you probably want to use the shade plugin a la https://maven.apache.org/plugins/maven-shade-plugin/examples... , but that's something you'd do as part of "productionisation". (Back when I worked at an early-stage startup we had things running and serving user requests via "mvn exec:java")

[ Parent | on HN ]

Re:Hard-won lessons: Five years with Node.js by lawik on Friday April 21, 2017 @10:06AM (#14165715)

Appreciate the overview. It sounds similar to what I'm used to but, as you say, perhaps a bit more verbose. And some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

Most dynamic languages tend to be more straight-forward with this.

[ Parent | on HN ]

Re:Hard-won lessons: Five years with Node.js by lmm on Friday April 21, 2017 @12:09PM (#14166794)

> some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

That's kind of our way to do virtualenv-like functionality, which is mandatory rather than optional. (Or you can specify the classpath manually in the same way you would for the pythonpath, but no-one wants to do that). IMO that's the right thing - having libraries installed in my system python has only ever caused trouble in the long- or even medium-term, even if it makes "hello world" use of libraries very slightly simpler.

There's probably a way to get a shell with the classpath set up correctly, but I always found that kind of modalness more confusing than helpful.

> I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

In my experience it does all work without any flags or extra knowledge. "mvn" is the entry point for all the things you want to do - you don't ever have to know that there's a "java" and "javac" underlying it.

[ Parent | on HN ]