Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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
Today I mainly focused on refining the
umple.orion. This involved me running through the setup of the system and using the system to identify information that I should include in the documentation and writing this information in a clear and concise language. I understand that this is not programming, but I am logging this work because it was sufficient (~5 hours) and because documentation is a very important part of the software development cycle. I want to make sure that my work is useable and understood by any successors especially considering its disconnected nature from the rest of the Umple project and early development stage that the Orion project is in (hence, not too much support or documentation available). I also made a minor change to my cleanup script since I was bound to find one minor quirk with all of the setting up and tearing down of the system.
I also made my pull request and spent time describing what is included in the request. I learned that the point of a pull request is to show the project owner that your modified version of the software is better than the master version. Properly convincing the project owner that your version is better than the master version is an important concluding step of feature additions, because without being able to convince them of this, your code changes will be thrown out. Let us hope for the best!
I woke up to some of the strangest Java errors which seemed to spawn overnight. I believe the errors were related to my build path. Regardless, I needed to change my project structure because the tests were not in a pretty plac (I have not ever made first tests for a Java project). Luck was on my side when restructuring the project solved my "cannot resolve the class of a file in the same package" issues.
I then added the JUnit dependency to my pom to the umple-orion-server had working automated build once again. Continuing with the server, I modified the build process of system to work with a constant-named umple-orion-server. Before doing this, the server built with a version number in the filename and the setup scripts fetched/renamed this file via wildcard.
I spent a lot of my work session attempting to get cascading menus for the UI of my plugin in Orion. I have tried doing this perviously, so I already knew where and where not to look. Through using and analysing the source code of other Orion plugins, reading through Orion forum posts, messaging the Orion IRC channel, reading through the Orion Client API documentation and referring to the (sometimes inconsistent to the API documentation) Orion JsDoc reference to experiment with and test different plugin codes, I found nothing better than what is currently in place ie no support for cascading menus in the current build of the Orion client API. I do understand that there are cascading menus for built-in features, but those are baked into the client's code and I would not want to build directly into the Orion client because my additions will most likely break with future updates of Orion and it would also be extremely difficult (time-consuming, costly,...). It is a shame to spend hours working and have nothing to show for it, but that is the cost of research and diving into unknown grounds.
Moving on, to the Orion plugin, I added every language which is currently supported in the Eclipse plugin. I then applied a few different labellings to the menu items to get a feel for what is the most user friendly. This was important to do because since there is no support for cascading menus, there are a lot of menu items so I wanted to make it easy for the user to find the menu item they are looking for. Earlier this semester I had designed the plugin so that the menu items only appear when you have an Umple file active, so these menu items will only appear when needed and will not annoy users working on other projects or with other files.
April 13th (Evening-Night)
I spent this work session atomizing umple-orion-server to make it testable. During this session, I learned how to make JUnit tests and refactored the server accordingly. The server now uses two new classes which are minimally exhaustively tested. The server is now more flexible for the future in case there is a change in the request syntax, and more importantly, the server is testable.
April 13th (Morning-Afternoon)
Today I resumed work. I planned on making the system Windows compatible today, but it already was Windows compatible. I spent the day installing, using and configuring Maven, Firefox, Chrome, Docker, Java, Windows, Orion, the Dockerfile, umple-orion-server, and umple.orion/plugin on Windows in attempts to get my system running on Windows. The outcome is that it is horribly tedious to get running because some of these apps (Maven, Docker) do not have user friendly set-ups and configurations on Windows. At the end of this work session, I performed the almighty
git add .; git commit to learn that
Your branch is up-to-date with 'origin/master'. nothing to commit, working tree clean: after all of the configuring and tweaking, the system was working all along.
The only possible changes that were made were that I changed line endings in the
run file from Windows line endings (inconclusive of why or how Windows decided to change this file's line endings without asking) back to Unix line endings (since it is run in an Ubuntu image). I say possibly because, once again, I never opened this file until I realised that Docker was getting confused by its instructions and it printed
\r in one of my debugging sessions. The behaviour of Maven, Docker, the server, and the plugin are all very odd because they seem to function inconsistently, but regardless, I expect (and suggest) the system will be deployed on Linux machines so the instability should not be an issue. These issues will only be raised for developers using Windows to work on this project. For that case, I suggest using a VM or installing Linux. Although this system does run on Windows, it is not worth the trouble.
This session allowed me to add to the documentation and confirm that the system is Windows compatible, but make the strong recommendation to deploy (and develop) on Linux.
Aside: I have changed my commit style to commit more often after reading about committiquette.
Vahdat has been having issues building and running the Docker image. Based on his error, it seems like either Docker has issues handling wildcards, or the umple-orion server is not building correctly. To fix this, I removed wildcards from the Dockerfile, and updated the README to specify that the setup script must be run from the repository's root directory. I did a few final tests to make sure that everything build properly from source.
I modified the Dockerfile and built some other scripts to automate the deployment and running of the Umple-Orion and Orion servers. The biggest challenge today was to be patient while testing.
I set up the umple server to build properly so that I can be deployed. Various small hiccups were encountered doing so such as needing to install umple.jar to my local repository, but Maven has a helpful community of developers, so none of these issues were major roadblocks.
Major changes were made to both the plugin and the server to support multiple languages. Along the way, I found a bug where filenames with special characters (like spaces) were being sent to the server in a different encoding. This was resolved by using a URL Decoder. There were also oddities with where the files were being generated. When using the
-g flag with Umple, files get generated in the current directory, so I had to create a folder for output and use the
--path option to redirect the location of output.
I have added the Umple content-type along with syntax highlighting to the plugin. These are built in features to the Orion plugin API, so no issues were encountered.
The Orion plugin now sends the filename of the currently opened file, along with the username. The Umple server gracefully handles the request.
The Umple server can now parse properly formatted requests. The Orion plugin currently sends a fake request with a constant username and file name.
My next step is to make the Orion plugin send the current user's username and file selection.
I started building my server and connecting it to the plugin I have previously created. There we're some dependency issues setting up the server, and further, getting the plugin to make HTTP requests to the server. The latter issue arose because the Orion client runs over HTTPS and my server is hosted on HTTP. I solved this by disabling some security settings in Firefox for the Orion client.
My next steps are to send the filename(s) and username to my server via the Orion plugin. I have done some surface research and will probably need to change the Orion plugin's service from
orion.page.command to be able to send multiple filenames to the server.
March 5th small update: I will be using a combination of
orion.navigate.command and the already-used
orion.edit.command. The former will allow me to send multiple filenames to the server.
"The current Orion server is written in Java, using Jetty and Equinox server infrastructure. This server does not currently define any Java API for extending or augmenting its behavior" (Orion Architecture). Since extending the Orion server is not supported, and modifying/hacking at the Orion server source code would lead to problems in future updates of the source and be incredibly difficult, I have come to an alternate solution after reading through Eclipse Orion based projects, Orion news, and other sources of information such as the Orion Developer Guide and communicating with a member of IBM.
I propose that I instead build a server with Java EE, which generates the code (just like UmpleOnline) and returns the generated code to the client. The client will be a Orion plugin which sends the selected file and all other related files to this server (initiated with a menu option), then once it gets a response from the Umple Generator server, it will place the received files on the Orion server using the Orion Server File API.
We will need to be able to host this server (unless there is an UmpleOnline API), but for the meantime I will test it with a local Tomcat server. Aside, I would like to apologize for the lack of apparent activity on my end. I would like to mention that I have been working hard at trying to figure out how to modify the Orion server or send custom requests to the Orion server until I discovered this much simpler alternative solution to the problem at hand.
I made a very basic plugin which adds a button to the Orion UI which says "Umple Generation" but does not have functionality. I hosted this plugin on my GitHub pages so that Orion can install the plugin. Aside from this, I have been putting in many hours, across 4 sessions (days), reading through the Orion documentation and forums, making a post of my own attempting to learn how to send requests from the client to the server and how to make the server generate code with umple.jar upon receiving these requests, however, I cannot seem to find any guidance as to what my next steps should be.
Edit from the future about my thoughts of the past: I just cannot seem to find a way to modify the Orion server to accomplish my task. I was instructed and guided to hack at the Orion server. I believe that any modifications I make to the Orion server will be highly cohesive and can easily conflict with future updates to Orion (it is still under heavy development). Making these modifications would make me an Orion developer, I am developing for Umple. I need to stop and discard all of progress in order design my own architecture to make this project possible.
Today was a day of research. I continued learning about Orion, but this time I went more in depth, gathering knowledge that I will implement Umple code generation (among other features) into Orion.
Earlier this week I fixed my Docker problem, and today I came across another issue with restarting the Docker application. I ended up learning the basics of using Docker to understand and fix the issue.
As for the future, I now know how to make a plugin for Orion, but the code generation needs to happen on the Orion server. So I will dive deeper into server-side development in my next work session, hopefully coming out with some implementation of Umple code generation in Orion.
Fixed up a small issue with my pull request concerning the format a comment in the generated code of the test templates. Started learning about Eclipse Orion on the wiki and set up and started to get acquainted with Orion by following some of the getting started guide. I also attempted to set up the Orion repository but I am getting an error related to a dependency when I try to start docker with
sudo systemctl start docker on Manjaro. I will try solving this error during my next Umple session, perhaps by installing docker from another source.
Fixing tests which failed after fixing issue 964. While fixing some of these tests, I've noticed that some of the generated code has method parameters of type
integer (which is now a typeless parameter after fixing issue 964). Only integer is a primitive PHP type. I have commented further in comments of issue 964. Issued my pull request for 964.
Another oddity that I ran into is that all
ClassCodeInjections_* tests which were failing continued to fail after generating and placing appropriate code. All reasons for failure were due to the test expecting a comment line but receiving a line of executable code. I fixed this by removing all lines of the form
// line * from the generated files for
Code sprint at the University of Calgary. I spent the first two days attempting to solve issue 656, running into a few roadblocks which made solving this issue very much more difficult than it seems at the surface. More information about these problems can be found in the issue's comments. Luckily, attempting to solve this issue allowed me to explore (in depth) and understand the architecture of Umple. I spent the final day (morning) of the sprint learning some PHP and working on issue 964. It was a quick fix, but it allowed me to find another issue, which I mentioned in the comments of the issue.
I got the environment set up in eclipse by performing a command line build and following Ahmed's steps. I started looking into solving my first issue. To do so, I have been getting a stronger understanding of Umple's architecture by referring to the architecture page and analysing the directory structure and reading through files.
I attempted to set up my development environment in Eclipse. I managed to get everything working except for an error in the cruise.umple.nebula project. In cruise.umple.core.Generator an import of cruise.umple.cpp.gen.Header cannot be resolved. I tried adding cruise.umple to cruise.umple.nebula's build path, but that caused a circular reference error.
I also went through some practice examples of using Umple. I used Umple Online to generate the Java code.
I finished reading the documentation and the key wiki pages. I successfully set up the development environment and plan on setting up the eclipse environment in my next work session.
Read through the core of the Umple user manual including User Manual Basics, Classes and Interfaces, Attributes, Associations, Methods and Directives. Did some experimenting in UmpleOnline and skimmed and compiled some generated code.