Continuing the discussion from Elevation data from local files:
For NetBeans it is the same. But is this simple and fast developer setup also the case for Windows?
Now I’m on Linux, but the old days on Windows the procedure was the same with Eclipse (and its integrated Maven support).
Oh, since when has it maven support integrated 
?
Eclipse is a platform and depending on selected package, Maven could be included (as in Java ones) for immediate use or not.
Its not perfect out of the box for windows + ecplise.
First you must be familiar with Maven.
Secondly, i think there may be some small tweaks required if you want to package a jar with dependencies.
Lastly, I’d like to recommend a a global version property for the sub projects to use - if that is the design. I believe right now their are all manually / statically entered, which makes updating them x4.
Its not perfect out of the box for windows + ecplise.
yeah, for windows it is indeed improvable, but that needs to come from the community as I’m no windows user
First you must be familiar with Maven
That is only true for Eclipse without the maven plugin and indeed required, yes.
Secondly, i think there may be some small tweaks required if you want to package a jar with dependencies.
Would you share your experience here?
I believe right now their are all manually / statically entered, which makes updating them x4.
What do you mean here? the explicit version in the pom.xml? That is not something you should need to fiddle with.
I tested recently (after Peter’s request) GH on Windows, with Eclipse and it was a matter of opening the Maven project.
More steps are probably needed if someone wants to compile with Maven the Android sample too.
Then the Maven Android Sdk Deployer can be extremely useful.
Jar with dependencies can be interpreted as including also Trove and SLF4J in destination jar.
The version, as Peter mentioned, is defined in pom.xml and used automatically via the Maven ‘install’ task during the modules building.
yeah, for windows it is indeed improvable, but that needs to come from the community as I’m no windows user
Lucky you! 
That is only true for Eclipse without the maven plugin and indeed required, yes.
This was just a comment. Depending on your java experience (mine coming from Android), I had no prior maven experience, which made the process slower. This isn’t a criticism, its just an observation / warning.
Would you share your experience here?
The biggest issue I ran into was getting the correct “run as” configuration in eclipse for the maven build (entering the necessary goals and ticking the right check boxes). It looks like you are staying IDE neutral (a good thing). Is there a doc on how to run maven properly to build the jar? I did not see one, but I did not search either.
If there is a desire for it, I might be able to do a doc for Eclipse + Maven (should be the same for any OS)
What do you mean here? the explicit version in the pom.xml? That is not something you should need to fiddle with.
Let me add context, because I think it makes a large difference:
I had not tried to just compile and package straight away with no modifications.
My comments and experience are based on forking the repo and adding graph extensions and other tweaks.
Now I have a new version. Ideally this new version has a new version number, which most likely should be a completely different version numbering scheme and new artifact.
If there is a desire for it, I might be able to do a doc for Eclipse + Maven (should be the same for any OS)
Sure! Also I think there is already a doc for Eclipse, maybe you can improve that? Or maybe we should make this better discoverable ?
Is there a doc on how to run maven properly to build the jar?
You mean via command line? That should be done via the graphhopper.sh script e.g.
mvn -DskipTests=true clean install assembly:single
builds the web, tools and core modules
My comments and experience are based on forking the repo and adding graph extensions and other tweaks.
All tweaks should be go back into GraphHopper master
If not possible due to different reasons, then we should at least modify GraphHopper in a way you won’t need to touch the core and can still use your extensions.
Now I have a new version. Ideally this new version has a new version number, which most likely should be a completely different version numbering scheme and new artifact.
Try:
mvn -P include-android versions:set -DnewVersion=0.12.34 -DgenerateBackupPoms=false