{"action":"created","issue":{"url":"https://api.github.com/repos/umple/umple/issues/751","repository_url":"https://api.github.com/repos/umple/umple","labels_url":"https://api.github.com/repos/umple/umple/issues/751/labels{/name}","comments_url":"https://api.github.com/repos/umple/umple/issues/751/comments","events_url":"https://api.github.com/repos/umple/umple/issues/751/events","html_url":"https://github.com/umple/umple/issues/751","id":135462244,"number":751,"title":"Replacing the current build system (Ant) with Gradle","user":{"login":"Nava2","id":302365,"avatar_url":"https://avatars.githubusercontent.com/u/302365?v=3","gravatar_id":"","url":"https://api.github.com/users/Nava2","html_url":"https://github.com/Nava2","followers_url":"https://api.github.com/users/Nava2/followers","following_url":"https://api.github.com/users/Nava2/following{/other_user}","gists_url":"https://api.github.com/users/Nava2/gists{/gist_id}","starred_url":"https://api.github.com/users/Nava2/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Nava2/subscriptions","organizations_url":"https://api.github.com/users/Nava2/orgs","repos_url":"https://api.github.com/users/Nava2/repos","events_url":"https://api.github.com/users/Nava2/events{/privacy}","received_events_url":"https://api.github.com/users/Nava2/received_events","type":"User","site_admin":false},"labels":[{"id":272502596,"url":"https://api.github.com/repos/umple/umple/labels/build","name":"build","color":"eb6420","default":false},{"id":252701501,"url":"https://api.github.com/repos/umple/umple/labels/eclipse","name":"eclipse","color":"ededed","default":false},{"id":252704426,"url":"https://api.github.com/repos/umple/umple/labels/Maintainability","name":"Maintainability","color":"ededed","default":false}],"state":"open","locked":false,"assignee":{"login":"ahochheiden","id":10782766,"avatar_url":"https://avatars.githubusercontent.com/u/10782766?v=3","gravatar_id":"","url":"https://api.github.com/users/ahochheiden","html_url":"https://github.com/ahochheiden","followers_url":"https://api.github.com/users/ahochheiden/followers","following_url":"https://api.github.com/users/ahochheiden/following{/other_user}","gists_url":"https://api.github.com/users/ahochheiden/gists{/gist_id}","starred_url":"https://api.github.com/users/ahochheiden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ahochheiden/subscriptions","organizations_url":"https://api.github.com/users/ahochheiden/orgs","repos_url":"https://api.github.com/users/ahochheiden/repos","events_url":"https://api.github.com/users/ahochheiden/events{/privacy}","received_events_url":"https://api.github.com/users/ahochheiden/received_events","type":"User","site_admin":false},"assignees":[{"login":"ahochheiden","id":10782766,"avatar_url":"https://avatars.githubusercontent.com/u/10782766?v=3","gravatar_id":"","url":"https://api.github.com/users/ahochheiden","html_url":"https://github.com/ahochheiden","followers_url":"https://api.github.com/users/ahochheiden/followers","following_url":"https://api.github.com/users/ahochheiden/following{/other_user}","gists_url":"https://api.github.com/users/ahochheiden/gists{/gist_id}","starred_url":"https://api.github.com/users/ahochheiden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ahochheiden/subscriptions","organizations_url":"https://api.github.com/users/ahochheiden/orgs","repos_url":"https://api.github.com/users/ahochheiden/repos","events_url":"https://api.github.com/users/ahochheiden/events{/privacy}","received_events_url":"https://api.github.com/users/ahochheiden/received_events","type":"User","site_admin":false}],"milestone":null,"comments":48,"created_at":"2016-02-22T16:07:17Z","updated_at":"2016-11-07T16:00:18Z","closed_at":null,"body":"## Brief Description\n\nCurrently, we use [Apache Ant](https://ant.apache.org/) which does the job as we need it. Unfortunately, as the project grows and becomes more complex, we are adding complexity and require flows that don't \"blend\" with Ant's XML build files (e.g. [1](https://github.com/umple/umple/blob/master/build/_template.xml#L14-L50), [2](https://github.com/umple/umple/blob/master/build/build.deps.xml#L53-L91), [3](https://github.com/umple/umple/blob/master/build/build.deps.xml#L164-L197)). I fear that over time, this system has developed a significant \"code-smell\" that will degrade over time. \n## Proposal\n\nI would like to use a more modern build system, [Gradle](http://gradle.org/whygradle-build-automation/). Gradle is a [Groovy](http://www.groovy-lang.org/)-based build tool that allows the full expressiveness of Groovy with the build power of Ant/Maven. \n\nTo do this, I would like to do this in parallel with the Ant build. I believe it is \"too big too fast\" to swap it out without running both side-by-side for a period. Luckily, our current CI tools will allow us to do this as time progresses. Additionally, there would need to be milestones before eventually deprecating the old system (i.e. updating documentation, getting individuals up to speed). I would like to keep simple tasks available, for example: `gradle quickTest:BuilderTest` would run the cheatsheet equivalent of: `ant -DshowJunitOutput=true -Djunit=BuilderTest -f build.umple.xml resetUmpleSelf compile template.test`.\n\nThis issue is a discussion thread, there would need to be more milestones created and \"attainable goals\" should this be accepted. \n### Pros\n1. Full access to Groovy\n2. Build logic works in dependency graphs (only build a->b->c if necessary)\n3. Battle tested by massive projects (e.g. Android)\n4. Allows for [polygot builds](http://gradle.org/why/polyglot-builds/)\n5. Automatic parallelism in the build chain based on dependency graphs\n6. Tight integration with Ivy\n7. Acceptable point to improve/change build commands\n### Cons\n1. New tooling, new work flows\n2. Will require time running in parallel\n3. Groovy is not XML (which everyone knows)\n4. Change\n## Counter build tools\n### Maven\n\nMaven is another XML build tool, but due to the XML nature of it, I do not see it being a significant benefit over the current Ant implementation. I also have a personal bias against it for being overly complicated. \n"},"comment":{"url":"https://api.github.com/repos/umple/umple/issues/comments/258876063","html_url":"https://github.com/umple/umple/issues/751#issuecomment-258876063","issue_url":"https://api.github.com/repos/umple/umple/issues/751","id":258876063,"user":{"login":"Nava2","id":302365,"avatar_url":"https://avatars.githubusercontent.com/u/302365?v=3","gravatar_id":"","url":"https://api.github.com/users/Nava2","html_url":"https://github.com/Nava2","followers_url":"https://api.github.com/users/Nava2/followers","following_url":"https://api.github.com/users/Nava2/following{/other_user}","gists_url":"https://api.github.com/users/Nava2/gists{/gist_id}","starred_url":"https://api.github.com/users/Nava2/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Nava2/subscriptions","organizations_url":"https://api.github.com/users/Nava2/orgs","repos_url":"https://api.github.com/users/Nava2/repos","events_url":"https://api.github.com/users/Nava2/events{/privacy}","received_events_url":"https://api.github.com/users/Nava2/received_events","type":"User","site_admin":false},"created_at":"2016-11-07T16:00:18Z","updated_at":"2016-11-07T16:00:18Z","body":"> > I think it is better to remove those , from the argument because it will be more close to what we get from the command line. \r\n> \r\n> From what I've read, this is exactly how you specify command line arguments in Gradle.\r\n>\r\n> http://stackoverflow.com/a/19256949\r\n\r\n[This](https://github.com/umple/umple.gradle/pull/2#discussion_r86768230) comment chain addresses the issue with command line arg parsing. 👍 \r\n\r\n> > Furthermore, I think it would be much better to design several tasks inside the plugin that allows us to directly generate code in a language. Each language will have its own task. This will provide not to deal with arguments. You can also provide an optional parameter for those tasks by them you can specify the destination location. \r\n>\r\n> Why would that be better? That's just going to be copy pasting what I have a bunch and changing one line, and any time you want to change the main logic in one you have to go and change all of them. I haven't quite figured out how to pass parameters from one task to another without using the global namespace, but if I can get that to work, I'd be fine with opting to do that instead of -P command line arguments stuff. I definitely disagree creating tons of tasks fro no real gain though.\r\n\r\nI think I agree with @vahdat-ab sentiment, but disagree with the task part. Utilizing a single task with multiple _configurations_ makes more sense. For example, given a `sourceSet`, if we can set the generator to be Java or Cpp at that level, it is very useful. Even better is if we can set an array of configurations. This is definitely possible and I think solves both of your concerns. \r\n\r\nA non-working, idea would be: \r\n\r\n```groovy\r\nsourceSets {\r\n  main {\r\n    umple {\r\n      generator: \"Java\"\r\n      // path: Take the output path from gradle\r\n    } \r\n  } \r\n}\r\n```\r\n\r\nObviously this is a bit down the road, but it is more or less to showcase what I meant. Keep as much configuration in the build files as possible, command-line args are annoying to maintain. \r\n\r\n> > Furthermore, the classpath concerns should be documented because it is critical for people who will use the plugin.\r\n>\r\n> What classpath concerns? What Kevin just mentioned? Or by concerns do you mean the problems I had getting it to work? I still haven't solved all the problems in that domain either, right now I'm specifying it via a dependency block, and I'm not sure if I can change those later in the build to use a different one. (like the freshly built compiler)\r\n\r\nThis would definitely be documented, but for the most part, it shouldn't actually be something someone would change. For example, users (non-dev) would have the compiler installed via Ivy and they are never the wiser. For developers, we have a specification in the `umple { }` directive in the build script to override the Jar file and should likely have a command-line argument too. But this is a bit outside the scope currently, I think. \r\n\r\n> I'm aware, I just wanted to expect the output somewhere and not have to go look for it. I didn't see a problem with temporarily giving multiple purposes to that folder.\r\n\r\nOf course, that makes sense. \r\n"}}
{"actor":{"display_login":"Nava2"}}