Open tisonkun opened 9 months ago
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...
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 https://github.com/korandoru/hawkeye/issues/64 within a Maven structure.
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.
@trustin may you take a look at https://github.com/trustin/os-maven-plugin/pull/71 or I'll send a patch for this issue based on that patch anyway >_<
I develop a Gradle base version now. I'll share the result with you soon :D
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.
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.