Xindice: a final suggestion

[Gianugo Rabellino <gi...@apache.org>]

As some of you might have noticed, Xindice is failing again, this time 
on a wicked part: in order to keep the build clean, a fileset of jars is 
specified at a project level and reused further on during the build: 
classpaths are set using this fileset and the fileset itself is used to 
configure the lib dir on the <war> task.

Now, Gump build is just fine, but packaging fails because the latest Ant 
*from CVS* expects a <zipfileset> as the parameter of the war/lib 
element, while we just have a <fileset>. Even more:  the *current* 
(stable) release of Ant supports only <fileset>at a project level, not 
<zipfileset>, so I cannot change the build file to accomodate the new 
ANT expected settings.

Now, this is exactly the problem that Gump is supposed to anticipate, 
but what would be the best solution?

1. tell Gump not to build the war (ugly workaround from a Gump POV);

2. upgrade our Ant version to the CVS one (somehow scary);

3. have a less maintainable build file removing the fileset and 
duplicating the list (ugly workaround from an Xindice POV);

4. don't use the war task altogether and roll back to the <jar> one 
(don't like it);

5. Bug the Ant developers so that they rollback the change to the War 
task, accepting also plain filesets as it was in the past: this sounds 
like the best solution to me since it was them to introduce a backward 
incompatible change (but I'm sure it was for a reason).

I'm kinda stuck. Suggestions?

TIA,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com

Re: Xindice: a final suggestion

[Sam Ruby <ru...@apache.org>]

Gianugo Rabellino wrote:
> As some of you might have noticed, Xindice is failing again, this time 
> on a wicked part: in order to keep the build clean, a fileset of jars is 
> specified at a project level and reused further on during the build: 
> classpaths are set using this fileset and the fileset itself is used to 
> configure the lib dir on the <war> task.
> 
> Now, Gump build is just fine, but packaging fails because the latest Ant 
> *from CVS* expects a <zipfileset> as the parameter of the war/lib 
> element, while we just have a <fileset>. Even more:  the *current* 
> (stable) release of Ant supports only <fileset>at a project level, not 
> <zipfileset>, so I cannot change the build file to accomodate the new 
> ANT expected settings.
> 
> Now, this is exactly the problem that Gump is supposed to anticipate, 
> but what would be the best solution?
> 
> 1. tell Gump not to build the war (ugly workaround from a Gump POV);
> 
> 2. upgrade our Ant version to the CVS one (somehow scary);
> 
> 3. have a less maintainable build file removing the fileset and 
> duplicating the list (ugly workaround from an Xindice POV);
> 
> 4. don't use the war task altogether and roll back to the <jar> one 
> (don't like it);
> 
> 5. Bug the Ant developers so that they rollback the change to the War 
> task, accepting also plain filesets as it was in the past: this sounds 
> like the best solution to me since it was them to introduce a backward 
> incompatible change (but I'm sure it was for a reason).
> 
> I'm kinda stuck. Suggestions?

Initial reaction: #5 also seems best to me.  See the "cross-project 
breakages" section of the following:

http://jakarta.apache.org/gump/nagged.html

Most of all, what Gump is designed to do is to actually get people to talk.

- Sam Ruby

Re: Xindice: a final suggestion

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

On Tue, 22 Apr 2003, Gianugo Rabellino <gi...@apache.org> wrote:

> Now, Gump build is just fine, but packaging fails because the latest
> Ant *from CVS* expects a <zipfileset> as the parameter of the
> war/lib element,

We (Ant developers) are aware of the change, it has also broken one of
our testcases 8-(

> 5. Bug the Ant developers so that they rollback the change to the
> War task,

Will happen, probably soon.

Cheers

        Stefan