UCOSPLogAlexHochheiden

Each UCOSP participant is asked to log all the steps they take as they make progress through the semester. This includes difficulties they faced (getting set up, understanding how to model in Umple, using UmpleOnline, code that is difficult to figure out, and development tools that are hard to figure out, or don't seem to work properly). The more log entries added the more we can better get a grip on the usability issues with Umple, and the more we can help future new contributors come up to speed.

Please record entries in reverse chronological order

Log Entries

###December 6th Addressed Kevin's main comments for my pull request on the umple gradle plugin. The nested file structure with the libs directory has been resolved, the directory is now just in the root folder of the umple gradle plugin, instead of one layer up. I think this will also resolve his problem of it not building out of the box (it does for me, with or without the recent changes). Next I'm looking in to adding the tests as he specified with the gradle check task.

I was also able to get ownership of the umple gradle plugin on the gradle plugin portal transferred to Tim's account. Once these changes are finalized I'll need to get him to publish the plugin again, or give me access to the new API keys so that I can do it myself.

Date

###November 28th I had a busy week since it's near the end of the semester (projects, papers, presentations, etc.), but I managed to get a few things done that I had planned for Umple/Gradle.

I made a forum post on the Gradle forums asking for them to transfer ownership of the plugin for my account to Tim's. They haven't responded yet, but I'm sure they'll get around to it.

I also updated the ReadMe on the Umple Gradle Plugin Repo. As I mentioned previously I needed to get some sort of documentation, and I think what I have there now qualifies. From my perspective it contains all the information you need to be able to use the plugin. I also left some tips/recommendations to use other plugins in conjunction to download the Umple compiler, basically just recording some of the stuff I found out on my own that I found useful.

I still need to get some work done on the bootstrapping task in the main Umple Repo build script, but I won't have much time in the next few weeks. Hopefully Tim will give me an extension and I can get some work done on it after final exam season is over. I also need to ask Kevin some questions about Ivy, since it looks like the Ant script does a lot of setting up for Ivy. I recall Kevin previously stated that Gradle has a 'tight integration with Ivy', so hopefully he'll be able to give some valuable insights.

###November 22nd I looked into having multiple tasks for each language to generate for the gradle umple plugin, but I really don't like that approach. I've decided to abandon it and keep it purely configured via project properties. This will allow the user to either use it with command line arguments, or set the project properties in a build script dynamically as they wish. I prefer the setting it in a build script, which is also what Kevin recommended.

I still need to update the documentation with some sort of a user guide, and also cover some of the details of my implementation. I think it's also a good idea for me to add that to the umple plugin description under the publishing, since I don't think there's any documentation included other than that and the link to the main Umple website, maybe we should point it to the umple gradle plugin repository on github instead? Something to think about.

I also still need to transfer ownership of the plugin on the gradle plugin portal to Tim. I should only have to make a forum post and it should be taken care of, at least that's what my google searches showed, we'll see though.

After I take care of this minor things I'll be working on the build script in the Umple repo, hopefully I can get the bootstrap working before the semester is over.

###November 14th I spent way too much time chasing my tail trying to do something that wasn't possible in Gradle, at least as far as I can tell. I was trying to use tasks like functions and give them parameters, and call tasks from inside other tasks, all of that isn't possible. I've learned that to get values from one tasks to another you need to have variables declared beforehand in some common scope, (like the project properties, or just the class) and manipulate those.

I knew that you could specify mustRunAfter/shouldRunAfter to get around weird stuff with depends on, but for some reason it's not working the way it should. I left a comment on the main issue and hope Kevin/Vahdat have some insight.

I figured out how to use a different plugin to download the stable release from http://cruise.eecs.uottawa.ca/umpleonline/scripts/umple.jar and place it in a static directory where the plugin expects it, so that's good. Right now it's only in the build script in the main umple repo, I had some troubles trying to get that task to run prior to my build for the plugin, but I think it should be possible to get that to work as well.

Once that's working it'll be easier for other people to help me out, since you'd just need to switch to my branches on both repos and do a few command line instructions and you'll see exactly the same stuff I see. The way it was working before you had to manually download these files and put them in the right spots, which was a lot less convenient.

I also managed to get the publishing working. I published my 'alpha' version of the plugin on the Gradle Plugin Portal and was able to use it in the build script in the main umple repo, so it's nice that that works. I decided to change that build script back to use the locally built plugin jar, so that I don't have to publish the plugin every time I make a tiny change to the plugin source code.

I definitely need to add some documentation on that page though, which is done through the build.gradle file via the description parameter in 'pluginBungle'. One thing to note is that I published the plugin through an account I registered for myself on the Gradle website. There's some API keys associated with my account that I used to publish, which I think will need to be shared somehow to anyone who works on the plugin so that they can publish as well. Not entirely sure of that, but it's not too important at the moment.

Gradle can definitely do some neat stuff, but so far I've found it really frustrating to work with. At first I thought it was just difficult because I'm not that familiar with Java, but now I'm finding that writing the Java code is trivial. My main grievance is that the errors you get from Gradle through the command line aren't very helpful. Even with the --debug and --info options the information you get is close to useless the majority of the time, even if you search google or stackoverflow. The documentation has some examples, but a lot of the times the examples don't work as stated, which leads me to believe that the documentation isn't quite up to date.

A lot of the posts I find on the internet for help all seem rather old too, 2012-2013 ish, and you see the 'incubating' tag all over the place in the Gradle docs, which basically means it's a test feature, no promises if it does what we say it does, or if it'll do what we say it did in the future. Just from my experience so far these things make it annoying to work with. I'd much rather work on something old and stable, where I can google any trivial thing I want to do and have 20 solutions, rather than finding these convoluted workarounds for basic things I want to get done.

###November 8th Updated my plugin to allow the ability to specify multiple arguments via multiple project properties in Gradle on the command line. This solves the problem of having to parse comma separated values. It was suggested by Kevin and works well.

###November 1st - November 7th I spent a significant amount of time working on the Gradle Umple Plugin and I finally got it working. I had a fundamental misunderstanding of how the plugin worked. I assumed that it packaged the umple compiler jar inside the umple plugin jar, but this was not the case. The umple compiler jar had to be specified for the build script in which the gradle umple plugin was being used. Kevin pointed me in the right direction on that one.

I also had some trouble specifying the classpath for my plugin and the umple jar, but in the end I got it to work. It definitely took a lot longer than I would have expected, but I think part of that is just as a result of my unfamiliarity with Java/Gradle/Groovy in general. Vahdat was of some assistance for getting the plugin to work.

I also added some static library directory in the root folder of both repos, so that I can just call the build on my plugin, then build on my script in the main umple repo and see the results, without having to move any of the jars manually, this allows for much quicker testing.

I added some code for publishing the plugin to the gradle plugin portal, but I haven't used it yet since the plugin isn't entirely complete.

The good news is that I now have a functioning prototype. There's still some minor changes to make that Vahdat and Kevin suggested, but I can call my plugin to compile umple files, which is good progress in my book.

I find Gradle very hard to work with. The documentation isn't very helpful at times and makes a lot of assumptions. My main grievance is that the code samples they show aren't the entire file. A lot of the time there's something else in the file that's necessary, that the person who wrote the documentation just assumes you know about already.

###October 22nd I spent some more time on this, and I think I managed to allow the plugin to take parameters from the command line, but I'm not able to test it yet. Right now I'm using the project properties to get the arguments, then splitting them and passing them to the UmpleConsole, this should work, I just think I might get a syntax error. Right now I'm working on figuring out how to test/use my plugin in a different build script.

If I can get that to work that'll be a huge step forward. I'll be able to specify arguments as parameters in a task, and have that task call/depend on my plugin task that runs the console and produces the output files. https://docs.gradle.org/current/userguide/plugins.html#sec:applying_plugins_buildscript appears to be what I want, since my plugin isn't published and is merely a prototype, but I'm not sure where to place my plugin jar relative to the build script, the documentation isn't quite clear. I'll try to look at some existing projects doing similar things to figure out what I'm missing.

###October 19th I made some progress in the plugin after asking for help from Kevin and Vahdat. Using Vahdat's code I was able to compile a .ump file through Gradle with hard coded parameters, which was progress. Kevin saw Vahdat's code and didn't really like how it was doing it, and figured out the problem with the dependencies I was having and managed to get the Umple jar in to the plugin a different way. He also set up the plugin as a standalone project, where as mine had just been in a build script, this was helpful.

###October 17th Began work on the Umple plugin. Updated the license and governance files to match those in the main Umple repositrory, then started small with a "Hello, World!" plugin in Gradle as Kevin had suggested. I'm a little behind schedule, I'd hoped to have finished the next few milestones by tomorrow, but that's probably not going to happen. I will do my best to catch up over the next week (Wish should be doable since I have no other major commitments for almost a week).

###October 13th Had my meeting with Kevin and Vahdat. Kevin was extremely helpful and established a starting point for the migration. He suggested the first thing we do is make a Gradle plugin for Umple. This will be used by pretty much all of the build scripts, and it will also allow third parties to use Umple however they wish to generate source code.

He created a list of small milestones for me in regards to creating this plugin and I will begin working towards them. Hopefully I will have good news by the next teleconference on Tuesday.

###October 11th Following the meeting with Vahdat I've just been thinking about the things I could/should do for the Gradle project. I think it would be useful to make a dependency graph, so we have a visual representation of all the various dependencies in our build. This would make it easier to see how everything ties together, and make not only creating, but maintaining the Gradle build scripts easier in the long run. For this I was considering Graphviz, you follow the syntax and then just generate the graph. This would allow future developers to easily modify the dependency graph when necessary.

Next would be just recreating all the build scripts in Gradle. I think the migration of every script would be a milestone. Making each individual script a milestone would be odd, since there are so many. I think once the first few are done, the rest shouldn't be too hard to implement.

After that would be documentation, which is basically just making a separate wiki entry for the Gradle build, detailing everything.

Once that's done, we'll need to add the Gradle build to our build server/CI.

I can't think of anything else that would need to be done aside from those tasks. As such, there's 4 tasks.

• Creating a dependency graph (small task)
• Recreating every build script in Gradle from scratch (large task, with many small subtasks)
• Creating a new wiki entry detailing the Gradle build process (medium task)
• Integrating the Gradle build with the build server(s)/CI (small-medium task?)

I have a meeting scheduled for Thursday with Kevan, and Vahdat, potentially Tim and Andrew as well. I think I'll have a better grasp of where this project is headed afterwards.

###October 6th I spent a lot of time reading through the Gradle documentation. I came across a section regarding Ant, and found out of Gradle's capability to import and existing Ant build. I decided this seemed like a good starting point for transitioning to Gradle, so I went ahead and tried it.

I was able to successfully import the Ant build scripts into Gradle, the problem is that when I attempted to run them there were build errors related to Ivy. (Some of the test scripts also have strange errors, they may be related to a relative path issue though) I spent some time troubleshooting the problem. My first instinct was to install Ivy through Chocolatey, since I remembered that during the Dev Environment setup this was done through Eclipse instead. This didn't solve the issue. I spent a while trying a few other things, but I haven't been able to resolve it yet.

I'll spend some time looking through our Ant scripts to find the source of these paths that Gradle can't find. If they're not in the existing Ant scripts, that will mean that Gradle added them itself, which means I will have to figure out how to properly include/reference them.

###October 5th After choosing the issue of transitioning our build system from Ant to Gradle it seemed to me that taking care of (https://github.com/umple/umple/issues/877) seemed unnecessary. Adding the Umple Eclipse plugin to the Ant build, when I'll just be replacing it with Gradle seemed a bit wasteful. I sent an e-mail to Tim and Vahdat regarding this, and Vahdat agreed. As such, I left some comments indicating this in (https://github.com/umple/umple/issues/877) and closed it. I then updated the Gradle transition issue (https://github.com/umple/umple/issues/751) and left a comment indicating my intentions. I'm now reading through the Gradle documentation so that I can understand how it works before I begin.

###September 28th - October 4th I spent some time reading through more Ant documentation in preparation for taking care of (https://github.com/umple/umple/issues/877). I also looked in to Maven for a bit, since Vahdat said we might be making the switch to that, and I was interested in doing the switch for my term project. During the teleconference this week, I was informed we would be moving the build system over to Gradle, not Maven, so my reading on that was somewhat wasted, but it was insightful nonetheless. It was confirmed that I would be tasked with the transition to Gradle, and that it will be my term project for Umple.

Also, I will be transition to twice-weekly logging from now on, as per recommendation from Tim.

###September 21st - September 27th, 2016 This week was the Code Sprint in Toronto. It was nice to finally meet the team in person and be right next to each other to ask questions as we were working on issues. I was somewhat productive the first day. I chose a pretty basic issue to resolve, which was removing some compiler warnings. I had some trouble finding out how to add compiler arguments to ant so that I could actually track down the specific warnings. I was able to find out how to do it by reading through the ant documentation and digging in to our build for a bit.

Once I was able to see what was causing the warnings, it was fairly trivial to make the necessary code changes to resolve them. The ones I was able to remove were related to functions that had been deprecated. I just had to look up the equivalent up-to-date function and replace it with that. I made sure to make my commits one by one so that they could easily be reverted later if they caused some unexpected problems.

I wanted to remove another type of warning (unchecked), after looking in to it and speaking with Vahdat, he said that it would be too difficult to change the code to remove this warning. Instead, he suggested to use java annotations to suppress the warning. I tried this, but it turns out that the umple compiler does not support java annotations. Vahdat then went on to raise an issue regarding this (https://github.com/umple/umple/issues/884), but Tim decided that this issue is not worth fixing. As such, I was not able to remove those unchecked warnings, and it doesn't look like they'll be going away any time in the near future.

The last types of warnings were appearing in some state machine examples. There were 3 different kinds of warnings, and they were being caused by two unique bugs with state machines. The warnings themselves are incorrect, the examples should not generate any of the warnings. I raised two issues (https://github.com/umple/umple/issues/884 and https://github.com/umple/umple/issues/886) regarding these problems. Hopefully somebody will resolve them.

Those were all the warnings with the build, so I was able to proceed with pushing my changing, and making a pull request. Everything passed on our CI, so I was able to close my issue.

I moved on to exploring my next issue, which was also related to the build, but in a completely different area. I'm now looking in to adding the eclipse plugin for umple to our build process. Vahdat made the plugin, so I was asking him lots of questions on how I will accomplish this. We also had some problems with the Eclipse environment when trying to build it through the UI, this appeared to be related to some project files overwriting things they shouldn't be. We didn't quite resolve it, but at least we were able to work around it and get it to build through the UI.

For now I need to look in to how to get ant to build this. I assume after that I will need to add a script to our CI to make it build routinely as well. I may speak with Tim if I should be doing it in ant or start on migrating our build process to maven as was discussed previously.

Overall the code sprint was a great experience. It'll be interesting to see how the semester goes.

###September 14th - September 20th, 2016 Following the first teleconference I set up the development environment, as instructed by Vahdat and Timothy. I followed the wiki step-by-step instructions and had no issues successfully completing a command line build. (One thing to note is that during the second teleconference, Vahdat and Timothy mentioned that you must search the console output of the build for "fail", if zero results are found, then the build succeeded, this is not mentioned anywhere on the wiki, there is no mention anywhere that the "success" output from the command line build cannot be trusted)

I skipped setting up a local Umple Online, but I did continue setting it up in Eclipse. Everything went smoothly following the wiki until Step 3e. I'm not sure how to compile the Master.ump file, I simply pressed F5 after cleaning then continued with the steps. Running the tests then resulted in several thousand errors. I mentioned this to Vahdat during the second teleconference and he said that I should restart Eclipse, do a command line build, then rerun the unit tests. (This worked, but this isn't mentioned anywhere on the wiki either) After doing that, all the tests passed, but a few test cases were skipped. (I'm unsure if this is expected or not)

###September 7th - September 13th, 2016 I started off by reading through some of the documentation on the wiki and browsing through the source code to get an understanding of how it all works. I then moved on to Umple Online and played around with the samples provided, as well as making a few basic ones of my own. I also briefly looked through the issue list, applying various filters just to get a feel for what sort of tasks need to be taken care of.