Hi Guys,
I have seen that MooseDevelopment is set as a prerequisite to
MooseStore even if there seems to be no obvious reason for it.
I would like to use the model defined in MooseStore also for the
Project Observatory but it seems awkward to ask the user to load all
moose when all that is actually needed is the MooseStore package...
Can you see a solution? :)
Mircea.
Hi,
Is there a way in Moose to get from the name of a method to the name
of the property defined with a pragma inside that method?
For example, having #numberOfMethod, how do I get to #NOM?
Thanks,
Ricky
New submission from Tudor Girba <girba(a)iam.unibe.ch>:
The underlying NetClientBase parcel that comes with 7.5 has changed with respect
to 7.4.1, and because of that Chronia does not work.
----------
assignedto: girba
component: Chronia
messages: 109
nosy: girba
priority: Bug
status: unread
title: Chronia is broken in 75 due to changes in NetClientBase
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue73>
________________________________________________
Dear Receivers,
hereby a call for participation to FAMOOSr 2007 in Zurich. Please
forward this mail to anyone in your network who may be interested in
this venue.
Please apologize multiple copies.
Early registration is until June 5, 2007
cheers,
Tudor Girba and Adrian Kuhn
***********************************************************************
CALL FOR PARTICIPATION FOR FAMOOSr 2007 in ZURICH
***********************************************************************
FAMOOSr – 1st Workshop on FAMIX and Moose in Reengineering
Location co-located with TOOLS Europe 2007
Date June 25 in Zurich, Switzerland
-----------------------------------------------------------------------
The increasing amount of data available about software systems poses
new challenges for re- and reverse engineering research, as the proposed
approaches need to scale. In this context, concerns about meta-modeling
and analysis techniques need to be augmented by technical concerns about
how to reuse and how to build upon the efforts of previous research.
The goal of this one-day workshop is to strengthen the community of
researchers and practitioners who are working in re- and reverse
engineering, by providing a forum for building future research using
or interested in Moose and Famix as shared infrastructure.
For more information, please refer to
http://smallwiki.unibe.ch/moose/famoosr2007/
!! Workshop program
09:00-09:45 Kick-off presentation.
10:00-10:50 Presentations, 5-10 minutes each.
11:00-11:50 Presentations, 5-10 minutes each.
12:00-12:30 Creating topics for focus groups.
12:30-14:00 Lunch break
14:00-15:00 1st iteration of work in focus groups
15:00-15:30 Preliminary presentation of results
15:30-16:30 2nd iteration of work in focus groups
16:30-17:00 Final presentations and wrap-up
!! Registration
Special pricing for early registration till June 5, 2007.
Registration page http://tools.ethz.ch/register.html
-----------------------------------------------------------------------
Hi,
I'm facing a very strange problem with my Ecore importer :
I implement the EMOF.Enumeration and EMOF.EnumerationLiteral this morning
and use them in my importer.
I wrote some tests and all of them run perfectly.
But when I try to replay my test scenario in a workspace :
|importer repository|
importer := EcoreMetaModelImporter withActiveMetaMetamodel.
importer importEcoreMMFile:
'F:\Cours\EclipseWorkbench\essaiEditor2\test.ecore' .
repository := importer asRepository.
self halt.
I encounter an error :
"Import error: unknwon EMOF class EMOF.EnumerationLiteral "
however, when I inspect my importer's metaRepository, EMOF.Enumeration and
EMOF.EnumerationLiteral appear in the metaRepository elements, but not in
its pathMap.
I don't understand why during the test EMOF.Enumeration and
EMOF.EnumerationLiteral are added to the pathMap of the metaRepositrory
and not during a execution in the workspace.
I 've tried to understand when the pathMap is initialized, but did not
find anything that helps me.
Any idea of what can happen ?
Thank
Pierrick.
PS : I have published my bundles : Meta-Ecore-Importer 0.1bouazza and
Meta-EMOF-Model 0.239e.2bouazza this afternoon.
Hi,
I'm still working on the ecore importer with sara.
Today, I convert a metamodel conform to Ecore in a model conform to EMOF
and then Sara generates the SmallTalk code associated with this model.
Concerning the Enumerations, I planned to implement them into the EMOF
Model (according to the OMG spec I found at
http://www.omg.org/docs/formal/06-01-01.pdf p31
but when I thought at how to convert it in SmallTalk, I found it better to
assimilate Enumeration and EnumLiteral to a class (the enumeration) and
subclasses (the enumLiterals) because they are nothing but types.
Do you think my idea is good, or should I implement Enumeration in the
EMOF Model and let Sara deal with them to generate SmallTalk code?
Thank you for your advices.
Pierrick
Hi Doru,
I have a slight problem with Hismo. I have a bundle with name
CodeCity and in that bundle I have several packages, one of which is
also called CodeCity.
After creating a History from several versions of the system, I
realized that somehow Hismo is not able to distinguish between the
two. Although in the MooseModels of the versions there are 2
FAMIXPackages that are related to each other (one of them belongsTo
the other), after creating a history I end up having one single
PackageHistory called CodeCity. Somehow, Hismo flattens the two...
I guess this is also because the bundles and packages in Smalltalk
are both modeled by the FAMIXPackage in Moose, but I would expect it
to take the mooseID into account on this one. Could you please fix this?
Thanks,
Ricky
New submission from Tudor Girba <girba(a)iam.unibe.ch>:
Submitted by Ricky Wettel.
I have a bundle with name CodeCity and in that bundle I have several packages,
one of which is also called CodeCity. After creating a History from several
versions of the system, I realized that somehow Hismo is not able to distinguish
between the two. Although in the MooseModels of the versions there are 2
FAMIXPackages that are related to each other (one of them belongsTo the other),
after creating a history I end up having one single PackageHistory called
CodeCity. Somehow, Hismo flattens the two...
I guess this is also because the bundles and packages in Smalltalk are both
modeled by the FAMIXPackage in Moose, but I would expect it to take the mooseID
into account on this one.
----------
assignedto: girba
component: Van
messages: 106
nosy: girba
priority: Bug
status: deferred
title: Wrong historical identities for FAMIXPackage
________________________________________________
Moose Bugs <moose-dev(a)iam.unibe.ch>
<http://macamis.unibe.ch/trackers/moose/issue71>
________________________________________________
