Display of workspace definitions and build settings

[Sebastian Bazley <Se...@london.sema.slb.com>]

LSD (utwente) does not seem to give access to the workspace definition file, as far as I can tell.
On other Gump systems the workspace XML file can be displayed by selecting a link on the Build Logs page.
It would be useful if LSD showed the actual workspace file being used.


On the other hand, LSD shows much more detail about the settings that are actually applied for each build; again, it would be useful
if the other Gumps could show what settings they used for running the builds.

Just a thought.

Re: Display of workspace definitions and build settings

["Adam R. B. Jack" <aj...@trysybase.com>]

> LSD (utwente) does not seem to give access to the workspace definition
file, as far as I can tell.

I've added this to the workspace page of the output:
    detailsSection.createNote('This install runs Python Gump, not
Traditional Gump.')

so we stop refering to Leo as a type of Gump. :-)

> On other Gump systems the workspace XML file can be displayed by selecting
a link on the Build Logs page.
> It would be useful if LSD showed the actual workspace file being used.


It shows the contents, not the XML. It is a bit of a long story, but could
be done. When showing the 'XML' of the module and project and whatever we
are merely re-serializing the effective DOM we have in memory. Since
everything get's woven into the workspace DOM, that one was too huge to
display. It could be done (from the original file) were somebody to want it
badly enough.

> On the other hand, LSD shows much more detail about the settings that are
actually applied for each build; again, it would be useful
> if the other Gumps could show what settings they used for running the
builds.

Most development it occurring on Python Gumps (dotnot.org --- down --- and
LSD). Please try to focus your requests there. My hope is that soon we'll
get more Python Gump's. I like the idea of maintaining Traditional Gumps
(for comparison) but I'm as we add more features to Python Gump we might
have to make a determination on that.

BTW: Less is often more, and Python Gump is getting to the stage where we
need to start trimming it's output to just what is valuable. We can add
certain things, like the XML output, if the user sets debug="true" or
verbose="true" on the module or project. I'm looking for things to hide, not
things to add.

regards,

Adam