On 2016-04-02, Gary M wrote:
> To clarify my post to the list, cab support is already built into ant.
> However the optional jar is not built, it has been remove from the
> build.xml.
This is a misunderstanding. We've split up the old ant-optional.jar long
ago and the tasks that don't require any additional jars have been
merged into ant.jar. It is still there and alive, even if it doesn't
work because cabarc isn't there.
Using the official Ant distribution binary:
$ cat cab.xml
<project>
<cab/>
</project>
$ ANT_HOME=/tmp/apache-ant-1.9.5 ant -version
Apache Ant(TM) version 1.9.5 compiled on May 31 2015
$ ANT_HOME=/tmp/apache-ant-1.9.5 ant -f cab.xml
Buildfile: /tmp/cab.xml
BUILD FAILED
/tmp/cab.xml:2: basedir attribute or one nested fileset is required!
Total time: 0 seconds
The task is there, really.
> I want to re-factor cab.java to support M$ new cab file utility, and in
> that process not violate the established practices and style making ant a
> great product. This also means to keep the current API and functionality,
> not to break any regression, back compatibility to existing deployments,
> and migrations to more modern environments..
<cab> itself has been neglected for quite some time. It has been
contributed and we may have applied the occasional bug fix, but it
hasn't really been developed any further. The task is typical for tasks
that have been written before we introduced resource collections.
If you want to just patch it so that it works for more modern
environments, that will be fine. If you were to write the task from
scratch I'd look into supporting resource collection rather than "just
filesets". and I'd use a more modern Java doing away with Vector. But
those are minor changes.
Unfortunately running the tasks requires a proper environment which
makes writing real tests difficult. I don't think we've got any decent
tests for the task (none at all AFAICT). This means it is way to easy to
introduce regressions. OTOH the task is small enough that perr review
may work out for us.
> 1) Should I keep the cabarc.exe support and detect the new makecab utility
> or remove existing cabarc.exe support ?
It should be possible to check whether cabarc.exe is on the path.
For the .NET tasks we do something like this in a build file
<property environment="env"/>
<condition property="csc.found">
<or>
<available file="csc" filepath="${env.PATH}" />
<available file="csc.exe" filepath="${env.PATH}" />
<available file="csc.exe" filepath="${env.Path}" />
</or>
</condition>
You could likely invoke Available programmatically and would only need
to check for the ".exe" case and the "Path" environment variable (this
is Windows only).
> 2) Is there a style guidance for build.xml file ? (I don't want to submit
> something that violates best practices)
In what way? You wouldn't be touching build.xml at all, I'd guess.
The only style guide we've got for Java files is "Sun conventions, no
tabs" plus "keep with the style that is already present when touching
existing code". Other than that it is quite diverse.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
