Closed kypvalanx closed 5 years ago
I'd much prefer if you could work on first time developer guides over switching from gradle. We have several custom steps for good reason - and that would be difficult to replicate in maven (and frankly, I've had to use maven and find it much harder to use).
I'd be willing to help you with the contribution guide of course.
Also, we're going to be switching the build eventually to be even more custom as we figure out how to use jlink and japplication properly :)
I actually duplicated a lot of the custom steps in maven already in an effort to do an "as is" conversion with the intention of standardizing the build later. I'm sure the difficulty is just not being used to it. i feel the same way about gradle.
so, I don't want to discourage your efforts to contribute - but I don't think it's likely we'll switch to maven - in fact we switched from maven to gradle several years ago. The reasons for this predate me (I've only been around a couple of years) but at this point what we have works, and switching doesn't seem to buy us much
That being said, its really awesome to see you want to get involved and there are a ton of areas looking for people to help.
OTOH
[0] I'd, personally, be open to moving to pure github from jira - but that's a larger conversation with the rest of the team!
Github lacks workflow customizations, categorizations, and of course, creation of release notes.
Much like what Grimreaper said we used Ant/Maven in the far reaches of the past, and the senior coders decided to move to Gradle/Groovy for some improved building that was forward thinking. The only developer from that era still around is @thpr or the original developer @mertonmonk Beyond that, Gradle allows for newbies to do fun things from their command line such as ".\gradlew run" and have a new build up and running. Unless there is a compelling reason to return to Maven, I think the future pathway will continue with Gradle. Of course, feel free to offer up your opinion on why it is superior in your mind. Well thought out discourse is healthy for a project.
Our developers are focused on major projects - Converting to a new formula system built from scratch, as well as GUI version 3 (JavaFX from Swing). So introducing build changes would likely be discouraged anyways. In fact, if you want to help in the build department, finding a solution to have an autobuild available/hosted on github would be great, or from our Jenkins hosted on another website.
Please continue to clean up the code base, everyone does appreciate any small fixes that refactor and clean up ancient messes. :)
If it's that far back that was a good choice. the only benefit i'd be looking for would be to move to a reactor style build [0] where pcgen base and formula would be sub modules of the project and could optionally be compiled before it.
I find that versioning code together that is always used together at work.
You can have submodules with Gradle as well.
I don't think there's any reason to rever back.
Closing this out. Thanks!
One thing i've noticed about this project is that it is difficult to build for someone new to the project. I'm not very experienced with gradle so correct me if i'm wrong, but there also appears to be a lot of very custom steps. I've done a proof of concept where i converted the project to a maven reactor that also includes the code from the supporting projects as separate modules. it works sans a few tests that appear to rely on run order.
I just want to know everyone's thoughts. should i keep going down this route or maybe focus instead on first time developer guides?