Ah, thanks that explains it. I was just leaving work when I encountered
this. It doesn't help that Batik's build.sh doesn't play nice with cygwin -
will submit a patch soon. *GRIN* sometimes I feel like I'm the only one
playing with cygwin and Apache!
> -----Original Message-----
> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 30 March 2001 5:06 pm
> To: [EMAIL PROTECTED]
> Subject: Re: [GUMP] Batik target changed
>
>
> > Batik's target isn't jars anymore. Choice of:
>
> jars appears to still be there, though perhaps not documented.
>
> Speaking of not-documented, one behaviour of gump that perhaps isn't
> clear...if you do a build all, gump will build with the target
> specified in
> the project definition. If you do a build of a specific project, it will
> try to use the default for that project. My rationale at the time was
> that a build all is likely a full build of documentation and packaging and
> the like, where as a build of a single project was likely development.
>
> However, there isn't consistency as to what the default target
> should mean.
> Batik's default is to print out a menu as you have seen. Castor's will do
> a compile but not produce a jar. Oro's default is not even a
> valid target!
Could/should this be (automatically) reported as a bug?
>
> Perhaps there should be separate attribute in the project definition
> defined for the name of the default target for an individual build?
Yep, agreed, but if a default isn't supplied in the proj def should we use
the all build target or the default target in the projects build file?
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
