Kevin Brightwell edited this page Aug 26, 2015 · 1 revision
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.

Log entries

Entry 41 - May 8

This is my final UCOSP log. Finals are done and course cleanup has finished. I've determined that I will stay on as an open source contributor in the future, fixing and maintaining and developing for Umple.

Entry 40 - March 31

Its been awhile since my last update, and in truth there probably should have been a few before this but I simply did not have time. Most of my time has been spent frantically preparing for my final week of the term and all the assignment and project madness that is associated. With that being said though I did get some things done, although not much.

Issue 76 (on Google Code), allowing classes to be declared as abstract, is for the most part very close to being done and could even be considered as such. I was debating implementing checks everywhere to force the issue where you cannot instantiate and abstract class however Andrew mentioned that it would be better if it were left for when native language compilers errors "bubbled up" in Umple, which would effectively give us the check for free. Furthermore, the only thing really left that I can see is to make this feature work with generation of code in languages other than just Java.

My focus right now, outside of my other classes, is finishing up a paper and presentation that I have on UCOSP and this project as well as an effort to fix issue 288 (on Google Code). I believe the problem is related to naming conflicts, as I was able to solve the example code that reproduced the error manually by doing just that. I will keep things posted on the status of this as time goes on.

Entry 39 - March 24

Continuing my work on issue 76 (on Google Code), I've been able to cause Umple classes with the "abstract" keyword present lead to generated Java code to contain the abstract class (with the keyword, iff it is an abstract class).

Currently debating the issue on enforcing no instantiation on abstract classes as there is a potential large amount of refactoring that would entail such a task, along with the end result of a massive performance hit.

Entry 38 - March 15

I'll start off by mentioning the obvious here. It's crunch time. I've greatly underestimated just how much I have on the table at the moment to get done, and its really starting to get to me. In the past week and a half of absence, I really haven't been able to do much. Two term projects coming up, a term paper, a midterm (which is scaring me), a few assignments and a presentation is what I'm currently up against.

I'm unsure how much more I can get done, but in all likelihood there is a light at the end of the tunnel and I should be able to do something more before end of term.

With all this being said, here is what I'm currently working on and plan to work on:

  1. Continue quest to provide more adequate internal documentation in the codebase, probably this time towards the jet templates (maybe).
  2. Fix issue 76 (on Google Code) (implement abstract classes for Umple)

The first will be a passively ongoing endeavour, and in truth I don't think I can finish it all. There's a lot of code and some of it I still do not understand and therefore would rather not try to comment it as there is an inherent risk that the wrong comment would go up misleading someone else down the road.

The second is what I plan to actively work on, and am currently doing so around the time of this writing. I think I will do this in a few iterative steps as follows, each of which could be a separate commit:

  1. Add the "abstract" keyword to the grammar so that it may be parsed, then see if Umple can parse it (this will clearly be tested).
  2. Following the above, the next step is to see if I can get an Umple class to recognize being "abstract", in other words to verify that it can be set to "abstract". This likely involves a meta model change for the Umple class entity and of course testing (of which is done first).
  3. Once this is all done, the framework is there much like singleton. Now the actual behaviour associated with being an abstract class has to be implemented and enforced. Particularly the class cannot be instantiated rather it must be subclassed. This will likely involve changing the jet-templates for the rule enforcing. Heavy testing will clearly need to be done in this area.
  4. Once the enforcements of the rules behind an abstract class are in place and working the next logical step is to look into porting the implementation (which will be for Java first) to the other languages (provided it makes sense to and is possible in said language).

For now I believe I have the first part done, all you have to do to make an abstract class is to create an Umple class like this:

class Foo

And it will be abstract.

Going to proceed with touching up the first part before committing.

Update 1

Abstract keyword is in working order, correctly sets class to abstract when present.

Groundwork is now here, as I outlined earlier, next up is to enforce the rules surrounding abstract classes.

Implementation committed.

Update 2

Felt that where I initially implemented the grammar for the abstract keyword was inappropriate as it is more so a programming paradigm than a pattern. Grammar has been reworked and committed without error.

Entry 37 - March 5

Wrote up a blog post for UCOSP.ca and forwarded to Tim to be submitted to the steering committee.

Besides this I have done a bit more internal documentation, in particular this time it was with the textual parser (mainly) along with the generator s. A bit of touch up was done to the previous parser.ump as well.

Entry 36 - March 1

As many others, I've had the unfortunate problem of dealing with a few midterms and assignments recently so progress has been slow. Only a few more, so hopefully I can stay on top of all this and not fall behind (multiple term projects and large-scale assignments approaching end of term...)


I've made further progress in regards to my quest to document the codebase. This time around the victim of being commented was the Umple Internal Parser, particularly with UmpleInternalParser.ump and UmpleInternalParser_Code.ump (both heavily dealing with tokens that are analyzed to populate an Umple meta-model instance).

I think this should certainly improve the time it takes to understand one of the most critical components of the Umple compiler.

Following this I'm going to continue internal documentation, however I may be looking to branch off to tackle an issue or two in the meantime.

Update 1

It appears that in my quest for better internal documentation that I was disregarding the convention for 2-space indentation, rather than tabs.

I've fixed this problem by regex pretty-printing all the source files I touched.

I was able to accomplish this by the great power of Vim and the help of the Vim Wiki. With the single press of the F7 key I can pretty-print/convert a source file to 2-spacing instantly.

I figure this would be beneficial to those that want to convert tabs, if they have been doing so, to format their code:

In your .vimrc (usually in your home directory) place the following:

set tabstop=2
set shiftwidth=2
set expandtab

map <F7> mzgg=G`z<CR>

This effectively tells Vim to consider all tabs as sequences of space characters, where a tab is 2-space, and all indentation levels are 2-space. The map is the macro for the F7 key to immediately pretty print in normal mode (his esc to get there in vim).

Entry 35 - February 26

I've been working away at internal documentation of the codebase, and for the most part have got Umple.ump to a satisfactory level (especially the meta-model, so its perfectly understandable now).

While commenting I noticed that a anomaly appeared in generated code... for example the Umple code:

 * The main meta-model of Umple.
 * The model contains everything that was derived from an Umple file (.ump) when it was parsed such as 
 * the classes, attributes, associations, methods, etc that were in it.
 * Put another way, when an Umple file (.ump) is parsed an Umple model is populated with everything that was parsed from that file.
 * Because of this it is absolutely critical to understand the model since it is basically the "root" of everything.
class UmpleModel

Would appear in Java as:

 * The main meta-model of Umple.
 * *
 * The model contains everything that was derived from an Umple file (.ump) when it was parsed such as 
 * the classes, attributes, associations, methods, etc that were in it.
 * *
 * Put another way, when an Umple file (.ump) is parsed an Umple model is populated with everything that was parsed from that file.
 * *
 * Because of this it is absolutely critical to understand the model since it is basically the "root" of everything.
public class UmpleModel

Which was very odd! (notice the double asterisks on the empty lines?)

As it turned out the problem was with an edge case I missed in my comment processing algorithm in Comment.format.

I've fixed the problem and committed it to the repository (see r1525 (on Google Code)).

Update 1

I've made some headway into providing internal documentation for some of the most important areas in the parser, particularly regarding Parser.java with the "parse()" methods.

They now have full javadoc describing what they do at a high level, what the parameters are for, in general how it works as well as a decent amount of comments inside the methods serving as an aid to whats going on.

Entry 34 - February 25

I haven't been working at my usual pace due to heavy workload on other projects and preparation for midterms but I should be good now (for the most part).

issue 235 (on Google Code) has been solved by Tim, so I am not looking into that anymore, rather instead I've been working on something rather critical which is issue 197 (on Google Code) (lack of internal documentation in the codebase).

The idea behind the internal documentation is as follows:

  • Provide comments in an umple file (.ump) in cruise.umple->src
  • Run a full build
  • Since the issues regarding comments in Umple code not transfering to generated code is solved, the comments will transfer to the corresponding generated Java files.
  • Developers can now take advantage of Eclipse's Intellisense.

I'm taking a systematic approach to this:

  1. To begin with, comment the primary "top-level" umple files, such as Umple.ump that deal with the meta-model and general structure of entities such as classes and what they contain.
  2. After this, work my way down into domain specific things such as "Parser_Code.ump" which are specific to the code that is in the parser such as the parsing logic.
  3. Repeat step 2) until satisfactory.

The idea for comments will be Javadoc on all attributes/associations and methods as well as classes. The format I'm going to follow, provided its necessary for non-obvious things is:

 * <General description of what the class is about,
 * what its used for and who might use it.  Brief (or not).>
class Foo
     // Brief comment about what the attribute is and what its for.

     // Brief comment about what the assocation is and what its for.

      * <General description of what the method is about,
      * what its used for and who might use it.  Brief.>
      * Parameters, if any, and explanations of them, if their 
      * not super obvious.
      * Return values, if any, and brief explanation (if necessary).

I'm hoping to have a significant amount of internal documentation done by the end of this weekend, and plan to make multiple incremental commits to achieve this. In the end the desire is to have enough internal documentation such that someone unfamiliar with the code, or rusty with it, will be able to learn the flow and how things work much more quickly than traditional tracing (which I had to do).

Entry 33 - February 20

I've been further looking into issue 235 (on Google Code) and upon Tim's suggestions I was able to find out where to look.

The example I am currently using is:

// Comment above a class.
class foo
  // Comment above a method.
  void testMethod()
    // inline method comment.
    System.out.println("Hello world"):

As it turns out the generated code in my local version of UmpleOnline comes back from the parser before getting formatted as:


Now the key thing here is to observe that the System.out.println("Hello world") does indeed appear that way (%22 means quotation).

This is the case JUST before the line of code:


And based on an email from Tim it looks like this is where things are going wrong. Since no other OS exhibits this problem it is likely the version of PHP on the mac or something along those lines.

I've been told that this is now a low priority issue as it is extremely isolated to a small case (local version of UmpleOnline for OS X, normal UmpleOnline works).

Outside of all this I have been looking into issue 197 (on Google Code) which specifies that the codebase needs much more internal documentation.

Entry 32 - February 19

In the past few days I've been looking over and analyzing existing issues and the ones I've identified that I would like to work on.

Following this I have also assisted a few with issues in development.

Currently I am looking into the mysterious issues around issue 235 (on Google Code) where quotations are escaped by back slashes. What is very disturbing about this is that its ONLY with Mac OS X and ONLY in UmpleOnline. Works fine in all other cases.

From this I can deduce that my investigation should be to compare what's going on between generating the Java code in linux and generating it in Mac OS X. Likely I will use Chrome's profiling tools for this (which I have never used, but like always I'm willing to learn and I can do so fast).

As far as the codebase is concerning, I am 99% confident that the changes to be made are not in any parser/compiler more over they will have to be made in the umpleonline/ project (php, javascript, etc) as somewhere there is indeed a string sanitizer that is OS specific that causes this mess-up, otherwise the command line generation would exhibit the same results.

Have to work the next 8 hours but I'll try to look into this later when I get time.

Update 1

Throwing proof of whats going on with this bug (issue 235 (on Google Code)) here.

The following is the umple code example I am testing with:

class Foo
  // I am a comment above a method.
  void testMethod()
    // "I am a comment inside a method."
    System.out.println("Hello world!");

And this is what I get if I generate Java code from it on the command line or in Eclipse:

/*This code was generated using the UMPLE @UMPLE_VERSION@ modeling language!*/

public class Foo



  public Foo()


  public void delete()

   * I am a comment above a method.
  public void testMethod(){
      // "I am a comment inside a method."
    System.out.println("Hello world!");


And this is what I get if I generate the Java code in my local version of UmpleOnline in Mac OS X (10.6):

/*This code was generated using the UMPLE modeling language!*/

public class Foo



  public Foo()


  public void delete()

   * I am a comment above a method.
  public void testMethod(){
      // \"I am a comment inside a method.\"
    System.out.println(\"Hello world!\");


Looking through the code in google tools and it appears that the generate button is tied heavily into JQuery, namely with the file "jquery-1.7.1.min.js", however as I expected the file is completely unreadable (like most JS libraries) which is frustrating so I have no idea what is going on in there. Perhaps I am looking at this the wrong way and someone with a more intricate knowledge of the front-end codebase could give me insight on this.

Entry 31 - February 16

I haven't had much of a chance to make any more progress on issues/fixes due to massive assignment overhead and midterms this week. I've updated the plan as to what I'm going to work on in the near future. These can be seen here:


I will try to get going on them right away, hopefully solving a few of them before the end of the weekend.

Outside of this I have tested a patch for James and committed it.

Update 1

I have began work on, and finished, the fix for issue 278 (on Google Code) where a method name of two characters or less caused a compilation error.

Fix has been committed.

Looking into another issue on my list.

Entry 30 - February 13

I have been actively working on ensuring custom methods in generated code (particularly PHP and Ruby) are correct in both content and format.

I have found out that PHP was fine, however Ruby was certainly not. To illustrate this I came up with a simple example:

Lets consider the following Umple code

     class Foo 
       void hello(name) 
           'Hello ' + name 

One would expect, at least for generated Ruby code, that the method would look like this:

     def hello(name) 
       'Hello ' + name 

However this is what happens when you write any custom method and try to generate it in Ruby code in general:

     def hello (name)end 

All you get is "def" followed by the method name, its parameters and the end... all on the same line. Even the "def" is incorrectly spaced from the prefix (should be 2-space, it is 1-space).

I submitted an issue on this earlier, issue 277 (on Google Code), and as well I have come up with a fix for it. The fix is in, and it is working (at least as far as the tests go and my manual observations).

One thing does disturb me though, and it is related to whitespace formatting in the custom methods. If you add your own tabs to add indentation to your Umple code it will cause anomalies in the generated code as those spaces you added will appear (in addition to the auto-format ones) in the code. This isn't harmful, but it looks bad when you have many lines in a method with different indentation levels... looks like a stair case.

I've been looking into writing a parsing algorithm to fix this, much like my comment one (recall Javadoc comments should stay Javadoc comments in generated code).

Entry 29 - February 11

Tackling the problem of moving generated comments above attributes (and later associations) in Java to the corresponding getter methods.

Upon initial inspection I figured the only thing to change would be the jet template for the getter method, however I made a silly mistake in this regard and it bit me back. When editing certain jet templates, make absolutely sure that you know if the code you put in there will be "WYSIWUG" or if it will actually "not appear, but do something to make something else appear"... the latter being 99% of the time. Unfortunately this time it was not.

To illustrate this:

<%@ jet package="cruise.umple.ignore" class="Ignore"%>
  public <%=gen.translate("type",av)%> <%= gen.translate("getMethod",av) %>()
    <% if (customGetPrefixCode != null) { append(stringBuffer, "\n    {0}",customGetPrefixCode); } %>
    return <%=gen.translate("attributeOne",av)%>;

The above is the jet template for the getter methods of attributes. So since I wanted to move comments above it, then I decided to do this:

<%@ jet package="cruise.umple.ignore" class="Ignore"%>

if (av.numberOfComments() > 0) { append(stringBuffer, "\n  {0}\n", Comment.format("Attribute Javadoc", av.getComments())); }

  public <%=gen.translate("type",av)%> <%= gen.translate("getMethod",av) %>()
    <% if (customGetPrefixCode != null) { append(stringBuffer, "\n    {0}",customGetPrefixCode); } %>
    return <%=gen.translate("attributeOne",av)%>;

Big mistake. Two issues here, first the newlines. While whitespace is normally key for readibility, it is lethal here since that whitespace will directly appear in the generated Java code. Whats the problem with this? Well there are over 200+ tests of varying complexity that "expect" certain output. Not good!

The second issue in this regard is the fact that I missed the "<% %>" tags. These, which I have known about in the jet templates for a while but only recently found out what happens when you don't use them, are critical. If you don't have these, then essentially what you write in the jet template is what will appear in all generated java code. Obviously this breaks many things.

The fix was this:

<%@ jet package="cruise.umple.ignore" class="Ignore"%>
  <% if (av.numberOfComments() > 0) { append(stringBuffer, "\n  {0}\n", Comment.format("Attribute Javadoc", av.getComments())); } %>
  public <%=gen.translate("type",av)%> <%= gen.translate("getMethod",av) %>()
    <% if (customGetPrefixCode != null) { append(stringBuffer, "\n    {0}",customGetPrefixCode); } %>
    return <%=gen.translate("attributeOne",av)%>;

Also as a reminder every time you make a change to a Jet Template (in my case UmpleToJava/templates), make sure you update the rest of the codebase so the change actually happens. Changing the Jet Templates alone does nothing, when you change a Jet Template it will "create" its own "JavaClassGenerator.java" and the interface generator. You have to copy and paste these (to replace) the old one in cruise.umple->src-gen-jet. For me this is cruise.umple.compiler.java in src-gen-jet. In practice it is w/e corresponding package for the language. Hopefully this helps.

Possible too much info here, and really verbose, but I felt like this would benefit anyone who is having issues with Jet Templates as they are really key when working with code generation.

Update 1

I have modified and changed how comments above attributes and associations are output in the generated Java code to solve the problem of no Javadoc API for them. Changes committed.

Entry 28 - February 10

It appears that the possible "fix" that I had come with last time is indeed not what was desired, and it did feel awkward. To refresh, I was looking into the Javadoc api generation on attributes and associations that appeared to be non-existant in the api and the reason for this was due to the fact that they were private. The supposed fix I had come up with was simply to add the "-private" flag when generating the Javadoc.

I now understand what was originally mentioned and am looking into having the Javadoc for attributes and associations appearing above the corresponding getter methods. I think I will discuss this in today's conference, as Tim noted, it is worth discussing. I really want to know what convention we want to follow here.

Update 1

Attended conference call this afternoon with Tim, Sonya and Song. Found out that the approach to be taken on my issue is to remove the comment above an attribute/association and place it on the getter.

Entry 27 - February 9

Early morning. It seems that the previous assumption regarding private attributes causing Javadoc generation to be ignored was true. I have confirmed on my local deployment that if you add the "-private" flag to compiler.php in the Javadoc building phase that the issue is resolved (at least at first glance).

I would also like to mention that a very helpful friend and colleague gave me some hints in regards to the nature of Javadoc api generation.

Entry 26 - February 8

I have been looking into an interesting issue around javadoc generation. Since most of the comment issues have been resolved in code generation it seems only natural that this be fixed.

The primary issue at hand was pointed out by Tim, where upon javadoc generation you will not be able to see any javadoc for attributes or associations in the generated javadoc api... and as it turns out I believe I have found the reason for this:


When you go to the "Specifying Visibility" it will note:

"By default, the Javadoc tool will document both public and protected members of an API. Sometimes you might want to show the private members as well or only show public members. In order to do this you can tell the Javadoc tool which member accessibility level to document."

Curiously I looked at the generated java files and sure enough the attributes are private. This explains why all method and class javadoc appear: They are public.

This means that the likely solution to this problem is to tell whatever is calling the javadoc command to take into consideration private attributes.

Looking into this.

Entry 25 - February 7

Fixed the issue where methods would not appear in php generated code. Following this fix I also added the ability for comments to appear around the method since the methods were now in existence.

Entry 24 - February 6

It is early morning and I have been trying to get the missing comment fix that is currently done in Java, C++ and PHP to work in Ruby.

I have done this, however I am hesitant to commit for a few reasons:

  • There are a few tests that block my ability to properly format the comments, as such things like this:
  I am a comment

Make the test fail, since it wants:

I am a comment

As well the custom method definitions have the same problem, I tried making sure that you could only have:


But it fails... since it wants 1 less space prior to the "def" (meaning it won't line up with everything else) and the end cannot have any spaces...

  • The last reason is because I'm tired atm and I need to rethink this. I need to take a break from testing and coding... perhaps I should do this...

I'm currently looking into this. Note that I do have comments appearing in generated Ruby code now, but I am not satisfied enough to commit with this going on.

Update 1

It appears I have completely missed a fundamental aspect around developing fixes for the code generation: Creating tests to verify the correctness of the output... I had only been creating tests for the parser and compiler... this is going to be fixed for my future Ruby commit (coming up) and the past ones.

I have also found a fix for the aforementioned problems with the Ruby comment issues.

Update 2

Ruby fix for missing comments in generated code has been committed, as well I added an extensive testing suite for the comments in each language to ensure that regression takes place and the comments don't disappear down the road.

Entry 23 - February 5

I have ported my fix for missing comments above attributes, associations and methods in generated Java code to generated C++ code.

Working on doing this for Ruby and PHP.

Update 1

I have ported the fix to PHP. However I ran into a problem to do with doing it for methods, since as it turns out you cannot get custom methods in generated PHP code to begin with. Looking into this, but I think its because there is no JET template that does this. I can make one.

Entry 22 - February 4

In the morning today I noticed that there was apparently a side bug related to comments that were already in Javadoc-like format. In particular if this was the case spacing and the asterisks would be warped due to the fact that they were not ignored (like they should be).

I fixed this in the morning and the commit went through successfully.

Additionally I spent some time looking into the same problem to do with associations in generated Java code. I have fixed this as well.

Currently looking into fixing the comment issues for other languages as I think its done for Java now.

Entry 21 - February 3

Following the advice of Tim, Andrew and Miguel I have been able to correctly resolve (at least as initial glance) the problem with the jet templates and to my surprise my fix works! However the formatting of the comments above the method is slightly off.

I'm now going to proceed to move all my "test modifications" into the corresponding ump files so that full builds will not erase my work. Following this I will touch up the formatting with the comments in the jet templates and then look into the other languages (I may do a commit when the java version is working correctly and wait for the rest even though they will be simple once one is done).

Update 1

I have fixed the formatting with the comments above methods (for Java), screenshots to follow later when I finish moving my changes to the respective .ump files.

Update 2

I attended the weekly Google+ hangout meeting today, and in addition to this I committed my fix for the issue around comments not appearing above methods in generated code.

The build has passed, so I am assuming that everything went okay with the commit. On to the next issue (attributes and other languages)

Update 3

Based on the knowledge of the codebase acquired while implementing my fix for the missing comments above methods issue, I was able to fix the related problem with attributes.

Comments above attributes in Umple code now directly transfer into the generated java code. The fix has been committed, and I believe the build has passed.

Entry 20 - February 2

I think I have refined my research into issue 146 (on Google Code) enough now that I'm positive the parser is not to blame for comments disapearing above methods. Its something to do with the generator, I've spent the last few days wolf-fencing and tracing with the debugger along with creating multiple tests to see if the parser was not picking up the comments.

It always has.

So where I am at now with this issue is to do with the UmpleModel. In particular I believe I've traced it down to this method where things start to go awry, since everything is fine before:

  // Generates the actual code
  public void generate()
      for (GenerateTarget target : getGenerates())
         String className = StringFormatter.format("cruise.umple.compiler.{0}Generator",target.getLanguage());
        Class<?> classDefinition = Class.forName(className);
        CodeGenerator generator = (CodeGenerator) classDefinition.newInstance();
    catch (Exception e)
      throw new UmpleCompilerException("Unable to generate code",e);

Somewhere in there the results of parsing are getting interpretted incorrectly resulting in no comments above methods, this may require modification of the code generation or the model itself. Investigating this further.

Update 1

It appears I may be quite wrong about the sole problem being with the java code generator that I had previously thought. After careful analysis of how class definitions themselves are parsed, and in particular how the comments above them are parsed, it appears they are added to the class themselves (and probably from there later on the generator grabs them to output to the generated code).

This tells me three things:

  1. It is indeed a parser problem, the internalParser has to be modified and I am currently doing so.
  2. The Method object itself has to be modified to allow operations with comments, much like UmpleClass does.
  3. The generator also needs to be modified in order to allow the generation of comments associated with methods in the same manner comments associated with class definitions are.

Going to see where this goes. It shows promise.

Update 2

I have had what I believe to be success from doing the above. Models actually receive just about any comment I put above them now. The only thing left is to get the jet-template issue resolved (so that I can have the appropriate code generator updated from jet).

I have placed my fix in the jet-template class_MethodDeclarator.jet (inside UmpleToJava/templates) however I lack the knowledge currently as to how to actually make it "generate" the gen files (which is what I need to test if this actually worked, I think it will).

Entry 19 - February 1

Found something interesting related to the issue I am working on, as it turns out the code:

class Foo
    // I am a comment above a method.
    void testMethod()
        // I am a comment inside a method.
        System.out.println("Hello world!");

Actually has BOTH comments parsed, contrary to my intial beliefs. This is both interesting and disturbing at the same time. Since the result of the parser for the grammars associated with the above is:

[classDefinition][name:Foo][inlineComment:I am a comment above a method.][concreteMethodDeclaration][type:void][methodDeclarator][methodName:testMethod][parameterList][code:// I am a comment inside a method.\nSystem.out.println("Hello world!");]

This leads me to believe that the problem is not with the parser, however I need to be sure of this before I go down the path of investigating the code generators. The generated code for the above class is this (note the missing comment above the method, EVEN though it parses it as far as I can tell):

/*This code was generated using the UMPLE @UMPLE_VERSION@ modeling language!*/

public class Foo



  public Foo()


  public void delete()

  public void testMethod(){
      // I am a comment inside a method.
        System.out.println("Hello world!");


Would it be correct to go down this route? Or should I keep analyzing UmpleInternalParser.java and Parser.java.

Will see what else I can find out on this.

Entry 18 - January 31st

Have been having a bit of difficulty tracking down the exact reason why Umple code such as this:

class foo
     public String print()
          System.out.println("Hello world!");

Caused absolutely no methods in the class definition at least in terms of how the parser sees it. For instance if you try to grab the Umple class from the model and assert that the number of methods is 1 (or greater than zero for that matter) you will get an assertion failure.

As it turns out you do not use the "public" keyword in front of these... slight oversight on my part. When removing the public keyword it parses it as a method and correctly formats it to the target language. Previously the entire class definition body (known as class content in the grammar) becomes all "extraCode". Based on this I think I will be able to follow this path and find the root of the problem related to inline and multiline comments disappearing above the method.

Current plan is to try to finish off this issue before Friday.

Entry 17 - January 30th

Did a series of tests across multiple operating systems and browsers to verify that the test version of UmpleOnline was not broken, at least at a reasonable usage level. Operating systems, with the browsers tested, include:

  • Windows 7 (Chrome, Firefox and IE9)
  • Mac OS X 10.6.8 (Snow Leopard) (Chrome and Firefox)
  • Ubuntu 11.10 (Oneiric Ocelot) (Chrome and Firefox)

Going to attempt to close issue 146 (on Google Code) for good today, however this depends on how much of a lead I can get on the outstanding work I have to do for my courses atm. Going to push for it.

Entry 16 - January 29th

Based on the progress I made with the supposed fix to the empty inline comment issue, I figured I would tackle the same problem related to empty multiLine comments. This proved to be a bit more of a hassle than I thought it would be and at this current time of writing I am very tired.

But I got it working, screenshot provided as I did for the fix on the inline comments. Left screen is what happens when you use empty multiLine comments (nothing appears and no code generates) while the screen on the right is my local deployment with the working fix (everything appears as it should).


I will wait until I get home from my shift at work tomorrow before I make the patch and submit it, because in my current state I do not think it is wise.


After work today I noticed that my previous patch was successful and I have become a committer.

In addition to this I spent a reasonable amount of time testing my next fix, which is related to empty multiLine comments, on my local deployment. Upon committing my fix to the repository I noticed that I was getting rejected with the message:

svn: Commit failed (details follow): svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKACTIVITY request for '/svn/!svn/act/dc9ebe88-bc26-4dad-8c58-33cabb6d8618'

which was very odd. As it turns out this was caused due to the fact that my working copy was not checked out using https. So I would therefore not be able to use the working copy to commit. The fix for this was the following, in order:

  • First I created a patch that had my fix.
  • I then checked out a new working copy with the command:

svn checkout https://umple.googlecode.com/svn/trunk/ trunk --username JordanJohns.c@gmail.com

which gave me a working copy for which I could commit with.

  • Following this I had to fix my local deployment since this was a new checkout, even though I named it the same (and renamed the old working copy). Basically I went through this wiki again:


and re-did steps 4 and 5. My local deployment then worked again with this new repo.

  • I then proceeded to setup Eclipse again to use this new working copy, which went without issue (had to run a full build first though to solve errors).
  • After all this, and verifying that things were stable I applied the patch for the multiLine fix to this working copy.
  • I then proceeded to extensively test by running multiple full builds, running all junit tests and doing manual testing on my local deployment. After doing this for a decent amount of time without errors I decided I would commit the fix, which I did.

I am now in hope that I did not break the build.

Update 2

I have received word that my first commit was successful and I did not break the build.

Entry 15 - January 28th

Heavy research and headway has been made on the aspect of issue 146 (on Google Code) where an empty "//" comment above a class definition would result in the class becoming the comment, in other words it won't compile it.

I have been adding numerous tests in multiple forms on this and so far they seem to be passing, as well I set up a local deployment of UmpleOnline to verify my fix which is working great as well.

The following is a screenshot demonstrating what happens on the current version of UmpleOnline if you use empty comments above class definitions (left screen) and what happens on my local deployment with my fix (right screen).


There is an unfortunate issue I am running into currently however, and I think it is very minor and is probably merely something I forgot. It relates to tests passing. When I wrote my tests for UmpleParserTest.java, to ensure classes would still exist in the presence of empty comments above them, I apparently did not add "expected results" in UmpleInternalParserTest.java which is causing 2 failed tests (duplicates of the ones that pass inside UmpleParserTest.java). I am actively looking into seeing what I am to put in there so my fix is complete.

Worthy things to note for those messing with the Parser:

  • When you are trying to solve a parser issue, you will typically mess with Parser.java and get it to work from there. However make sure when your done that you move the fix in code to Parser_Code.ump since Parser.java gets overwritten on a full build! (Very important to know!)
  • What goes hand in hand with the above is to ensure that you remove or at the very least comment out significant print statements (if you use those for debugging) in Parser.java if you are going to do a full build. Why bother if they are getting overwritten anyway? Because if you don't you will run into an unfortunate issue where the full build has to compile and build 641 files and this will result in every single line being printed to stdout. This made my workstation go from a 52 second full build to almost 17 minutes. If I were to have done that mistake on my laptop or something with moderately less power it would have been many hours.

Note that the second point can be easily mitigated if you don't mind terminating the build-in-progress, but then you deal with version issues (which are okay, but can be frustrating).


I have figured out the issue about the UmpleInternalParserTest. The patch is now submitted for the empty inline comment issue.

Entry 14 - January 27th

Participated in a G+ Hangout in the afternoon on progress and to discuss the issues with IE9.

Outside of this I have setup a secondary development environment on my desktop (Ubuntu 11.10) for ease of development.

A minor thing to note with this, and this is not in the dev setup wiki (as far as I could see):

1) You have to install antcontrib:


Or else building from the command line will fail immediately.

Instructions are here:


But essentially all you have to do is untar the file:

tar -zxvf ant-contrib-1.0b3-bin.tar.gz

I then, for convenience, moved the ant-contrib directory to home. Then I cd'd into /usr/share/ant/lib and proceeded to copy the jar file into here:

sudo cp ~/ant-contrib/ant-contrib-1.0b3.jar .

Outside of this getting it to compile on the command line required an install of php and "rake" (for Ruby). Simply a couple of apt-get's solved this. (php and rake)

After this was done command line compilation works fine. However Eclipse was bugged with errors to do with joptsimple, which are listed here:

  • joptsimple cannot be resolved to a type
  • OptionParser cannot be resolved to a type (multiple instances)
  • OptionSet cannot be resolved to a type (multiple instances)
  • The import joptsimple cannot be resolved
  • The method optParse(String.md) from the type UmpleConsoleMain refers to the missing type OptionSet

Oddly enough, I do not get this error on my mac dev setup (which works fine), just this new Ubuntu setup. Going to go with James fix on this that I talked to him about unless there is another way. The fix:

  1. http://repo1.maven.org/maven2/net/sf/jopt-simple/jopt-simple/4.3/jopt-simple-4.3.jar
  2. Add it to the build path (library-> add external jars)

That should fix the issues in Eclipse. It did for me. Thanks again to James on this.

UPDATE: James and I found out that the trunk of the repo became borked late tonight (or technically really early in the morning), see Umple-Dev for info on this. Its critical (only 4 directories for a fresh checkout).

  • Jordan

Entry 13 - January 26th

Retested the new version of UmpleOnline:


to see if many of the major issues with IE9 under Windows 7 remained, which they did. Issues summarized (which can also be found at Umple-Dev):

  1. UI size issues still remain. The textual area on the left is noticeably smaller than the viewing area on the right.
  2. Yellow background highlighting still occurs when you give the left textual area or the right viewing area focus.
  3. The options button under Tools still runs away from you if you try to approach it to click on however this time it seems to run away if you are anywhere below the textual or viewing area (in other words its far easier to experience the running away behaviour now, before you had to be directly above it).
  4. When loading an example many association and inheritance lines are extremely elongated resulting in warped diagrams and large scroll bars in the viewing pane.

UPDATE: Added the screenshot below to show the comparison across the browsers. From left to right: Google Chrome, Firefox, IE9. Note that the "Options" button is not expanded down as I mention because my cursor is not near it.


Note: If you want to be able to view the screenshot in detail, copy the image url and open it in a new tab. Its a multi-monitor screenshot so it may appear very small in this wiki page (it does on my laptop).

Entry 12 - January 25th

As per the request to test out the new version of Umple online I took it upon myself to see if there were any problems with browsers under Windows 7. I found that for the most part everything worked well (Chrome and Firefox) except for IE9 which failed horribly. Below is my findings with it:

  1. Major sizing issues with the UI all over the place. In particular the textual area on the left is a far smaller rectangle than the one on the right (about 2/3 the size). As well most things in the middle tool bar area bleed into the scroll bars on the right side.
  2. The left textual input area has a very large yellow background surrounding it if you give it focus (click in it to see). The right viewing pane also has this problem, but it is more like a border than a huge area around it.
  3. If you try to click on the "Options button" from above in the Tools menu it runs away from you, extending further and further down until you tire of chasing it. This results in a very large scroll bar on the page. It seems to reset and exhibit jumpy behavior if you can get below it (very hard to do)
  4. Writing a simple class such as:
class derp


And then quickly running the cursor to the top and bottom (line 1 and 4) with the arrow keys results in the line number counter getting mixed up seemingly permanently. For example the second line will be line 4, as will the 4th. In some cases I was able to get the 4th and 2nd line reversed (for the line number).

In addition to the testing I found, as many others have, that log entries listed in chronological order carry significant burden to both the reader and to the writer. I have reversed them for the sake of the reader and myself. Newest entry is always at the top, oldest at the bottom (reverse chronological order). Also began a new scheme for the entry headings, by using the date in them which should have been there from the beginning.

Current plan is still to look into issue 146 (on Google Code), however I'm currently playing catch up with everything else. Pushing really hard to get a free day in this week to sit down for a long sprint at this. When this issue gets solved the C++ generation development has me interested as I could look into the incorrect code anomalies it is generating.

Entry 11

Ran into quite a bit of trouble with Umple Version issues that propogated everywhere. Had to resolve them by resetting them via:

ant -f build.umple.xml -Dmyenv=local -Dumple.version= template.resetVersion

Where the "" is the "wrong version" that you are trying to reset.

Also found out that simply doing a full build without specifying the environment pushes this issue further, do not simply use "ant" ensure a full build is done with:

ant -Dmyenv=local

And if you want to, in addition to a full build, deploy to your local UmpleOnline then you want to do this:

ant -Dmyenv=local -DshouldPackageUmpleOnline=true

Outside of the version issues I have been delving further into issue 146 (on Google Code), in particular why an empty comment above a class breaks. The current objective is to have an empty comment ignored completely.

Current trace in the code related to this issue is:

1) TextParser.java: Method "nextLine()" has been modified and now seems to properly parse "//\nfoo" as two separate entities (an empty comment and a variable) however "//\nclass foo{}" does not work which is the goal. I believe I have to look into other places for this. Another important note here, and really it is critical, is that if you want to change something in TextParser.java you have to do it in "TextParser_Code.ump" since TextParser.java gets overwritten by the .ump file on compile.

2) Parser.java: Have been looking into this in how the grammar is broken down and parsed, but not much progress has been made in here.

3) umple_classes.grammar and umple_core.grammar: Been learning the grammar structure, since it is clear that this is needed to fully understand the root of the comment problem.

4) Have also written a few tests that demonstrate the issue at hand (ParserTest.java and TextParserTest.java and UmpleParserTest.java).

Current plan is to continue on this issue and fix the problem with the empty comment, and then fix the related issue in 146 where // comments do not work at the method level within a class.

Entry 10

Resolved the test failure issues and general build issues on the first day of the code sprint (Friday Jan 20th).

Looking into issue 146 (on Google Code) (the comments):


Also created a model example of a hospital system and submitted a patch for it to appear in UmpleOnline.

Entry 9

Didn't realize that the findings after the meeting did not get updated on my wiki, so here is what I found out.

The steps to correctly setup the development environment without errors are the following:

1) Download and install the Eclipse Modelling Tools.

2) Follow the development environment setup:


When you do the first step there is a critical issue that I ran into, which turned out to be the reason why there was always errors by step 5 in the dev setup. When you have to install the Eclipse Plugin (listed here):


You cannot do step 2 method 1, because if you do then step 2 method 2 is impossible to do without starting over. The reason for this is that when you try to install xtext and jet later (the topic of step 2 method 2) Eclipse will outright refuse to do so, and will fail every time telling you to check the log files.

The solution I came to was to just do step 2 method 2 instead and then proceed to follow the rest of the dev setup. In the end all errors were resolved for compilation, the only outstanding issue remaining is the fact that all tests fail.

Entry 8 (Jan 10/12)

Upon the advice suggested earlier to compile on the command line I achieved what I believe to be success. Eclipse of course still fails (unfortunately), but running the ant script manually works:

ant -Dmyenv=local -f build/build.umple.xml

However, I noticed the output from running the ant script that all the Junit tests failed...

    [junit] WARNING: multiple versions of ant detected in path for junit 
    [junit]          jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
    [junit]      and file:/Volumes/HDD/Mac/Documents/University/Eclipse/Working_Copy/trunk/cruise.umple/bin/org/apache/tools/ant/Project.class
    [junit] TEST cruise.umple.PlaygroundMainTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleFileTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleInternalParserTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleParserStateMachineTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleParserTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleParserTracerTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleSystemExamplesTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleXtextParserTest FAILED
    [junit] TEST cruise.umple.docs.ContentParserTest FAILED
    [junit] TEST cruise.umple.docs.DocumenterTest FAILED
    [junit] TEST cruise.umple.implementation.ClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.CodeInjectionTest FAILED
    [junit] TEST cruise.umple.implementation.EqualsTest FAILED
    [junit] TEST cruise.umple.implementation.ExternalClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.InterfaceTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.MNToMNTest FAILED
    [junit] TEST cruise.umple.implementation.MNToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.MNToNTest FAILED
    [junit] TEST cruise.umple.implementation.MNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.MStarToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.MStarToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ManyToMNTest FAILED
    [junit] TEST cruise.umple.implementation.ManyToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ManyToManyTest FAILED
    [junit] TEST cruise.umple.implementation.ManyToNTest FAILED
    [junit] TEST cruise.umple.implementation.ManyToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.NToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.NToNTest FAILED
    [junit] TEST cruise.umple.implementation.NToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.OneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.OneToMandatoryManyTest FAILED
    [junit] TEST cruise.umple.implementation.OneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.OneToNTest FAILED
    [junit] TEST cruise.umple.implementation.OneToOneTest FAILED
    [junit] TEST cruise.umple.implementation.OneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.OneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToNTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.OptionalOneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.ReflexiveAssociationTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalMNTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalMStarTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalManyTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalNTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.UnidirectionalOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.cpp.CppClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.cpp.CppExternalClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.cpp.CppInterfaceTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.ecore.EcoreGeneratorTest FAILED
    [junit] TEST cruise.umple.implementation.java.JavaClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.java.JavaExternalClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.java.JavaInterfaceTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.json.JsonTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.papyrus.PapyrusGeneratorTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpCodeInjectionTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpEqualsTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpExternalClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpInterfaceTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMNToMNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMNToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMNToNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMStarToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpMStarToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpManyToMNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpManyToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpManyToManyTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpManyToNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpManyToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpNToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpNToNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToMandatoryManyTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToOneTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpOptionalOneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpReflexiveAssociationTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalMNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalMStarTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalManyTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.php.PhpUnidirectionalOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyCodeInjectionTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyEqualsTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyExternalClassTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyInterfaceTemplateTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMNToMNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMNToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMNToNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMStarToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyMStarToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyManyToMNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyManyToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyManyToManyTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyManyToNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyManyToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyNToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyNToNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToMandatoryManyTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToOneTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalNToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToMNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToManyTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyOptionalOneToOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyReflexiveAssociationTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalMNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalMStarTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalManyTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalOptionalNTest FAILED
    [junit] TEST cruise.umple.implementation.ruby.RubyUnidirectionalOptionalOneTest FAILED
    [junit] TEST cruise.umple.implementation.simulate.SimulateGeneratorTest FAILED
    [junit] TEST cruise.umple.implementation.textuml.TextUmlGeneratorTest FAILED
    [junit] TEST cruise.umple.implementation.xmi.XmiGeneratorTest FAILED
    [junit] TEST cruise.umple.implementation.yuml.YumlTemplateTest FAILED
    [junit] TEST cruise.umple.statemachine.implementation.StateMachineTest FAILED
    [junit] TEST cruise.umple.statemachine.implementation.cpp.CppStateMachineTemplateTest FAILED
    [junit] TEST cruise.umple.statemachine.implementation.java.JavaStateMachineTemplateTest FAILED
    [junit] TEST cruise.umple.statemachine.implementation.php.PhpStateMachineTemplateTest FAILED
    [junit] TEST cruise.umple.sync.DeleteAssociationActionTest FAILED
    [junit] TEST cruise.umple.sync.DeleteGeneralizationActionTest FAILED
    [junit] TEST cruise.umple.sync.EditActionTest FAILED
    [junit] TEST cruise.umple.sync.EditAssociationActionTest FAILED
    [junit] TEST cruise.umple.sync.NewAssociationActionTest FAILED
    [junit] TEST cruise.umple.sync.NewGeneralizationActionTest FAILED
    [junit] TEST cruise.umple.sync.UpdatePositioningActionTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.TracerTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.java.JavaTracerTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.php.PhpTracerTest FAILED
    [junit] TEST cruise.vml.VmlConsoleTest FAILED
    [junit] TEST cruise.vml.VmlParserTest FAILED
    [junit] Tests FAILED

But the main thing is this was achieved:

Total time: 1 minute 9 seconds

Going to investigate the failed tests, and in particular the suspecting warnings prior to the test run.

Entry 7

Took another direction and approach on this. Set up linux ubuntu on my desktop and followed all instructions presented in the development environment (up until Step 5 where I cannot go further due to errors) and encounter the same problems as I did on my mac machine. Errors listed:

  • Bundle 'org.eclipse.xtext.ui.codetemplates.ui' cannot be resolved

  • Project 'cruise.umple.xtext' is missing required source folder: 'xtend-gen'

  • The project cannot be built until build path errors are resolved

  • The project was not built since it depends on cruise.umple.xtext, which has build path errors

  • The project was not built since it depends on cruise.umple.xtext, which has build path errors

Steps to reproduce:

1) Download Eclipse Modelling Tools:


64-bit Linux version downloaded.

2) Checkout a copy from google code:

     svn checkout http://umple.googlecode.com/svn/trunk trunk

3) Run Eclipse, set the workspace to the "trunk" (the working copy that was recently checked out).

4) Install the Eclipse plugin


Do steps: 0, 1 and 2 (method 1).

5) Follow steps 3 and 4 here:


6) When you reach step 6, where the video and everything else makes notion that there should be no errors, you will have 5 errors and 4 warnings.

Curious as to where I'm going wrong here, its not a platform issue AFAIK since I just tried this out on another OS and the same situation occurs.

Entry 6

Update on the video problems, they do work, just for some reason it takes a very long time to load them. Only the videos in question exhibited that, all the other ones were fine. Time to load was in and around 5 minutes (which is highly unusual). I use 2 systems with a different OS on each:

1) Windows 7 Ultimate 64bit (my desktop)

2) Mac OS X 10.6.8 Snow Leopard (my mobile machine)

The development environment problems are still present for me, going to take another stab at it later on today hopefully but the steps I took were from here:


I followed step 1 exactly with no issues what-so-ever. I then followed step 2, checked out a working copy of the trunk and used that as the Eclipse workspace. Following this I did step 3 which went without a problem (there were errors, but this is supposed to happen until everything is there so no real issue). Step 4 is more or less where the issues happened, I followed the steps exactly, as well as referencing the video:


And at 2:01 it mentions to build and there were no errors... mine had 5 errors (already mentioned) and 4 warnings. This is on my mac.

Entry 5

First little hurdle to get over here, and that is getting the base dev environment setup. It seems that I am stuck with a small number of errors as follows (I have followed, at least I think, the instructions to a tee):

1) Bundle 'org.eclipse.xtext.ui.codetemplates.ui' cannot be resolved

2) Project 'cruise.umple.xtext' is missing required source folder: 'xtend-gen'

3) The project cannot be built until build path errors are resolved

4) The project was not built since it depends on cruise.umple.xtext, which has build path errors

5) The project was not built since it depends on cruise.umple.xtext, which has build path errors

Errors 3,4 and 5 are the same thing as far as I can see due to errors in the xtext project, errors 1 and 2 I'm assuming are caused due to this. I am not sure (still looking into it). What I've found so far:

For error 1, it seems that it is referring to the manifest file in the xtext ui project... in particular the line:

" org.eclipse.xtext.ui.codetemplates.ui"

Entry 4

Fairly comfortable with the idea behind Umple, what its for and how to use it. Taking a stab at looking into the development environment setup and it appears that the youtube link for Video A exhibits the same problems the previous video had that I mentioned above (does not load/start):


So I have to download the previous version.

Entry 3

Probably irrelevant to me at this point (or maybe not) but I tried viewing the first video at:


to see if there was anything I missed on my playthrough with UmpleOnline and I found that the video does not load... at all. Tested this on my Windows machine and my mac, other youtube videos work just fine. Out of curiosity I went to the next video (Video B) and it worked. Not sure whats wrong with the first one.

Entry 2

Was a little rough on getting associations to work correctly, more or less this is a fault due to not using UML for some time and forgetting proper rules. As well the syntax took a bit to remember, I think I have it now and have created some sample models using associations.

Methods also make sense here, figured out how to do them in Umple. Not sure yet how to make them appear in the UML, as I've only been able to see them appear in the generated Java code from the Umple code I have been playing around with.

Entry 1

Initial understanding of how to create UML using Umple seems to be going good, 2DShapes example helped me derive assumptions to how the syntax on Umple translated into the UML. I can quite easily now create classes and play with inheritance. No issues so far.

Plan of attack is as suggested: Learn how to use Umple before learning how to develop for it.