Adam Bolding-Jones edited this page Feb 21, 2017 · 15 revisions
Clone this wiki locally

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


February 20th

I've spent several hours researching and experimenting with Gradle since my last log entry. I've also had detailed discussions with Kevin and Vahdat regarding the best way to approach this Gradle build project. It's been a long time coming, but I think we're all finally on the same page regarding what needs to be done and (more or less) how it will be done and I feel like I can start coding.

The first task is to refactor and expand the functionality of the existing Gradle plugin for Umple. The existing plugin is a good start, but it doesn't have enough features for it to be useful in the build process. I'm going to change the way configuration is set for the plugin, add new default configuration options, and dynamic tasks to compile the generated source code (e.g. .java -> .class files, .cpp -> .o).

Once this is finished, I'm going to use the plugin to build the Umple compiler jar. This will involve creating a multi-project Gradle build, and creating some new tasks for packing the compile files into the Umple jar.

These two tasks should keep me busy for at least the rest of this week. Hopefully, they go smoothly.

February 15th

I've spent time this week going through some simple Gradle tutorials as well as reading the comments in issue 751 to get a sense for what work has already been done. I've been in contact with Vahdat and Kevin to get their input on the workflow I've been proposing. Looks like it'll be a challenging project, but I think I'll learn a lot.

February 9th

I spent last weekend working on several open issues and have made good progress on them. I made a PR that was merged and in so doing closed two issues. I've got another PR pending that's just waiting forreview from some senior Umple devs, and a fix for the final outstanding issue ready to go (I'm just waiting for approval to implement it as it involves a non-trivial change to the way Umple processes files). I'll be particularly gratified once the pending PR goes through because it fixes two issues that I personally identified. Taking issues all the way from the creation to fix stage has been a great learning experience for me.

Unfortunately, working on the issues means I'm a bit behind on my main project. I talked this over with Tim and Vahdat and they're ok with that, but I'm still a bit concerned that I might not have time to finish the project properly. We'll have to see. I start "real work" on it tonight!

February 2nd

Today has been quite productive. I submitted a PR that closed two issues, 969 and 986. I'll let the commits and PR logs provide the details, but essentially I fixed an issue where Java methods were being generated without a return type if none was specified (now if none are specified void is the return type) and an issue that was causing threading code to be generated incorrectly in some cases.

January 29-30th

I've been working to resolve all the issues that have been assigned to me so I can start in on the term project (to convert the Umple build process from Ant to Gradle).

The biggest challenge in tackling the issues has been getting familiar enough with the Umple code base to make changes with confidence. A secondary challenge has been adapting my working style to a project as large as Umple. Gone are the days of careless builds! Since a full build takes around 8 minutes on my machine, I've had to think carefully about the best way to get my changes to show up in Umple. Most of the time a full build is not the best option.

I've also had a couple false starts keeping my local repository organized. It's been awhile since I used Git and Github, and I've already learned the hard way the downsides of not keeping commits organized and not maintaining my fork of Umple properly (note to self: don't push changes to master!)

However, I finally feel like I'm familiar enough with the project to start in on the actually changes I need to make. I've already submitted a PR to fix issue 948, and am planning on submitting several more PRs over the next few days to fix the remaining issues that are assigned to me.

January 20th - 22nd (UCOSP code sprint in Calgary)

  • Spent several hours become more familiar with the implementation details of Umple while fixing small bugs and identifying new issues. I stepped through the parser and analyzer code in the Eclipse debugger and recognized many similiarities between Umple and the compilers I've studied at school (the parser tokenizes the input and produces an AST, the compiler (i.e. UmpleInternalParser) analyzes the tree to compile the Umple code into whatever the target code is.)
  • Noticed that Umple relies on the system default encoding to read in .ump files and produce generated code. Discussed this issue with Vahdat and explained why I think UTF-8 is a more sensible default. Created issue 960 to track this. Will start working on a fix once Tim has had a chance to comment.
  • Identified a bug in Umple that allows methods to be specified without providing a return type. This results in generated code that cannot be compiled in many cases. This is related to issue 969 and 958. Started work on a fix.
  • Choose "use Gradle to build Umple" as my term project.

January 17th

  • Spent time going over the Umple manual more carefully. I found a number of typos. I'm tracking them and will create a PR to fix them sometime soon (though I'm treating it as low priority).

January 14th

  • Worked with Ahmed to determine the cause of the Eclipse development environment setup issue being experienced by the UCOSP students. To fix it, I will modify the cruise.umple.nebula .project file so that the project correctly linked to some file generated by a full build. I created an issue to track this fix.
  • Noticed that the generated Java code's toString() method is in many instances creating an unnecessary variable. Brought this to the attention of Vahdat and created an issue. I've assigned myself to the issue and hope to investigate it during the code sprint.

January 10-11th

  • Decided to switch development platform to Windows since I'm running Ubuntu off a USB and it's quite slow. I was able to get everything setup and all tests are passing.
  • I got Ant setup as an External Tool in Eclipse and contributed documentation describing the process. As part of writing the documentation I got to submit a pull request to master (all I added was a screenshot for the documentation) -- this was helpful because it reminded me how Git works, and also what the process is for creating a pull request for Umple.

January 8th

  • Did a full build from the command-line, then got the plug-in working in Eclipse, and got the development environment set up. Currently 3071/4086 tests are failing.
  • Corrected typos and added a few additional details to some steps in the development environment and Eclipse plug-in setup pages.

January 7th

  • Worked through the first third of the Umple manual and several preliminary examples on the Umple site. I understand the basics of what Umple does and how to use it.
  • Got Ubuntu setup on my machine, installed Eclipse Neon as well as the various Umple dependencies. I'll spend the weekend getting the development environment completely setup - first I'll get a full build running from the command line, then I'll work on getting things setup in Eclipse.
  • Started tracking typos I found in the documentation.