Package (re)naming for the latest release

[gionn]

Hi,

it looks like that in the latest release of sshj, the groupId of the artifact has been changed to com.hierynomus, but the library maitains the old package naming of schmizz.net, breaking the 1-1 correspondance between the Maven {groupId, artifactId} pair and the Java package name.

e.g.: when an old version of sshj is a transitive dependency in a project that use the latest com.hierynomus:sshj, maven treats them as different libraries, putting both of them in the classpath without rising any conflict alert, but since the share the same package naming, only one of them will be actually usable on runtime (and may lead to unexpected behavior).

[hierynomus]

Yes, it was changed, as I took over from Shikhar as maintainer. I have push access to com.hierynomus amongst others. I didn't yet want to break all code by moving the code to a new package. But it might be indeed a good idea. Will do that with the next release.

[hierynomus]

Thought about it some more. Will not do that for the next release, but will first release a new version. The main reason is that there are a lot of fixed issues which I first want to get out, before moving all the stuff over. The next version will be 0.12.0. When I move the classes, I will update the version of the library to 1.0.0, notifying a (very) breaking change :wink:. Agreed?

[gionn]

As you prefer, I've already setup a dependency exclusion for the old sshj transitive dependencies I have, it isn't a blocking issue (just high chance to get punched in the face :D).

Thanks.

[exceptionfactory]

@hierynomus What do you think about the timing for aligning the Java package naming and releasing a 1.0.0 version?

[exceptionfactory]

There are also several ported classes for certain algorithms that would benefit from aligned package naming.