Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: Issue 474 in moose-technology: Java Enums aren't modeled correctly when using inFusion
by moose-technology＠googlecode.com 11 Mar '11

11 Mar '11

Updates: Status: Fixed Cc: georgeganea Labels: Milestone-4.4 Comment #1 on issue 474 by tudor.gi...(a)gmail.com: Java Enums aren't modeled correctly when using inFusion http://code.google.com/p/moose-technology/issues/detail?id=474 Fixed. It will be available in the future release of inFusion.

1 0

Re: Issue 231 in moose-technology: browseSource does not work in Moose when called from a different OS than the one on which the source code has been parsed with an external parser
by moose-technology＠googlecode.com 11 Mar '11

11 Mar '11

Updates: Status: Fixed Labels: -Platform-VW -Platform-Squeak Component-ExternalTools Platform-Pharo Milestone-4.4 Comment #5 on issue 231 by tudor.gi...(a)gmail.com: browseSource does not work in Moose when called from a different OS than the one on which the source code has been parsed with an external parser http://code.google.com/p/moose-technology/issues/detail?id=231 This has been solved by having the inFusion export only paths separated by /. It will be available in the following release.

1 0

Re: Issue 223 in moose-technology: infusion- information lost
by moose-technology＠googlecode.com 11 Mar '11

11 Mar '11

Updates: Labels: Component-ExternalTools Comment #9 on issue 223 by tudor.gi...(a)gmail.com: infusion- information lost http://code.google.com/p/moose-technology/issues/detail?id=223 (No comment was entered for this change.)

1 1

Re: Issue 187 in moose-technology: infusion does not set Invocation#receiver?
by moose-technology＠googlecode.com 11 Mar '11

11 Mar '11

Updates: Status: Duplicate Labels: -Component-Tools Mergedinto: 533 Comment #6 on issue 187 by tudor.gi...(a)gmail.com: infusion does not set Invocation#receiver? http://code.google.com/p/moose-technology/issues/detail?id=187 (No comment was entered for this change.)

1 0

Issue 551 in moose-technology: VerveineJ should export parameterized types
by moose-technology＠googlecode.com 11 Mar '11

11 Mar '11

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.4 New issue 551 by tudor.gi...(a)gmail.com: VerveineJ should export parameterized types http://code.google.com/p/moose-technology/issues/detail?id=551 These are the Java Generics.

1 0

Issue 548 in moose-technology: VerveineJ should export both packages and namespaces
by moose-technology＠googlecode.com 10 Mar '11

10 Mar '11

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-VerveineJ New issue 548 by tudor.gi...(a)gmail.com: VerveineJ should export both packages and namespaces http://code.google.com/p/moose-technology/issues/detail?id=548 Because the Java package plays both the role of a FAMIX namespace and of a FAMIX package, VerveineJ should export both.

1 0

Re: Famix Java
by Tudor Girba 10 Mar '11

10 Mar '11

Excellent! Regarding the problem: parentModule comes from the C extension which you got because you exported the complete meta-model. You should use parentScope. Cheers, Doru On 10 Mar 2011, at 10:25, Nicolas Anquetil wrote: > > I generated the new Famix Java. > > There is one error in ScopingEntity : > > @FameProperty(name = "globalVariables", opposite = "parentModule", derived = true) > public Collection<GlobalVariable> getGlobalVariables() { > if (globalVariables == null) { > globalVariables = new MultivalueSet<GlobalVariable>() { > @Override > protected void clearOpposite(GlobalVariable e) { > e.setParentModule(null); > } > @Override > protected void setOpposite(GlobalVariable e) { > e.setParentModule(ScopingEntity.this); > here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > setParentModule wants a Module and not a Scope > } > }; > } > return globalVariables; > } > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

2 3

Package blueprint: your advice
by Simon Denier 09 Mar '11

09 Mar '11

I am in the process (that is, when my mind is not full with the 1000 things to do when moving to a new city) of refactoring package blueprints, with multiple objectives in mind: - make package blueprints work with namespaces - a testbed for Chef queries - rewriting the code to make it a bit more object-oriented - add tests There is one loophole I would like to expose and get your opinion about. Package blueprints shows references between classes across packages. Unfortunately nothing has been planned to handle class extensions. Right now there are just ignored so the picture given by package blueprints might be incomplete (but not false). I don't plan for now to do something about this but if some people want to give a thought about this and later add their idea, they are welcome. -- Simon Denier

3 9

Integration of Fuel in next Moose Release ?
by Laval Jannik 09 Mar '11

09 Mar '11

Hi all, What do you think about integrate Fuel in next release of Moose ? It seems to work well, so it is a good candidate to save models. Cheers --- Jannik Laval

5 7

Fuel export/import
by Martin Dias 09 Mar '11

09 Mar '11

Hi! I am ready to continue working on the Fuel extension for binary export/import in Moose. I am working on: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… Tasks: - create ConfigurationOfFuel with a default config - fix an error running tests (I thin the problem raises because now I'm on Windows, not MacOs) - fix a buf found by Doru last time: "a bug with FAMIXAccess that when the isWrite flag was nil, isRead would raise an error (it is fixed in the meantime). This appeared when I exported the model with MSE, but it did not appear when I used Fuel". - fix the icon for Fuel import in MoosePanel. Is this ok? Cheers, Martin

4 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev