{"action":"created","issue":{"url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/112","labels_url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/112/labels{/name}","comments_url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/112/comments","events_url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/112/events","html_url":"https://github.com/SpongePowered/SpongeCommon/issues/112","id":97956063,"number":112,"title":"Implementation Repo Changes","user":{"login":"Zidane","id":744482,"avatar_url":"https://avatars.githubusercontent.com/u/744482?v=3","gravatar_id":"","url":"https://api.github.com/users/Zidane","html_url":"https://github.com/Zidane","followers_url":"https://api.github.com/users/Zidane/followers","following_url":"https://api.github.com/users/Zidane/following{/other_user}","gists_url":"https://api.github.com/users/Zidane/gists{/gist_id}","starred_url":"https://api.github.com/users/Zidane/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Zidane/subscriptions","organizations_url":"https://api.github.com/users/Zidane/orgs","repos_url":"https://api.github.com/users/Zidane/repos","events_url":"https://api.github.com/users/Zidane/events{/privacy}","received_events_url":"https://api.github.com/users/Zidane/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/SpongePowered/SpongeCommon/labels/high-priority","name":"high-priority","color":"e11d21"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-07-29T14:57:38Z","updated_at":"2015-08-06T03:45:12Z","closed_at":null,"body":"Pinging @SpongePowered/developers \r\n\r\nThis has been brewing internally for a bit but now we want to take the first steps at fixing up our repo setup so that it isn't so painful to work on the Sponge implementation. Here is what needs to happen (looking at you @Minecrell ). Any assistance you can add would be great @AbrarSyed .\r\n\r\n1. Rename Sponge to SpongeForge. Only happens when the below is finished.\r\n* Adjust classpath of SpongeVanilla to org.spongepowered.server. I do NOT want to rename SpongeForge's classpath as I don't want anyone confused about the fact it would become org.spongepowered.forge. Changing Vanilla's makes a lot more sense as SpongeVanilla is actually the full server modification (instead of being a mod for another one).\r\n* Remove building of SpongeCommon in SpongeForge and SpongeVanilla. This, in lack of better words, turns SpongeCommon into just a sourceset in those projects. This will cut down the setupDecompWorkspaces to 1 per impl.\r\n* SpongeForge and SpongeVanilla need to have the runDir added to their scripts (or perhaps to the common one) so that gradle runServer/runClient will have its root in the run directory.\r\n* SpongeForge should remove the subfolders for server and client in its run directory. This is not needed whatsoever.\r\n* Come up with a mechanism to handle the hassle with dealing with submodules. This is not an open invitation to some bastard \"run a shell script and it will setup some symlinked workspace for you\". I'm thinking of an optional thing to run (as part of the toolchain) that would not only update submodules but also do setupDecompWorkspace. I welcome ideas on this one.\r\n\r\nI'm aware I said that we would merge back into one repo. After thinking about it and hearing both sides, it would fix some issues but bring about new ones that would go against the spirit of this project (and definitely against Vanilla).\r\n\r\nAt this point, this is higher priority than anything else on our plate.\r\n"},"comment":{"url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/comments/128226967","html_url":"https://github.com/SpongePowered/SpongeCommon/issues/112#issuecomment-128226967","issue_url":"https://api.github.com/repos/SpongePowered/SpongeCommon/issues/112","id":128226967,"user":{"login":"DarkArc","id":778012,"avatar_url":"https://avatars.githubusercontent.com/u/778012?v=3","gravatar_id":"","url":"https://api.github.com/users/DarkArc","html_url":"https://github.com/DarkArc","followers_url":"https://api.github.com/users/DarkArc/followers","following_url":"https://api.github.com/users/DarkArc/following{/other_user}","gists_url":"https://api.github.com/users/DarkArc/gists{/gist_id}","starred_url":"https://api.github.com/users/DarkArc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DarkArc/subscriptions","organizations_url":"https://api.github.com/users/DarkArc/orgs","repos_url":"https://api.github.com/users/DarkArc/repos","events_url":"https://api.github.com/users/DarkArc/events{/privacy}","received_events_url":"https://api.github.com/users/DarkArc/received_events","type":"User","site_admin":false},"created_at":"2015-08-06T03:45:11Z","updated_at":"2015-08-06T03:45:11Z","body":"#### Git submodule troubles\r\n\r\n> The problem you aren't getting with submodules is the gradle scripts handle dependencies and therefore is superior to git submodules because you don't have to hope that joe developer actually does a submodule update. The goal is to make this stupid simple.\r\n\r\nWell has using a git hook been considered? I'd have to test it to make sure, but this (or something like it) should work: \r\nhttps://github.com/chaitanyagupta/gitutils/blob/master/submodule-hooks/post-merge-checkout\r\n\r\nThe benefit here being, we don't have to invest time in converting the build system, nor concern ourselves with the extra bandwidth. \r\n\r\nAdditionally, has it been considered that we could potentially add onto our gradle build task a git submodule update step? It's not impossible to work with git inside of gradle. \r\nhttp://stackoverflow.com/questions/13719676/gradle-how-to-clone-a-git-repo-in-a-task\r\n\r\nThe mentioned project doesn't currently appear to support submodules, however, it proves the concept of git integration into a gradle build procedure is more than possible.\r\n\r\nOne possibly interesting approach would be to grab the commit hash for both submodules, and match them to what should be checked out. This could allow us to set \"tampered\" flags which would reveal that the build may be invalid, as well as emit warnings.\r\n\r\n#### Lack of my script solution\r\n\r\n> ...and to this day I've yet to see your script solution put onto paper and up for review. This issue was made so that team members could keep up to speed with what is going on AND community members can see that we are moving on solving this issue. This isn't like other projects, I don't keep things behind closed doors.\r\n\r\nI have a lot to do these days, sorry, but I'm not going to be able to put the time in to do it properly, and if I can't do it properly, I'm not going to do it. There's also a large amount of work and knowledge about the current gradle setup required to implement such a thing, both of which as previously noted I don't currently have time for. \r\n\r\nThe attitudes towards a home brewed script solution were also far from enthusiastic. However, what zml has brought to the table, is not unique to Sponge, nor is it -- at least from the surface -- half baked.\r\n\r\nAs for hiding things behind closed doors, I don't see the point in having open contact with a community if you don't give them the means to partake in the discussion intelligently. I'm arguing that there should be more information here, not less. \r\n\r\n#### Core problems\r\n\r\nRegardless of the above, I find distributing jars, or using submodules to be treating the symptom, not the root problem. Which in my opinion anyways, is that our source is divided into several different repositories, each with their own concept of a build system, and two different implementations.\r\n\r\nOne argument for separate repositories is that we can have people work on the API and the implementation. This is one of those things that sounds far better on paper than in practice. What good is an API definition without an implementation? \r\n\r\nAllowing this is like using the waterfall method. Rather than adapting the API as more is discovered about our implementation requirements, we're currently creating it up front. This approach has been proven to be flawed time and time again. How many things have been recoded in Sponge because we decided, \"Oh hey that actually isn't going to be practical to implement?\" or during implementation we discovered \"oh... wait, this doesn't make as much sense as it originally did.\"\r\n\r\nFollowing that conclusion, we hit another road block however when considering requiring an implementation, because at some point it was decided to officially on board Vanilla and Forge. So now we must maintain two implementations with separate bases. It seems unreasonable to require two different implementations with an API PR. \r\n\r\nSo what can we do at this point? \"Version stuff!\" Great... Now we've just made the problem worse. We don't even know what features we have anymore. As @bloodmc has pointed out, the commit log is also not an accurate tale as we have \"Bump common ref\" with the jars, we'll undoubtedly have \"Bump common version\".\r\n\r\nThere is an abstraction @sk89q used in WorldEdit, platforms, which allows WorldEdit to query for features of the implementation. This is a far more reasonable approach, as it allows the implementation to say \"I don't actually support that... please don't touch it...\"\r\n\r\nIf we want to support things as a multi implementation API we should actually do that, rather than praying that somehow implementation A & B can be put into sync, and assuming everything API definition wise can be taken care of ahead of time.\r\n\r\nFollowing this train of thought, also frees us from Bukkit's core limitation, which is backwards compatibly -- and thus refusing to accept API features that could at some point be removed. As with this methodology, you can write your plugin to respond to the lack of a feature, without causing crazy problems, and thus can add more fine grained APIs which leverage current features.\r\n \r\nThis is not pertinent to the discussion, however, I used to say \"Bukkit is a mod, and it should act like such.\" Anything can be removed, and trying to determine the effectiveness of a modding API on the probably that a feature is not removed is a fundamental failure in my opinion."}}