Try using this instead,
javac srcdir=${basedir}\source\a includes=java file names
classpath=${mypath.path}
/javac
Hope this helps
-Original Message-
From: Grand Cheng [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 1:53 AM
To: [EMAIL PROTECTED]
Subject:
Is there a way to reuse path definitions when using import, in a way
similar to what you can do with targets?
I've a standard path defined in a common build file, which is good for
almost all my projects.
When I need to change it I'm forced to redefine it completely, even when
it would be
Hi,
[...]
target name=CompileMyStuff
javac srcdir=${basedir}\source\a /
classpath refid=${mypath.path} /
/target
try using
classpath refid=mypath.path /
^^^
instead.
Greetings
Chris
[...]
yep:
common.xml:
---
property name=prop value=common/
path id=classpath.additional/
path id=classpath
path refid=classpath.additional/
/path
build.xml:
--
property name=prop value=specific/
import file=../../common.xml/
path
Grand:
Keep in mind that if your base folder is named 'base' and
your package name is named 'foo' then you need to compile the source from
folder 'base' which referennces package (folder) foo
Since your email did not provide package names I do not know what the
specific names would be
Martin
-
[EMAIL PROTECTED] wrote:
common.xml:
---
property name=prop value=common/
path id=classpath.additional/
path id=classpath
path refid=classpath.additional/
/path
The classpath.additional has to defined in the common.xml because its
references there.
So basically
Dear Colleagues,
I want to generate reports for the files that have
been changed in our project between two cvs tags. The
reports are simple: they should include the name of
the files that have been changed, the files that are
added and the files that have been deleted between the
two tags. The
This will cause the annoying
Overriding previous definition of reference to classpath.additional
message.
There is a bug report requesting the reduction of this message to verbose,
perhaps this would be a good thing to do!
Peter
[EMAIL PROTECTED] wrote:
yep:
common.xml:
---
property
Peter Reilly wrote:
This will cause the annoying
Overriding previous definition of reference to classpath.additional
message.
Yeah. I already got that when I redefined the path.
There is a bug report requesting the reduction of this message to verbose,
perhaps this would be a good thing to do!
I
I'm trying to connect from a Windows machine to a Solaris box using SCP.
I get the following output from the any task:
[scp] Connecting to 192.168.*.*
FAILED
\test\build.xml:16: No response from server
SCP is running on the server, as I can use other SCP clients to copy
files. The release
Hi Everyone,
I appreciate the help.
Unfortunately I still can't seem to get the compile going. Martin, you
mentioned that it would be helpful if I provided the package names, so
here is the build file itself, and the problems I am encountering.
Maybe I am compiling from the wrong base folder?
Mike
192.168.*.* is a DHCP dynamically assigned IP address
Please confirm the IP Address via tracert hostname of your Sun Box
Martin-
- Original Message -
From: Nibeck Mike [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 9:07 AM
Subject: ANT 1.6, SCP and session
From: Ivan Ivanov [mailto:[EMAIL PROTECTED]
2) cvschengelog has tag attribute which queries the
changelog for a specific branch.
I don't have an answer to your question, but just wanted to
point out that any file added on the branch only never shows
up in the CVS changelog for the branch!
On Tue, 5 Oct 2004, Richard Russell [EMAIL PROTECTED] wrote:
You said: ...you want to express yourself in loops while Ant wants
to work on collections. This is most certainly true! But how do I
express what I want to do in this particular case, as an operation
on a collection?
Even if it
Note that by putting the extension classpath before the import,
and removing the it from common.xml, this works fine, and has the
advantage of failing the build is the importing build file does
not declare a path with the required ID.
Kind of like having an 'abstract' path.
Granted, that's more
Hi,
Thanks for the assistance.
With regard to 2)resolving classepath issues I guess I am still a bit
unsure of what you mean. But here is what I did.
1) I left the basedir as c:\
2) I changed src1 to location=PCCSOU~1\CAN\
I hope what I have changed is what you were referring to.
I ran the
Dominique,
Thank you for your answer. I also thought that it
might be a pure CVS issue. However, I am still two
lazy to generate these reports manually so I am
thinking of writing custom task that invokes cvs diff
instead of cvs log (as I said in the prevois email cvs
-q rdiff -s -r tag1 -r tag2
Maybe that´s historical: when writing that peace of code I tested the
paths _inside_ the buildfile and then extracting that into common.xml :)
Jan
-Ursprüngliche Nachricht-
Von: Dominique Devienne [mailto:[EMAIL PROTECTED]
Gesendet am: Mittwoch, 6. Oktober 2004 16:46
An: Ant Users
I should have sent a different example. Although the IP is traditional
served via DHCP, it is static on this server. I have also connected
using HOSTANEM, with the same results. I can ping/trace route between
IP and name from the client with no problem.
_mike
-Original Message-
From:
Dominique Devienne wrote:
Note that by putting the extension classpath before the import,
and removing the it from common.xml, this works fine, and has the
advantage of failing the build is the importing build file does
not declare a path with the required ID.
But it also makes the common build
Assuming the CVS output is similar to the command Ant already
uses, then it would be easy I'd think, but I've been wrong with
this kind of quick assessment before ;-)
The Devil's in the details, and as Joel would say, it's never
as easy as it looks. Give it a try and let us know. --DD
Thanks again Conner.
This is the last I will post on the subject.
I found a nice little article callled Manifest Destiny that does a nice job
of explaining the manifest file, its format, how it is used and it even
includes a bit about ANT.
http://www.sys-con.com/story/?storyid=36995DE=1
-Original Message-
From: Stefano Mancarella [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
Note that by putting the extension classpath before the import,
and removing the it from common.xml, this works fine, and has the
advantage of failing the build is the importing build
I've been specifying paths in an xmlproperty file which is loaded by the
common build file and used by other build files by importing the common build
file. All build files use the same build structure so the paths are always
applicable to all builds. I also tend to define a path that is empty,
Dominique Devienne wrote:
Yeah, it should work. But I prefer to have a callable/complete
common.xml.
I guess that strikes me as strange. I've designed at least 3
quite large multiple-build-files Ant builds for mixed C/C++/Java
projects using import, and the build files I import are never
callable
Jacob Kjome wrote:
I also tend to define a path that is empty, but
referenced by one of the other standard paths. That way, I can override that
empty path and the pathelements will get included in the standard path by
reference.
Hopefully that's what you are looking for.
Yes it is. Thanks
I think it's just a different design.
In mine the common build file already contains everything I
need for a
typical project out of the box.
The purpose of the including build file is just to add/rewrite/extend
custom stuff. For very basic projects it just adds a target
to pack the
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
[SNIP]
Even if it isn't the right verb, a simple copy on
your source
fileset would already do if it knew how to append -
as would concat
with a nested redirector. I'd probably prefer the
concat approach
since an appending copy sounds strange.
I prefer to keep my build files shorter, as they are
already definitely too long.
Mine are actually quite small now that I import all the
common parts from a small set of 'abstract' build files.
(and by 'abstract' I mean meant to imported as opposed
to necessarily having 'abstract' targets).
Dominique Devienne wrote:
I prefer to keep my build files shorter, as they are
already definitely too long.
Mine are actually quite small now that I import all the
common parts from a small set of 'abstract' build files.
(and by 'abstract' I mean meant to imported as opposed
to necessarily having
Hello:
I am trying to figure out how to handle the data being passed to me by my IT
department. They finally agreed to send me an xml document (see snippet
below) and that should have made my life much simpler.
Maybe I should describe what I'm trying to do:
I am attempting to stop multiple
This is what I have been doing to arrange my data in XML files. Its a bit
crooked way of organizing data but
it is read very easily and readily available in properties.
e.g. in your case I would change the format of the XML file to something
like this.
servers
server1Machine1/server1
Or use something like XMLTask...
http://www.oopsconsultancy.com/software/xmltask/index.html
Jake
Quoting [EMAIL PROTECTED]:
This is what I have been doing to arrange my data in XML files. Its a bit
crooked way of organizing data but
it is read very easily and readily available in
Yes
It appears your javac task is exhausting the memory resource I would suggest
adding memoryMaximumSize parameter to javac task
e.g.
javac srcdir=${src} destdir=${build} memoryMaximumSize=500M
(you also might want to add memoryInitialSize parameter at a size sufficient
to start with say 250M)
34 matches
Mail list logo
