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

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.

14 years, 2 months

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

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.

14 years, 2 months

Re: Issue 223 in moose-technology: infusion- information lost

by moose-technology＠googlecode.com

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.)

14 years, 2 months

Re: Issue 187 in moose-technology: infusion does not set Invocation#receiver?

by moose-technology＠googlecode.com

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.)

14 years, 2 months

Issue 551 in moose-technology: VerveineJ should export parameterized types

by moose-technology＠googlecode.com

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.

14 years, 2 months

Issue 548 in moose-technology: VerveineJ should export both packages and namespaces

by moose-technology＠googlecode.com

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.

14 years, 2 months

Re: Famix Java

by Tudor Girba

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."

14 years, 2 months

Package blueprint: your advice

by Simon Denier

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

14 years, 2 months

Integration of Fuel in next Moose Release ?

by Laval Jannik

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

14 years, 2 months

Fuel export/import

by Martin Dias

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

14 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev