TCLethbridge edited this page Aug 29, 2015 · 3 revisions
Clone this wiki locally

Each UCOSP participant is asked to log all the difficulties they have getting set up to understand Umple. This includes 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.

( copy and pasted verbatim from another UCOSP student's log )

Log Entries

1/2 April 2015

Added new repository for data for Umpr, submitted PR#11 for upgrading the Umpr PHP code and adding information. Further, I added better "ignore" and "merging" support for output folders (required for using the git repository): PR#15.

All umpr's data is stored in umple-ucosp/umpr.data currently, but is subject to change.

I lost a lot of time trying to make the application automatically download the umpr.data repository, but I gave up after a lot of attempts and it being extremely slow for page loads.

I've also opened several issues for future work to be completed on both repositories.

I submitted a patch to add a link to umpr.a4word.com within UmpleOnline.

31 March 2015

I've created a tutorial page on my project, Umpr and on how to create a new UmprCoreRepositories.

I also refactored my projects core naming to be cruise.umple.umpr.core instead of cruise.umple.sample.downloader. See PR#13.

26 March 2015

I added Filtering capabilities to the umpr page, it is ready to be hosted.

My next task is to start writing documentation, I think I'll do it on the wiki for my projects rather than on the full umple wiki.

From the outline of work on 3 March, the following tasks are left:

  1. Integrate the link into UmpleOnline
  2. migrate umpleonline non-core examples into a repository

I don't think (2) will be done as Tim expressed that there are legacy issues with changing that (publications etc). Thus, I will only do (1).

I did find today that there is a test case in Umple that causes the build to fail at random. This is due to the nature at which the test case is run, MultipleQueuedStateMachinesTest depends on the fact that the CPU running the tests is fast enough to complete the operations within a single cycle. This is not the case on Travis as during peak hours (9-5), it is running on a single core and is quite slow. I'm going to open an Issue for this, and I might try to fix it.

25 March 2015

Improved output table PR#9.

Improved output files and generation: PR#12.

25 March 2015

Finished fixing the state machine version since it broke some internals. Next step is to implement better error logging on the front end to take advantage of the new "fail stage."

24 March 2015

Fixed Issue 691 (on Google Code) and 692 and submitted a patch to Andrew.

Started implementing the changes from the two issues into the downloader.

The downloader now uses an State Machine to run the import process, really cleaning up some of the ugly code. The State Machine is a single state order, i.e. on creation it runs the process and when completed the constructor will return. This behaviour is perfect because this code is simple now compared to the older version.

23 March 2015

Fixed up a patch for adding an importer handler factory for Andrew.

  • Added SCXML import facilities via a repository: PR#10
  • Opened PR#9 to add improvements suggested by Andrew and Tim previously discussed in other entries (e.g. adding model verification)
  • Opened www-PR#2 which adds better viewing of imported content
  • Fixed backend to use Umple's new UmpleImportType instead of my own hand-rolled version
  • Added better error messages depending when things go bad when importing, however I opened #11 to give better inference to when bad things happened

19 March 2015

I added Modelling into the Importer to make sure that models that are Imported are valid (turns out most are not). Following this, if they fail the "success" rate is known.

I've opened numerous issues now as more of a "task management" approach then as "bugs." Similar to how the issues are running on the main repo.

I wrote two patches:

  1. I added a factory for UmpleImportHandlers since it will probably grow in the future and Warren already abstracted out the main interface. (Patch info)
  2. Replaced some ant build code with the new Ant tasks, but this is triggering some unforseen issues with JET templates. :( (Patch info)

18 March 2015

Add proper packaging so the jar can be run from the command line. See PR#4.

Did some initial work on a front end, it parses a preloaded JSON fromat from the backend. See PR#1. This is a PoC, however it does show some features talked about in the meeting today (e.g. UmpleOnline links for showing the files directly--they will only work once the code is hosted somewhere).

17 March 2015

I've finished the serializers, I need to do the deserializers. I'm writing unit tests using jayway/JsonPath and they are quite simple and elegant. I'm pleasantly surprised by this.

I've prepared a PR #3, I'll merge it when the build confirmed passage.

Addressed a bunch of comments from Andrew, I'll open an issue for Annotations. I'm uncertain if I'll have time to complete this in addition to my current work before end of term. That being said, I can formulate a grammar spec and propose it.

With the PR closed, the basic functionality is now complete and "tested." My next step is to get the functionality into a web front end. I've put a sample of the meta.json in a Gist.

13 March 2015

I've started getting custom JSON deserializers running. Still need to finish them.

12 March 2015

Something I really wanted and couldn't figure out before: Getting Java-like enum classes into Umple.

It is a bit clunky, but here is an example that I'm using.

I've now added a proper test repository since I don't trust my current code to work. The JSON parsing currently fails because the objects that Umple creates have recursive relationships that Jackson fails on OOTB. Without annotations, it'll take some effort to produce nice JSON.

11 March 2015

I added test cases to my project and finally fixed the build to work correctly. Unfortunately, I have to compile umple from source everytime I compile the project. This is because I have made changes to the API that did not make it into the most recent release.

You can see how I did this via travis here. This is a bit of an irritation, ideally the Ivy dependency management could just pull this information from a repository with "latest" it'd never be a concern!

4 March 2015

Add patches for Updating the Import model, fixed the CC build by removing tests.

3 March 2015

I tried to improve the Ant tests, but I ended up finding a defect with Linked Files and the UmpleModel. I originally thought it was my fault, but it turns out its an issue within the UmpleModel. I've opened Issue 684 (on Google Code) to deal with it. I would like some confirmation that it is a defect before I go digging more.

I'm going to give a patch for the tests that currently pass (all but the linked files one) and fix things.

New task outline after talking with Andrew:

  1. Make sure the ant stuff is done (oh god it better be)
  2. Finish output formatting for the current repository setup (i.e. ecore importing, others come later)
  3. Front-end for current setup
  4. Integrate the link into UmpleOnline
  5. Add support for non-ecore imports, migrate umpleonline non-core examples into a repository


  1. Dependency integration
  2. CI/build infrastructure improvements

2 March 2015

I prepared two patches to add the Java 8 functionality I worked on previously for Andrew. He applied one, but due to the way that CC builds on the server, the build broke and I had to rush a patch to remove the tests. I've now sent a second patch to fix the first one re-adding tests and fixing the failures.

I submitted a second patch which exposes the Import API in a cleaner and more consumable way for secondary applications (i.e. my term project). This patch has yet to be applied.

I also further extracted a lot of functionality on my term project. I now have my project running tests in Travis-CI, however the build currently fails because it needs the Import patches to work. I considered butchering the build to get it working via my branch, but I considered that poor practice and choose to let the build fail for now. This involved getting the project building via Ant.

The Ant build structure I've used will download and install Apache Ivy and load it at build time, there-in removing the requirement of having an unmanaged dependency in the build chain. I would like to use this as a PoC for bringing in the same into the Umple build chain.

My next step on the project is to introduce a test repository that I can use to verify the repositories work without the intense downloads (against the slow webpage..) and with guaranteed consistency.

27 February 2015

I investigated a lot of things I talked about in a previous post about means of utilizing Travis better. However, I got a bit turned off by my findings. To have Travis publish any builds opens up security issues.

From an email thread between myself, Andrew, and Tim:

Regarding using the jars that Travis builds, it is not a simple solution. One solution is to have an FTP server to upload the Jars Travis builds. There is a glaring security hole here, though: FTP login information must be stored in plain-text within the repository or have anonymous FTP access. Having plain-text storage essentially implies an anonymous access since anyone could read the credentials. Also, I've heard of bots that trawl open source projects looking for information like this to exploit it. This gives me serious cause for concern.

As another option, having a simple server that accepts a post call using these WebHooks would be a safer (albeit more work) effort to trigger cruise to build jars. My large concern here is that while Jars are hosted within the repository, this would imply adding the newly constructed jars as a commit which then triggers another build, ad infinum. This issue will arise with either git or svn.

I would like to suggest a different hosting idea for the jars, using a simply configured Ivy repository -- a glorified directory structure that Ivy can read from. A suggested work flow to utilize this would be:

  1. Travis Builds master branch -> Triggers WebHook on cruise
  2. Cruise builds the jars for proper branch via information from WebHook.
  3. Cruise publishes jars in Ivy

We would then modify the build in Umple to use Ivy and it would resolve the jars from the Ivy repository if a local copy is not available (i.e. you haven't built Umple locally). This would effectively remove binaries from the Umple repository. It does add a requirement that developers now need to have Ivy installed on their system and accessible to ant (same way we have ant-contrib). In addition, all shipped dependency jars can be removed and their equivalent versions pulled from Maven (e.g. JOptSimple). An example of an Ivy-fed project can be seen in my term project here.

While I think this is a great step for the long run, I also think it's a large jump that may not be worth doing until a full-move to git/GitHub is done. For now, I think having all of the tests run and having the Travis badge show the status is a solid start. If willing, I would be willing to try and get an architecture setup via a VM as a PoC for what cruise could do. All in, there's a discussion to be had and it's Tim's call!

25 February 2015

Refactoring more code, to make it as simple as possible to add new repositories. Further, adding a better status result after it's done.

I need to open a task for adding Java/PHP Annotations into Umple to let a lot of the current code be rewritten using Umple.

-- Continued --

In reflection, I'm unsure if it is worthwhile. The issue surrounding Annotation is that many languages do not have any support for the notion: i.e. C++ (no support), PHP support via external repository, and several others will not have support for them. I'm on the fence as to the worth of the adventure.

24 February 2015

I found a bug a few days ago, but I've only now tracked it down. This ECore file causes the importer to all out due to a failed regex split. I believe the issue is because the file is malformed.

The issue is caused by these lines (752..754):

    <eClassifiers xsi:type="ecore:EClass" name="Presentation" eSuperTypes="/0/Conference_activity /0/Conference_contribution">
      <eStructuralFeatures xsi:type="ecore:EReference" name="is_given_by" ordered="false" eType="/0/Active_conference_participant" eOpposite="/0/Person/give"/>

I'm unsure if this is invalid or not, the error that shows up is because it tries to split /0/Person/give by /0/Active_conference_participant and get the [1] result. When it can't split it, there is only one result ([0]).

I'm unfamiliar with how eCore works, but by looking at the other parts of the file, it appears as though

<eStructuralFeatures xsi:type="ecore:EReference" name="is_given_by" ordered="false" eType="/0/Active_conference_participant" eOpposite="/0/Person/give"/>

should be:

<eStructuralFeatures xsi:type="ecore:EReference" name="is_given_by" ordered="false" eType="/0/Active_conference_participant" eOpposite="/0/Active_conference_participant/give"/>

That being said, I'm in very unfamiliar territory with this specification.

23 February 2015

I further extracted functionality into components to be used. The initial "repository" is now defined, and in an easily extensible way to add more repositories. I've also added a proper CLI interface (starting point, at least).

22 February 2015

After travelling for a few days, and now fighting a flu, I'm rather "under the weather," but been working.

From the PoC, I started extracting functionality into a workable and more flexible architecture. I started working on unit tests and separation of components. My progress is being kept in the RefactorMain branch.

Thus far, there will be a collection of "Repositories" which house collections of importable files to download. These files are then pumped into the UmpleConsoleMain and create .ump files if successful. These files are currently not compiled, but could be in future iterations.

I also created a new repository for a front-end. There is nothing there, but my plan is to clone out the UmplifyOnline front end and modify it to my needs. For now, the plan will be to display static tables of information, perhaps serving the imported umple files as raw content for now. Time will tell.

18 February 2015

I've created a PR for reference here: https://github.com/Nava2/Umple/pull/1

I wrote a wikipage "cookbook" style for using the Ant task, UmpleAntTasks.

I've completed a simple PoC for the import downloader. I need to confirm an architecture diagram.

16 February 2015

Finalized patches for <umplec> with testing and replaced calls in the build chain. This patch involved two parts. My next task is to document the tasks in the wiki.

I also started a discussion surrounding bringing the umple java requirement up to 1.8.

15 February 2015

Drafted tests for <umplec> task, need to add more. <umplei> is next.

I'm always scared of losing my progress, so it's located here.

14 February 2015 (Continued)

I've restructured the UmpleConsoleMain function to make it consumable by others. This involved creating a new configuration structure UmpleConsoleConfig.

This structure is used to run the UmpleConsoleMain from different sources. The UmpleAntTask I've written thus far will run through here.

I refactored the Builder::runAnt method to be more flexible (I need to run separate tasks).

I had to update some tests for UmpleConsoleMain because I changed some of the output to System.out, but the test now passes.

One thing I did when I did this was up the Java version to the current stable release, 1.8. I more or less did this without thinking, and it wasn't necessarily a good idea. I question whether the project is in a state to do this yet, I'll have to query the list.

Tomorrow, I'm going to implement some ant tasks, here are my ideal tasks:

  • <umplec> - Compile umple files to a language
  • <umplei> - Import xmi files, convert to ump files

Once I've implemented these + tests, I'll modify the existing build code to use them. This last step will probably require two patches because the build file can't be broken.

14 February 2015

I had to redo everything I worked on for the past few weeks. The patches I sent Andrew were incomplete, and svn published over all of my changes.

I've spent the last few hours recreating the design and I need to reimplement some changes I was planning on submitting with the adjustment, as well.

10 February 2015

I forgot to update my log.

I submitted two patches to be applied sequentially to work on Issue 674 (on Google Code). However, I the patch does not complete it, but it does give a baseline for having things work. I wrote the initial patch using the wrong command-line. I'm adjusting this now.

Earlier this week I joined Andrew and John for working on his code-base.

5 February 2015

I tried to use Umple to write the ant task, but Ant needs the bean properties to not return boolean values. I've now gotten around it via prepending _ in front of fields.

I also figured out how to properly expose my $PATH variable from eclipse. StackOverflow Post

4 February 2015

Due to what can only be described as the Gods shining their light on me, I figured out how to get custom ant tasks working. Now, I am working on integrating my refactoring of the umple.jar's main into an Ant task.

3 February 2015 (2)

Working on getting the ant tasks working.

I've improved Builder's Ant methods to what I need. I'll probably submit a patch with these improvements + tests.

I hate Ant. It's making me angry.

Specifying a -lib parameter when running a build.xml causes all others to be dropped. I do not know how to get around this.. tasks are also going to fail right away because I need to package ant tasks into a Jar. :(

3 February 2015

I'm trying to figure out how to use ant to fetch git repositories cleanly.

I found the git-ant-tasks repository which seems like a good starting point.

I've wanted to propose the following for awhile, but I've only now just formulated it.

Proposed Project Structure

This is a proposal, and is not a work item for me currently.

Intent of this restructure

  • Move to git over subversion, including github for improved workflow -- Pull Requests over Patches
  • Improve modularity of the project into sub-projects instead of a single monolithic structure
  • Remove hosting of binary jar files in the repository (including umple*.jar) via Apache Ivy
  • Add support for CI tools
  • Add triggers for remote upload for current builds and bootstrapping via downloading jars
    • Ivy supports setting up custom repositories, so we might get some of this for free when we download dependencies this appears to solve this very cleanly
  • Allows for replacing the build tools in the future if considered worthwhile
  • With a modularized build infrastructure getting the project into projects like Maven becomes a lot easier


This proposal has the following impact:

  • Developers now use git instead of subversion; there is a lot of documentation on getting used to these changes
  • Code would be hosted on GitHub
  • The "patch" mentality becomes "pull request" mentality -- GitHub Pull Requests
  • Each subproject builds into it's own Jar, but a single monolithic jar will remain (same as currently designated)
    • Allow a project to be build inside itself assuming dependencies are met -- use ivy to fetch modules instead of requiring the entire project

The following intend to stay the same:

  • Minimize subproject infrastructure changes
    • Add a build.xml for custom build information, overall build structure is reliant on the other projects
  • Overall project structure -- the folders become pseudo folders as in the repository has no literal folders inside, but once a build script is run, it will fetch them and bring them in

Proposed project setup

  • umple/umple

    • Main repository with a configuration file for sub projects
    • Includes only build configuration and metadata to specify projects
    • The build file will clone each repository if it does not exist, otherwise pull the latest changes
    • The build of each project is completed via the <ant> task and reading configuration
  • umple/cruise.umple.build

    • Includes build task that are available to all other projects during umple's build phase
  • umple/cruise.umple.core (and all other sub projects)

    • Individual repository
    • Includes any build configuration by defining an ant build file

New PR Workflow for new contributors

  1. Fork the repository to contribute to
  2. Make changes, make sure the build passes via the forked build (Travis will verify builds pass before merging
  3. Code review on changes
  4. Submitter adjusts as required
  5. Commiter merges PR

Probable issues

  • Decoupling the UmpleTo* projects from cruise.umple may provide extremely problematic depending how the code is coupled in here
  • Setting up an Ivy repository can be tough and would require a server to run it (cruise would work)
  • Decoupling -- just in general..

Proposed bite-sized chunks

  1. Integrate Ivy into the toolchain
    • Have the project build and publish Ivy/Maven artefacts locally to the developer machine
    • Use the project from the local repository as a dependency
  2. Create the next subproject using this technique rather than in-tree building as a PoC
  3. Migrate UmpleTo{Java, PHP, C++} to use the approach in (2)
    • Each would be its own task.
  4. Migrate all other projects
  5. Remove projects from build tree, migrate root project

28 January 2015

Finally sitting down to work on some things again. Due to computer issues, I've had to re-setup my environment again. That being said, I have things up and running again.

I moved my project repository to the new organization here:

I tried to set things up using IntelliJ as it is my preferred IDE, but the ant support is dodgy -- thus I switched back to Eclipse.

I setup my project to run with Ivy, and I'm working on building up models.

I've been running into some problems with building my project with Umple and Ant. Ant isn't greatly supported, so it's becoming a bit tough.

I need to find some Ant tasks for umple.

After the meeting, I need to create a ticket for Ant tasks for integration into build chains. They do not exist. I created Issue 674 (on Google Code) to address this, and I will work on this myself.

I was under the impression I couldn't use umple to write the ant tasks, but because we have an umple compiler, it should work without concern.

I'm going to try to have this in a separate project and see if we can build the project that way.

27 January 2015

Joined up for the call with Andrew on the live coding session.

21 January 2015

Working on getting the umple environment setup on my Linux box (Linux n2-linux 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux) because my laptop is currently getting repaired with Apple.

20 January 2015

Worked with Andrew to get a patch submitted. Dealt with strange newline characters that svn wasn't cleaning before creating a patch. Tim ultimately solved it for us.

19 January 2015

Fixed a patch for whitespace issues for Andrew.

Found a wiki page on ECore modelling support in Umple, it seems like it is available, but not necessarily ready: https://code.google.com/p/umple/wiki/EcoreDevelopmentStatus

I think I'll have to adjust the API so I can access it by loading the Jar into an application.

I've started working on the semester project, but I'm currently hosting it on GitHub: https://github.com/Nava2/umple.sample.downloader. I've done this so that I can commit lots and not interrupt the build chain for cruise. Once it gets to a "stable" space, discussions around location/project will follow.

The current toolchain for working with these websites will be (subject to change..):

  • JSoup for webcrawling -- this gives an excellent API for working with DOM elements, it is modelled after the JS environment in browsers which holds familiarity compared to a SAX parser approach
  • Ivy for dependency management -- Manual dependency management is so two years ago
  • Ant for build chain -- kept due to consistency with Umple
  • Jackson for JSON read/write -- This one makes me cautious because I want to use Umple wherever possible and Jackson depends heavily on Annotations, a feature not supported in Umple

I also need to go and drop off my laptop for repairs, so my progress for this project may be hindered due to having to resetup my environment on my desktop box, and not being able to work remotely.

18 January 2015

Project specification

This project will work on tackling Issue 448 (on Google Code) as a project.

The central focus will be on creating a downloader with configurable "repositories" such as z-info.

This will be a command-line tool.

17 January 2015

Sat down to work on finding an Issue to fill time. I went through the support for Issue 76 (on Google Code) and found that there are some inconsistencies and missing language support for the abstract keyword. Unfortunately, I was missing the proper links for some of the languages. I chose to fix the issues with Ruby to make it more "ruby-like" behaviour for the ruby generator. I opened Issue 669 (on Google Code) and submitted a patch to Andrew and Tim.

I spent the majority of my afternoon working on Issue 589 (on Google Code). I tried to read in and debugged several concrete issues:

  1. Boolean variables in a Constraint tree are treated differently than all other primitive types.
  2. C++, and PHP are not affected by the defect.
  3. The case only happens with constraints and is not dependant on actions (it appeared to be until finding no. 1).

Andrew and Vivian are working on an issue in the same area, hopefully I will be able to piggy back on some knowledge here.

Tomorrow, I plan to solidify my project.

16 January 2015

Build was solved by reverting to HEAD revision.

I opened issue 667 (on Google Code) (via +aforward) and created an integration script to run through Travis-CI continuous integration server.

I did this for two reasons:

  • Commonly used framework in open source communities
  • Easily test against multiple platforms -- osx, linux, different softare versions.

I tested this via a personal fork of umple and created a patch and sent it to Andrew/Tim.

I've also been trying to help others with setting up their environments and picking up Java -- for those without a background with it.


15 January 2015

I've successfully compiled umple while changing the Java header to be a different comment, however I can't get the second compile to work. The testbed/ fails to compile with the following:

[javac] /Users/kevin/workspace/umple/testbed/src-gen-umple/cruise/associations/specializations/Zww.java:38: error: illegal start of type
    [javac]     List<? extends > newWs = super.getWs();

I've not been able to figure out why.. I assume it's a build configuration issue.

After our meeting this week, and I'll be talking about it tomorrow, I want to investigate generating regex for the syntax yaml using the grammar for umple. I'm unsure if it will work due to making sure the colouring is correct -- could be a neat project.

13 January 2015 (continued)

I stopped to work on work (shudder) and came back to the Sublime syntax highlighter. I have hosted my work on a Github repository because Package Control requires it. There is still a lot of work to make it more useful than a simple syntax highlighter. But for now, it looks very similar to the Java syntax highlighter.

I need to find a document showing as many use cases as I can so that I can make sure everything highlights properly. I've added a remark on issue 188 (on Google Code) showing my progress.

12/13 January 2015

I've began working on the check list provided by Andrew:

  1. Write a brief welcome message to umple-dev@googlegroups.com
  2. Re-create a model from a past assignment (big or small) in umpleonline and paste the saved URL in your log
  3. Run a full build (required for creating a patch), all tests should pass, how many are there
    • I did this last week, the number of tests are: 3866, but two fail shown here. This seems to be caused by this from the build log:
     [echo] Resetting To Test Version: -> @UMPLE_VERSION@
     [echo] Resetting To Last Version: -> ${last.version}

I tried rebuilding the library a second time after the first build, but it still didn't adjust the issue. The version now says that it is @UMPLE_VERSION@.

  1. Add a test to umple project (any test), and create a valid patch (please send to aforward@gmail.com)
    • I'm not sure where to add tests, I looked to find a few tests to add but need to put more effort in.
  1. Load the umple projects into eclipse, and provide a screenshot in your log

    • I'm not sure what this means, but: http://i.imgur.com/V9bjhex.png
  2. Change the welcome comment in the generated Java code (UmpleToJava project), create a new version of Umple, re-generate your code from #1 to observe the changes

    • I'm unsure what this means, but I compiled and have Umple working by running the tests.

7) Find an easy bug in bugs.umple.org, resolve it and send a patch I've not submitted a patch, but I am working on getting a syntax highlighter for umple going in Sublime Text 3.

http://i.imgur.com/NQaGkER.png This works towards issue 188 (on Google Code).

6-7 January 2015

I got the umple project running with some headaches around following the guides on the getting started page for developers. Building the file from the UI does not work the same as from the command-line -- definitely an issue. Once umple is built from the command-line however (using ant), it worked without concern. I am on Mac OSX with my current build, and the steps to get it up and running simply took installing the latest JDK (1.8 as of writing) and then through homebrew: brew install ant antlr. Following this, I installed the latest eclipse SDK (new computer so I lost my previous installs) and installed the XText/XTend plugins from this update site.

So being a bit ahead of the game, I got frustrated by the current XText UI so I decided that I would take a crack the initial start of issue 319 (on Google Code) since it is tagged as UCOSP and I've wanted to work with XText in the past (previous work experience) but lost out on the opportunity (our project shifted significantly).

First thing in this issue is looking at Make your XText based editor 300 times faster. This article suggests to modify the Guice module to use SimpleResourceSetProvider instead of XtextResourceSetProvider.

I made the mistake of adjusting the abstract XText-generated module instead of the post generation version, UmpleUiModule. One of the really nice things about Guice is that these configuration changes are so simple and straight-forward.. usually.

In doing these changes and just getting the XText run configurations to run, I fear I may have created invalid run configurations since UmpleUiModule is never loaded. Arguably, this is a better problem than: "Oh God, I broke everything."

I "fixed" an issue where the ui plugin was requiring a package that isn't exported by any plugin that could be depended on by just removing the package. This does not seem like a solution. The package is: org.eclipse.xtext.xtend2.lib which I removed from the cruise.umple.xtext manifest. The problem is that the available plugins that are depended on do not export this package. That being said, running the eclipse application now runs my module changes but follows up with a failure to load the umple files in the Eclipse Editor -- small win, big loss.

I now get an error referring to a missing umple.ecore which is a generated file that exists, but I don't think is being exported with the plugin -- thus causing the issue.

Caused by: java.lang.RuntimeException: Missing serialized package: umple.ecore