Add maven support

[meta1203]

Tested, it works. This is great for those who want to be able to use maven to manage their dependencies while creating a GP extension.

[andrepl]

not sure how I ended up getting pinged on this, but I did... is github intelligent enough to know that I submitted a SIMILAR Pull request? because that's almost creepy...

Anyway, my attempt was rejected. I wish you luck. :)

for the sake of completeness, here's my pull request: #6

[meta1203]

Huh.
I can understand all the points that Tux2 made in #6 but how would a person who wants to use maven add this as a dependency? One of my WIP plugins forces WorldEdit on plots, and rather than have to build it in eclipse every time and track down the latest dependency's .jar for every update, I use maven.

[andrepl]

you'd have to manually install GP into your local maven repo. see this: http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html

frankly I find all of those points to be irrelevant.

• It clogs up my workflow making a simple compile take 2-10 times as long.

once in a while a build will take longer than usual, but most time, maven has cached the dependencies, so the difference is neglegible.

• I only have 2 dependencies, Vault and Bukkit, which is pretty common and not hard to include in a project

the time required to add the dependencies is irrelevant (and still faster w/ maven, IMO). The collective time saved by everyone who wants to compiles against GP outweighs that. a non mavenized dependency is a wart on any project that uses it, which is the VAST Majority of bukkit plugins.

• Maintaining the maven file would take me more time than actually making the plugin

This is utter nonsense. you can copy/paste a pom file from any other bukkit plugin, change a few variables and be up and running in minutes. pom files almost never need updating, and they can actually save you time by substituting properties like version#'s author name etc into your plugin.yml and other resource files.

• It's a great tool, but it's like using a chainsaw to cut a twig in this context; it gets the job done, but it's overkill and takes longer than just breaking the twig off.

People who want to extend GP have to break the same twigs over and over again, because upstream can't be bothered to adjust. this seems selfish.

[BCProgramming]

First "Why Maven?", and not something else like Ant or Gradle? Forcing every single downstream user to use one build system is more selfish then not enforcing any. It also requires every contributor to use Maven.

Maven is a good example of a solution that has become it's own problem. For two reasons; first Rather than easily solving the problem of complex builds it simply creates another set of technologies, files, and conventions that you need to learn. The second is the collosal mind-share it has somehow gathered; I'm not really sure how it became the go-to dependency management system, since it's pretty crappy at that unless you need it for transitive dependency management, but I guess maybe Lady Gaga or EvilSeph said "I like Maven" and now everybody is batshit insane about how awesome it is while knowing very little about both Maven and particularly any other build systems.

There are certainly circumstances where it can be extremely useful, but I don't think they apply here.

"This is utter nonsense. you can copy/paste a pom file from any other bukkit plugin, change a few variables and be up and running in minutes. pom files almost never need updating, and they can actually save you time by substituting properties like version#'s author name etc into your plugin.yml and other resource files."

At which point, those plugin.yml files become completely useless and the entire project is completely useless to people that aren't using Maven. Forcing a build system on every single consumer of a project is selfish. Not forcing any build system isn't. Right now I can use ANT or even MSBUILD to automate builds of GriefPrevention. If Maven "support" was added it would require Maven, especially if it went the route of using replacable parameters. Worst case scenario one of us would need to figure out why GriefPrevention's Maven configuration should point at the seemingly arbitrary url "http://ci.herocraftonline.com/plugin/repository/everything", at least referring to this particular pull request.

Let's assume this project is mavenized. Great. Now everybody that uses Maven has an advantage, or something. I suppose that depends on if you think maven is a solution to a problem or a problem in and of itself. Of course, now the project stops getting regular updates unless Tux finds some free time, because I'll stop caring. I'll learn maven for a Job or a client but I'm not going to learn it for a bukkit plugin especially when absolutely nobody can quantify any of the benefits, instead preferring to give paragraphs of weasel words. In my own research both as a result of the previous pull request as well as before that (I looked into Maven with a C# project before deciding I didn't really need a build tool) I found Maven to be one of the better solutions if transitive dependency management is required, but I'm not convinced that's needed here; also, the problems it has as a result of being a download/repository system outweigh that. We also would have the issue of people that don't use Maven, who would pretty much be screwed. Now they are forced to learn maven if they ever want to build from source.

[andrepl]

" ... especially when absolutely nobody can quantify any of the benefits, instead preferring to give paragraphs of weasel words."

We were having a civil discussion before this, but frankly, this is overdue...

This attitude is the exact reason I forked GP for my own use and won't bother to work with the upstream project. You, personally, are arrogant, rude and condescending. You treat everyone like garbage by default, and it's a really shitty way to run a project. I wish you luck in your programming endeavours, but I hope our paths don't cross again. you're unpleasant to work with.

[BCProgramming]

It's simply that I count far more points against this than in favour of it.

to repeat, First, we have the problem that any person contributing to or who wants to deal with the source is going to need to have at least a basic understanding of maven. At least enough to get it installed and working.

Second, the majority of those benefiting will be those already using Maven.

Third, we come back to the point I made before, as to why we should prefer one build environment over another. I can't find any reason.

In terms of "weasel words' I was referring to passages like this:

"People who want to extend GP have to break the same twigs over and over again, because upstream can't be bothered to adjust. this seems selfish."

Which by people you actually mean yourself, and by, "upstream can't be bothered to adjust" you mean "upstream won't change for a particular build system". The way I read it, it was conflating your own personal idea of how something should be with how everybody wants it. Everybody who wants to extend GP doesn't use Maven, though that is essentially what is being asserted. Best case scenario then is that those people aren't affected at all. Additionally, if GP was to use it, they would pretty much have to to the exclusion of other build environments. In fact, that is the second instance where you 'weasel worded' your own preferences as being those of everybody:
"The collective time saved by everyone who wants to compiles against GP outweighs that. a non mavenized dependency is a wart on any project that uses it, which is the VAST Majority of bukkit plugins."

The way I'm reading this is the assertion essentially everybody compiling against GP would benefit if GP used Maven, but I don't see this as being the case- the only dependent project on dev.bukkit I could find was the dynmap plugin. For example, though I readily admit my search was very cursory. A non-mavenized dependency is only a concern if a dependent project is using maven to handle it's dependencies. a non MS-Builded project is equally a concern if a dependent project is using MSBuild, same story for many other dependency management and build systems. And many of those selections are in fact mutually exclusive, whereby you cannot use some of them in combination; so in many ways, selecting one build system excludes selecting others. Again, at least as I understand it.

"You, personally, are arrogant, rude and condescending. You treat everyone like garbage by default, and it's a really shitty way to run a project."

I disagree. Wanting to have some actual facts brought into a decision like what build system to use rather than conflations of personal preference as something that would benefit everybody is hardly arrogant, rude, or condescending, or treating anybody like garbage, or a bad way to run a project. I'd argue that not wanting to force every single person who wants to extend or otherwise deal with the plugin on a source basis into using one particular build system without a good reason seems quite reasonable. Just because maven is trendy for Java projects doesn't mean it should be used, in fact, that is the reason I instead want to have a much better reason to use it, and that no particularly powerful reasoning for such a switch has been given aside from points that boil down to either "I want it" or "everybody is doing it" style phrasing so far seems to solidify my original idea that it is merely something that is trendy to do, with questionably present but strangely unspecific benefits; most benefits seem to be exclusive to those that are using maven for a dependent project, but I don't think forcing everybody to use maven to solve one set of people's transitive dependency management is a particularly good one, either.

Just to be clear, Maven or another such capability is not completely off the table, here. I just haven't been convinced, personally, that there are any actual tangible benefits to it, and those things that have so far been mentioned don't agree with those facts I could determine; eg. Even if half the people that had GP as a dependency used Maven for dependency management, that still means half the people don't, and by integrating maven support, we basically kick them in the balls and force them to switch from whatever they are currently using, at least as I currently understand it.

To re-iterate the reasoning so far:

1.Maven requires changes to the arrangement of the source, as well as changes to specific files to properly utilize it. This involves moving the files to a new location dictated by maven, adding the pom file (simple enough) as well as changing files such as plugin.yml to essentially be created as part of the build process by maven.

This has two issues, I feel. As noted, I think this forces pretty much anybody dealing with GriefPrevention or at the very least the source to use Maven. Otherwise, when they build the files will likely be considered to be in a different package, due to the enforced Maven directory structure. This would be exacerbated if plugin.yml were to appropriately take advantage of a build step to add entries to the plugin.yml; at which point, in order for a valid yml, people without maven or who don't want to use it, will have to either make the replacements manually or take the plugin.yml from the appropriate built .jar of the plugin.

1. There is a very real suspicion, on my part, that Maven is a "trendy" system to use. This doesn't inherently give it any merit, and I don't want to be a snowflake in the trending snowball, if that makes sense; If I allow a decision to use a build system to be based on what others are using- rather than specific pros and cons of that build system- I'm not really deciding anything, I'm letting others decide. That's not really a bad thing in the case of a OSS project, but one has to consider the long term survivability of a project that allows the ebb and flow of popular, trendy software management to push the software boat around, rather than aweighing the anchor of consistency. It's certainly possible that following such trends ebb and flow could put the project in a better position, but the best way to come to that determination would be by basing such considerations on known information.
2. The one thing that I would like, and I think this may provide, would be the ability to add new dependencies to GP itself. I wanted to add a dependency on McMMO to cancel Bleed events, for example; while I was able to do that locally, the Jenkins build failed. I don't know if Jenkins has maven support but if it did this issue could have been fixed by adding a dependency on McMMO; OTOH I don't actually have access to the Jenkins so wouldn't be able to change it initially to support maven (A cursory search says that it is indeed possible).

of course that's where we come to the crux of the consideration; it is mere luck for the above circumstance that mcMMO does support maven, and in that case it would be very useful to have that support to add a dependency on it. This is probably the 'problem' that maven support would be designed to address; the problem of people using Maven being able to add GriefPrevention as a transitive dependency, as we can do with McMMO. But the thing is that while it would make that easier (or even possible, though based on the previous comments it's possible to add it manually even if the dependency isn't "mavenized"), it would provide no benefit, and in fact even some negative aspects, to those dependent projects not using maven. At least again, through my understanding of it; I've mentioned this perceived limited repeatedly, and I don't think anybody has corrected it, so I assume it is the case? Is it possible to provide maven support without affecting projects dependent on GriefPrevention that don't use Maven?

I can sort of see it from the other side, what with the devotion of time to create the contribution, and that is appreciated; but the way I see it is that this contribution amounts in many ways to forcing a particular build system on the project and possibly those projects dependent on it; or at the very least the biggest benefits would only be seen by those that use Maven; but at the same time, other build systems provide similar functionality. Personally I prefer to remain "build system agnostic", but if there is some actual citable benefit that doesn't use weasel words (And I did not mean this in a defamatory way, it's likely they weren't used purposely in that way, but to me that's how they read) Then I'm open to the idea, particularly if some of the cons I've listed are in fact misconceptions.

[Tux2]

I don't use maven and I don't want to be forced to use it. It's slow and cumbersome on my computer and I've been forced to use it with several projects and it wasn't a pleasant experience. Builds that would have taken me 2 seconds to build took 5 minutes with maven, even with all the stuff cached... I don't really care to go down the maven road again.

[andrepl]

@BCProgramming You already closed this PR before even bothering to comment so any discussion is pretty pointless. It seems like you made your mind up a while ago. That wall of text is only going to be seen by 3 people now, and frankly, I didn't even read it because I don't have any interest in the outcome, use what you want.

[Tux2]

@andrepl sorry about the wall of text. BCProgramming can be quite blunt and direct sometimes. If there was a way to do this without interrupting our current work flow it would definitely be something we would consider. I personally do not like maven at all, and I've used it on a few projects. Cached or not it seems bulky, bloated, and slow on all but the biggest projects with millions of dependencies. I build a jar in under a second with my current setup. With maven, it takes over 30...

[BCProgramming]

I closed the PR because there was no new information that tipped the scales towards using Maven or really any Transitional dependency manager, and there was nothing I could add, at the time I closed it, that I hadn't already said in the previous PR. I responded to comments after it was closed, resulting in this discussion. I'm certainly willing to consider this idea if given some concrete examples of possible benefits it could have on the workflow as well as any information on whether dependent projects would require maven or would just be able to use it optionally. So far I count being able to put placeholders in the plugin.yml and being easier to manage by those using it as a dependency, (and presumably being able to manage GP's dependencies as well, which would be useful for various soft-dependencies) but not all people using GP as a dependency are using Maven. If it was a majority, I could see it being a reasonable consideration to add that support, but I'm not able to confirm that that is the case, only one dependent plugin I found is using Maven for Dependency management.

[andrepl]

@Tux2 no hard feelings, like I said I have no desire to push anything on anyone. to be clear, I forked for several reasons, none of which had anything to do with Maven. It was almost entirely because I wanted freedom from backwards compatibility concerns and freedom to remove/break features willy-nilly. BC's bad attitude only caused me to not bother with any non-bug-fix contributions (and to even avoid the questionable ones).

@BCProgramming closing the PR without any response from someone actually involved in the development team is not only unprofessional, it's also all those other negative qualities I listed before... I know you disagree, that's what makes it worse. You should leave public relations to Tux.

[meta1203]

Woah!
@BCProgramming If you want reasons for maven, I can give you a couple of the reasons why I think it would be a good addition, and negate some of your points.
I understand that a workflow change would be necessary for maven, but it would not be drastic. Right now you have an "src" folder containing the source, with plugin.yml at the root. With maven, those would translate to "src/main/java/" and "src/main/resources/plugin.yml". The bin folder is unnecessary, as it will be replaced by "target" once built. All other packages, files, coding conventions, etc will stay the same. Also, the "plugin.yml" does NOT need to be generated with maven. Anything put in the "src/main/resources/" will be packaged into the jar at build time.
Maven's pom.xml is difficult, if you want it to do more that what this project needs. For example, I package BitcoinJ with Satoshis to bundle the goods together so that a manual classpath is unnecessary. But, as you know, this project doesn't need that, so the pom.xml stays small and neat.
Maven may not be the only build system out there, but it is one of the most compatible. Most people use either Ant or Maven, but usually Maven if there are dependencies to be wrangled. The ability to change a number and have a dependency pulled on the next build is IMHO a much better way than throwing .jars at a piece of code. Sure, Maven isn't the only build system out there, but it is one of the most popular. Also, you make the point that EVERYONE would have to use maven to compile the dependency. While that is true, I can assume that no one here would want to compile GP by hand. The amount of poking around in a .zip file is just redundant with build systems. Not to mention that the compiled .jar would still be compatible with other build systems. I know ant takes a jar file happily.
Also, Jenkins is practically MADE for Maven. It's high level of integration makes it perfect for this sort of project (Mavenized, of course :P)
One last thing about universal Mavenization: It isn't required. We could continue on our happy ways without maven in GP. All we would have to do is pop the .jar into our repos and watch it go. But we want maven for simplicity. One of the ideas behind maven is portability, that a jar can be made on any machine with a JDK. We don't want maven because we "OMG HAVE TO HAVE MAVENZ" but rather because it is a nice way to deal with dependencies.
Hope that changed some Cons into Pros for you guys.

[BCProgramming]

@meta1203
Thanks, very informative and it answers pretty much all the concerns I had.

Primary among them was whether the .jar could still be used normally, which I suspected to be the case, but couldn't find any documentation on. (Maven's docs seem to be a bit lacking, but StackOverflow appears to cover much of what is missing) The second was of course source compatibility that would allow for builds by those without a maven environment. It sounds like that wouldn't be a problem, and would in fact require conscious effort (in terms of adding replacable build parameters).

I figure it would also have the advantage of making it possible to add dependencies without having access to jenkins (beyond of course setting up maven support for it originally) presumably from that point new dependencies (soft or otherwise) could be indicated by changing the pom.xml file.

The ability to change a number and have a dependency pulled on the next build is IMHO a much better way than throwing .jars at a piece of code.

I'm guessing this is advantageous in both ways; eg. GP could be quickly tested on a new Dev build of bukkit by changing the POM without having to mess about with Eclipse or IDEA project files and references. I believe both have some sort of support for Maven within their project management, as well.

One of the ideas behind maven is portability, that a jar can be made on any machine with a JDK.

Well, and Maven, presumably.

Well so far I'm convinced that it probably won't have any negative effects on those devs that aren't using maven for dependency management, though there is still the issue of having to become familiar with the basic workings of Maven (again). Of course this gives me a very good reason to switch to IntelliJ entirely since it appears to have much cleaner Maven support than Eclipse. Dev builds using Jenkins would require changes by Tux2 as well, so it's up to him on that one particularly. If we can convince him to install and configure the maven jenkins module I'd tag along :P

Fundamentally I'm trying to keep the amount of work, such as performing commands, editing configs, etc. required for making changes to a minimum; It's already more work to work on GP in terms of steps to commit than my C# Projects, with which Git is integrated directly into Visual Studio, whereas with Eclipse I've ended up having to use the command line. I personally want to avoid putting too many barriers to make changes otherwise I'll probably just end up working on others stuff :P Heck I even made a python script for packaging up the .jar faster, because right-clicking and choosing "Compress to zip" was too much work.

I'm supposing that it would be possible to create a jar as part of the maven build process, meaning that while it might be a bit of effort to get the original setup working I'm thinking that, hopefully, once that is done it might be possible to reduce the "mindshare" the project requires for add->test->edit->test cycles.

Do you have any insight into how the repository part works? How I understand it is it would be possible for projects that depend on GP (and use maven for handling dependencies) to essentially refer to whatever the latest build is, and the next time they build it would update to that latest build if necessary. I notice you refer to a particular repository in the pull request's added pom.xml, can you offer any insight into how that part works and how it would fit into the build process? I am guessing it could be made automatic for certain build configurations, but I'm particularly curious what it would take to create such a online repository and what sort of webhost resources would be required, or whether there is some free central repository. I'm also curious how well it integrates with Eclipse, as I wasn't able to really get it working well (Only tried for about a half-hour). I was going to swap over to IntelliJ in the morning since I recall several references to maven in the menus when I was messing about with it previously.

On the flipside, if we don't go with the maven route, is there any other change that might make it easier to integrate the resulting .jar into a maven build process, or is that something that is essentially manual in that circumstance?

[BCProgramming]

alrighty, Since this pull request would require some conflict resolution with the current master branch, which would make things confusing, I decided to give this a try myself. Of course if this actually get's pulled into the master branch the motivation and credit would go to AndrePL and yourself. It's not anything of the sort that I want to steal credit, I just think it seems reasonable that if I'm going to be dealing with Maven I should at least know how to migrate a project to it, if that makes sense.

What I ended up doing was trying to use IntelliJ IDEA's ability to import from a maven project pom.xml; I basically copied the pom.xml file from this pull request. I changed the version from 7.7 to 7.8, though, but I don't know if that would do anything.

I put the pom.xml file in the root eclipse workspace folder for GriefPrevention. Then I moved the entire me directory to directory to src/main/java; eg. so for example GriefPrevention.java moved from src\me\ryanhamshire\GriefPrevention\GriefPrevention.java to src\me\ryanhamshire\GriefPrevention\GriefPrevention.java

I was able to use IntelliJ to import the project through the maven file, and it appeared to work. However attempting to build indicated that, there was in fact a missing reference to Vault. eg. "java: \src\main\java\me\ryanhamshire\GriefPrevention\Configuration\WorldConfig.java:19: package net.milkbowl.vault.economy does not exist"

I got a similar error when I performed a similar series of steps with Eclipse's Maven integration.

Other than the missing references/packages, it doesn't give any other errors though, so not sure what is wrong.

This sort of brings me to another question, particularly with eclipse. I had to 'import' the project, but does this mean that it will no longer use any maven configuration or dependency management for builds, or am I misunderstanding? If I was to change pom.xml and add a file or try to get Vault added, would Eclipse recognize that and add the dependency?

Right now I just added it to the Eclipse Project Java Build Path, but am certain this is something of a hack solution.

I committed the change which of course has broken the Jenkins build system, so the "ball is in Tux's court" in a manner of speaking. If you can look over that commit though and tell me what problems there are I would appreciate it :)

[ryantheleach]

would Eclipse recognize that and add the dependency?

for the most part, yes, as long as its been imported as a maven project. the plugin m2eclipse is needed but seems to be packaged with eclipse for java and eclipse for java EE these days.

[riddle]

@Tux2 We’re looking for a nasty DB slowdown on server shutdown in 7.8 and forked GP to Mavenize it. Build time on our Jenkins, 3s. Not sure where you get your 30.

Anyway, I hope I won’t need to maintain the fork forever, we just want to find the bug and fix it.