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
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
> > 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
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
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.
> >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
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
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
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