"mavenize" #25
"mavenize" #25
Conversation
Only adds pom and jars which are not published to a maven repo while maintaining this project's directory structure
|
|
||
| <groupId>me.mrCookieSlime</groupId> | ||
| <artifactId>CSCoreLibPlugin</artifactId> | ||
| <version>1.5.16</version> |
There was a problem hiding this comment.
Do I need to update that everytime? D:
There was a problem hiding this comment.
No, if you don't care about maven, you don't have to.
| </repository> | ||
| <repository> | ||
| <id>jitpack.io</id> | ||
| <url>https://jitpack.io</url> |
There was a problem hiding this comment.
Why exactly is this here?
There was a problem hiding this comment.
This is for the GriefPrevention dependency.
| <repository> | ||
| <id>bintray-tastybento-maven-repo</id> | ||
| <name>bintray</name> | ||
| <url>http://dl.bintray.com/tastybento/maven-repo</url> |
There was a problem hiding this comment.
Also, what is this used for?
There was a problem hiding this comment.
For aSkyBlock dependency.
pom.xml
Outdated
| <artifactId>Lockette</artifactId> | ||
| <version>0.91.4.9</version> | ||
| <scope>system</scope> | ||
| <systemPath>${basedir}/lib/Lockette.jar</systemPath> |
There was a problem hiding this comment.
Do we really need to include the compiled distributables of these Plugins in the github repository?
Because neither of us owns this content after all...
There was a problem hiding this comment.
No, don't have to include, but I do know some repos that do (e.g. https://github.com/projectkorra/projectkorra , some others that I don't recall right now since I'm in a rush right now).
There was a problem hiding this comment.
Again, "But others do it as well" is no proper justification, that is a called a relativistic bias.
Shouldn't this be able to be served over jitpack.io as well?
There was a problem hiding this comment.
I looked into the licenses of the jars included in this PR regarding distribution, and they all seem to be okay:
- MassiveCore + Factions are MIT (although it seems like MassiveCore has finally been mavenized once again, so I'll see if I can find their maven repo or get it working with jitpack.)
- Towny is Creative Commons (Attribution-NonCommercial-NoDerivs 3.0 Unported)
- LWC just requires this file to be included.
- Lockette uses NPOSL-3.0
I did try using jitpack for some of these; LWC and Lockette had missing dependencies in their pom, and thus cannot build. Towny I've heard is a dependency nightmare, and I assumed MassiveCore + Factions weren't mavenized (they were originally, then de-mavenized due to not wanting others to "easily compile it for themselves because he gets rewards from bukkitdev downloads", then I guess they decided to mavenize again.)
If you still really don't want to include these jars, I can fork a couple of these and fix the dependency issues (and use jitpack), or just leave as-is and developers can download the jars themselves into the lib folder.
There was a problem hiding this comment.
Id prefer the removal of the distributables, how you handle the rest is up to you.
|
I really really dislike Maven and am not going to use it, can I still commit to this like before or do I need to make any changes to my working chain? |
Yup. That's why I configured it to use your existing directory structure. |
|
+1 to this PR. Mavenizing a project is a good thing 100 times out of 100. Confining developers and contributors to your IDE of preference in order to get a working jar out of your code is a terrible way to go about the open source, and that's not even mentioning how maven makes it easy to distribute your jarfile to other people who also use the platform. This makes version controlling dependencies in all projects easier, because you just need to change a number in order to get the newest version, instead of having to try to find it online. |
|
@Redrield I am not argumenting against this PR, if I would, I would have closed it. |
|
@TheBusyBiscuit Not using universal dependency management does limit the IDE that contributors can use without adding cruft to the repository. It also slows them down the first time they fork it if you don't add the jars to the repo. Say that you use Eclipse, and you've commited the .classspath plugin. If you havent included the jars, they're gonna need to go download them, which takes time out of actually contributing to your project. If they want to use IntelliJ, they're going to need to download the jars, and then add them one by one to their project, which uses an incompatible file structure to Eclipse. Maven solves this problem by having one file that is recgonized by all IDEs, and that contains information about all your dependencies. There won't be incompatibilities or lost time if both IDEs can reliably import a Maven project, and add dependencies from it to the developer's classpath. Overall, it feels like you're making excuses for your workflow where they shouldn't be made. Saying that "Java source code will always be just that" doesn't work when you have dependencies that you're going to need, and your IDE may not even recognize the file adding these dependencies to the classpath. |
|
Alright, was able to find a maven repo for everything, so all binaries have been removed from this PR. |
|
@Redrield Argumenting that the world is going to break down if we don't use Maven or claiming that nothing is going to work without Maven is just overreacting. And Java Source Code is just Java Source Code. Full Stop. TL;DR: Claiming that not using Maven would confine you in your IDE preference is still false. @RoboMWM Thanks for making the changes, merging it. |
This allows the project to be compiled via maven, and allows for easy workspace setup in IDEs.
This PR maintains this project's directory structure. Only adds pom.xml and jars which are not published to a maven repo.