Provide the core detect logic as a separate artifact

[tisonkun]

It's a bit common to use the resolved classifier in code in addition to in pom.xml. Although we may use a filtered resource file, it resolved the classfier at compile time instead of runtime.

Of course I can refactor out the related code from this project, but I wonder if it can be done in the upstream so that we're sure the same logic is used between the plugin and library.

cc @trustin I can invest some time to work on an implementation, but it can change the structure of this project so I'd like to ask for a consensus first.

[trustin]

Hey- I agree with you that a separate core module is the way to go. A pull request would be great for sure! I was also thinking of migrating to Gradle before making it happen but it never had a chance to get my attention recently...

[tisonkun]

Cool. I'll try to make an implement.

Out of curiosity, what benefits do you find to migrating to Gradle? I found Maven has a more mature ecosystem and even did some tricks to distribute my project as a Gradle plugin korandoru/hawkeye#64 within a Maven structure.

[trustin]

I ended up preferring Gradle over Maven for its much easier customizability and its nice Kotlin DSL. I also find it evolves much faster, which may or may not be a good thing, although I like where it goes.

[tisonkun]

@trustin may you take a look at #71 or I'll send a patch for this issue based on that patch anyway >_<

[tisonkun]

I develop a Gradle base version now. I'll share the result with you soon :D

[tisonkun]

Published at https://github.com/tisonkun/os-detector/.

@voidzcy @trustin @ejona86 I'd prefer to merge this fork or even all these three repos together so that we provide a programmatic interface, maven plugin (extension), and gradle plugin together and keep the logics aligned.

I don't have a strong feeling on where it places but I'd like to maintain it so a write permission and a way to drive release is desired.