Re: Deprecation

2004-06-19 Thread Steve Loughran
Adam R. B. Jack wrote: I'd like to discuss deprecation. 2) The use of 'forrest *batch call*' [the forrest folks have deprecated the interface we rely upon for this, and with batch & xdocs (forrest webapp) we have convoluted code.] This raises a question with me: how should I

Re: Deprecation

2004-06-17 Thread Stefan Bodewig
On Wed, 16 Jun 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > I guess I could then teach gumpy.py to get from a TAG, and then > overlay metadata from CVS HEAD. Not sure if CVS would be too happy > with that (due to the overlap). CVS will work OK as long as all files inside a single directory

Re: Deprecation

2004-06-16 Thread Adam R. B. Jack
> > Unfortunately this'll freeze the metadata, so doesn't seem too > > workable. > > Only tag the python directory? Assuming I added this logic to templates (and other non-metadata areas), to get all of Gumpy, I guess I could then teach gumpy.py to get from a TAG, and then overlay metadata from CV

Re: Deprecation

2004-06-16 Thread Stefan Bodewig
On Mon, 14 Jun 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > I'd like to be able to deprecate functionality. Since we don't have > releases (we work from CVS HEAD), I'd consider tagging the tree (so > folks can freeze themselves at a certain point). Good idea. > Unfortunately this'll freeze

Deprecation

2004-06-14 Thread Adam R. B. Jack
I'd like to discuss deprecation. The only Gump API we have today is the metadata. I'd like to formalize that [perhaps even with version attributes on major (distributed/community edited) elements], have XSD schema for validation. I'd also like to be able to migrate/enhance it it.

Re: [Mx4j-devel] MX4J and Gump (and another log4j deprecation effect)

2004-05-25 Thread Adam R. B. Jack
> >From time to time we get an email similar to this one, and we try to promptly fix the build. Thanks, that is aprpeciated, so mind if automate that? This entry will do it. > I am in a busy period now, but I'll try to get the build going as soon as I can, running against the latest stable

Re: [Mx4j-devel] MX4J and Gump (and another log4j deprecation effect)

2004-05-25 Thread Niclas Hedhman
On Tuesday 25 May 2004 15:23, Bordet, Simone wrote: > The only thing I'd prefer to avoid is to make our build running against the > latest CVS (which are usually unstable), since this is gump's job. You should build and release against the latest stable Log4J, no doubt. > If Log4J removed deprec

RE: [Mx4j-devel] MX4J and Gump (and another log4j deprecation effect)

2004-05-25 Thread Bordet, Simone
Hi Adam, > I don't know if you are aware of Apache Gump, but it is a > continuous integration tool. See: > >http://gump.apache.org Yes, we know gump. >From time to time we get an email similar to this one, and we try to promptly fix the >build. Last time was Axis (they reintroduced the A

MX4J and Gump (and another log4j deprecation effect)

2004-05-24 Thread Adam R. B. Jack
Hi, I don't know if you are aware of Apache Gump, but it is a continuous integration tool. See: http://gump.apache.org MX4J has an entry, which means it gets compiled against the very latest (CVS HEAD, SVN trunk) of it's dependencies (when possible.) See: http://brutus.apache.org:8080/g