[HEADSUP] Overrides/merging...

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

I think that the 'old school' Gumpers understood merging and overrides, but
that both are at risk with Gumpy. Not intentionally, so much as through lack
of understanding. I seriously doubt that overrides work as (traditionally)
intended, and merging -- gosh knows, probably not. Not saying this is a good
thing, nor something I won't work to fix (over time), I'm just stating the
fact we need to keep aware of...

BTW: Many times (more recently) I've looked forward to seeing the back of
"Traditional Gump", I feel it slows downs extending the metadata and
extending Gump. In hindsight, I really appreciate that slow down.
Traditional Gump's differences (from Gumpy) are a valuable communication
tool. They are good for assumption/difference detection, and help preserve
the intellectual property/experience invested in Gump.

regards

Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com

Re: [HEADSUP] Overrides/merging...

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

> So in theory merging should work and overriding may work - depending
> on which XML representation is read first and whether the first or the
> later representation wins.

I think that is a fair read. It dregs up a memory of how Nick Chalko and I
were trying to override some projects with packages (on a trimmed down Gump,
namely http://gump.chalko.com/py) and we did have to re-order things in the
profile to make this work.

So, perhaps I was merely being pessimistic about this area. Let's hope, and
learn facts (see next paragraph).

P.S. Stefano, did my original heads-up get explained/clarified in this
thread? I think working through it with Stefan might've clarified it, but if
not, please let me know.

P.P.S. Not looked here for a while, seems that code I wrote (in amongst the
dragons) to annotate XML errors, seems to be at least partly working...

http://gump.chalko.com/py/#Annotations

> >> Unit tests?
> >
> > Meaning, does Gumpy have any?
>
> No, I know it has 8-)

Only because you pay attention as well as you do. I really need to document
more for other developers (Python or not) to get involved.

> If we know how we want overrides and merges to work, it should be
> possible to put together simple workspaces to test the code.

Yes,  indeed. We have a couple of things started. In python/gump/test we
have a resources with a few test workspaces. The unit tests do attempt to
load/check them. These work ok [for loading metadata], until you try to run
them (since there are no valid contents.)

So (mainly for this maven work) I create an area with some unit tests in. I
think I probably need to work w/ infr to make this a permenant area (they
deleted the last one on me, not their fault.) See:
http://svn.apache.org/repos/test/gump-test/ In here we have some
viable/simple projects

But, for what you are describing, I think the test workspaces the unit tests
use are fine.

I'll add something to JIRA saying we need such unit tests. I need to master
JIRA, and also as the number of tasks grows we'll need a record. [Since Gump
never does a release, per se, we never get a change list other than this
list, at best.]

> Maybe this is something that happens with the move to TLP, assuming we
> can get some of the Python savvy folks in the ASF involved.

I'd love that. The best part of OSS (for me) is learning from others,
experiencing through other's eyes. My eyes ain't seen the glory of the
coming of the Python ... yet. ;-)

regards

Adam

Re: [HEADSUP] Overrides/merging...

[Stefan Bodewig <bo...@apache.org>]

On Wed, 11 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> For things which are 'named' (Profiles, Modules, Projects,
> Repositories, Servers) an object is created (and stored in a hash)
> when first encountered.  Subsequence XML representations of such an
> object with such a name get the hashed object to work on.

So in theory merging should work and overriding may work - depending
on which XML representation is read first and whether the first or the
later representation wins.

>> Unit tests?
> 
> Meaning, does Gumpy have any?

No, I know it has 8-)

If we know how we want overrides and merges to work, it should be
possible to put together simple workspaces to test the code.

> FWIIW: Gumpy needs to move from basic Python (teaching myself as I
> go along) to 'power Python', leveraging more packages & being
> 'nicer' Python code.

Maybe this is something that happens with the move to TLP, assuming we
can get some of the Python savvy folks in the ASF involved.

Stefan

Re: [HEADSUP] Overrides/merging...

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

> > I seriously doubt that overrides work as (traditionally) intended,
> > and merging -- gosh knows, probably not.
>
> I don't have any overrides in my workspace anymore, I do merge in a
> <deliver> (which has to die) tag to the gump project.
>
> Is there an easy way in Gumpy to see whether this has been merged in,
> in "traditional" Gump I'd look into work/merge.xml.

Yes, and no. There is :

http://lsd.student.utwente.nl/gump/workspace.html

but I have a slight privacy issue with that, that I might have to knobble
it. [I have a suspicion that this, above, is stale.]

That said, as I understand it, merging works like this in Gumpy:

For things which are 'named' (Profiles, Modules, Projects, Repositories,
Servers) an object is created (and stored in a hash) when first encountered.
Subsequence XML representations of such an object with such a name get the
hashed object to work on. As such attributes ought be overridden.
Sub-element, they get set or added to (dependent upon if they are single or
mulitple, i.e. repeating). [P.S. I'll find a place to document this...]

I can't swear to it that sub-elements are handled correctly, actually, nor
any of this. I've not dug in to it too deep to exactly this.

Truth ... this is the only remaining area of code (Sam's, or some Sam
'borrowed') that I've not re-worked to a point I feel comfortable with it.
(Ok, not messed w/ the GUI much either.) This XML -> Object code is so
'intricate Python' (returning existing objects from constructors, delegating
method calls, attributes as methods) that it defeats me any time I try to
take control of it. I managed to put some error handling in (XML errors are
now reported as annotations on the parent object) but that nye on killed me.
There be dragons in there... ;-)

> Unit tests?

Meaning, does Gumpy have any? Yes, despite the fact they do me little
good -- as CVS re-re-re-re-commits show -- 'cos there is insufficient
coverage at this point. Still, we won't get coverage without unit tests, so
I just need to make these run (some directory problem) and then keep them
green...

http://lsd.student.utwente.nl/gump/jakarta-gump/gump-test.html

BTW: Gumpy uses a hacked up pyunit class I wrote instead of the real Python
pyunit, 'cos I didn't know the latter exists. I ought move to the real
pyunit, and see if there are any tools to exercise coverage.

FWIIW: Gumpy needs to move from basic Python (teaching myself as I go along)
to 'power Python', leveraging more packages & being 'nicer' Python code. We
currently require Python 2.2 (with logging bundled into our CVS repository)
we can remove that with Python 2.3, they added it. I tried to keep Gumpy
standalone/2.2, but I think it ought leverage Python more, so I might start
breaking that. Also, I need to go find that lint-like tool that Ted Leung
wrote about...

regards,

Adam

Re: [HEADSUP] Overrides/merging...

[Stefan Bodewig <bo...@apache.org>]

On Tue, 10 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> I seriously doubt that overrides work as (traditionally) intended,
> and merging -- gosh knows, probably not.

I don't have any overrides in my workspace anymore, I do merge in a
<deliver> (which has to die) tag to the gump project.

Is there an easy way in Gumpy to see whether this has been merged in,
in "traditional" Gump I'd look into work/merge.xml.

Unit tests?

Stefan

Re: [HEADSUP] Overrides/merging...

[Stefano Mazzocchi <st...@apache.org>]

Adam R. B. Jack wrote:

> I think that the 'old school' Gumpers understood merging and overrides, but
> that both are at risk with Gumpy. Not intentionally, so much as through lack
> of understanding. I seriously doubt that overrides work as (traditionally)
> intended, and merging -- gosh knows, probably not. Not saying this is a good
> thing, nor something I won't work to fix (over time), I'm just stating the
> fact we need to keep aware of...
> 
> BTW: Many times (more recently) I've looked forward to seeing the back of
> "Traditional Gump", I feel it slows downs extending the metadata and
> extending Gump. In hindsight, I really appreciate that slow down.
> Traditional Gump's differences (from Gumpy) are a valuable communication
> tool. They are good for assumption/difference detection, and help preserve
> the intellectual property/experience invested in Gump.

I'm not sure I'm following you Adam, can you be more explicit?

-- 
Stefano.