Adam Bolding-Jones edited this page Apr 6, 2017 · 29 revisions

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


April 6th

Making good progress. See the commit history for https://github.com/umple/umple.gradle/tree/ss-config-n2 for details. Here's the short version. The changes to the plugin are (finally) more-or-less complete, and I've been able to use Gradle to build the umple jar from scratch! I use the plugin the generate all the Java files from the .ump files, then compile all the Java files, and package everything up into a runnable jar. There are still a few kinks to work out, though. The biggest issue will be updating the build to use the new Umple Gradle plugin syntax. There's also the mysterious "extra {" issue when DocumenterMain.java is generated, but that seems to be an Umple bug rather than a Gradle bug. Using the jar from the command line seems to fix the problem. I'm also having a bit of trouble with parts of the build showing up as "up-to-date" when they aren't.

I think I can finally set the light at the end of the tunnel.

March 30th

There are two big tasks remaining. 1) build the Umple jar 2) finishing work on the changes to the plugin started by Kevin

I made progress on both these issues this week. For 1), I haven't made much progress since last week. I've got a runnable jar, but I'm still "cheating" a bit by using the Java files generated by the Ant build. I don't want to spend too much time on this issue before 2) is resolved though. Resolving 2) is going to involve making big changes to how configuration is passed to the plugin, which will definitely affect the Umple build progress.

Overall, by the end of the semester, I hope to have done three things:

  1. Gotten a "quick build" working with Gradle
  2. Finish the plugin changes
  3. Get a Gradle script made for the Umple Eclipse plugin.

Here's a link to one of the more active threads that has seen a lot of activity this week: https://github.com/umple/umple.gradle/commit/12342d712058f54dc293e93ee63fd6ce100f6069#commitcomment-21565291

March 25th

I made some great progress yesterday. I was able to use Gradle to compile the Java files of all the umple jar subprojects, and then I was able to package the resulting class files up into a jar! And it ran! I can use the jar I built to run umple from the command line.

This is great, but my solution still involves a lot of duct tape. It'll definitely need to be cleaned up before it's pushed to the repo. Also, I'll need to incorporate generating all the Java files from the .ump files into the Gradle build process. This shouldn't be too tough though, as it'll just a be matter of pointing the Umple Gradle plugin at the right sub projects.

I've got a few other projects I need to get finished before I can sit down and work on the next steps, but I'm looking forward to moving forward some more in a couple of days!

March 24th

I hit a big roadblock with the umple.jar build. It appears that some sub projects must be compiled together, which makes the dream of building and compiling each sub project individually not fully realizable. I've talked to Vahdat and Kevin about this, and the plan is to build as many projects independently as possible. For those that can't be generated independently, we'll build as a unit.

The good news is that the framework for building the projects independently is there. If down the road the sub projects can be refactored to allow independent building it will be very easy to adapt the Gradle build to take advantage of this.

Kevin has also created a branch that changes the way the plugin handles configuration. It's a pretty big shift with around 600 changes. Kevin has asked me to take the lead on completing the changes (it's currently broken) and getting them merged. The problem is that neither Kevin nor I know how to resolve one of the breaking issues. He's posted on the Gradle forums and I've posted on Stack Overflow, hopefully someone there has an idea of how to resolve the problem.

March 15th

I've been working with Kevin to address some outstanding issues in a pending PR that contains enhancements for the plugin. I've also been continuing work on getting the Umple compiler jar built. It's slow going, but I made a big breakthrough yesterday! I finally figured out how to add dependencies to the source set that we're using to compile each of the sub projects. Now I can generate and build cruise.umple! It was a really big job to sift through all the documentation and forum posts to find that information. 3/4 of the work with Gradle is just reading -- there seems to be a shortage of Gradle experts out there, so many Gradle questions on SO go unanswered.

I'm trying to keep these updates less frequent and less verbose because I find I'm often repeating what's already been written in the PRs and issues that I've been working on. To get more detail on what I've been up to, please have a look at the issue tracker and PR history of the Umple Gradle repo. In particular, have a look at issue 10

March 8th

It's been awhile since my last update. I'm made a lot of progress since my last entry. I've completely reworked the Umple Gradle plugin so that we can use it for the main Gradle build. In addition to changing core functionality to make it work with our build, I've added unit and integration tests, and continuous integration via Travis-CI. Check out https://github.com/umple/umple.gradle for details.

I've also worked on getting the Umple compiler built using the new plugin. It's tricky, but I'm making progress. I've successfully build a few of the sub projects (UmpleToJava, UmpleParser, etc.). That means using the plugin to generate the java files, storing the java files in the right place, then compiling them into .class files.

I'm currently stuck on what appears to be an Umple bug. I'm really reluctant to working on fixing an Umple bug right now because I'm already so pressed for time on the Gradle build. I'm really hoping that Vahdat or Kevin will have an idea for a work around or fix.

February 26th

Finally closed my last outstanding PR today. That brings my closed issue count up to five! I'm quite proud of that. I've also added more integration tests to the Umple Gradle plugin. I'm quite happy with how the integration testing has turned out -- I now have separate integration and unit test tasks, and one of my integration tests uses the plugin to generate Java, compile it, and then check that both of those steps were done correctly. It was a lot of work to figure out how to set something like that up (lots of JUnit and Gradle reading, as if I haven't done enough of that already!), but it's done now and I'm happy with it. Kevin has a couple review comments that I need to address before I merge the integration testing stuff, but they're relatively minor. Should be able to merge in the next couple of days.

February 24th

I've expanded the existing Umple plugin so that it is now source-set aware. In short, once a .ump file is used to generate Java files, the plugin now adds all generated Java files to the generatedSource source set. This source set is used to compile the generated files later in the build. I've also refactored the plugin to include default values for plugin configuration values, and also extracted the plugin default names as constants. This makes it easier to view and change the plugin configuration options.

I've also added integration test functionality to the plugin at the suggestion of Kevin. Currently there's only one lonely test, but now that the framework is in place it should be easy to add more tests in the future. I'm going to try to add more in the next couple of days.

Finally, I've built a prototype build system that performs a simplified version of the build tasks required to package the umple compiler jar (using the umple plugin). It's working, so the next step is to expand the process to the actual Umple build. I'll probably start a fresh project for this, but I'll keep the "hello world" project around. I think I can use it in integration testing.

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.
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.