Re: ant 1.7. Finding undefined variables
Dominique Devienne wrote: On Wed, May 20, 2009 at 2:28 PM, Dave Pawson dave.paw...@gmail.com wrote: 2009/5/20 Dominique Devienne ddevie...@gmail.com: Yes, that's what I generate. Except I run through the properties file and the build file to ensure I get all the (used) properties! As apposed to what I remembered to put in (and didn't change). That's the problem I was addressing, those changes and the odd properties I'd forgotten to test using fail/ Maybe running in verbose or debug mode and grepping for all property related messages, especially those about not finding the property, and convert that into a build similarly to what you did? --DD A really ruthless trick would be to have a switch to say halt on an attempt to resolve an unresolved variable, giving you the trace of where things were when the situation was reached -or let you provide a list of unresolved variables to fail on. This would let you track down a problem without breaking the moment you hit the first echo statement with any undefined value in the printed message - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
On Wed, May 20, 2009 at 11:25 PM, Dave Pawson dave.paw...@gmail.com wrote:
2009/5/20 Dominique Devienne ddevie...@gmail.com:
I suggested postprocessing Ant's output as there are can hidden use of
properties which is not easy to pick up by parsing the Ant XML file
(they don't look like ${name} in attributes for example), and could
thus possibly pick up info on more properties.
An example please Dominique?
XML elements reading properties without the ${name} notation
target if/unless
fail if/unless
conditionisset property/condition
...
XML elements writing properties affecting the rest of the build:
condition property
exec (output|error)property
manifestclasspath property
...
In macros with params having default params (or lack thereof, what you
try to catch), it uses @{name} to differentiate it from property using
the ${name}. Of course the two can be combined ${...@{bar}} so
figuring out what property could be missing would replicate the
running behavior.
These are various reasons looking for ${name} may be insufficient for
some builds. Nonetheless I agree than looking for ${name} covers a lot
of ground.
You need to watch out for property helpers though, as
${toString:some-ref-id} is a fake property name converting the Java
object (Ant datatype typically like a path) with reference id
some-ref-id to a string on the fly. (undocumented feature, but
there's an official API to add custom property helpers for
${helper:rest} notation.
But yes, for clarity, I am assuming ${name} form. ?Best practice?
Using ${name} is how you deref properties in the XML. All I'm saying
is that property derefs happen in the code as well, and that even
${name} can have a different meaning with macros and property helpers
(the latter is not very common, but the former more so).
But as I said, ${name} covers 90% of the ground, if not more. I just
wanted to make you aware of the 10% or 5% or 1% you could be missing.
90+ % is a good hit rate ;-) --DD
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
2009/5/21 Dominique Devienne ddevie...@gmail.com:
An example please Dominique?
XML elements reading properties without the ${name} notation
target if/unless
fail if/unless
conditionisset property/condition
...
XML elements writing properties affecting the rest of the build:
condition property
exec (output|error)property
manifestclasspath property
I've not seen any of those.
Perhaps you could provide me with an example build file I can experiment with?
Below, the xslt script I'm using if you want to play
java -cp saxon9.jar:/myjava:/myjava/xercesImpl.jar
net.sf.saxon.Transform -x:org.apache.xerces.parsers.SAXParser -o $3
$1 $2 $4 $5 $6
regards
?xml version=1.0 encoding=utf-8?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:dp=http://www.dpawson.co.uk/ns#;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
exclude-result-prefixes= xs
version=2.0
xsl:strip-space elements=*/
d:doc xmlns:d=http://www.dpawson.co.uk/ns#;
d:revhistory
d:purpose
d:paraThis stylesheet works with an ant build file file to produce a
ant script which tests all variables within the build file/d:para
/d:purpose
d:revision
d:revnumber1.0/d:revnumber
d:date2009-05-20T11:15:12Z/d:date
d:authorinitialsDaveP/d:authorinitials
d:revdescription
d:para/d:para
/d:revdescription
d:revremark/d:revremark
/d:revision
/d:revhistory
/d:doc
xsl:output method=xml indent=yes encoding=utf-8/
xsl:template match=/
project name=testvars.2
xsl:apply-templates select=//pathelement/
xsl:apply-templates select=//exec/
xsl:apply-templates select=//arg/
xsl:apply-templates select=//java/
xsl:apply-templates select=//fileset/
xsl:apply-templates select=//jvmarg/
/project
/xsl:template
xsl:template match=pathelement[contains(@path,'$')]
xsl:copy-of select=dp:property(@path,'')/
/xsl:template
xsl:template match=exec[contains(@executable,'$')]
xsl:copy-of select=dp:property(@executable,'')/
/xsl:template
xsl:template match=arg[contains(@value,'$')]
xsl:copy-of select=dp:property(@value,'')/
/xsl:template
xsl:template match=arg[contains(@line,'$')]
xsl:copy-of select=dp:property(@line,'')/
/xsl:template
xsl:template match=java
xsl:if test=contains(@classname,'$')
xsl:copy-of select=dp:property(@classname,'')/
/xsl:if
xsl:if test=contains(@dir,'$')
xsl:copy-of select=dp:property(@dir,'')/
/xsl:if
/xsl:template
xsl:template match=fileset[contains(@dir,'$')]
xsl:copy-of select=dp:property(@dir,'')/
/xsl:template
xsl:template match=jvmarg[contains(@value,'$')]
xsl:copy-of select=dp:property(@value,'')/
/xsl:template
xsl:template match=*/
!-- --
!-- Function to output all properties for checking --
!-- --
xsl:function name=dp:property
xsl:param name=str as=xs:string/
xsl:param name='res' as=item()*/
xsl:analyze-string select=$str regex=\$\{{([^}}]+)\}}
xsl:matching-substring
xsl:variable name='part'
property name={{prop.msg}} value=Must be defined, preferably in
${{basedir}}/${{properties.file}}/
fail message={regex-group(1)} ${{prop.msg}} unless={regex-group(1)}/
/xsl:variable
xsl:choose
xsl:when test=contains(regex-group(2), '$')
xsl:copy-of select=dp:property(regex-group(2), $part)/
/xsl:when
xsl:otherwise
xsl:copy-of select=$part/
/xsl:otherwise
/xsl:choose
/xsl:matching-substring
xsl:non-matching-substring
!-- xsl:message
oops xsl:value-of select=$str/
/xsl:message
--
/xsl:non-matching-substring
/xsl:analyze-string
xsl:value-of select=$res/
/xsl:function
/xsl:stylesheet
...
In macros with params having default params (or lack thereof, what you
try to catch), it uses @{name} to differentiate it from property using
the ${name}. Of course the two can be combined ${...@{bar}} so
figuring out what property could be missing would replicate the
running behavior.
These are various reasons looking for ${name} may be insufficient for
some builds. Nonetheless I agree than looking for ${name} covers a lot
of ground.
You need to watch out for property helpers though, as
${toString:some-ref-id} is a fake property name converting the Java
object (Ant datatype typically like a path) with reference id
some-ref-id to a string on the fly. (undocumented feature, but
there's an official API to add custom property helpers for
${helper:rest} notation.
But yes, for clarity, I am assuming ${name} form. ?Best practice?
Using ${name} is how you deref properties in the XML. All I'm saying
is that property derefs happen in the code as well, and that even
${name} can have a different meaning with macros and property helpers
(the latter is not very common, but the former more so).
But as I said, ${name} covers 90% of the ground, if not more. I just
wanted to make you aware of the 10% or 5%
ant 1.7. Finding undefined variables
I've been writing a couple of ant build files in which I've defined quite a few variables in an included properties file. A couple of variables within the build.xml too. I keep changing them which results in undefined variables which ant ignores, spreading odd filenames all over the place. I've scratched the itch, wondered if it is of use. Idea: run a python script over any property files to find all defined variables. That generates an ant build file which can be called up from the main build file. run an ~XSL 2.0 stylesheet over the main build file, that generates another ant build file which again can be run from the main build file. Does it sound to be of use to this group? Open source. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
On Wed, May 20, 2009 at 1:38 PM, Dave Pawson dave.paw...@gmail.com wrote: I keep changing them which results in undefined variables which ant ignores, spreading odd filenames all over the place. What I used to do was use fail with a nested condition asserting for some properties to be defined were indeed defined. Aborts the builds right away if they're missing. That addresses the Ant ignores undefined properties part. As to your idea, I'm not sure I'm following, sorry. --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
2009/5/20 Dominique Devienne ddevie...@gmail.com: On Wed, May 20, 2009 at 1:38 PM, Dave Pawson dave.paw...@gmail.com wrote: I keep changing them which results in undefined variables which ant ignores, spreading odd filenames all over the place. What I used to do was use fail with a nested condition asserting for some properties to be defined were indeed defined. Aborts the builds right away if they're missing. That addresses the Ant ignores undefined properties part. As to your idea, I'm not sure I'm following, sorry. --DD Yes, that's what I generate. Except I run through the properties file and the build file to ensure I get all the (used) properties! As apposed to what I remembered to put in (and didn't change). That's the problem I was addressing, those changes and the odd properties I'd forgotten to test using fail/ regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
On Wed, May 20, 2009 at 2:28 PM, Dave Pawson dave.paw...@gmail.com wrote: 2009/5/20 Dominique Devienne ddevie...@gmail.com: Yes, that's what I generate. Except I run through the properties file and the build file to ensure I get all the (used) properties! As apposed to what I remembered to put in (and didn't change). That's the problem I was addressing, those changes and the odd properties I'd forgotten to test using fail/ Maybe running in verbose or debug mode and grepping for all property related messages, especially those about not finding the property, and convert that into a build similarly to what you did? --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
2009/5/20 Dominique Devienne ddevie...@gmail.com: Maybe running in verbose or debug mode and grepping for all property related messages, especially those about not finding the property, and convert that into a build similarly to what you did? --DD Yes Possibly. I chose Python and xslt. I gather you don't find it of use then? -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
On Wed, May 20, 2009 at 3:24 PM, Dave Pawson dave.paw...@gmail.com wrote:
2009/5/20 Dominique Devienne ddevie...@gmail.com:
Maybe running in verbose or debug mode and grepping for all property
related messages, especially those about not finding the property, and
convert that into a build similarly to what you did? --DD
Yes
Possibly.
I chose Python and xslt.
I suggested postprocessing Ant's output as there are can hidden use of
properties which is not easy to pick up by parsing the Ant XML file
(they don't look like ${name} in attributes for example), and could
thus possibly pick up info on more properties.
I gather you don't find it of use then?
Sorry, didn't mean to imply it wasn't useful. I'm not sure where to
put it though. Maybe the Ant wiki would be a good place? Cheers, --DD
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
2009/5/20 Dominique Devienne ddevie...@gmail.com:
I suggested postprocessing Ant's output as there are can hidden use of
properties which is not easy to pick up by parsing the Ant XML file
(they don't look like ${name} in attributes for example), and could
thus possibly pick up info on more properties.
An example please Dominique?
But yes, for clarity, I am assuming ${name} form. ?Best practice?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
ant 1.7: ant 1.5.1 patch
isArch isVersion; } return retValue; } } -- View this message in context: http://www.nabble.com/ant-1.7%3A-ant-1.5.1-patch-tf4822841.html#a13798004 Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.7.1 --- Additional Comments From [EMAIL PROTECTED] 2007-05-30 06:30 --- I have reverted the bzip2 output stream code, and the example files that were provided now work. Thanks a lot for providing the example files - they were extremely useful. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |regression --- Additional Comments From [EMAIL PROTECTED] 2007-05-28 08:34 --- Tested with ant 1.6.5. ant 1.6.5 works with this build file - so this is a regression. comment #2 also says this. Looking at the SVN repository the main change that I can see is: revison 278185 http://svn.apache.org/viewvc?view=revrevision=276208 which was applied as a result of: http://issues.apache.org/bugzilla/show_bug.cgi?id=24798 this was done to make bzip2 faster and use less memory - however on some edge cases it does seem to generate corrupt files. I would suggest rolling back the changes. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-05-28 08:39 --- Opps THAT should be: ! http://svn.apache.org/viewvc?view=revrevision=278185 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-05-02 03:06 --- Created an attachment (id=20086) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20086action=view) Testcase with datafile for which the bzip2 task creates a corrupted bz2 file I have managed to reduce the size of my testcase to 10MB uncompressed (should have done that earlier). Note that if I only take the last 9MB of the testcase file, the created bzip2 file is correct. The attached archive contains a testcase data file for which the ant bzip2 task creates a corrupted bz2 archive and an ant buildfile which demonstrates the behavior. The buildfile creates the bz2 archive and then executes the command-line bzip2 -tv, which shows the error. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dev@ant.apache.org |[EMAIL PROTECTED] Status|NEEDINFO|NEW --- Additional Comments From [EMAIL PROTECTED] 2007-05-02 03:08 --- Changing status and reassigning to [EMAIL PROTECTED] as requested in the NEEDINFO status description. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dev@ant.apache.org --- Additional Comments From [EMAIL PROTECTED] 2007-05-02 03:20 --- Thanks for the test build file and data. I can confirm that I see the same error. reassigning to dev@ant.apache.org -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-04-29 21:08 --- (In reply to comment #6) So is it the content of your specific file, or might it be possible to create a buildfile or other program capable of -producing- a file that would show the same problems? My file was an oracle dump file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-04-29 22:53 --- (In reply to comment #6) So is it the content of your specific file, or might it be possible to create a buildfile or other program capable of -producing- a file that would show the same problems? I tried at first to set up a script which creates files with random data of increasing length to generate a smaller testcase, but the script ran very slow (mainly because of /dev/random taking long to generate random data). I am also not sure how the bzip2 algorithm behaves on pseudorandom data and if the error will be triggered at all. I think that to create a testcase, knowledge of the algorithms used is needed to generate testcases for the boundary conditions; in other words you already need to have a good idea what the error might be to write a testcase for it (and I have no understanding of how bzip2 works). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-04-28 13:41 --- So is it the content of your specific file, or might it be possible to create a buildfile or other program capable of -producing- a file that would show the same problems? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added Summary|ant 1.7 tar and bzip2 tasks |ant 1.7 bzip2 task creates |corrupted output file when |corrupted output file for |size exceeds certain limit |some inputs --- Additional Comments From [EMAIL PROTECTED] 2007-04-26 23:02 --- I have updated the summary to better describe the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Linux |All --- Additional Comments From [EMAIL PROTECTED] 2007-04-26 06:38 --- I've run into the same problem with the bzip2 task. The src file was originally 837MB, but through repeatedly splitting the file I could create a 22MB test file which when bzipped with the ant task creates a corrupt bz2 file (verified with bzip2 -t). I'll attach this file as a testcase. If I cut the file to 21MB, ant creates a working bz2 file. I could reproduce this error on both Windows XP and Linux, so I changed the OS field to All. The error happens with both Java 1.5.0_10 and Java 1.6.0. I also tested the following ant versions: Corrupted bz2 file: Apache Ant version 1.7.1alpha compiled on April 25 2007 (nightly build) Apache Ant version 1.7.0 compiled on December 13 2006 Working: Apache Ant version 1.6.5 compiled on June 2 2005 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 --- Additional Comments From [EMAIL PROTECTED] 2007-04-26 06:57 --- I can't attach the testcase, since its compressed size (1.4M) exceeds the bugzilla limit for uploads. Does anyone have a server where I can upload and link it? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41596.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41596
--- Additional Comments From [EMAIL PROTECTED] 2007-04-26 08:52 ---
(In reply to comment #0)
Description:
Ant tar task with bzip2 compression option or ant bzip2 task generates
corrupted output for filesize of roughly 170+MB (before compression).
This problem occurs with ant version 1.7 installed in 12/06.
Tested on linux with both jdk 1.5 and jdk 1.6
Work around: replace tar compress=bzip2.. or bzip2 ..
with 2 steps: tar .. and exec ...bzip2
For example,
Replace this:
bzip2 src=${out.file}.dmp.tar
destfile=${out.file}.dmp.tar.bz2
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/bzip2
Or this:
tar destfile=${out.file}.dmp.tar
compression=bzip2
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/tar
With:
tar destfile=${out.file}.dmp.tar
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/tar
exec dir=${dumps.dir}
executable=bzip2
arg value=${out.file}.dmp.tar/
/exec
(In reply to comment #3)
I can't attach the testcase, since its compressed size (1.4M) exceeds the
bugzilla limit for uploads. Does anyone have a server where I can upload and
link it?
I believe it's the content specific. However I couldn't upload our data because
it's confidential. Your testcase is crucial in this case.
Hopefully ant developers will contact you to get your testcase.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] New: - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41596.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41596
Summary: ant 1.7 tar and bzip2 tasks corrupted output file when
size exceeds certain limit
Product: Ant
Version: 1.7.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
Description:
Ant tar task with bzip2 compression option or ant bzip2 task generates
corrupted output for filesize of roughly 170+MB (before compression).
This problem occurs with ant version 1.7 installed in 12/06.
Tested on linux with both jdk 1.5 and jdk 1.6
Work around: replace tar compress=bzip2.. or bzip2 ..
with 2 steps: tar .. and exec ...bzip2
For example,
Replace this:
bzip2 src=${out.file}.dmp.tar
destfile=${out.file}.dmp.tar.bz2
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/bzip2
Or this:
tar destfile=${out.file}.dmp.tar
compression=bzip2
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/tar
With:
tar destfile=${out.file}.dmp.tar
tarfileset dir=${dumps.dir}
include name=${dist.schema}.dmp/
/tarfileset
/tar
exec dir=${dumps.dir}
executable=bzip2
arg value=${out.file}.dmp.tar/
/exec
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41596 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2007-02-12 11:30 --- I have not been able to reproduce this. I have tested with the Knoppix.iso file as an example of a large (~700M) file: tar destfile=iso.tar.bz2 compression=bzip2 tarfileset dir=. include name=big.iso/ /tarfileset /tar The resultant tar bz2 file seems ok, tar xjf works on it and the cmp program reports no difference: ~/learning/a/big ls big.iso big.iso.save build.xml iso.tar.bz2 ~/learning/a/big tar tjf iso.tar.bz2 big.iso ~/learning/a/big mkdir z ~/learning/a/big cd z ~/learning/a/big/z tar xjf ../iso.tar.bz2 ~/learning/a/big/z cmp big.iso ../big.iso ~/learning/a/big/z -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: please update the next release of Ant 1.7 to Xerces 2.9.0]
As raised on the user mail list. Should we upgrade? It would get the latest version out, stop them receiving support calls related to old apps, etc. And, assuming we have been using the live source tree in gump, it is what we've been building against. Original Message Subject: Re: please update the next release of Ant 1.7 to Xerces 2.9.0 Date: Mon, 04 Dec 2006 11:06:20 + From: Steve Loughran [EMAIL PROTECTED] Reply-To: Ant Users List user@ant.apache.org To: Ant Users List user@ant.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Jacob Kjome wrote: Quoting Steve Loughran [EMAIL PROTECTED]: http://ibiblio.org/maven/xerces/ I see the 2.8.1 jars and poms there. I can ping the xerces list and get them to put the 2.9.0 versions out there. What's the time frame for the next release? Is it imminent? I can work on them to get it out there. Maybe you can just check in the 2.9.0 stuff (xercesImpl.jar, xml-apis.jar, serializer.jar) in the meantime if the next release of Ant-1.7 (final?) is happening soon. Jake It would be nice for everything to be in sync, but that is separate from the apache launch. If the release manager agrees, then yes, we will ship with the latest version. Given that SVN_HEAD Ant and xerces have been coexisting on gump, the upgrade should not be traumatic. -steve - 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]
AW: [Fwd: Re: please update the next release of Ant 1.7 to Xerces 2.9.0]
Is that jar available for JDK1.2 ? Means: are the classes compiled for use on 1.2? Jan -Ursprüngliche Nachricht- Von: Steve Loughran [mailto:[EMAIL PROTECTED] Gesendet: Montag, 4. Dezember 2006 15:19 An: Ant Developers List Betreff: [Fwd: Re: please update the next release of Ant 1.7 to Xerces 2.9.0] As raised on the user mail list. Should we upgrade? It would get the latest version out, stop them receiving support calls related to old apps, etc. And, assuming we have been using the live source tree in gump, it is what we've been building against. Original Message Subject: Re: please update the next release of Ant 1.7 to Xerces 2.9.0 Date: Mon, 04 Dec 2006 11:06:20 + From: Steve Loughran [EMAIL PROTECTED] Reply-To: Ant Users List user@ant.apache.org To: Ant Users List user@ant.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Jacob Kjome wrote: Quoting Steve Loughran [EMAIL PROTECTED]: http://ibiblio.org/maven/xerces/ I see the 2.8.1 jars and poms there. I can ping the xerces list and get them to put the 2.9.0 versions out there. What's the time frame for the next release? Is it imminent? I can work on them to get it out there. Maybe you can just check in the 2.9.0 stuff (xercesImpl.jar, xml-apis.jar, serializer.jar) in the meantime if the next release of Ant-1.7 (final?) is happening soon. Jake It would be nice for everything to be in sync, but that is separate from the apache launch. If the release manager agrees, then yes, we will ship with the latest version. Given that SVN_HEAD Ant and xerces have been coexisting on gump, the upgrade should not be traumatic. -steve - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: please update the next release of Ant 1.7 to Xerces 2.9.0]
On Mon, 04 Dec 2006, Steve Loughran [EMAIL PROTECTED] wrote: As raised on the user mail list. Should we upgrade? I share Jan's concern (class file format might be too recent), other than that +1. And, assuming we have been using the live source tree in gump, it is what we've been building against. I'm pretty sure that Xerces 2.9 came from trunk, but the XML APIs thing might very well come from a branch we've never used in Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] Please let us get 1.7 first, Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[X] Looks promising - but take our time and put it in when it is ready. I agree with Steve McConnell that class loader mutation is not something we should encourage. If we have to do it for ant-*.jar optional bundled tasks for compatibility reasons, then OK, but it is unnecessary for nonbundled tasks which can be taskdef'd with a proper classpath, and we can probably do something cleaner for namespaced antlibs. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VOTE: add an antlib (and optional task) loader to ant 1.7
Sorry for asking for another vote on the Classloader for ant issue,
but I think that the last vote was very half-hearted in slight support
of including the (new) classloader task. However, I think that there
was not enough support. In the meantime, I have
been looking at Jesse's idea to have a secondary classloader
that is used to load antlibs and optional tasks. I presented an
initial implemention (see the classloader for 1.7 subject).
This does the following:
1) A new classloader is created for loading tasks/types:
* componentClassLoader
The parent of this loader in the normal Project loader.
2) This is initializes with the jars containing ant's optional
tasks/types
3) The componentClassLoader will be a normal AntTaskLoader
(parentFirst), except for classes in o.a.t.a.taskdefs.optional
and o.t.a.types.optional, for these the classloader will load
from this classloader first. (This is like the way the SplitLoader
works in JUnitTask).
4) A task will be provided to allow ant scripts to add jars/directories
to the componentClassLoader - possible name addlibpath
5) This compoentClassLoader will be inherited by subprojects
created by ant, antcall and subant.
A build script will look something like this:
project xmlns:ac=antlib:net.sf.antcontrib
property environment=env/
!-- test for ant optional task - jdepend --
addlibpath
fileset dir=${env.JDEPEND_HOME}/lib/
/addlibpath
jdepend
classespath path=build/classes/
/jdepend
!-- test for ant lib --
addlibpath
fileset dir=${user.home}/ant-contrib
includes=ant-con*.jar/
/addlibpath
ac:for param=param list=a,b,c
sequential
echo@{param}/echo
/sequential
/ac:for
!-- test for script --
addlibpath
fileset dir=${user.home}/lang/bsf includes=*.jar/
fileset dir=${user.home}/lang/beanshell includes=*.jar/
/addlibpath
script language=beanshell
System.out.println(Hello world);
/script
/project
Vote:
yes this is a good thing for 1.7 [ ]
no, let us stabilize 1.7[ ]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: Sorry for asking for another vote on the Classloader for ant issue, but I think that the last vote was very half-hearted in slight support of including the (new) classloader task. However, I think that there was not enough support. In the meantime, I have been looking at Jesse's idea to have a secondary classloader that is used to load antlibs and optional tasks. I presented an initial implemention (see the classloader for 1.7 subject). Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On Mon, 2006-09-04 at 20:25 +0100, Steve Loughran wrote: Peter Reilly wrote: Sorry for asking for another vote on the Classloader for ant issue, No problem. I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. I agree with Steve here. 1.7.0 has been 'just around the corner', for a while now, I'd rather not have any new additions that may require a quick 1.7.1 release (not that I think your idea + code is bad). I'm eager to try and get a cleaner integration of scripting into Ant and a new classloader-style mechanism seems a good way to approach that (I like the syntax in the example you posted), but right now I think it's more important to ship what we have. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. +1 new branch for 1.8 and include code for experimental classloaders etc Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On Mon, 04 Sep 2006, Steve Loughran [EMAIL PROTECTED] wrote: Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. Same here. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. Or rather create an 1.7.x branch and put the classloader into trunk. We are not required to let three years pass between 1.7.0 and 1.8.0. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On 9/4/06, Peter Reilly [EMAIL PROTECTED] wrote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ ] +0, since didn't fully follow the ClassLoader discussion, so can't really yeah or nay this. Note though that I liked Jesse's idea of not loading tasks by default, and allow taskdef to specify which classpath to use. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE: add an antlib (and optional task) loader to ant 1.7
-Original Message- From: Peter Reilly [mailto:[EMAIL PROTECTED] Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ ] I'm a *non-binding* -1 on doing this relative to 1.7. This position is on the basis that I think that there is an fundamental flaw with the notion of classloader mutation (with the exception of system classloader mutation necessary in a small number of special cases). I think that Ant is moving in the right direction based on the separation of jar files dealing with individual optional task groups (e.g. Junit, Java Mail, Jdepend, etc.) - but I think that the direction forward should be discrete classloaders per extension. For example - the Java Mail task does not need nor is related to Junit testing concerns and both can co-exist is separate classloaders. Establishing a classloader specifically addressing a particular extension would eliminate potential conflict issues inherent in the current proposal and I believe its feasible to do this at the level of a the taskdef definition by adding classloader criteria to the antlib XML definition. In effect the classloading hierarchy should look more like the following: || | System CL | || ^ | || | Ant Project CL | (configurable to include custom project extensions) || ^ | | ... | | | || |-| |---| | Core Tasks CL | | Junit Antlib CL | | XYZ Antlib| || |-| |---| Where each antlib classloader is created based on XML data declaring new classloader creation criteria (i.e. no mutation in the general case) and where the taskdef task incorporates parallel/equivalent functionality. Cheers, Steve. -- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Ant 1.7 - ReleaseInstructions - Compiler
We say to need Java 1.2 - any class format changes between 1.2 and 1.4? I would feel more safe to do a compile run on 1.2 Jan -Ursprüngliche Nachricht- Von: Kev Jackson [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 22. August 2006 02:29 An: Ant Developers List Betreff: Re: Ant 1.7 - ReleaseInstructions - Compiler On 21 Aug 2006, at 21:19, Antoine Levy-Lambert wrote: Hello Kev, when you built the alpha version of ant 1.7, which compiler did you use ? 1.4 or 1.5 ? I used the default compiler, which at the moment is 1.5 Kev -- I call it the State where everyone, good or bad, is a poison- drinker: the State where universal slow suicide is called - life - Friedrich Nietzsche - 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]
Re: AW: Ant 1.7 - ReleaseInstructions - Compiler
Hello Jan, Ant 1.6 was compiled using 1.4 For the sake of simplicity I will try to build Ant 1.7 with 1.5 because we have 2 classes which use 1.5 APIs. Regards, Antoine On Aug 24, 2006, at 10:02 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We say to need Java 1.2 - any class format changes between 1.2 and 1.4? I would feel more safe to do a compile run on 1.2 Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.7 --- Additional Comments From [EMAIL PROTECTED] 2006-08-23 10:40 --- Fixed in SVN_HEAD, with tests. Please check the 1.7beta when it comes out. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.7 - ReleaseInstructions - Compiler
Hello Kev, when you built the alpha version of ant 1.7, which compiler did you use ? 1.4 or 1.5 ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 - ReleaseInstructions - Compiler
On 21 Aug 2006, at 21:19, Antoine Levy-Lambert wrote: Hello Kev, when you built the alpha version of ant 1.7, which compiler did you use ? 1.4 or 1.5 ? I used the default compiler, which at the moment is 1.5 Kev -- I call it the State where everyone, good or bad, is a poison- drinker: the State where universal slow suicide is called - life - Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant 1.7 - ReleaseInstructions - Compiler
-Original Message- From: Kev Jackson [mailto:[EMAIL PROTECTED] Sent: Tuesday, 22 August 2006 9:59 AM To: Ant Developers List Subject: Re: Ant 1.7 - ReleaseInstructions - Compiler On 21 Aug 2006, at 21:19, Antoine Levy-Lambert wrote: Hello Kev, when you built the alpha version of ant 1.7, which compiler did you use ? 1.4 or 1.5 ? I used the default compiler, which at the moment is 1.5 Kev: I would feel more comfortable if it was compiled against 1.4. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 --- Additional Comments From [EMAIL PROTECTED] 2006-08-07 04:19 --- -idl should probably be treated the same way as -iiop -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 --- Additional Comments From [EMAIL PROTECTED] 2006-08-02 18:16 --- I that added this. I did it because the switch to java1.5 was breaking things, as suddenly, silently, rmic wasnt creating backwards compatible bits. You dont find out that you've stopped creating compatible stubs when Now, regarding the patch cmd.createArgument().setValue(stubOption); --- if (stubVersion == null !attributes.getIiop()) cmd.createArgument().setValue(stubOption); Um, what happens if stubVersion!=null? Surely we'd actualy want the stub version people asked for to be set. I will commit a patch that works, if it comes with -unit tests that fail before they are applied (antunit ones are good) -rmic tests that set a stub version and which don't fail when the patch goes in. -steve -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 --- Additional Comments From [EMAIL PROTECTED] 2006-08-02 18:53 --- Steve, You are right. I will work up the -unit tests for the before and after. Powell -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40152] New: - rmic: Ant 1.7 adds -vcompat when building iiop stubs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40152 Summary: rmic: Ant 1.7 adds -vcompat when building iiop stubs Product: Ant Version: 1.7Alpha (nightly) Platform: Other OS/Version: OpenVMS Status: NEW Severity: normal Priority: P3 Component: Core tasks AssignedTo: dev@ant.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hello, The RMIC task with Ant 1.7 appears to adds a default -vcompat option for compatibility. Since the default changed in Java 5.0 I can see where we might need to add this option for compatibility; however when building IIOP stubs I don't believe the -vcompat options should be supplied as a default. If we supply this option rmic attempts to build a JRMP stub and not an IIOP stub file. Example: While testing the Ant 1.7 against the jboss junit tests I came across the following failure: ... [rmic] '-vcompat' [rmic] '-iiop' [rmic] '-g' [rmic] [rmic] The ' characters around the executable and arguments are [rmic] not part of the command. [rmic] Files to be compiled: org.jboss.test.txpropiiop.interfaces.a.SessionA org.jboss.test.txpropiiop.interfaces.a.Sessi onAHomeorg.jboss.test.txpropiiop.interfaces.b.SessionB org.jboss.test.txpropiiop.interfaces.b.SessionBHome [rmic] error: org.jboss.test.txpropiiop.interfaces.b.SessionBHome is an interface; stubs are needed only for remote object clas ses. ... -vcompat was not supplied during with Ant 1.6.5, and if I supply the following patch to DefaultRmiAdapter.java, Ant 1.7 builds the rmi test stubs correctly. This also continues to supply -vcompat as a default option if - iiop is not supplied. # diff DefaultRmicAdapter.java_orig DefaultRmicAdapter.java DefaultRmicAdapter.diffs # cat DefaultRmicAdapter.diffs 209c209,210 cmd.createArgument().setValue(stubOption); --- if (stubVersion == null !attributes.getIiop()) cmd.createArgument().setValue(stubOption); Note: this is not specific to OpenVMS; I receive the same failures under Windows as well. Best Regards, Powell Hazzard HP Java Engineering -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
Steve Loughran wrote: jfuller wrote: Steve Loughran wrote: jfuller wrote: Looks good during my first checks. looks good on OSX 10.4.6, will be testing this release on a 'serious' build server farm over the weekend (rhe4). how many servers constitutes serious? the system consists of 6 servers, in pairs of 2 (dev/critical towers)...allows client (and me) to deploy new build software (like ant) easily without taking down critical build servers. These server pairs each cater to different groups and roles in build process which spans the globe; Development build server pair: Is responsible for catering to a group of 40+ developers worldwide, e.g. builds the software and deploys to the same box they determine via svn branch/tag Test/Integration build server pair: Is where we have to test integration with some other systems (mainframe db and some websphere specific stuff that is too much of a burden on dev build server)..in addition run functional and Deployment build server: selects tagged versions for build, final processing with respect to security thingies and handover to deployment system...which then deploy to a test farm...which in turn is where the app itself is hit at speed and scale. I doubled up in kit, because we had the resourcesand I like to keep things simple when working at such scale...cfengine helps out with keeping everything in sync. That sounds like quite a rigorous process. yes, cfengine and lcfg can keep your stuff in control. There's also games you can play with vmware/xen hosted images, where the real CPUs just host the virtual machines, and those you replicate off managed gold images. yes, this is a technique I have tried, though I have to admit being a bit 'fundamentally' leary about vmware/xen. I have been burned a few times through the testing of software...which was failing due to issues with virtual machine, though there was little to indicate this..which meant many man hours spent fixing false positives. If I have any excess (as you can see) I tend to spend it physically replicating environments...though, if you say things are ok now a days...then I may give it another go (perhaps as an optimisation step first!) There is also SmartFrog http://smartfrog.org/ Puppet http://reductivelabs.com/projects/puppet/index.html yes I have yet to use smartfrog in a commercial setting, though I am a big fan. didnt even know about puppet, will take a look. both of these have a non-XML language to describe system configuration, and runtimes to bring up distributed apps. I will cover smartfog in the deployment chapter of Java-Dev-with-Ant (Jim, would you like to review that chapter?), while puppet is something I know of but havent used would be an honour to review the chapter. just send it along. myself. It could be better at low-level linux config, because smartfrog, being built on java and rmi, needs a lot more of the system working before it can start configuring across systems. completely agree. cheers, Jim Fuller - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
Steve Loughran wrote: That sounds like quite a rigorous process. yes, cfengine and lcfg can keep your stuff in control. There's also games you can play with vmware/xen hosted images, where the real CPUs just host the virtual machines, and those you replicate off managed gold images. yes, this is a technique I have tried, though I have to admit being a bit 'fundamentally' leary about vmware/xen. I have been burned a number of times through the testing of software in such virtual environments...was getting test failures due to issues with virtual machine; though there was little to indicate this at the application layer..which led to many man hours spent trying to fix false positives. I got quickly tired debugging and testing the OS layer, rather then my application...this was a while back so maybe things have moved on. There is also SmartFrog http://smartfrog.org/ Puppet http://reductivelabs.com/projects/puppet/index.html yes I have yet to use smartfrog in a commercial setting, though I am a big fan. didnt even know about puppet, will take a look. both of these have a non-XML language to describe system configuration, and runtimes to bring up distributed apps. I will cover smartfog in the deployment chapter of Java-Dev-with-Ant (Jim, would you like to review that chapter?), while puppet is something I know of but havent used would be an honour to review the chapter. just send it along. myself. It could be better at low-level linux config, because smartfrog, being built on java and rmi, needs a lot more of the system working before it can start configuring across systems. completely agree. cheers, Jim Fuller - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
Kev Jackson wrote:
yes, cfengine and lcfg can keep your stuff in control. There's also
games you can play with vmware/xen hosted images, where the real CPUs
just host the virtual machines, and those you replicate off managed
gold images.
It's funny that you mention this, as my current project is working on
bash + perl + python scripts to automate updates to some software hosted
in xen - we have two xen images for each component, when we get an
update, the host shuts down one of the images (let's say guest 'b'),
while the other continues and takes over as the master ('a'), the host
(via the scripts) updates the shutdown image, reboots it, then switches
control over to it. So far it's been fairly simple (although there's a
lot of gpg signatures etc flying about to validate where the updates
come from), the hard bit (swapping images in/out) is on this weeks task
list.
The spec is ok, but some kind of controller + dsl would be nice, these
scripts do feel a little 'hacky' for my liking, although I've discovered
bashunit in the process (yes unit testing bash - I never thought I'd see
that). The worst part is getting the environment setup - writing the
scripts is fairly simple, but having every little detail in place before
you can test anything is a real pain.
You have something that works but will not scale. You know that, don't you?
Like I said, puppet and smartfrog. I know, I work on the smartfrog team
and am biased, but puppet is nice too.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
You have something that works but will not scale. You know that, don't you? Absolutely - but then I'm being paid to implement a spec, not to suggest an alternative solution. This is the way it works in the outsourcing/offshoring dev world - we just get a spec and have to implement it regardless of personal feelings or indeed technical merit. When I first started in this business (offshore work) I got into a lot of arguments over stupid specs, it cost me a lot of goodwill with customers, I've learnt to bite my tongue (for the most part), as pissing off your clients is generally a bad idea :) Scalability aside, the customer just wants something to work (tm) and considered bash to be adequate for the task - it's actually rather scary how much of a duct tape solution this is really, but then I'm enjoying hacking perl and python for a change. Like I said, puppet and smartfrog. I know, I work on the smartfrog team and am biased, but puppet is nice too. I suggested smartfrog when we got the project, but the customer wants a very small image (even adding python to the build was considered risky - so there's no way a JVM will get added, we can't even add ruby now :( ). I haven't heard of puppet, but I'll have a look tomorrow and see if I can convince the customer - I don't want to re- invent the wheel badly if it's unnecessary! Kev -- Man is truly free only among equally free men - Michael Bakunin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
jfuller wrote: Steve Loughran wrote: jfuller wrote: Looks good during my first checks. looks good on OSX 10.4.6, will be testing this release on a 'serious' build server farm over the weekend (rhe4). how many servers constitutes serious? the system consists of 6 servers, in pairs of 2 (dev/critical towers)...allows client (and me) to deploy new build software (like ant) easily without taking down critical build servers. These server pairs each cater to different groups and roles in build process which spans the globe; Development build server pair: Is responsible for catering to a group of 40+ developers worldwide, e.g. builds the software and deploys to the same box they determine via svn branch/tag Test/Integration build server pair: Is where we have to test integration with some other systems (mainframe db and some websphere specific stuff that is too much of a burden on dev build server)..in addition run functional and Deployment build server: selects tagged versions for build, final processing with respect to security thingies and handover to deployment system...which then deploy to a test farm...which in turn is where the app itself is hit at speed and scale. I doubled up in kit, because we had the resourcesand I like to keep things simple when working at such scale...cfengine helps out with keeping everything in sync. That sounds like quite a rigorous process. yes, cfengine and lcfg can keep your stuff in control. There's also games you can play with vmware/xen hosted images, where the real CPUs just host the virtual machines, and those you replicate off managed gold images. There is also SmartFrog http://smartfrog.org/ Puppet http://reductivelabs.com/projects/puppet/index.html both of these have a non-XML language to describe system configuration, and runtimes to bring up distributed apps. I will cover smartfog in the deployment chapter of Java-Dev-with-Ant (Jim, would you like to review that chapter?), while puppet is something I know of but havent used myself. It could be better at low-level linux config, because smartfrog, being built on java and rmi, needs a lot more of the system working before it can start configuring across systems. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
yes, cfengine and lcfg can keep your stuff in control. There's also
games you can play with vmware/xen hosted images, where the real
CPUs just host the virtual machines, and those you replicate off
managed gold images.
It's funny that you mention this, as my current project is working on
bash + perl + python scripts to automate updates to some software
hosted in xen - we have two xen images for each component, when we
get an update, the host shuts down one of the images (let's say guest
'b'), while the other continues and takes over as the master ('a'),
the host (via the scripts) updates the shutdown image, reboots it,
then switches control over to it. So far it's been fairly simple
(although there's a lot of gpg signatures etc flying about to
validate where the updates come from), the hard bit (swapping images
in/out) is on this weeks task list.
The spec is ok, but some kind of controller + dsl would be nice,
these scripts do feel a little 'hacky' for my liking, although I've
discovered bashunit in the process (yes unit testing bash - I never
thought I'd see that). The worst part is getting the environment
setup - writing the scripts is fairly simple, but having every little
detail in place before you can test anything is a real pain.
Kev
--
All governments are in equal measure good and evil. The best ideal
is anarchy. - Leo Tolstoy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
Looks good during my first checks. looks good on OSX 10.4.6, will be testing this release on a 'serious' build server farm over the weekend (rhe4). -- Jim Fuller --- FlameDigital Limited | Webcomposite s.r.o. Technical Director Co-Author WROX Pro PHP4 XML, WROX Pro PHP Web Services Co-Creator EXSLT http://www.exslt.org Technical Reviewer WROX Beginning Databases, Beginning XSLT, XML Handbook, Extreme XML 2004,2005,2006 XML Prague 2005/2006 http://www.xmlprague.cz --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
jfuller wrote: Looks good during my first checks. looks good on OSX 10.4.6, will be testing this release on a 'serious' build server farm over the weekend (rhe4). how many servers constitutes serious? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
Steve Loughran wrote: jfuller wrote: Looks good during my first checks. looks good on OSX 10.4.6, will be testing this release on a 'serious' build server farm over the weekend (rhe4). how many servers constitutes serious? the system consists of 6 servers, in pairs of 2 (dev/critical towers)...allows client (and me) to deploy new build software (like ant) easily without taking down critical build servers. These server pairs each cater to different groups and roles in build process which spans the globe; Development build server pair: Is responsible for catering to a group of 40+ developers worldwide, e.g. builds the software and deploys to the same box they determine via svn branch/tag Test/Integration build server pair: Is where we have to test integration with some other systems (mainframe db and some websphere specific stuff that is too much of a burden on dev build server)..in addition run functional and Deployment build server: selects tagged versions for build, final processing with respect to security thingies and handover to deployment system...which then deploy to a test farm...which in turn is where the app itself is hit at speed and scale. I doubled up in kit, because we had the resourcesand I like to keep things simple when working at such scale...cfengine helps out with keeping everything in sync. its serious for me! Any other build infrastructure stories welcome. I have been testing current head of Ant for some time on dev servers; though wont be pushing out to critical servers for some time yet. cheers, Jim --- FlameDigital Limited | Webcomposite s.r.o. Technical Director Co-Author WROX Pro PHP4 XML, WROX Pro PHP Web Services Co-Creator EXSLT http://www.exslt.org Technical Reviewer WROX Beginning Databases, Beginning XSLT, XML Handbook, Extreme XML 2004,2005,2006 XML Prague 2005/2006 http://www.xmlprague.cz --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.7 alpha available for testing...
Hi, Fixed the download problem with some .htaccess mojo, so for your approval and delight: http://people.apache.org/~kevj is now hosting the latest build. KNOWN PROBLEMS: - ManifestTest fails on OSX 10.4 with Java5 I looked at this and cannot see why it's failing - the recent changes may have caused it, but I haven't heard anyone else complaining, so maybe it's only apparent on OSX? I've only signed the tgz file itself, not the files inside - I assume that is the correct approach, as the script in ReleaseInstructions was driving me mad as I had to enter a passphrase for each file in the distribution directory Please test and see if you get the ManifestTest problem - I want to know if it's platform specific. Thanks, Kev -- I call it the State where everyone, good or bad, is a poison- drinker: the State where universal slow suicide is called - life - Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 alpha available for testing...
I'm not sure I like the version number. No problem with the Saigon bit, but should be 1.7.0alpha. Looks good during my first checks. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Stefan Bodewig wrote: Say there is a method void doSomething(Object o); in a class inside the Java class library of JDK 1.3 and a new overload void doSomething(String s); was added in JDK 1.4. Any call to doSomething() compiled on JDK 1.4 and above will pick the String signature and fail with a NoSuchMethodError (or IncompatibleClassChange, not sure) when run on JDK 1.3. NSME. There are several examples of changes like this in the JDK Annoyingly, StringBuffer.append(StringBuffer) added in JDK 1.4: StringBuffer b1, b2; // ... b1.append(b2); when compiled against JDK 1.4's rt.jar will yield code which does not run on JDK 1.3 - even though the same code compiles on JDK 1.3 and runs fine on either JDK! You need to write b1.append((Object) b2); or b1.append(b2.toString()); to ensure that the code can be safely compiled and run on either JDK. so you can't be sure it works just bbbe setting the correct target. Correct. Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. Not true. Check javap; both signatures exist in the bytecode. javac -source 1.5 automatically creates the cT(Object) overload which delegates to cT(BI) after a cast. This is necessary for compatibility with 1.4-based client code. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Kev Jackson wrote: I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. [...] Note that we could set up separate source roots containing phony classes and interfaces matching what we need for these kinds of JARs. If you had the real thing available it would use it; else it would compile against the stubs. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Sat, 10 Jun 2006, Jesse Glick [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. Not true. Check javap; both signatures exist in the bytecode. OK, so that means that JDK 1.4 compiled code should work in Java 5, but not the other way around. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'm tempted to do it but can't as I am three chapters out from finishing the text of the book, then its all the other stuff with updating it. not only would being the release manager add extra workload, it'd lead to conflict of interest (i'd be against anything inconsistent with the book text, see) I should be able to pull some work time to help with functioanl testing on odd platforms, as its interesting enough to qualify as a bit of research. I have a vmware image of win98 that we could put java1.2 on, and could set up on another vmware system (linux, probably), luntbuild to do continuous integration on the release branch. This would be an interesting exercise in the runup to release. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 5 Jun 2006, at 03:08, Steve Loughran wrote: Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'm tempted to do it but can't as I am three chapters out from finishing the text of the book, then its all the other stuff with updating it. not only would being the release manager add extra workload, it'd lead to conflict of interest (i'd be against anything inconsistent with the book text, see) I'm starting to feel confident enough to do it except for the potential amount of extra work it may include (hope that nothing happens at work to suddenly bog me down) I should be able to pull some work time to help with functioanl testing on odd platforms, as its interesting enough to qualify as a bit of research. I have a vmware image of win98 that we could put java1.2 on, and could set up on another vmware system (linux, probably), luntbuild to do continuous integration on the release branch. This would be an interesting exercise in the runup to release. Having a vmware image setup for the testing would be a great contribution - I doubt anyone would willingly work on win98 with jdk1.2, so I think your vmware image is the only way that combination will be tested :) thanks Kev -- All governments are in equal measure good and evil. The best ideal is anarchy. - Leo Tolstoy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Kev Jackson wrote: On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Just to note that I am happy to be a fall back if you run into problems Kev. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
A quick update regarding my situation trying to build a test release dist. I can now bootstrap everything except starteam and weblogic. I'm also having a strange issue with Echo not compiling in eclipse (but works fine from command line). ie, I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. I'll see if they get back to me. Regarding weblogic, if anyone has a jar file for that I'll probably need it as I doubt bea will supply me with one without again registering. Thanks Kev -- It is through disobedience that progress has been made, through disobedience and through rebellion - Oscar Wilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Hi, I am going to make these jars available to Kevin. Regards, Antoine Kev Jackson wrote: A quick update regarding my situation trying to build a test release dist. I can now bootstrap everything except starteam and weblogic. I'm also having a strange issue with Echo not compiling in eclipse (but works fine from command line). ie, I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. I'll see if they get back to me. Regarding weblogic, if anyone has a jar file for that I'll probably need it as I doubt bea will supply me with one without again registering. Thanks Kev -- It is through disobedience that progress has been made, through disobedience and through rebellion - Oscar Wilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. What about cross-compiling against older JDK's by tweaking the bootclasspath/extdirs on Javac's command line? We'd just need to keep older rt.jar files. Anyone tried that before? (I vaguely recall discussions around this). --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Ant 1.7 release
Hi Dominique, I think it is worth a try to build ant with Java 1.5 in one shot, and run tests on 1.2, 1.3, 1.4 and see how it behaves. We could also change ProxyDiagnostics and call the 1.5 APIs which are in there using reflection/introspection. There is also one test class which requires 1.5 to compile I think, so we could change it too. In this case we could build Ant 1.7 in one shot using JDK 1.4 like 1.6. We must find a solution which is simple for the release manager. We also need to automate other steps of the release process such as PGP signing the build artifacts. Regards, Antoine Original-Nachricht Datum: Fri, 2 Jun 2006 09:22:43 -0500 Von: Dominique Devienne [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Re: Ant 1.7 release We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. What about cross-compiling against older JDK's by tweaking the bootclasspath/extdirs on Javac's command line? We'd just need to keep older rt.jar files. Anyone tried that before? (I vaguely recall discussions around this). --DD - 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]
Re: Ant 1.7 release
Kev Jackson wrote: On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Thanks Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke Hello Kev, you need the libs for all the optional tasks described in the section installing ant of the manual. the way to check that you have all the libs is to make a full build and check that all the ant-* jar files have built and are not manifest only. the only lib which belongs to a product without an open source license is weblogic. I can help you regarding this one if you like. Concerning the system, any operating system is good. I built Ant 1.6 under Windows 2000 with a Sun JDK 1.4, all in one go. It looks like that Ant 1.7 has classes which require to be built under JDK 1.5. Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Concerning the sources, you need the head revision from SVN obviously. Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Ant 1.7 release
Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html -target version Generate class files that will work on VMs with the specified version. The default is to generate class files to be compatible with the JDK 5 VM. When the -source 1.4 or lower option is used, the default target is 1.4. The versions supported by javac are: cldc1.0 Generate class files suitable for use on VMs in Connected Limited Device Configuration (CLDC) version 1.0 and later. The compiler generates stack maps making the use of the preverifier unnecessary. 1.1 Generate class files that will run on VMs in JDK 1.1 and later. 1.2 Generate class files that will run on VMs in JDK 1.2 and later, but will not run on 1.1 VMs. 1.3 Generate class files that will run on VMs in JDK 1.3 and later, but will not run on 1.1 or 1.2 VMs. 1.4 Generate class files that will run on VMs in JDK 1.4 and later, but will not run on 1.1, 1.2 or 1.3 VMs. 1.5 Generate class files that are compatible only with JDK 5 VMs. 5 Synonym for 1.5 So a -target 1.2 should work the job - which is the default behaviour in our buildfile (property javac.target). Could only produce troubles if there is use of Java5 language stuff in the JDK5-only classes (e.g. enum, generic). Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Ant 1.7 release
Original-Nachricht Datum: Thu, 1 Jun 2006 16:36:11 +0200 Von: [EMAIL PROTECTED] An: dev@ant.apache.org Betreff: AW: Ant 1.7 release Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) So a -target 1.2 should work the job - which is the default behaviour in our buildfile (property javac.target). Could only produce troubles if there is use of Java5 language stuff in the JDK5-only classes (e.g. enum, generic). This is not the case. There is one class called ProxyDiagnostics under util/java15, it uses JDK 1.5 APIs but no generics or enum. So in principle, it should be possible to build Ant 1.7 in one shot under JDK 1.5 Jan Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Hi all, I'm not confirming yet to be release manager, but I'm preparing a build environment with all libs etc - so I'm edging my hat into the ring you need the libs for all the optional tasks described in the section installing ant of the manual. I have all the latest libs as described in this section, but I still can't get a completely clean compile of the following (from within eclipse) org.apache.tools.ant.taskdefs.optional.XalanLiason org.apache.tools.ant.taskdefs.optional.junit.Xalan1Executor packages: org.apache.tools.ant.taskdefs.optional.ejb org.apache.tools.ant.taskdefs.optional.starteam org.apache.tools.ant.taskdefs.optional.scm the way to check that you have all the libs is to make a full build and check that all the ant-* jar files have built and are not manifest only. the only lib which belongs to a product without an open source license is weblogic. Which tasks require this weblogic.jar? I'm getting quite a clean build here without it and I can't see where it's required. I can help you regarding this one if you like. Concerning the system, any operating system is good. Well my main (currently only personal) machine is an ageing G4 powerbook - OSX 10.4 with Java5 (apple supplied, also have JDK1.3/1.4 available). I have a nice OpenBSD3.9 box in the office here and obviously I have access to WindowsXP sp2 machines too, so I can potentially test a build on 3 envs, although realistically I'd only build it under my main machine as the others are not setup as dev boxes. I built Ant 1.6 under Windows 2000 with a Sun JDK 1.4, all in one go. It looks like that Ant 1.7 has classes which require to be built under JDK 1.5. Well I can certainly build a test release on my main machine if I can get all the required jars - my plan is to create a release-test build/ dist today and upload to my apache space if all goes well. Thanks for the info so far Kev -- I call it the State where everyone, good or bad, is a poison- drinker: the State where universal slow suicide is called - life - Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Thu, 1 Jun 2006, Jan Materne [EMAIL PROTECTED] wrote: Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html -target version Generate class files that will work on VMs with the specified version. That's only one part of the problem. The other one is that you might be using methods introduced in later versions of the class library by accident. Say there is a method void doSomething(Object o); in a class inside the Java class library of JDK 1.3 and a new overload void doSomething(String s); was added in JDK 1.4. Any call to doSomething() compiled on JDK 1.4 and above will pick the String signature and fail with a NoSuchMethodError (or IncompatibleClassChange, not sure) when run on JDK 1.3. There are several examples of changes like this in the JDK so you can't be sure it works just bbbe setting the correct target. Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. Do you have any advice for building/testing a release to avoid a 'working' release for one jdk which breaks on a different jdk? I was seriously considering the release manager role for 1.7 until this email :) Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Fri, 2 Jun 2006, Kev Jackson [EMAIL PROTECTED] wrote: On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. The pragmatic way is to assume that (1) nobody complained that Ant 1.6.5 didn't work so JDK 1.4 was fine back then and (2) the unit tests cover quite a bit of our code so running the unit test suite with JDK 1.2 is supposed to find trouble spots. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 2 Jun 2006, at 11:37, Stefan Bodewig wrote: On Fri, 2 Jun 2006, Kev Jackson [EMAIL PROTECTED] wrote: On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. Well that's physically impossible for my main machine as there isn't a JDK 1.2 for OSX (earliest is 1.3.1 I believe). The pragmatic way is to assume that (1) nobody complained that Ant 1.6.5 didn't work so JDK 1.4 was fine back then and (2) the unit tests cover quite a bit of our code so running the unit test suite with JDK 1.2 is supposed to find trouble spots. So then the 'solution' (for want of a better description) would be simply to compile with the Java5 jdk, but set the source option as 1.4. Then run the junit tests on a 1.2 vm? As I'm assuming that other people will be testing on various os' and vms, there should be adequate coverage of the vms (but I'm also guessing that there will be a tendency for the vms to be skewed towards the newer versions (1.4 +)) Thanks Kev -- Society in every state is a blessing, but government even in its best state is but a necessary evil; in it's worst state an intolerable one - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.7 release
Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Thanks Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 beta?
Kev Jackson wrote: Antoine Levy-Lambert wrote: Kev Jackson wrote: Hi, Checked the planning wiki this morning and noticed that the release schedule for the first beta of 1.7 is set at May/June this year. Since this is rapidly approaching, what are the thoughts on a: timing, each release requires a vote. A vote is open one week. but the next issues are more important b: fixes/features that still need to go in before release the wiki says this : * Fix for key IDE bugs (see eclipse, netbeans bugzillas) [all] * classloader to allow adding of jars to the current classloader (would solve a /lot/ of problems at the cost of some issues)[peter] (status RE some issues risk? -MJB) * Junit 4 integration to a level that Ant-dev and junit are happy. Who can take care of what here ? Which are the key IDE bugs ? I agree that this list as it stands is a little vague. Junit 4 integration would be another case of having special code to deal with a Java5 environment. Junit4 is special as I'm trying to set up a phone conf with the team to discuss who owns the junit4 ant task problem. If we can have an excellent junit4 task bundled with junit itself, I'll be happy, or we have a separate antlib. I think the latter may be the place to start -leave junit for junit3 only. I have this jar if anyone needs it (WebLogic 8.1, I also have 9 too I think). I agree that getting that particular jar is a pain - thankfully we don't have any oracle dependencies - that website always makes me want to kill kittens - I don't know how much user unfriendly they can be. I had WL on my laptop for a while, which was an unpleasant experience. I'd only ever install it in a new VMWare image I didnt value from now on. Its own JRE!. It's own version of Ant! with an Ant.bat! on the path! -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 beta?
( I just replied using the wrong from: address, so it probably wont go through. lets try again) Kev Jackson wrote: classloader to allow adding of jars to the current classloader (would solve a /lot/ of problems at the cost of some issues)[peter] (status RE some issues risk? -MJB) Primarily, it can cause fun with IDEs. * Junit 4 integration to a level that Ant-dev and junit are happy. Who can take care of what here ? Which are the key IDE bugs ? I agree that this list as it stands is a little vague. Junit 4 integration would be another case of having special code to deal with a Java5 environment. I'm trying to set up a conf call with the junit team, to see how best to go with the junit4 support. I am currently thinking -junit stays 3.8.x only. -we add a new junit antlib for junit4 support, design it to work on 1.6.5 and 1.7 -maybe hand off ownership of the antlib to the junit team, if they want to gain that tight coupling and take on the costs. So as part of the release target, openpgp is used to sign the archives created - sounds good to me Apache now requires signing by someone whose keys are cross authenticated. We also need to push out beta JARs to the cvs.apache.org maven1 repository, final ones to the big maven1/maven2 repo, with half-decent .pom files. I can take ownership of creating all those pom files if nobody else wants to take it on, as I use them a lot @work (with ant, naturally) - release instructions the release instructions need to be updated for subversion. I never created branches in subversion ... Branching in svn is pretty easy, but as far as I know, svn does a lazy copy - ie it doesn't copy files over to the branch until there's a change recorded - just something to be aware of - branches we will need to decide if we will want to branch ant, and if yes when. Experience from the 1.6 time showed that during a long time we did double maintenance of 1.6 branch and HEAD. We might want to delay the creation of a 1.7 branch until there is a say at least 1.7.1 ... - antlibs do we want to release antunit, dotnet and svn antlibs at the same time ? or parallel ? Should each antlib be in principle like an independent project and have its own release instructions ? Since 1.7 is the first version to properly support antlibs, wouldn't it make sense to release the first batch of ant libs at the same time, but then after to have them on their own release schedules? Seems good. - dependencies of ant we have removed from the build 4 external jars which were not to be found anymore anywhere. Still, gathering the dependencies is a problem for the release manager. For instance to get the weblogic.jar I downloaded an eval version of weblogic. (Lengthy process involving registration ...). I have this jar if anyone needs it (WebLogic 8.1, I also have 9 too I think). I agree that getting that particular jar is a pain - thankfully we don't have any oracle dependencies - that website always makes me want to kill kittens - I don't know how much user unfriendly they can be. WL itself hurts. I know people hate jboss for its worst-in-class classloader, but it doesnt make such a mess of your machine. Mind you, I've never tried WebSphere. Kev - 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]
Re: Ant 1.7 beta?
Kev Jackson wrote: I'm trying to set up a conf call with the junit team, to see how best to go with the junit4 support. I am currently thinking -junit stays 3.8.x only. -we add a new junit antlib for junit4 support, design it to work on 1.6.5 and 1.7 -maybe hand off ownership of the antlib to the junit team, if they want to gain that tight coupling and take on the costs. That sounds like a good plan - it would be much better if the JUnit people can support their own JUnit antlib WL itself hurts. I know people hate jboss for its worst-in-class classloader, but it doesnt make such a mess of your machine. Mind you, I've never tried WebSphere. Ah yes WL is one of my least favourite pieces of software - the 'hacked up not quite Ant' that it sticks on your path (before your current ANT_HOME), the 'not eclipse' IDE (WL Workshop) - great let's strip out the good features of eclipse (refactoring support, CVS/SVN support) and leave you with a bloated IDE that only works with WL, the jrocket vm - which doesn't like code compiled with the Sun JDK, but interestingly has no problems with code compiled with Jikes. A whole host of wizzy gui configurators/installers, but the shell scripts are placed in different location depending on linux/windows. And a hot-deploy mode that doesn't work (unless you use the web application / server admin tool to deploy) - which defeats the point of the 'special' bundled Ant, or the supplied shell scripts. 1.if you install it on a vmware image (Solaris?) it wont make a mess of your dev box. 2. cargo from codehaus.org should do deployment too. Its on my todo list to do full deployment from smartfrog to the various app servers, even though we tend to use jetty in-process for our day to day work. Lightweight, easily configured, self-contained. I've used a very old version of WebSphere (3.5) and it sucked, given the time WL 8+ has had since 2000 (when I used that bug-ridden steaming pile of expletive deleted), and coming from a completely different company, I hoped for something much better - but no it sucked too, but in a different way. I'm not sure, but I suspect that all J2EE appservers suck, I just haven't had the misfortune to try them all (yet). Classic app servers were what? -Web front end -EJB hosting -JMS message queuing -maybe JMX management -guis to make it easier for people to get into a non-reproducible configuration With hibernate you get good persistence without the app server, leaving only the web front end, management and the queue to deal with. That's a lot lighter wait. Oh, yes, there is that SOAP stack, but my own Alpine prototype does that in about 20 classes. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 beta?
Its on my todo list to do full deployment from smartfrog to the various app servers, even though we tend to use jetty in-process for our day to day work. Lightweight, easily configured, self-contained. I'll have to try jetty, it's been on my list of web containers to try for donkey's years. Classic app servers were what? -Web front end -EJB hosting -JMS message queuing I think that JMS may be the only part of classic j2ee that is worth keeping - it does have a *very* good reputation amongst the financial it set. -maybe JMX management -guis to make it easier for people to get into a non-reproducible configuration Yes those guis are a pain - and people always fall into the trap of using the gui to configure something, so you just end up with an test server setup differently from the intergration server set up differently from the production server. With hibernate you get good persistence without the app server, leaving only the web front end, management and the queue to deal with. That's a lot lighter wait. Oh, yes, there is that SOAP stack, but my own Alpine prototype does that in about 20 classes. web front end [tomcat/jetty behind apache/lighttpd], management [shell scripts or perl or something], pretty much everything else can be done with Spring+Hibernate+FOSS libs. SOAP was bolted on to all the containers years after they came out - it was never part of the original j2ee landscape and the servers weren't designed for it. Anyway - at least someone else understands the pain of j2ee development :) Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 beta?
Kev Jackson wrote: Hi, Checked the planning wiki this morning and noticed that the release schedule for the first beta of 1.7 is set at May/June this year. Since this is rapidly approaching, what are the thoughts on a: timing, each release requires a vote. A vote is open one week. but the next issues are more important b: fixes/features that still need to go in before release the wiki says this : * Fix for key IDE bugs (see eclipse, netbeans bugzillas) [all] * classloader to allow adding of jars to the current classloader (would solve a /lot/ of problems at the cost of some issues)[peter] (status RE some issues risk? -MJB) * Junit 4 integration to a level that Ant-dev and junit are happy. Who can take care of what here ? Which are the key IDE bugs ? c: anything else I see issues/questions/improvement points concerning the release process Some points spring to my mind : - signing of zips, tgzs, ... I did this manually for 1.6.x. Stefan Bodewig had informed us of the development of the openpgp module of jakarta commons [2]. We should check if this works for us and somehow bundle this in the build. - release instructions the release instructions need to be updated for subversion. I never created branches in subversion ... - branches we will need to decide if we will want to branch ant, and if yes when. Experience from the 1.6 time showed that during a long time we did double maintenance of 1.6 branch and HEAD. We might want to delay the creation of a 1.7 branch until there is a say at least 1.7.1 ... - antlibs do we want to release antunit, dotnet and svn antlibs at the same time ? or parallel ? Should each antlib be in principle like an independent project and have its own release instructions ? - dependencies of ant we have removed from the build 4 external jars which were not to be found anymore anywhere. Still, gathering the dependencies is a problem for the release manager. For instance to get the weblogic.jar I downloaded an eval version of weblogic. (Lengthy process involving registration ...). Kev Antoine [1] [WWW] http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [2] http://jakarta.apache.org/commons/sandbox/openpgp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 beta?
Antoine Levy-Lambert wrote: Kev Jackson wrote: Hi, Checked the planning wiki this morning and noticed that the release schedule for the first beta of 1.7 is set at May/June this year. Since this is rapidly approaching, what are the thoughts on a: timing, each release requires a vote. A vote is open one week. but the next issues are more important b: fixes/features that still need to go in before release the wiki says this : * Fix for key IDE bugs (see eclipse, netbeans bugzillas) [all] * classloader to allow adding of jars to the current classloader (would solve a /lot/ of problems at the cost of some issues)[peter] (status RE some issues risk? -MJB) * Junit 4 integration to a level that Ant-dev and junit are happy. Who can take care of what here ? Which are the key IDE bugs ? I agree that this list as it stands is a little vague. Junit 4 integration would be another case of having special code to deal with a Java5 environment. c: anything else I see issues/questions/improvement points concerning the release process Some points spring to my mind : - signing of zips, tgzs, ... I did this manually for 1.6.x. Stefan Bodewig had informed us of the development of the openpgp module of jakarta commons [2]. We should check if this works for us and somehow bundle this in the build. So as part of the release target, openpgp is used to sign the archives created - sounds good to me - release instructions the release instructions need to be updated for subversion. I never created branches in subversion ... Branching in svn is pretty easy, but as far as I know, svn does a lazy copy - ie it doesn't copy files over to the branch until there's a change recorded - just something to be aware of - branches we will need to decide if we will want to branch ant, and if yes when. Experience from the 1.6 time showed that during a long time we did double maintenance of 1.6 branch and HEAD. We might want to delay the creation of a 1.7 branch until there is a say at least 1.7.1 ... - antlibs do we want to release antunit, dotnet and svn antlibs at the same time ? or parallel ? Should each antlib be in principle like an independent project and have its own release instructions ? Since 1.7 is the first version to properly support antlibs, wouldn't it make sense to release the first batch of ant libs at the same time, but then after to have them on their own release schedules? - dependencies of ant we have removed from the build 4 external jars which were not to be found anymore anywhere. Still, gathering the dependencies is a problem for the release manager. For instance to get the weblogic.jar I downloaded an eval version of weblogic. (Lengthy process involving registration ...). I have this jar if anyone needs it (WebLogic 8.1, I also have 9 too I think). I agree that getting that particular jar is a pain - thankfully we don't have any oracle dependencies - that website always makes me want to kill kittens - I don't know how much user unfriendly they can be. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 NullPointerException AbstractFileSet and OOM error
Well, I checked out appfuse, DL'd Tomcat... then it wants mysql, which I just don't have time to install too right now. :) I will check in my changes anyway. -Matt --- Kev Jackson [EMAIL PROTECTED] wrote: well, obviously if I broke them it's entirely likely they won't be alone. Probably the easiest/most BC thing will be some form of checking whether (Abstract?)FileSet instances have a project set and using the task's project if not (I think fileset handling is separate from other ResourceCollections, so that will work... otherwise I'll clone the filesets). I'll take a look in about ten hours after I get to work. -Matt For testing purposes: Yes, there's a couple operations that copy around 500 files. Here's how to reproduce the problem in AppFuse: 1. Checkout the latest code from CVS: cvs -d :pserver:[EMAIL PROTECTED]:/cvs co -P appfuse (you may have to login first, password is guest) 2. cd into appfuse/extras/appgen and run ant test-all. 3. Make sure your ANT_OPTS are set to . When I do this, I get the following after 4 minutes: [copy] Copying 328 files to C:\Source\appfuse-appgen2 [copy] Copying 104 files to C:\Source\appfuse-appgen2\extras BUILD FAILED C:\Source\appfuse\extras\appgen\build.xml:639: The following error occurred while executing this lin e: C:\Source\appfuse\extras\appgen\build.xml:546: The following error occurred while executing this lin e: java.lang.OutOfMemoryError: Java heap space Total time: 4 minutes 9 seconds Ant 1.7 fails when trying to execute the cargo config, long before the heap space issue (probably within ~1 min). Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 NullPointerException AbstractFileSet and OOM error
On 4/18/06, Matt Benson [EMAIL PROTECTED] wrote: Well, I checked out appfuse, DL'd Tomcat... then it wants mysql, which I just don't have time to install too right now. :) I will check in my changes anyway. Thanks, I have all these installed as my 'day job' is server-side/web-app java, so it wasn't a big deal for me. I'll test the changes this morning. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 NullPointerException AbstractFileSet and OOM error
Matt, Just verified your changes have fixed the problem relating to Cargo and the NullPointer I was experiencing - thanks for looking into it for me. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 NullPointerException AbstractFileSet
Hello Kev, the question is which piece of code creates the filesets which are added here to the delete task. this piece of code is probably creating the filesets in such a way that the project field is not set. I imagine this happens in the org.codehaus.cargo.container codebase. Changing in Delete.java this line : 553 fs.getDirectoryScanner().getIncludedDirectories())); to fs.getDirectoryScanner(getProject()).getIncludedDirectories())); would fix (or mask) the problem. Regards, Antoine Kev Jackson wrote: Hi, During the course of trying to debug this memory problem with AppFuse/Ant, I've come across a NullPointerException in AbstractFileSet.setupDirectoryScanner : 462 It seems as if the project variable is null so the method p.log fails Running the same test on Ant 1.6.5 works fine and I can't see any changes to AbstractFileSet since 1.6.5 was released (June 2005). Anyone have any idea why the project isn't set? works JDK1.5 Ant 1.6.5 fails JDK1.5 Ant 1.7 (trunk) compiled today against JDK1.5 Windows XP SP2 Stack trace: org.codehaus.cargo.container.ContainerException: Failed to create a Tomcat 5.5.9 standalone configuration at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfigura tion.configure(AbstractLocalConfiguration.java:167) at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatLocalConta iner.doStart(AbstractTomcatLocalContainer.java:74) at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(Abstrac tLocalContainer.java:303) at org.codehaus.cargo.ant.CargoTask.executeActions(CargoTask.java:408) at org.codehaus.cargo.ant.CargoTask.execute(CargoTask.java:389) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:104) at org.apache.tools.ant.Task.perform(Task.java:369) at org.apache.tools.ant.Target.execute(Target.java:356) at org.apache.tools.ant.Target.performTasks(Target.java:384) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1265) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(Single CheckExecutor.java:37) at org.apache.tools.ant.Project.executeTargets(Project.java:1117) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:389) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:104) at org.apache.tools.ant.Task.perform(Task.java:369) at org.apache.tools.ant.Target.execute(Target.java:356) at org.apache.tools.ant.Target.performTasks(Target.java:384) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1265) at org.apache.tools.ant.Project.executeTarget(Project.java:1234) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe cutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1117) at org.apache.tools.ant.Main.runBuild(Main.java:675) at org.apache.tools.ant.Main.startAnt(Main.java:195) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:278) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:99) Caused by: java.lang.NullPointerException at org.apache.tools.ant.types.AbstractFileSet.setupDirectoryScanner(Abst ractFileSet.java:462) at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(Abstra ctFileSet.java:428) at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(Abstra ctFileSet.java:398) at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:552) at org.codehaus.cargo.container.spi.configuration.AbstractStandaloneLoca lConfiguration.cleanConfigurationDirectory(AbstractStandaloneLocalConfiguration. java:121) at org.codehaus.cargo.container.spi.configuration.AbstractStandaloneLoca lConfiguration.createConfigurationDir(AbstractStandaloneLocalConfiguration.java: 89) at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandalo neLocalConfiguration.doConfigure(AbstractCatalinaStandaloneLocalConfiguration.ja va:64) at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfigura tion.configure(AbstractLocalConfiguration.java:163) ... 32 more java.lang.NullPointerException
AW: Fileset and Custom Fileset in Ant 1.7
And you should ensure that you _really_ need a fileset. 2 years ago (or so) I wanted to write a new fileset and end on a selector. Jan -Ursprüngliche Nachricht- Von: Matt Benson [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 21. September 2005 17:00 An: Ant Developers List Betreff: Re: Fileset and Custom Fileset in Ant 1.7 --- JP Fiset [EMAIL PROTECTED] wrote: [snip] Can anyone comment on the impact of those changes as to the compatibility of fileset-based tasks between 1.6 and 1.7? After reviewing the code (without testing my assumptions), it looks like: 1. Fileset-based tasks written to take advantage of ResourceCollection instead of FileSet will not run in Ant prior to 1.7 2. Fileset-based tasks written prior to 1.7 (dependent on FileSet) will not be able to support custom file sets, even if running in 1.7 Are my assumptions right? For the most part, yes. However, depending on your needs you have some options. If your custom fileset follows basic fileset semantics you can subclass fileset and use your implementation freely in version current and future Ant. See zipfileset for an example of a fileset subclass with (very) different behavior from the parent. Another option you have is--if your resources will always be true files--to program to the path class. In current Ant versions a path can contain fileset|dirset|filelist in addition to its own path attribute and pathelement child elements, but in Ant = 1.7 path will accept any ResourceCollection as long as it consists of filesystem resources only. In effect ResourceCollections are transparent to tasks that make use of paths instead of filesets. -Matt JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - 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]
Re: AW: Fileset and Custom Fileset in Ant 1.7
I believe I do, but if you can prove me wrong, then I'd be delighted to go around custom files sets. I am trying to provide file selectors in svn-ant, which is an ant library that support subversion. Subversion keeps track of files that are deleted and missing. If I want to write an ant task where all missing files are restored, then the classic file set is not sufficient. I created a new file set that queries the subversion client for all files, regardless of whether they are present on the file system or not. Since there are already existing ant tasks based on file sets to perform restoring operations, using the custom file set allows re-using the same code but with the ability to specify files that are, as far as the file system is concerned, non-existent. I can not see a way around it, since the classic file set can not predict files that are not on the file system. I know that creating a custom file set that returns paths of non-existing files is a departure from what is generally accepted of a file set, however mis-use of the custom file set will result in a task failure. For example: svnFileSet id=missingFiles dir=workingCopy svnMissing/ /svnFileSet copy todir=x fileset refid=missingFiles/ /copy will fail. But, this weird behaviour is just a nuisance compared to the great benefits of something like this: svnFileSet id=modifiedFiles dir=workingCopy and svnModified/ svnAdded/ svnReplaced/ /and /svnFileSet copy todir=x fileset refid=modifiedFiles/ /copy Tell me what you think. I am in the development stage for this feature, and I have yet to submit the patch to svn-ant. This is a good time to influence the design. JP [EMAIL PROTECTED] wrote: And you should ensure that you _really_ need a fileset. 2 years ago (or so) I wanted to write a new fileset and end on a selector. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fileset and Custom Fileset in Ant 1.7
I am interested in developing a custom fileset. After reading the mail archives, it appears that much work is currently happening to allow custom file sets in 1.7. Looking at the trunk implementation, I see that this change will affect all fileset-based tasks. Can anyone comment on the impact of those changes as to the compatibility of fileset-based tasks between 1.6 and 1.7? After reviewing the code (without testing my assumptions), it looks like: 1. Fileset-based tasks written to take advantage of ResourceCollection instead of FileSet will not run in Ant prior to 1.7 2. Fileset-based tasks written prior to 1.7 (dependent on FileSet) will not be able to support custom file sets, even if running in 1.7 Are my assumptions right? JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fileset and Custom Fileset in Ant 1.7
--- JP Fiset [EMAIL PROTECTED] wrote: [snip] Can anyone comment on the impact of those changes as to the compatibility of fileset-based tasks between 1.6 and 1.7? After reviewing the code (without testing my assumptions), it looks like: 1. Fileset-based tasks written to take advantage of ResourceCollection instead of FileSet will not run in Ant prior to 1.7 2. Fileset-based tasks written prior to 1.7 (dependent on FileSet) will not be able to support custom file sets, even if running in 1.7 Are my assumptions right? For the most part, yes. However, depending on your needs you have some options. If your custom fileset follows basic fileset semantics you can subclass fileset and use your implementation freely in version current and future Ant. See zipfileset for an example of a fileset subclass with (very) different behavior from the parent. Another option you have is--if your resources will always be true files--to program to the path class. In current Ant versions a path can contain fileset|dirset|filelist in addition to its own path attribute and pathelement child elements, but in Ant = 1.7 path will accept any ResourceCollection as long as it consists of filesystem resources only. In effect ResourceCollections are transparent to tasks that make use of paths instead of filesets. -Matt JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
Jesse Glick wrote: Has anyone given thought to when we drop support for running Ant on JDK 1.2/1.3? These releases are pretty old by now and AFAIK all major platforms have had a decent 1.4 port for a while. I am guessing most Java developers would be using a relatively recent JDK anyway - and those who are still using 1.2/1.3 probably don't expect to be able to use the latest releases of every tool like Ant, either. However Ant has been a constant in most Java dev shops, and dropping support for 1.2/1.3 would be like dropping NT support (after all everyone uses XP Pro or a flavour of Unix right?) Also there have been many bug-fixes since Ant 1.5, and I'm sure there'll be more to come, do we consign JDK1.2 to Ant 1.6.3? Continuing to support 1.2 and 1.3 means we need to continue to have various hacks in the codebase - long if/else clauses, reflection - which could otherwise be removed. It means more codepaths, thus harder code to read and more of a testing burden. It also means we cannot easily use JDK 1.4+ APIs, and cannot use assertions at all. I agree that the code is more complicated than necessary (stuff like the StringUtils class provides basic support for stuff that's in JDK1.4, and this type of re-inventing is seemingly a waste of everyone's time). It'd also be good to get rid of some of the deprecated parts of Ant (although there's a BC issue there too). Personally I don't really mind (I use 1.4/1.5 so 'no skin off my nose'), but if we are to drop support for 1.2/1.3, could we not also take the opportunity that it represents to sanitize the code-base and rid ourselves of certain legacies? Create in effect a Ant 1.6.3 (works with older stuff), Ant 1.7+ (newer code, requires 1.4+, get's rid of legacy cruft). Essentially acknowledge that by dropping 1.2/1.3 we're breaking BC so why not take the opportunity to really break BC? rambling now erm +0.2 I suppose Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
Stefan Bodewig wrote: On Wed, 06 Apr 2005, Jesse Glick [EMAIL PROTECTED] wrote: Has anyone given thought to when we drop support for running Ant on JDK 1.2/1.3? These releases are pretty old by now and AFAIK all major platforms have had a decent 1.4 port for a while. We still have a customer who rejects to go beyond 1.3 right now. I'm talking about a webcenter with tons of legacy Java apps (unfortunately none written by us). The risk that one of them breaks is simply too high. I still use JDK 1.3 on my Linux box as my day-to-day JDK. These are just datapoints. I'd have to support JDK 1.2 and this is certainly easier to do if your compiler is a JDK 1.2 one, which is easiest to do if Ant runs on JDK 1.2. But I can achieve the same with 1.2 support in Ant as well. The risk with 1.2 is that we dont have the execution environment for regression. All in all I'm -0.5 on dropping JDK 1.2 for Ant 1.7 and -0.75 on dropping JDK 1.3 for Ant 1.7. I'm -1 on dropping 1.3 , 0 on 1.2 what is the cost of 1.2 support? The1.1 to 1.2 transition was profound, but things are relatively stable until the 1.4-1.5 transition, as long as you avoid javax.security. I have 1.5 on my desktop, and regularly get cruise control mail that I have checked in a 1.5-ism, even with language level left at 1.4 Personally. I'd be happer dropping Win9x support :) But note that you can't even run the last JDK 1.2 maintenance release on a recent Linux distribution, unless you use an obscure LD_PRELOAD hack (*). I don't run a /recent/ Linux distro either ;-) There could be a reason to not drop JDK 1.3 support before FreeBSD has a decent JDK 1.4 (Apache's infrastructure has some bias towards FreeBSD). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 4:24 PM To: [EMAIL PROTECTED] Subject: Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)? On Wed, 06 Apr 2005, Jesse Glick [EMAIL PROTECTED] wrote: Has anyone given thought to when we drop support for running Ant on JDK 1.2/1.3? These releases are pretty old by now and AFAIK all major platforms have had a decent 1.4 port for a while. MacOS X 10.2 (Jaguar) shipped with 1.3, so there may be desktop Java applications that require 1.3 support in that arena. -- Rick Genter Principal Engineer Silverlink Communications mailto:[EMAIL PROTECTED] (781) 272-3080 x242 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
Stefan Bodewig wrote: All in all I'm -0.5 on dropping JDK 1.2 for Ant 1.7 and -0.75 on dropping JDK 1.3 for Ant 1.7. BTW dropping JDK 1.2 support but supporting JDK 1.3 doesn't buy us a lot; few new APIs or other features were added in JDK 1.3, as it was mostly a performance release. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org if I had known it was harmless I would have killed it myself - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
Jesse Glick wrote: Stefan Bodewig wrote: All in all I'm -0.5 on dropping JDK 1.2 for Ant 1.7 and -0.75 on dropping JDK 1.3 for Ant 1.7. BTW dropping JDK 1.2 support but supporting JDK 1.3 doesn't buy us a lot; few new APIs or other features were added in JDK 1.3, as it was mostly a performance release. For non-gui stuff, 1.5 is the first release that really brings a lot. I agree, dropping 1.2 doesn't bring a lot code-wise, but it saves quite some testing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Drop 1.2/1.3 support in Ant 1.7 (or sometime)?
Martijn Kruithof wrote: Jesse Glick wrote: Stefan Bodewig wrote: All in all I'm -0.5 on dropping JDK 1.2 for Ant 1.7 and -0.75 on dropping JDK 1.3 for Ant 1.7. BTW dropping JDK 1.2 support but supporting JDK 1.3 doesn't buy us a lot; few new APIs or other features were added in JDK 1.3, as it was mostly a performance release. For non-gui stuff, 1.5 is the first release that really brings a lot. I agree, dropping 1.2 doesn't bring a lot code-wise, but it saves quite some testing. yes, but we werent doing that testing :) we arent testing on win9x either. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
