Analysing this very useful (and big) modules decoupling..
Will the elevation data import via tif files remain as part of graphhopper-core module (along with xmlgraphics-commons dependency)?

Currently yes, as I'm not sure how the dependencies should look like. E.g. should it be readerosm->elevation->core or
elevation->readerosm->core or
elevation->core && readerosm->core or
with some kind of plugin mechanism where the elevation module is completely separated ...

Core should be best independent (if possible) from graph creation business.
But what you describe is a good point for thinking, i.e. how the elevation and various readers interact with each other..

BTW: maybe we should use GraphHopper for osm stuff for backward compatibilty and the core graphhopper class will then be GraphHopperCore (GraphHopper extends GraphHopperCore). Or should we keep it as it is GraphHopperOSM extends GraphHopper? Which I like more but breaks compatibility?

Hmm nice thought. For clear API the 2nd solution (with data suffix) appears more appropriate i.e. GraphHopperOSM extends GraphHopper.
Or we could have the irregularity of GraphHopper for osm and GraphHopperShp for shp?

Or we could have the irregularity of GraphHopper for osm and GraphHopperShp for shp?

Indeed, this would be too ugly. So let us break and we already report the user what to do to fix this: https://github.com/graphhopper/graphhopper/pull/740/files#diff-59d362881b641ff1b933a3785503c20eR774

At least for the elevation module this could work as follows. E.g. in the current Import file (tools module) we can do:

public class Import
{
    public static void main( String[] strs ) throws Exception
    {
        CmdArgs args = CmdArgs.read(strs);
        GraphHopper hopper = new GraphHopperOSM().init(args);
        // one line glue code of OSM and elevation module 
        hopper.setElevationProvider(ElevationHelper.createElevationProvider(args));
        hopper.importOrLoad();
        hopper.close();
    }
}

The same would be necessary in the web module. The downside is that we would need this glue code and also explicitely define the elevation module as separate dependency besides reader-osm in all downstream dependencies which need osm import with elevation. Not sure if this is okay.

Another possibility to avoid the glue code would be very simple reflection code asking for elevation and if not existing falls back to ElevationProvider.NOOP. I would try to avoid this as e.g. iOS will have problems with this but maybe it is not a problem at all when we provide the possibility to do this by hand.

Merged now.