We know why ant is doing this. Most of the <copy> tasks are setup to
filter="true".
Ant's filtering ability is much like the cpp, which can take a #DEFINE and
replace the configured value. The difference for us is that @some.property@
will be replaced by ${some.property} or left as is if there is no such
property defined.
I have made use of this to generate configurations of the applications I
built for all users, who may not really know how each part of the system is
configured. All they know, or rather need to know (which is important,
because they could know, but choose not too) is a few configuration
properties which get dropped into local.properties. In many cases the
example file covers the default values for this and can provide
documentation on what it does.
To do this and keep the build system simple, this feature of ant has been
turned on by default. I recently started using it to generate the
version.properties file which will always keep the version number of
generated builds current, with out user interaction (or rather
retention of the task of updating it by hand).
The manual build system uses this to keep the thirdparty support files
separate from jboss specifics.
There are other areas which could benefit from this type of dynamic
configuration of files, but alas there is a limited amount of time which I
can (or am willing to) spend on a build system. Once it does its job well,
makes most everyone happy, requires little maintenance and fulfills all
designed needs, it is time to let it rest.
Soon enough new ideas will birth which will demand change from it, give it
time to grow or rather go work on the boot & configuration systems because
they are vastly more interesting.
=)
--jason
On Thu, 6 Sep 2001, Julian Gosnell wrote:
> Or we could investigate why Ant is doing this,
>
> Surely, if there are no Strings to replace, Ant should leave the file alone....
>
> Perhaps upgrading Ant would fix this ?
>
> Jules
>
> Jason Dillon wrote:
>
> > > > I don't get it... why are we filtering?? Wasn't everything working with
> > > old
> > > > build system without filtering???
> >
> > That really depends by what is meant by "working". I would not consider the
> > old build system as "working", and thus spent lots of time trying to fix it,
> > which I think went well for the most part.
> >
> > I enabled filtering by default an all source copies (which I expected to be
> > text not binary), to allow those files to pickup configuration from the
> > build system. I think that it is beneficial, though currently it is only
> > being used in two places (version.properties and the manual/src/xdocs
> > stuff).
> >
> > If it is causing a fuss, then we can simply drop the default fitering and
> > only filter those files which need to be. This will complicate the build
> > system slightly, since you will have to have additional copy tasks with
> > filtering enabled, which include the select files, then the regular copy
> > tasks will have to exlude those files and such.
> >
> > I prefer the filters, but I don't really care either way.
> >
> > --jason
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
