The Nightmare of EA & the file system

[kiwi]

Hi all! (I'm reposting this as a registered user... I'm poised to buy this product, but I want to get this sorted out... someone please help

I've always been a fan of Enterprise Architect... but there's one thing that's been a brick wall for me with my latest attempt to use it... why on -earth- is the relationship between EA and the file system so difficult?

I've been wrestling with EA 3.1 for several hours today and I can't for the life of me find how to generate code properly. Here are my problems:

a) the documentation refers to menus that don't exist e.g. Reference/Code Generation Defaults
b) I have no idea how to specify the target language, the interface just makes no sense at all.
c) when I try and do a generation, having given up trying to find out how to change the paths, I'm stuffed -- the paths seem to be that of a Sparx developer and it just says 'error pathname not found'.

Heeeeeelp!


BTW Here's a design suggestion.

Project options:Code generation

Language: [popup with java etc, choose one]
Source directory: [choose one here] [ ] relative to project (checkbox)

how's that?

[ronnie]

Firstly, the choice of different languages is set for each object - double click the object (say a package or class) to get the properties window and on the right there is a language drop-down.
There is a default setting for this in 'View, Options, Generation'. Note that this doesn't affect any existing objects.

When you go to 'code engineering, generate source code' off of a package context menu then it asks you which objects within the package to generate and then prompts for each file location and name if it's new, otherwise you can synchrinize.

Ronnie

[kiwi]

Hi Ronnie, thanks a bundle for your quick response!

You say:
>When you go to 'code engineering, generate source code'
>off of a package context menu then it asks you which
>objects within the package to generate and then prompts >for each file location and name if it's new, otherwise you can
>synchrinize

This doesn't happen for me. I select a package, and In the 'Generate Code' window, I choose 'includes all child packages', at which time the classes appear. The 'target file' column has a pathname for the 'EAExample' of 'C:\bin\JDK\demo\sound\src\...' which is not on my machine and I have no idea how to change this (this is a big part of my first question).

I then choose 'Overwrite code' and click 'Generate'... to which it says 'path not found: C:\Bin\...' etc.

??

cheers,
Julian.

[gsparks]

Hi,

Just a little backgound on the file handling and why it doesnt seem straightforward:

EA is a multiuser system, and as such there may be a number of developers writing code and synchronizing, reversing with the EA model at any time. Each will be on a different machine and each -may- have a different file system setup ... that is developer A may have their code in c:\source and developer B in c:\Projects\source. The solution to this was to develop the "Local Paths" substitution function (in Reference/Local Directories)

This lets a developer substitute a macro for all or part of a directory name... eg. CPP_SOURCE as a macro could be expanded on one machine as c:\source and on another as c:\projects\source. This way the EA model becomes developer independent. If you have a play with this facility you will see what it does and how it helps.

This dialog can also be used to 'bulk change' a hard coded directory name. If you have 100 files all in c:\temp\source and want to move the lot to c:\source, you can define a macro (eg. CPP_FILES) and specify the actual path as c:\temp - then press 'Apply Path' to update the hard coded paths to something like %CPP_FILES%\<filename> ... you can now move all your files to c:\source and reconfigure the macro to point to c:\source instead of c:\temp\source.

Note that you could now press the 'Expand Path' button to expand all paths from %CPP_FILES%\<filename> to c:\source\<filename>

This seems a little complicated at first - but makes it much easier to share source between mutpile developers on their own machines.

The default language is defined in the Local Settings (View\Options) dialog on the Code Generation page.

Checking thru this I have noticed that an object does not pick up the default language until it has been opened and closed? I will ensure this is updated as soon as the object is created.

I also notice that when you modify the Local Directories paths and macros, objects in the currently loaded diagram will not be refreshed until you reload the diagram.

I will look into both the above. I will also look into updating the help file and/or adding some web pages on this topic - as it is not immediatley obvious how this all hangs together.


Hope this has provided some help,

Geoff Sparks

[kiwi]

Thanks Geoff, as I've come to expect with Sparx, quick responses, consideration of possible ways to improve.

Where do I sign?  

If for my help and others, you could post notice of changes to dox and/or builds to this thread that'd be most appreciated.

cheers!
Julian.

[kiwi]

Ok.... a few weeks later and this thing is still a major sticking point, luckily I rememebered I had the problem before and your comments Geoff were a help, this time on my project, I did what you suggested in response to my first question and it works. I

There's a very easy way in the current system to make this a little more intelligent: 1) automatically create a 'local path' for each language option. JAVA for java etc etc. Or java-src or something readable and sensible. THEN if the user, the first time, chooses a path that is RELATIVE to the current project, automatically make the substitution. This is at least a little better.

But if you happen to move the project, you'll get that same arrogant 'can't find the folder specified' error. Humf.

This brings up the SECOND part: 2) these 'local paths' should be intelligently-represented as local to the project directory if possible. That is, the way things are now, you should put a a variable %PROJECT% in the local path mappings themselves, or whatever, which can be embedded in other directory names. This effectively allows you to have local paths that are relative to the project.

This would mean someone could move the project around, and everything would work, all the time.

So example:

• Let's say you have your files in C:\Dox\Proj
  
• Default language was java.
  
• Simply by choosing 'generate code' the first time, you get a file chooser saying 'where exactly' and it appears in C:\Dox\Proj.
  
• You choose 'C:\Dox\Proj\autogen\
  
• This creates a new entry 'JAVA' which is '%PROJECT%\autogen\' (yes, nested substitution).
  
• The file path for each class is then as before: %JAVA%\autogen
  

Of course really you want your 'paths' to be specified in some cleaner way that they're relative to the project, but my suggestion would probably take less effort (and I'd see the changes sooner, which would be better

[LarrySkelly]

Could you extend this facility so that it also applies to generic files attached to any object on the Files tab of the property sheet?  

Otherwise one has to use the web notatation specification 'file://directory/myfile.doc'.  This works if files never change locations, but does not enable users to use the layer oif redirection to move files around as required.

Thanks,
Larry