I am working on this script to see dependencies of seaside and citezen...
I would to group the nodes according to their names in Mondrian. Is it
possible? Here is my script:
view shape rectangle
width: [:pack | pack numberOfProviderPackages + 3 *3];
height: [:pack | pack numberOfClientPackages + 6 * 3];
if: [:pack | pack name includesSubString: 'Citezen'] fillColor: Color
red;
if: [:pack | (pack name includesSubString: 'Seaside') and: [(pack name
includesSubString: 'Citezen' ) not]] fillColor: Color lightBlue.
view nodes: (model allPackages select: [:pack | ((pack name
includesSubString: 'Citezen') or: [pack name includesSubString: 'Seaside'])
or: [pack name includesSubString: 'Pier']]).
view edgesToAll: #staticProviderPackages.
view dominanceTreeLayout..
Like in the figure, I would like to group red nodes on the left and light
blue nodes on the right and at the same time keeping dominanceTreeLayout.
[image: Screen shot 2011-11-09 at 4.08.18 PM.png]
thanx.
Usman
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.6
New issue 747 by andreho...(a)gmail.com: We should have set methods for all
properties
http://code.google.com/p/moose-technology/issues/detail?id=747
All methods annotated with <MSEProperty:type:> must have a set methods.
Now, when we export a model to MSE we cannot load them because some
properties don't have set methods.
Hi,
I've parsed a Java system by using Verveine-J (pretty fast :) and imported
the resulting MSE file in the Moose Suite 4.6 Development I downloaded from
the moose website. Everything went fine.
I saw that each non-stub FAMIXClass has a FAMIXFileAnchor that correctly
points to the java source code file that contains the class declaration.
However, I cannot find the right way to directly access this declaration
(even though the FAMIXFileAnchor contains also
startLine,startColumn,endLine, and endColumn). I tried to call the method
FAMIXFileAnchor>>sourceText, but I only get an empty string.
Is there a way to access the source code?
Thanks.
Cheers,
Alberto
--
View this message in context: http://moose-dev.97923.n3.nabble.com/Getting-the-source-code-of-a-FAMIXClas…
Sent from the moose-dev mailing list archive at Nabble.com.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 742 by usman.bh...(a)gmail.com: smalltalkClass and compiledMethod
extensions should be covered by tests
http://code.google.com/p/moose-technology/issues/detail?id=742
especially when the mporter semantics is to distinguish or not metaclasses.
Right now
FamixClass>>smalltalkClass
"Returns the associated smalltalk class if it exist in the system."
^ FAMIXNameResolver smalltalkClassFromFamixClassName:
self name ifAbsent: [nil]
FamixMethod>>compiledMethod
"Return the compiled method associated to the receiver or nil"
| realClass |
realClass := self parentType smalltalkClass.
self hasClassScope
ifTrue: [realClass := realClass class].
^ realClass isNil
ifFalse: [realClass compiledMethodAt: self name asSymbol]
ifTrue: [nil]
It is strange that we have to do the test hasClassScope in the
compiledMethod method since normally smalltalk should correctly handle it.
Hi guys
here are some notes we wrote when browsing the MooseTask
- It would be good to rename MooseTask should be renamed because it has
nothing to do in Moose.t
- MooseTask and MooseOperator should be in the same package: Moose-Core
since MooseOperator has nothing to do with Smalltalk.
- the hierarchy of MooseCompositeImporterTask is really dealing only with
Smalltalk importing logic.
so we should rename it:
SmalltalkCompositeExtractorTask or at least
SmalltalkCompositeImporterTaskcolle
- MooseImportClassesTask should be renamed SmalltalkImportClassesTask
or SmalltalkExtractClassesTask
since it only create entity extracted from Smalltalk.
( Importer vs extractor
I would like to keep the term importer to the action of populating a model
and the action to extract model from source code.
In java, c3 we have extractor and in Moose importers and extractors)
- I would rename SmalltalkImporter as SmalltalkExtractor like that we have
a clear line.
- Nobody is referencing PackageDescription?
- Now our problem is that we would like to run tasks when a
a Smalltalk model is extracted and imported and when a mse file is
imported.
We should probably introduce the logic of the plugin login somewhere
in a superclass and (MSEImporter should be a subclass of MooseTask - not
verified if make sense)
- I have no clue about the contents of the Moose-GenericImporter. It looks
like we stopped in the middle of something (which is probably true).
- MooseImportingTask is still Smalltalk specific so I would move to
the Moose-SmalltalkImporter.
- MooseFileStructureImporter looks really broken but it can be a nice
example of a subclass of MooseImporterTask (not MooseExtractorTask)
Doru it would be fun to do some pair programming to address these changes.
Do you have time this evening?
Hi guys
here are some notes we wrote when browsing the MooseTask
- It would be good to rename MooseTask should be renamed because it has
nothing to do in Moose.t
- MooseTask and MooseOperator should be in the same package: Moose-Core
since MooseOperator has nothing to do with Smalltalk.
- the hierarchy of MooseCompositeImporterTask is really dealing only with
Smalltalk importing logic.
so we should rename it:
SmalltalkCompositeExtractorTask or at least
SmalltalkCompositeImporterTaskcolle
- MooseImportClassesTask should be renamed SmalltalkImportClassesTask
since it only create entity extracted from Smalltalk.
( Importer vs extractor
I would like to keep the term importer to the action of populating a model
and the action to extract model from source code.
In java, c3 we have extractor and in Moose importers and extractors)
- Nobody is referencing PackageDescription?
- Now our problem is that we would like to run tasks when a
a Smalltalk model is extracted and imported
Hi guys
We are adding Author to Moose as an experience to learn how to extend moose.
In the past, for a moose entity with a unique name we were using the
uniqueName as mooseID
What is the status now?
For example we would to make sure that author can be retrieved by their
name
mooseModel entityNamed: 'me'
and that we do not have conflict with other Moose entity.
Stef
Hi
I would like to know how I can get the latest version from a given version.
Because I do not want to have to merge back.
So how do I get all the latest versions of packages? and does it work?
Stef