Did you try to download it from a mirror? The mirrors are probably not up
to date yet :-) Follow the "master distribution directory" link
(http://www.apache.org/dist/ant/).
--
knut
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Montag, 3. März 2003 16:
This discussion starts to get interesting. Just a few thoughts...
> >
> > because it feels more natural?
> >
> >
> >
> >
> > or
> >
> > ant:element="classpath">
> >
> I see. This is an interesting idea, whether is more natural
> is debatable ;-).
>
It'd be natural to people who've worked wit
> I have been thinking about using namespaces with antlibs like this:
>
>
><.. init properies .../>
> xmlns:antelope="antlib:${antelope.jar}">
>
>
>
>
>
>
>
>
>
>
>
That is almost the same thin
>
> Or even:
>
>
That syntax abuses the purpose of XML Namespaces, IMO. Although a namespace
is identified by an URI, I don't think attaching semantics to it is correct.
Also, would ProjectHelper2 (using SAX2) resolve property references in
namespace declarations? Questionable whether that
>
> peter reilly wrote:
> > True. It seems quite difficult to use namespaces in a nice way.
>
> You are not supposed to "use namespaces in a nice way".
> XML Namespaces are there so that you can avoid name clashes
> for XML element and attribute names if you want to use XML
> vocabularies from va
Some more thoughts on namespaces...
>
> > I do not like the "type" attribute, type is already use on several
> > places like
>
> names ...
>
> This is where I'd really see a magical namespace for attributes that
> get parsed by Ant's core.
>
Then the whole thing would resemble XML Schema Ins
Peter,
>
> example:
>
>
> newattribute="MyFileSet attribute"/>
>
>
>
>newattribute="MyPath attribute"/>
>
>
I assume you meant to write "ant:type" instead of "ant-type"...
I suppose in both examples all further attribut
>
> Costin Manolache wrote, On 03/05/2003 8.22:
> ...
> > One use case I had in mind for CH was a namespace like "jmx:...",
> > where the JMXComponentHelper would use the JMX metadata to
> create the
> > task ( no ant table ). That's clearly outside the scope of
> antlib or ant (
> > it's just
>
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>
I agree. With the new ProjectHelper2 everything should be in place to start
using namespaces.
This would also allow antlibs to have a DTD or XML Schema which could be
used in XML edit
> > >
> > > Let's not reinvent the wheel here.
> > >
> > > The solution for names conflicts is namespaces - not rewriting.
> > >
> >
> > I agree. With the new ProjectHelper2 everything should be in
> > place to start
> > using namespaces.
> >
>
> I have no problem on allowing people to use
Peter,
>
> >
> >
> > This would allow arbitrary NSURIs ( for people who like
> meaning-free URIs)
> > and allow the classpath association.
>
> I do not want meaning-free URIs.
> I want ant to ignore URIs that it does not understand.
> At the time of processing the typedef's uri, the parsing
Hi,
At our company we're developing Ada95 code for various platforms, including
OpenVMS. We've built our own development tools based on Ant for this. I
was wondering if someone in the Ant community had some useful tips or other
information on this topic to share. E.g. what tasks work / don't wo
Stefan,
Thanks for your quick reply.
>
> > At our company we're developing Ada95 code for various platforms,
> > including OpenVMS.
>
> You are the first person reporting anything about Ant on OpenVMS
> AFAIK.
>
Don't know whether I should be surprised or not... But the VM
implementation pro
Stefan,
>
> > I think it should all be solvable inside Execute. You could
> > restrict users to only execute .EXE and .COM files on VMS. Another
> > solution is to write the command to a temporary .COM and then
> > execute that. But I have to do some more testing here.
>
> In either case, we
> At the moment it seems that Ant's basic requirements to make
> work could be covered by Java and maybe an ANTRUN.COM DCL script along
> the lines of antRun and antrun.bat.
>
If I'm not mistaken then a DCL script can only process a maximum of 8
arguments and the call to a DCL script from Java,
>
> > But the other Runtime.exec() methods (without working directory)
> > should all work.
>
> So let's really treat OpenVMS like OS/2 and disable the Jdk13Launcher
> unconditionally.
>
The Java CommandLauncher for VMS could catch the IOException with the
message "function not implemented" and
Steve,
>
> Maybe we could start with a run of the full ant unit test
> suite on VMS
> to see what happens.
>
That souds like a good idea. I will try to do that. But I can only run the
tests on the system I have access to, which is OpenVMS 7.3.1 for Alpha with
HP's JVM version 1.4.1. I'll l
Stefan,
On OpenVMS System.getProperty("path.separator") returns ":". This causes
the Os condition to classify OpenVMS as Unix. So the check for OpenVMS
needs to take place before the one for Unix. And you have to guard the
check for Unix against OpenVMS in the same manner as you do against Mac.
>
> > If I'm not mistaken then a DCL script can only process a maximum of
> > 8 arguments and the call to a DCL script from Java, including the
> > script filename and its arguments, can at the most be 256 characters
> > long.
>
> I'm out of OpenVMs business for too long, to know whether you are
> >
> > What remains to be done:
> > 1. Add a method Execute#isFailure(int result) or something similar
> > 1.1 Modify to use this method
> > 1.2 Update documentation of
> > 2. Write a RUNANT.COM DCL sript for shell execution
> > 3. Write a ANT.COM (and BUILD.COM) script
> >
> > Task 1. (a
Hi,
I have now written a simple patch for the task to make it OpenVMS
compatible. I've added it to Bugzilla (ID 21877).
The Execute class now has an OpenVMS specific CommandLauncher which writes
the command into a temporary DCL script. Further a static method
Execute#isFailure(int exitValue) i
Stefan,
Thanks for applying the patch so fast!
Meanwhile I've been working on adding support for VMS logicals. This is a
bit tricky, because a logical can have multiple values and it can also be
defined in multiple tables. Additionally the output from SHOW LOGICAL can't
just be read in as on Un
Title: RE: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs ExecTa sk.java Execute.java
Stefan,
>
> > Would you be interested in a patch for this?
>
> Off course.
>
OK, here's the patch.
I suppose that it's OK to use the collection framework, now that Ant 1.6 will require Java 1
>
> The way it is now will make useless on OpenVMS, right? The
> code now expects file names to be in OpenVMS format while is
> going to add any source/target files in Unix format.
>
That's right. But it can't be fixed in Execute, as Execute only deals with
the command as a String array. It
> >>unless java does the VMS filespec generation
> >>
> >
> >
> > That's another possibility. But in that case the VMS
> specific code wouldn't
> > only be inside oat.ant.taskdefs.Execute, but also in
> and .
> > Worse yet, this translation isn't really trivial either.
> The JVM has to do
>
I've noticed that the normalize(File) method in FileUtils requires that the
File to normalize is absolute. I was wondering what the reason is for this
reason. Would it be too complex to normalize a relative path on Windows
systems?
I think it makes perfectly sense to normalize a path like "./foo
>
> > I've noticed that the normalize(File) method in FileUtils
> requires that
> the
> > File to normalize is absolute. I was wondering what the
> reason is for
> this
> > reason. Would it be too complex to normalize a relative
> path on Windows
> > systems?
> >
> I do not know.
I get the i
>
> > I get the impression FileUtils#normalize(File) mimics the behaviour
> > of File#getCanonicalFile().
>
> To a certain extent, yes.
>
> > But I suppose there's a good reason for not using that method
>
> Symbolic links.
>
Makes sense. I've added that as a comment to FileUtils#normalize(S
Stefan,
> > I've noticed that the normalize(File) method in FileUtils requires
> > that the File to normalize is absolute. I was wondering what the
> > reason is for this reason.
>
> I'm not entirely sure (we extracted the code from Project way back
> IIRC). On problem I can imagine is that of
> > For VMS I intend to add a method FileUtils#toVMSPath(File):String.
> > I was just thinking if a more generic
> > FileUtils#toOSPath(File):String would make sense. What do you
> > think?
>
> There currently is no need for it except in the OpenVMS case, we could
> add toOSPAth later IMHO.
>
O
This very much reminds me of what I was doing in our build environment. I
basically had a template buildfile and could override that for any project
like this:
<.../>
<.../>
The difference is only that I didn't implement as a task
(top-level tasks didn't exist back then). (Similar
Dominique,
> Indeed ;-) What you demoed Conor is precisely the use case I
> need, which was
> very much inspired by Knut's past posts. I also like Knut's
> name better, as it's more explicit.
>
> The one thing I'm not too sure about is the and
> ones... Why are these needed? Property
> immut
Stefan,
> > On the downside a FileUtils#toVMSPath(File) would push the OS
> > awareness responsibility up a level, in which case
> > Commandline.Argument.setFile(File) would have to check for OpenVMS
> > and call this method.
>
> I agree, Commandline.Argument shouldn't need to be aware of this.
>
Stefan,
>
> > With the new ODS-5 file system this is a little bit different; I'd
> > call it "partially case sensitive".
>
> Your description sounds much like Windows NTFS or MacOS X with HFS+.
>
I wasn't aware of this.
> > So one solution would be to leave this problem with the buildfile
> >
Antoine,
> is it then impossible in a Java program to be sure what the exact case
> spelling of a file in OpenVMS is ?
More or less. If you do a File#listFiles() you will get entries with the
correct case, but only for this last segment of the path. All other
segments will reflect the same case
>
> > Example: I have a file FOO.TXT on the file system and select it with
> > . It will get selected because
> >
> > new File("foo.txt").getCanonicalPath()
> >
> > returns "foo.txt" instead of "FOO.TXT".
>
> This is bad, in particular as it won't get selected for
> includes="fo?.txt", so
Dominique,
> Even my current use of I find hackish, but
> without the ability
> to use Ant's own digester-like XML to Java engine, I find
> easier to call
> another Project and extract what I need out of it, rather
> than coding from
> scratch the info I need about of a separate non-Ant (data-
Nice!
I also created a bug in Bugzilla for this, as that seems to be the prefered
way of handling bugs. But there seems to be some delay, so you can just
close it once it gets through to the mailing list. I apologize for the
inconvenience. In future I'll try to only post patches through Bugzill
38 matches
Mail list logo
