Sylvain Wallez wrote:
> Or, if filtering is removed (didn't follow the ongoing discussion), this
> can be used to exclude source files specific to a particular JDK version.
>
Yes, filtering has been removed - we don't need it any more and therefore
we don't copy any source files anymore. This is
Stefano Mazzocchi wrote:
The ideal solution to the problem (without requiring to filter
everything out would be)
too bad it doesn't work because the tasks assumes that each
file in its fileset is a dire
Ok, I just did the split as a proof of concept - and we don't need to
copy the source code anymore. Now, if you want to refactor it... :)
Carsten
> From: Torsten Curdt [mailto:[EMAIL PROTECTED]
>
> > Can't we extend a BaseAbstractEqslConnection and just add the methods
> > that change from one
One solution to avoid filtering our java-code because of jdk-dependencies
is to separate this code into different source directories.
For example for the databases block that uses ant filtering we could
generate three directories:
blocks/databases/java - the common code
blocks/databases/java1.2 - t
Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> > Is anyone against removing the use of the ant properties
> > from Constants.java? This will avoid copying and filtering
> > the java sources (at least for most parts).
>
> I am +1.
>
> Question though (a little off topic):
>
> Sometimes it i
Is anyone against removing the use of the ant properties
from Constants.java? This will avoid copying and filtering
the java sources (at least for most parts).
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
> Oh, and how about "stale" files. I mean, if I vppcopy a file, then
> delete the original vpp, is the filtered resulting java file still
> there? IIRC there was a lsync task floating around that synched
> correctly, maybe a vppsynch could be the *final* solution?
Yes, if you use (see vpp.sourcef
(ccing to cocoondev to see if they like the idea)
(ccing to krysalis-dev because it seems like the solution to the
jdk filtering stuff)
didge wrote, On 24/02/2003 22.23:
But the 'lost-update' issue is a much more serious one. Dead serious, I
might say, the problem is that the way the javac task is
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> > There are currently three properties used in Constants.java: the name,
> > the copyright year and the version. Ok, the first one could be simply
> > hard-coded because it is fixed. (And I think we can remove this name
> > property completly
Carsten Ziegeler wrote, On 24/02/2003 13.17:
There are currently three properties used in Constants.java: the name,
the copyright year and the version. Ok, the first one could be simply
hard-coded because it is fixed. (And I think we can remove this name
property completly from the build system).
Carsten Ziegeler wrote:
There are currently three properties used in Constants.java: the name,
the copyright year and the version. Ok, the first one could be simply
hard-coded because it is fixed. (And I think we can remove this name
property completly from the build system).
Now, if this is the on
ROTECTED]
> Sent: Saturday, February 22, 2003 12:53 PM
> To: Apache Ant
> Cc: [EMAIL PROTECTED]
> Subject: Javac task design problems
>
>
> Let me give you some context: Cocoon has one of the most complex builds.
> Our entire build files reached 250Kb. Half of which we
Let me give you some context: Cocoon has one of the most complex builds.
Our entire build files reached 250Kb. Half of which were dynamically
generated thru an XSLT transformation (for those optional modules we
call "blocks").
The build system was simply too complex to be maintained and I decid
13 matches
Mail list logo
