Re: ant 1.5.4 : Import
On Tue, 29 Jul 2003 05:15 am, Antoine Levy-Lambert wrote: Now we need someone (Conor ?) to decide in which order these different points are going to be added to our code. (Like what is happening for antlib). No, we all get to decide :-). I have but one vote. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
I agree that ${basedir} should be the value of basedir for the main
buildfile being executed. But what I think is necessary is to have
access to the basedirs of the imported file in a systematic, deterministic
and conflict free way. I do not think we need some special importdir
what we need is ${basedir.importedprojectname} and so on. This properties
will point to the where the local basedir for that local file is suppose to
be.
I think this is all getting too complex for import. What you are describing
is project composition where each project maintains its own context, its own
basedir, etc. This can be done separately from import. We have discussed
this in the past as projectref.
In fact I would like to rename import as include to reinforce the fact
that this is its primary function. In fact the problems we are seeing with
import all come because it tries to do two things beyond a simple #include
operation - target renaming and allowing imports to access resources
according to their import file location.
The problem with import is that it flattens a hierarchy of project files
into a single project but tries to preserve some of the hierarchy based on
project names. Having multiple basedirs, ${basedir.X}, [EMAIL PROTECTED],
partially
visible targets, etc is just a whole load of complexity for very little
benefit, IMHO.
If you want a hierarchy of projects, do that separately. If you maintain the
hierarchy in separate project instances, you eliminate all the name clashes,
etc.
So baed on discussions so far, my proposal would be:
1. import with optional name. The name is to be used in the renaming of
targets.
2. Define a single property ant.import.file which is resolved at import time
to the import location. All other properties are nt resolved.
3. All containers are projects for IDE compatibility. Note, however, that
there will be some build files, designed to be imported, which will not be
valid standal;ong build files - e.g. their targets may depend on non-existent
targets which the importer is to provide.
4. All normal Ant operations (i.e. not imports) are resolved to the basedir of
the outer project. There is no access to other basedirs.
5. Import specs are relative to importing file location. Don't use href as it
creates expectations of a URL which opens up issues.
6. An attribute may be added to the project element to mark a build file as
not importable.
Keep is Simple.
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21943] - Need way to set -verbose or -debug via properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21943. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21943 Need way to set -verbose or -debug via properties [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 00:03 --- These properties will have no effect. Currently in Ant, the -debug and -verbose flags do not affect the internal operation of Ant at all. All Ant tasks generate the full spectrum of log messages. These flags affect the operation of the Ant's default logger, which is part of the Ant command line setup. I don't know how Maven achieves its Ant integration but I presume there is a build listener somewhere. It is this listener you need to control. I couldn't find a Maven source distribution to take a look - sorry. You should ask the Maven team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
Conor MacNeill wrote, On 29/07/2003 1.23:
On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
I agree that ${basedir} should be the value of basedir for the main
buildfile being executed. But what I think is necessary is to have
access to the basedirs of the imported file in a systematic, deterministic
and conflict free way. I do not think we need some special importdir
what we need is ${basedir.importedprojectname} and so on. This properties
will point to the where the local basedir for that local file is suppose to
be.
I think this is all getting too complex for import. What you are describing
is project composition where each project maintains its own context, its own
basedir, etc.
AFAIK this is done with ant
This can be done separately from import. We have discussed
this in the past as projectref.
Hmmm, I'll look in the archives.
In fact I would like to rename import as include to reinforce the fact
that this is its primary function. In fact the problems we are seeing with
import all come because it tries to do two things beyond a simple #include
operation - target renaming and allowing imports to access resources
according to their import file location.
That was thought about, but then I looked in the XSLT spec, and import
seems to look more like it. And it's similar to Java imports.
The problem with import is that it flattens a hierarchy of project files
into a single project but tries to preserve some of the hierarchy based on
project names. Having multiple basedirs, ${basedir.X}, [EMAIL PROTECTED], partially
visible targets, etc is just a whole load of complexity for very little
benefit, IMHO.
Are you talking about the current version or the proposals? IMHO the
current version simple includes with a bit of target name rewriting.
If you want a hierarchy of projects, do that separately. If you maintain the
hierarchy in separate project instances, you eliminate all the name clashes,
etc.
Import is not made to make hierarchies of projects. It's made to include
buildfile snippets and utility finctions, not hierarchical buildfiles.
So based on discussions so far, my proposal would be:
1. import with optional name. The name is to be used in the renaming of
targets.
+1 Similar to current bahaviour.
2. Define a single property ant.import.file which is resolved at import time
to the import location. All other properties are nt resolved.
+1 as now
3. All containers are projects for IDE compatibility. Note, however, that
there will be some build files, designed to be imported, which will not be
valid standal;ong build files - e.g. their targets may depend on non-existent
targets which the importer is to provide.
+1 as now
4. All normal Ant operations (i.e. not imports) are resolved to the basedir of
the outer project. There is no access to other basedirs.
+1 as now
5. Import specs are relative to importing file location. Don't use href as it
creates expectations of a URL which opens up issues.
+1 as now
6. An attribute may be added to the project element to mark a build file as
not importable.
+1 Similar to current behaviour.
So basically add:
import file= prefix=/
^
and
project importable=true||false||[undefined]/
^
Keep is Simple.
The current version is in fact made to minimize changes and keep it very
simple, and it seems that you are coming too to my conclusions.
The problem, as you correctly note, is not about import per se, but
about false expectations that people try to realize with it.
My question is: what are users trying to do with it that is not in his
scope and cannot be done with ant?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
I think this is all getting too complex for import. What you are
describing is project composition where each project maintains its own
context, its own basedir, etc.
AFAIK this is done with ant
Not quite the same. projectref allowed the projects to be running in
tandem and for dependencies to exist beteween the projects. e.g.
projectref file=blah.xml ref=blah/
target name=test depends=blah:init
javac srcdir=${blah:src.dir}/
/target
Syntax et al up for grabs but still very different from ant
In fact I would like to rename import as include to reinforce the
fact that this is its primary function. In fact the problems we are
seeing with import all come because it tries to do two things beyond a
simple #include operation - target renaming and allowing imports to
access resources according to their import file location.
That was thought about, but then I looked in the XSLT spec, and import
seems to look more like it. And it's similar to Java imports.
import is closer to C #include than java import.
The problem with import is that it flattens a hierarchy of project
files into a single project but tries to preserve some of the hierarchy
based on project names. Having multiple basedirs, ${basedir.X},
[EMAIL PROTECTED], partially visible targets, etc is just a whole load of
complexity for very little benefit, IMHO.
The current version is in fact made to minimize changes and keep it very
simple, and it seems that you are coming too to my conclusions.
The problem, as you correctly note, is not about import per se, but
about false expectations that people try to realize with it.
Yes. I am arguing for the current import with some limited changes.
My question is: what are users trying to do with it that is not in his
scope and cannot be done with ant?
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
On 28 Jul 2003, [EMAIL PROTECTED] wrote: in the sense that I do not connect at all the new process to stream handlers and the ant logging system, disabling input, output, error, and return exec attributes in the case of spawn. Won't this cause (1) the spawned process to hang as soon as it tries to read from stdin (no big deal as it isn't supposed to do so, I guess). (2) the spawned process to be stoped or even killed by the system (at least Unix) as soon as it tries to write to stdout or stderr (probably either with SIGTTOU, SIGPIPE or SIGHUP). The better approach for (2) would probably be to enforce the output and or error attributes to be set for spawn=true and probably use OS specific redirections instead of stream handlers to ensure the spawned process will never try to write to stdout/err. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
On 28 Jul 2003, [EMAIL PROTECTED] wrote: This change allows exec to start a process which will run independently of ant. Will the spawned process keep running after Ant is finished? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
Conor MacNeill wrote, On 29/07/2003 9.15:
On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
I think this is all getting too complex for import. What you are
describing is project composition where each project maintains its own
context, its own basedir, etc.
AFAIK this is done with ant
Not quite the same. projectref allowed the projects to be running in
tandem and for dependencies to exist beteween the projects. e.g.
projectref file=blah.xml ref=blah/
target name=test depends=blah:init
javac srcdir=${blah:src.dir}/
/target
Syntax et al up for grabs but still very different from ant
Ah, ok, now I get it, thanks :-)
Basically it's an ant file that exposes targets and properties.
Given this, I understand the proposal of making:
import - include
projectref - import
although I'm personally +-0 on either denomination.
But is the above not overlapping with Gump?
Personally, I don't see the real need for it, as the same can be done
with correctly-written @importable files. In the specific, init values
should be included rather than imported.
Can you point me to some relevant use-cases?
TIA
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
On Tue, 29 Jul 2003 05:42 pm, Stefan Bodewig wrote: On 28 Jul 2003, [EMAIL PROTECTED] wrote: in the sense that I do not connect at all the new process to stream handlers and the ant logging system, disabling input, output, error, and return exec attributes in the case of spawn. Won't this cause (1) the spawned process to hang as soon as it tries to read from stdin (no big deal as it isn't supposed to do so, I guess). Just off the top of my head, I think we can close that stream which will cause an EOF rather than a hang. (2) the spawned process to be stoped or even killed by the system (at least Unix) as soon as it tries to write to stdout or stderr (probably either with SIGTTOU, SIGPIPE or SIGHUP). The better approach for (2) would probably be to enforce the output and or error attributes to be set for spawn=true and probably use OS specific redirections instead of stream handlers to ensure the spawned process will never try to write to stdout/err. Why not just caveat user :-) Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED] wrote: (2) the spawned process to be stoped or even killed by the system (at least Unix) as soon as it tries to write to stdout or stderr (probably either with SIGTTOU, SIGPIPE or SIGHUP). Why not just caveat user :-) AFAIU the current implementation will ignore the error/output attributes, which means that the user may think everything is fine even if it isn't. And then even if we use our PumpStreamHandler for stdout/stderr things are going to fail if the process is expected to outlive Ant (I'm still not sure if it is). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/types/selectors BaseSelectorContainer.java ContainsRegexpSelector.java ContainsSelector.java DateSelector.java DependSelector.java DepthSelector.java DifferentSelector.java ExtendSelector.java FilenameSelector.java MajoritySelector.java MappingSelector.java PresentSelector.java SelectSelector.java SelectorContainer.java SelectorScanner.java SelectorUtils.java SizeSelector.java TypeSelector.java
peterreilly2003/07/29 01:37:19
Modified:src/main/org/apache/tools/ant/types/selectors
BaseSelectorContainer.java
ContainsRegexpSelector.java ContainsSelector.java
DateSelector.java DependSelector.java
DepthSelector.java DifferentSelector.java
ExtendSelector.java FilenameSelector.java
MajoritySelector.java MappingSelector.java
PresentSelector.java SelectSelector.java
SelectorContainer.java SelectorScanner.java
SelectorUtils.java SizeSelector.java
TypeSelector.java
Log:
style
Revision ChangesPath
1.11 +23 -0
ant/src/main/org/apache/tools/ant/types/selectors/BaseSelectorContainer.java
Index: BaseSelectorContainer.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/types/selectors/BaseSelectorContainer.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- BaseSelectorContainer.java4 Jul 2003 23:18:49 - 1.10
+++ BaseSelectorContainer.java29 Jul 2003 08:37:17 - 1.11
@@ -80,6 +80,7 @@
/**
* Indicates whether there are any selectors here.
+ * @return true if there are selectors
*/
public boolean hasSelectors() {
return !(selectorsList.isEmpty());
@@ -87,6 +88,7 @@
/**
* Gives the count of the number of selectors in this container
+ * @return the number of selectors
*/
public int selectorCount() {
return selectorsList.size();
@@ -94,6 +96,8 @@
/**
* Returns the set of selectors as an array.
+ * @param p the current project
+ * @return an array of selectors
*/
public FileSelector[] getSelectors(Project p) {
FileSelector[] result = new FileSelector[selectorsList.size()];
@@ -103,6 +107,7 @@
/**
* Returns an enumerator for accessing the set of selectors.
+ * @return an enumerator for the selectors
*/
public Enumeration selectorElements() {
return selectorsList.elements();
@@ -189,6 +194,7 @@
/**
* add a Select selector entry on the selector list
+ * @param selector the selector to add
*/
public void addSelector(SelectSelector selector) {
appendSelector(selector);
@@ -196,6 +202,7 @@
/**
* add an And selector entry on the selector list
+ * @param selector the selector to add
*/
public void addAnd(AndSelector selector) {
appendSelector(selector);
@@ -203,6 +210,7 @@
/**
* add an Or selector entry on the selector list
+ * @param selector the selector to add
*/
public void addOr(OrSelector selector) {
appendSelector(selector);
@@ -210,6 +218,7 @@
/**
* add a Not selector entry on the selector list
+ * @param selector the selector to add
*/
public void addNot(NotSelector selector) {
appendSelector(selector);
@@ -217,6 +226,7 @@
/**
* add a None selector entry on the selector list
+ * @param selector the selector to add
*/
public void addNone(NoneSelector selector) {
appendSelector(selector);
@@ -224,6 +234,7 @@
/**
* add a majority selector entry on the selector list
+ * @param selector the selector to add
*/
public void addMajority(MajoritySelector selector) {
appendSelector(selector);
@@ -231,6 +242,7 @@
/**
* add a selector date entry on the selector list
+ * @param selector the selector to add
*/
public void addDate(DateSelector selector) {
appendSelector(selector);
@@ -238,6 +250,7 @@
/**
* add a selector size entry on the selector list
+ * @param selector the selector to add
*/
public void addSize(SizeSelector selector) {
appendSelector(selector);
@@ -245,6 +258,7 @@
/**
* add a selector filename entry on the selector list
+ * @param selector the selector to add
*/
public void addFilename(FilenameSelector selector) {
appendSelector(selector);
@@ -252,6 +266,7 @@
/**
* add an extended selector entry on the selector list
+ * @param selector the selector to add
*/
public void addCustom(ExtendSelector selector) {
appendSelector(selector);
@@ -259,6 +274,7 @@
/**
* add a contains selector entry on the selector list
+ * @param selector the selector to add
*/
public void addContains(ContainsSelector selector) {
Re: FileUtils#normalize(File)
On Mon, 28 Jul 2003, Knut Wannheden [EMAIL PROTECTED] wrote: 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. On Unix, getCanonicalPath will resolve the link and return the absolute filename of the file you've linked to. In most situations this is not what we want. Suppose a directory structure A |- B |- C for fileset dir=A includes=B/**/. We want to include B, even if it happens to be a symbolic link to C. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MatchingTask.java
peterreilly2003/07/29 01:47:12
Modified:src/main/org/apache/tools/ant/taskdefs MatchingTask.java
Log:
style
Revision ChangesPath
1.40 +19 -3
ant/src/main/org/apache/tools/ant/taskdefs/MatchingTask.java
Index: MatchingTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MatchingTask.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- MatchingTask.java 25 Jul 2003 08:59:39 - 1.39
+++ MatchingTask.java 29 Jul 2003 08:47:12 - 1.40
@@ -289,7 +289,7 @@
/**
* Returns the set of selectors as an array.
- *
+ * @param p the current project
* @return an array of selectors in this container
*/
public FileSelector[] getSelectors(Project p) {
@@ -318,6 +318,7 @@
/**
* add a Select selector entry on the selector list
+ * @param selector the selector to add
*/
public void addSelector(SelectSelector selector) {
fileset.addSelector(selector);
@@ -325,6 +326,7 @@
/**
* add an And selector entry on the selector list
+ * @param selector the selector to add
*/
public void addAnd(AndSelector selector) {
fileset.addAnd(selector);
@@ -332,6 +334,7 @@
/**
* add an Or selector entry on the selector list
+ * @param selector the selector to add
*/
public void addOr(OrSelector selector) {
fileset.addOr(selector);
@@ -339,6 +342,7 @@
/**
* add a Not selector entry on the selector list
+ * @param selector the selector to add
*/
public void addNot(NotSelector selector) {
fileset.addNot(selector);
@@ -346,6 +350,7 @@
/**
* add a None selector entry on the selector list
+ * @param selector the selector to add
*/
public void addNone(NoneSelector selector) {
fileset.addNone(selector);
@@ -353,6 +358,7 @@
/**
* add a majority selector entry on the selector list
+ * @param selector the selector to add
*/
public void addMajority(MajoritySelector selector) {
fileset.addMajority(selector);
@@ -360,6 +366,7 @@
/**
* add a selector date entry on the selector list
+ * @param selector the selector to add
*/
public void addDate(DateSelector selector) {
fileset.addDate(selector);
@@ -367,6 +374,7 @@
/**
* add a selector size entry on the selector list
+ * @param selector the selector to add
*/
public void addSize(SizeSelector selector) {
fileset.addSize(selector);
@@ -374,6 +382,7 @@
/**
* add a selector filename entry on the selector list
+ * @param selector the selector to add
*/
public void addFilename(FilenameSelector selector) {
fileset.addFilename(selector);
@@ -381,6 +390,7 @@
/**
* add an extended selector entry on the selector list
+ * @param selector the selector to add
*/
public void addCustom(ExtendSelector selector) {
fileset.addCustom(selector);
@@ -388,6 +398,7 @@
/**
* add a contains selector entry on the selector list
+ * @param selector the selector to add
*/
public void addContains(ContainsSelector selector) {
fileset.addContains(selector);
@@ -395,6 +406,7 @@
/**
* add a present selector entry on the selector list
+ * @param selector the selector to add
*/
public void addPresent(PresentSelector selector) {
fileset.addPresent(selector);
@@ -402,6 +414,7 @@
/**
* add a depth selector entry on the selector list
+ * @param selector the selector to add
*/
public void addDepth(DepthSelector selector) {
fileset.addDepth(selector);
@@ -409,6 +422,7 @@
/**
* add a depends selector entry on the selector list
+ * @param selector the selector to add
*/
public void addDepend(DependSelector selector) {
fileset.addDepend(selector);
@@ -416,6 +430,7 @@
/**
* add a regular expression selector entry on the selector list
+ * @param selector the selector to add
*/
public void addContainsRegexp(ContainsRegexpSelector selector) {
fileset.addContainsRegexp(selector);
@@ -423,7 +438,7 @@
/**
* add a type selector entry on the type list
- * @param selector
+ * @param selector the selector to add
* @since ant 1.6
*/
public void addDifferent(DifferentSelector selector) {
@@ -432,7 +447,7 @@
/**
* add a type selector entry on the type list
- * @param
cvs commit: ant/src/main/org/apache/tools/ant/filters/util ChainReaderHelper.java
peterreilly2003/07/29 01:57:32
Modified:src/main/org/apache/tools/ant/filters StringInputStream.java
src/main/org/apache/tools/ant/filters/util
ChainReaderHelper.java
Log:
style
Revision ChangesPath
1.12 +1 -0
ant/src/main/org/apache/tools/ant/filters/StringInputStream.java
Index: StringInputStream.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/filters/StringInputStream.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- StringInputStream.java25 Jul 2003 08:45:26 - 1.11
+++ StringInputStream.java29 Jul 2003 08:57:32 - 1.12
@@ -64,6 +64,7 @@
*/
public class StringInputStream
extends InputStream {
+
/** Source string, stored as a StringReader */
private StringReader in;
1.19 +3 -1
ant/src/main/org/apache/tools/ant/filters/util/ChainReaderHelper.java
Index: ChainReaderHelper.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/filters/util/ChainReaderHelper.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ChainReaderHelper.java25 Jul 2003 08:45:26 - 1.18
+++ ChainReaderHelper.java29 Jul 2003 08:57:32 - 1.19
@@ -78,6 +78,8 @@
*/
public final class ChainReaderHelper {
+// default buffer size
+private static final int DEFAULT_BUFFER_SIZE = 8192;
/**
* The primary reader to which the reader chain is to be attached.
*/
@@ -86,7 +88,7 @@
/**
* The size of the buffer to be used.
*/
-public int bufferSize = 8192;
+public int bufferSize = DEFAULT_BUFFER_SIZE;
/**
* Chain of filters
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
Yes, the spawned process keeps running after ant is finished. This is the case in the testcase which I wrote. The spawned process is sh (the Bourne Shell interpreter) which sleeps for 10 seconds. I also wrote a dummy java class which writes to some file during 10 seconds and outlives ant. Cheers, Antoine - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 9:43 AM Subject: Re: cvs commit: ant/docs/manual/CoreTasks exec.html On 28 Jul 2003, [EMAIL PROTECTED] wrote: This change allows exec to start a process which will run independently of ant. Will the spawned process keep running after Ant is finished? Stefan - 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: FileUtils#normalize(File)
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(String). 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? Another question: Now that Java 1.2 will be required, do you intend to refactor the code to use the new Java 1.2 classes and change code which now uses reflection to access some of the Java 1.2 methods? -- knut
Re: cvs commit: ant/src/main/org/apache/tools/ant/types Resource.java ZipScanner.java
On 29 Jul 2003, [EMAIL PROTECTED] wrote: Some tasks rely on the DFS ordering getIncludedXYZ used to provide I'm not sure whether we want to provide this as the sort order has never been documented. The recent changes in DirectoryScanner could lead to a situation in which A/C will be returned before A/B, I don't think this is a big issue but patched it for completeness. The change to ZipScanner in turn is necessary as getIncludedDirectories could return A/B before returning A itself - this could cause trouble within Zip where the code assumes that the parents of a given directory have been added before the directory itself[1]. The change to Resource is merely cosmetic. Stefan Footnotes: [1] Not strictly true, the code will ensure that the parents have been added before, but may do the wrong thing WRT to Unix permissions once my next patch to Zip is committed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/etc/testcases/taskdefs multimap.xml
bodewig 2003/07/29 02:35:46
Modified:src/etc/testcases/taskdefs multimap.xml
Log:
avoid spurious ${baseScratchDest} directory
Revision ChangesPath
1.2 +1 -0 ant/src/etc/testcases/taskdefs/multimap.xml
Index: multimap.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/multimap.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- multimap.xml 24 Jul 2003 13:14:20 - 1.1
+++ multimap.xml 29 Jul 2003 09:35:46 - 1.2
@@ -12,6 +12,7 @@
property name=map.ext value=.copy2/
property name=rootScratchDir value=test_multi_mapper_scratch_area/
property name=baseScratchSrc value=${rootScratchDir}/src/
+ property name=baseScratchDest value=${rootScratchDir}/dest/
target name=setup
delete dir=${baseScratchSrc}/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/CoreTasks exec.html
- Original Message - From: Stefan Bodewig [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 9:42 AM On 28 Jul 2003, [EMAIL PROTECTED] wrote: in the sense that I do not connect at all the new process to stream handlers and the ant logging system, disabling input, output, error, and return exec attributes in the case of spawn. Won't this cause (1) the spawned process to hang as soon as it tries to read from stdin (no big deal as it isn't supposed to do so, I guess). (2) the spawned process to be stoped or even killed by the system (at least Unix) as soon as it tries to write to stdout or stderr (probably either with SIGTTOU, SIGPIPE or SIGHUP). The better approach for (2) would probably be to enforce the output and or error attributes to be set for spawn=true and probably use OS specific redirections instead of stream handlers to ensure the spawned process will never try to write to stdout/err. I do not know at all what is going to happen with output, error, stdin for the spawned process. I do not know how you implement OS specific redirections ? I designed this to start something which is going to outlive ant, I thought anyway that you do not want the output or error messages coming from the spawned process to pollute asynchronously the ant logs. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ant 1.5.4 : Import
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
I think this is all getting too complex for import. What
you are describing
is project composition where each project maintains its own
context, its own
basedir, etc. This can be done separately from import. We
have discussed
this in the past as projectref.
In fact I would like to rename import as include to
reinforce the fact
that this is its primary function. In fact the problems we
are seeing with
import all come because it tries to do two things beyond a
simple #include
operation - target renaming and allowing imports to access resources
according to their import file location.
Is import to support target overriding? If it does, then
we are talking about import if it does not (i.e., targets in
importing and imported files with same name causes ERROR) then
we are talking about include.
The problem with import is that it flattens a hierarchy of
project files
into a single project but tries to preserve some of the
hierarchy based on
project names. Having multiple basedirs, ${basedir.X},
[EMAIL PROTECTED], partially
visible targets, etc is just a whole load of complexity for
very little
benefit, IMHO.
As long as I have a way to specify relative imports I have no issue.
1. import with optional name. The name is to be used in the
renaming of
targets.
Fine, but then this is not include it is import. :-)
2. Define a single property ant.import.file which is resolved
at import time
to the import location. All other properties are nt resolved.
This one you need to explain better. What does it mean resolved at import time?
Can I mention this property inside a target of the imported file?
If I can, would it be set to the expected value when the target is later
executed?
Otherwise, would the lifespan of the property be the import action itself?
That may mean the property will be set while executing top-level targets
And if I want to preserve the value I need to save if on my own properties.
If the otherwise is what you mean, then fine. But I would prefer having
the local basedir (or the file dir) because one usually need to refer
to other relative files and not to the build file itself. It makes no sense
to force users to do file arithmetic when it is not necessary.
(I vote for keeping ant.import.basedir) which applies all the basedir rules
as we have them today.
4. All normal Ant operations (i.e. not imports) are resolved
to the basedir of
the outer project. There is no access to other basedirs.
With the caviat that during importing I can have access to
the ant.import.basedir and can save it on my own properties
if I need to.
5. Import specs are relative to importing file location.
Don't use href as it
creates expectations of a URL which opens up issues.
Yes, that is fine. As long as I can say file=${basedir}/xyz (for
an import from the top) or file=${ant.import.basedir}/xyz (for an
import from the local basedir).
Imports can only be at top level, right?
6. An attribute may be added to the project element to mark
a build file as
not importable.
I really do not see the need for this. It seem superfluous.
How many of you scan their disks for build.xml files to execute
without knowing what they do?
Keep is Simple.
Yes.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21941] - Filesets with directories excluded still scan the directories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21941. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21941 Filesets with directories excluded still scan the directories [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 10:57 --- I have just done a change in CVS which fixes this problem. I also have added 3 new testcases for DirectoryScanner which show or control that exclude patterns have priority over include patterns. I mark the bug as fixed, hoping that my changes are OK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
If you want to simplify things, why not go even further? On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED] wrote: 1. import with optional name. The name is to be used in the renaming of targets. I'd like to think about removing target renaming completely. What exactly is the use-case for this? I've come up with a vague idea, but it would help tremendously what people do want this feature for. 2. Define a single property ant.import.file which is resolved at import time to the import location. All other properties are nt resolved. Why does the imported/included file need to know its name, after we've limited it to not access resources relative to its own basedir as in 4. All normal Ant operations (i.e. not imports) are resolved to the basedir of the outer project. There is no access to other basedirs. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21941] - Filesets with directories excluded still scan the directories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21941. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21941 Filesets with directories excluded still scan the directories --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 11:04 --- Actually, the limitation of my change is that if we have exclude name=src/test/**/ then src/test will not be scanned. But if we have exclude name=**/test/**/ then src/test or src/project1/test or src/project2/test will be scanned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
On Mon, 28 Jul 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: href should also support URLs But as DD pointed out, this is opening a pandora box. If imported files are downloaded from an http server or from a jar file, there will be problems with properties, ... I don't think I've understood this problem. As only the outer file has a basedir, property file=/ will be resolved to the basedir of the outer file, no URLs involved. 2) several components should be able to import the same build file --- (Alexey Solofnenko) proja.xml import projb.xml import projc.xml projb.xml and projc.xml must be allowed to import both common.xml for instance Where is the problem? ProjectHelper2 is complaining about such situations currently So it should be fixed. If we wanted to allow overriding of targets but no target renaming at all, we'd simply ignore all targets that are already there while importing. Top-level tasks will appear twice, with or without a name attribute. 7) antreturn Is not related to import. We've dismissed any such patches in the past, which doesn't mean we'll dismiss it again. But we should keep the discussions separate in order to get this one finished. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
antoine 2003/07/29 04:19:28
Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Log:
Some ftp servers have binary as default, so when binary is false
it is good to set explicitly the ascii mode for the transfer.
Problem reported by Michael Nebus (Michael dot Nebus at Pfizer dot com)
Revision ChangesPath
1.39 +6 -0
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
Index: FTP.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- FTP.java 26 Jul 2003 15:58:11 - 1.38
+++ FTP.java 29 Jul 2003 11:19:27 - 1.39
@@ -1203,6 +1203,12 @@
throw new BuildException(could not set transfer type:
+ ftp.getReplyString());
}
+} else {
+
ftp.setFileType(org.apache.commons.net.ftp.FTP.ASCII_FILE_TYPE);
+if (!FTPReply.isPositiveCompletion(ftp.getReplyCode())) {
+throw new BuildException(could not set transfer type:
++ ftp.getReplyString());
+}
}
if (passive) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant WHATSNEW
antoine 2003/07/29 04:24:50 Modified:.WHATSNEW Log: added 2 new entries to WHATSNEW Revision ChangesPath 1.472 +6 -0 ant/WHATSNEW Index: WHATSNEW === RCS file: /home/cvs/ant/WHATSNEW,v retrieving revision 1.471 retrieving revision 1.472 diff -u -r1.471 -r1.472 --- WHATSNEW 28 Jul 2003 10:39:29 - 1.471 +++ WHATSNEW 29 Jul 2003 11:24:48 - 1.472 @@ -216,6 +216,9 @@ * ftp chmod failed when the remote system was UNIX and local system Windows Bugzilla Report 21865. +* ftp did not set the ascii mode explicity, causing problems with ftp servers + having binary as default + * replace would change \r\n into \r\r\n under Windows. Other changes: @@ -506,6 +509,9 @@ * DirectoryScanner has been optimized for cases where include patterns do not start with wildcards. Bugzilla Report 20103. + +* DirectoryScanner begins to be optimized not to scan excluded directories. + Bugzilla Report 21941. * Added keep-going feature. Bugzilla Report 21144 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
Stefan Bodewig wrote, On 29/07/2003 12.59: If you want to simplify things, why not go even further? On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED] wrote: 1. import with optional name. The name is to be used in the renaming of targets. I'd like to think about removing target renaming completely. What exactly is the use-case for this? I've come up with a vague idea, but it would help tremendously what people do want this feature for. I thought I had already answered this? Anyway, the need is that I have to be able to override a target I import. For example, let's say I have a compile target I want to import, and I want to make it additionally call the pre target before and the post target after. This is a very common usecase that can make me reuse targets with minor adjustments case per case. So, let's say that there is no renaming. To use the imported compile target I will have to make my mycompile target. project import file=commontargets.xml/ target name=mycompile depends=pre, compile, post/ target name=pre /target target name=post /target /project Now all seems ok, just a minor issue that I cannot use compile but have to change name... Then I want to run the test target that is in the imported buildfile. Wait a sec, the test target in the imported buildfile is: target name=test depends=compile /target But it won't work, as I need to call pre to be able to launch a compile! There is no way out, I'm not able anymore to use an imported target. In case of renaming, I can do: project import file=commontargets.xml/ target name=compile depends=pre, original.compile, post/ target name=pre /target target name=post /target /project and test will work. What renaming does is give me the possibility of decorating the imported targets, and effectively importing the dependency graph, not only the single targets. This is a major feature of import. 2. Define a single property ant.import.file which is resolved at import time to the import location. All other properties are nt resolved. Why does the imported/included file need to know its name, after we've limited it to not access resources relative to its own basedir as in It *has* to be able to access resources relative to it's position, else for most purposes it's useless. The problem comes with the concept of basedir, as in normal buildfiles it references the path WRT which all paths are resolved. Here they are *not* resolved automatically, but the author can use to do it in a similar way by using the and file position. It's the automaticity of this resolving that is the problem, and basedir is normally associated with it. 4. All normal Ant operations (i.e. not imports) are resolved to the basedir of the outer project. There is no access to other basedirs. If the above two features were missing, it would be almost of no use. And yes, in that case it would have to be called imclude. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
On Tue, 29 Jul 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: I thought I had already answered this? quite possible. Anyway, the need is that I have to be able to override a target I import. I don't think I like either the idea of of what you describe nor the implementation. I'd probably prefer a simple include without any target overrides then. Let's say I'm -0 on the feature as such and consequently won't stand in the way of any implementation details with further questions. For example, let's say I have a compile target I want to import, and I want to make it additionally call the pre target before and the post target after. Then you don't want to import the target but a different target IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ExecTaskTest
Stefan Bodewig wrote: Calendar.getTimeinMillis() has protected access in JDK 1.3 In this case, I will write a small internal class in my test case which will extend GregorianCalendar and offer public access for getTimeinMillis Cheers, Antoine
Re: FileUtils#normalize(File)
On Mon, 28 Jul 2003, Knut Wannheden [EMAIL PROTECTED] wrote:
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 relative paths that go up
beyond , something like normalize(../../foo).
Even a path like ../foo could be normalized using the system
property user.dir,
No, most invocations of normalize happen from resolveFile, so you
already know which absolute directory to resolve against. ${user.dir}
is almost always wrong for Ant's own usage.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileUtils#normalize(File)
On Tue, 29 Jul 2003, Knut Wannheden [EMAIL PROTECTED] wrote: 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. Another question: Now that Java 1.2 will be required, do you intend to refactor the code to use the new Java 1.2 classes and change code which now uses reflection to access some of the Java 1.2 methods? Gradually, when you are working on FileUtils anyway, this would be a good time to do it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any chance for fileset arithmetic?
On Fri, 25 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote: Would it be possible to add fileset joining, subtraction, This is already possible, if you use selectors instead of include/exclude children. file renaming/mapping Every time anybody proposes to allow nested mappers in fileset, they seem to mean something different. What should fileset dir=. includes=**/*.java mapper type=glob from=*.java to=*.class/ /fileset be? A set of the (potentially non-existant) files that I get when I replace .java with .class in the names of the existing files? A set of the (potentially non-existant) files that I get when I replace .java with .class in the names of the existing files, but only those that really do not exist or are older than the corresponding class files? Something else? and selectors into fileset itself? Are there since selectors are part of Ant. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21526] - Enhancement JavaCC, JJTree and JJDoc [update]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21526.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21526
Enhancement JavaCC, JJTree and JJDoc [update]
--- Additional Comments From [EMAIL PROTECTED] 2003-07-29 14:48 ---
Some questions
+if ((outputDirectory == null)
+ (outputFile.startsWith(/) || outputFile.startsWith(\\)))
+{
+throw new BuildException(Absolute path in 'outputfile' not
supported: + outputFile);
+}
only if outputdirectory has not been set? I.e. absolute paths are supported
if it has been set?
+throw new BuildException(Drive letter in 'outputfile' not
supported: + outputFile);
Is this a general limitation of jjtree?
Maybe this table could be attached to jjtree.html ?
Of course it can, if you send a patch ;-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any chance for fileset arithmetic?
Hello Stefan,
I actually meant that mappers inside filesets would rename files in the
filesets. I need something like:
fileset id=client.fileset
fileset dir=build/docs prefix=wwwroot/docs/
fileset dir=build/lib1 prefix=subproduct1/lib/
fileset dir=dev_docs/client_readme.txt path=readme.txt/
fileset dir=dev_docs/docs includes=**/*.client.html
mapper type=glob from=*.client.html to=*.html/
/fileset
fileset refid=component1.client-fs/
/fileset
Right now I have to execute copy every time I need a complex fileset.
- Alexey.
--
{ http://trelony.cjb.net/ } Alexey N. Solofnenko
Pleasant Hill, CA (GMT-8 usually)
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 7:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Any chance for fileset arithmetic?
On Fri, 25 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote:
Would it be possible to add fileset joining, subtraction,
This is already possible, if you use selectors instead of
include/exclude children.
file renaming/mapping
Every time anybody proposes to allow nested mappers in fileset,
they seem to mean something different.
What should
fileset dir=. includes=**/*.java
mapper type=glob from=*.java to=*.class/
/fileset
be?
A set of the (potentially non-existant) files that I get when I
replace .java with .class in the names of the existing files?
A set of the (potentially non-existant) files that I get when I
replace .java with .class in the names of the existing files, but only
those that really do not exist or are older than the corresponding
class files?
Something else?
and selectors into fileset itself?
Are there since selectors are part of Ant.
Stefan
-
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: Any chance for fileset arithmetic?
On Tue, 29 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote: I actually meant that mappers inside filesets would rename files in the filesets. I'm still not sure I understand it. I need something like: fileset id=client.fileset fileset dir=build/docs prefix=wwwroot/docs/ Say you have build/docs/index.html. Do you expect the invocation of DirectoryScanner#getIncludedFiles to return index.html or wwwroot/docs/index.html? What would you expect delete to do with that fileset? What would you expect zip to do? Right now I have to execute copy every time I need a complex fileset. By using copy you physically create a file structure, this is quite different from the above. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any chance for fileset arithmetic?
I think it is easy. zip already supports part of it with zipfileset.
delete will delete the original file. copy and others will copy or see
the files with new names. I just want to avoid copying a hundreds megabytes
of data just to lay them out correctly. It would help with sync. It would
also be possible to say that a client fileset is component1 and component2
client filesets.
- Alexey.
{ http://trelony.cjb.net/ } Alexey N. Solofnenko
Pleasant Hill, CA (GMT-8 usually)
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 8:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Any chance for fileset arithmetic?
On Tue, 29 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote:
I actually meant that mappers inside filesets would rename files
in the filesets.
I'm still not sure I understand it.
I need something like:
fileset id=client.fileset
fileset dir=build/docs prefix=wwwroot/docs/
Say you have build/docs/index.html.
Do you expect the invocation of DirectoryScanner#getIncludedFiles
to return index.html or wwwroot/docs/index.html?
What would you expect delete to do with that fileset? What would
you expect zip to do?
Right now I have to execute copy every time I need a complex
fileset.
By using copy you physically create a file structure, this is quite
different from the above.
Stefan
-
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: Any chance for fileset arithmetic?
On Tue, 29 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote: I think it is easy. zip already supports part of it with zipfileset. Sure, but not for plain filesets. delete will delete the original file. I.e. treat it like any fileset. copy and others will copy or see the files with new names. I.e. copy has to be aware that this is not a plain fileset and do something special with it. The point I'm trying to make is that the meaning of the prefix attribute depends on the task - and that the task must be made aware of it to give it any meaning. In CVS HEAD, you can define zipfileset outside of any tasks and you can use zipfileset wherever you can use a fileset in Ant 1.5. It sounds as if you really wanted that copy and a couple of other tasks become aware of the fact that they are using a zipfileset. I just want to avoid copying a hundreds megabytes of data just to lay them out correctly. I completely understand that goal, just think you are tackling it from the wrong end. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any chance for fileset arithmetic?
Maybe I am wrong, but a fileset or a filelist is essentially a
collection of data files with names (isn't logically filelist an ordered
fileset?). There is no reason for the names to be exactly as they are in
the file system. Some special tasks like delete need to access original
files. Some other tasks like copy or zip need only data from the files.
They do not really care about original file names.
Right now tasks have to be aware about any extra fileset functionality they
support (zipfileset, tarfileset,...). So the proposal is to make it
generic. One of the beneficiaries is sync task. Its main goal is to create
final images, but it is not really useful, since right now it is impossible
to create an image with one command. So maybe instead of fixing each and
every task, it is better to provide a generic solution that covers copy,
zip, sync and others.
- Alexey.
--
{ http://trelony.cjb.net/ } Alexey N. Solofnenko
Pleasant Hill, CA (GMT-8 usually)
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: Any chance for fileset arithmetic?
On Tue, 29 Jul 2003, Alexey Solofnenko [EMAIL PROTECTED] wrote:
I think it is easy. zip already supports part of it with
zipfileset.
Sure, but not for plain filesets.
delete will delete the original file.
I.e. treat it like any fileset.
copy and others will copy or see the files with new names.
I.e. copy has to be aware that this is not a plain fileset and do
something special with it.
The point I'm trying to make is that the meaning of the prefix
attribute depends on the task - and that the task must be made aware
of it to give it any meaning.
In CVS HEAD, you can define zipfileset outside of any tasks and you
can use zipfileset wherever you can use a fileset in Ant 1.5. It
sounds as if you really wanted that copy and a couple of other tasks
become aware of the fact that they are using a zipfileset.
I just want to avoid copying a hundreds megabytes of data just to
lay them out correctly.
I completely understand that goal, just think you are tackling it from
the wrong end.
Stefan
-
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: Perforce bugs [was] ant 1.5.4
HEAD. -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 10:35 AM To: Ant Developers List Subject: Re: Perforce bugs [was] ant 1.5.4 - Original Message - From: Matt Bishop [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 7:21 PM I have found a couple problems, and I will upload a couple of patches today. Did you find problems with the CVS HEAD or with ant 1.5.3 ? Antoine - 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]
DO NOT REPLY [Bug 18154] - SimpleP4OutputHandler can throw exceptions that should be build exceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18154 SimpleP4OutputHandler can throw exceptions that should be build exceptions [EMAIL PROTECTED] changed: What|Removed |Added Summary|P4HandlerAdapter can throw |SimpleP4OutputHandler can |exceptions that should be |throw exceptions that should |build exceptions|be build exceptions --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 18:54 --- Fixed the title to match the bug better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14395] - No way to set additional global options for Perforce tasks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395 No way to set additional global options for Perforce tasks --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 18:55 --- Created an attachment (id=7565) Fixed P4Cmd handling to allow multiple additional command parameters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant DirectoryScanner.java
antoine 2003/07/29 12:47:16
Modified:src/main/org/apache/tools/ant DirectoryScanner.java
Log:
the method isMorePowerfulThanExcludes was returning false on
org/apache/tools/ant/taskdefs
in the run-tests target of our buildfile because of the exclude pattern :
exclude name=${ant.package}/taskdefs/TaskdefTest*Task.java/
:-(
Revision ChangesPath
1.61 +3 -12 ant/src/main/org/apache/tools/ant/DirectoryScanner.java
Index: DirectoryScanner.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/DirectoryScanner.java,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- DirectoryScanner.java 29 Jul 2003 10:49:11 - 1.60
+++ DirectoryScanner.java 29 Jul 2003 19:47:16 - 1.61
@@ -1004,19 +1004,10 @@
* @since ant1.6
*/
private boolean isMorePowerfulThanExcludes(String name, String
includepattern) {
-String shortpattern =
SelectorUtils.rtrimWildcardTokens(includepattern);
+String soughtexclude = name + File.separator + **;
for (int counter=0; counter excludes.length; counter++) {
-String shortexclude =
SelectorUtils.rtrimWildcardTokens(excludes[counter]);
-// here we are checking that the trimmed exclude pattern is not
a plain directory
-// exclude name=foo/ means exclude only the directory foo,
but not its subdirs
-if (shortexclude.length() excludes[counter].length()) {
-if (excludes[counter].charAt(shortexclude.length()) ==
File.separatorChar) {
-if (matchPath(shortexclude, name, isCaseSensitive)) {
-if (shortexclude.length() shortpattern.length()) {
-return false;
-}
-}
-}
+if (excludes[counter].equals(soughtexclude)) {
+return false;
}
}
return true;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Mkdir.java
antoine 2003/07/29 13:03:07
Modified:src/main/org/apache/tools/ant/taskdefs Mkdir.java
Log:
Similarly to what happens with the delete task, there seem to be race
conditions which prevent successful directory creation on Windows.
This change allows a second try.
Revision ChangesPath
1.25 +19 -2 ant/src/main/org/apache/tools/ant/taskdefs/Mkdir.java
Index: Mkdir.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Mkdir.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Mkdir.java9 Jul 2003 13:12:23 - 1.24
+++ Mkdir.java29 Jul 2003 20:03:07 - 1.25
@@ -1,7 +1,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2000,2002 The Apache Software Foundation. All rights
+ * Copyright (c) 2000,2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -71,6 +71,7 @@
public class Mkdir extends Task {
+private static final int MKDIR_RETRY_SLEEP_MILLIS = 10;
/**
* our little directory
*/
@@ -92,7 +93,7 @@
}
if (!dir.exists()) {
-boolean result = dir.mkdirs();
+boolean result = mkdirs(dir);
if (!result) {
String msg = Directory + dir.getAbsolutePath()
+ creation was not successful for an unknown reason;
@@ -109,6 +110,22 @@
*/
public void setDir(File dir) {
this.dir = dir;
+}
+/**
+ * Attempt to fix possible race condition when creating
+ * directories on WinXP. If the mkdirs does not work,
+ * wait a little and try again.
+ */
+private boolean mkdirs(File f) {
+if (!f.mkdirs()) {
+try {
+Thread.sleep(MKDIR_RETRY_SLEEP_MILLIS);
+return f.mkdirs();
+} catch (InterruptedException ex) {
+return f.mkdirs();
+}
+}
+return true;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18154] - SimpleP4OutputHandler can throw exceptions that should be build exceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18154 SimpleP4OutputHandler can throw exceptions that should be build exceptions [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14395] - No way to set additional global options for Perforce tasks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395 No way to set additional global options for Perforce tasks [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-07-29 20:10 --- reopening bug, since Matt thinks it is not OK yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14395] - No way to set additional global options for Perforce tasks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14395 No way to set additional global options for Perforce tasks [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdocs - link to wiki?
On Tuesday, July 29, 2003, at 10:26 AM, Stefan Bodewig wrote: I'd be very careful with pulling down examples for our tasks from a page that anybody can edit (mostly anonymously) and include it in our distribution as definitive reference information. I'm even hesitant to do it for online docs. Yeah, I understand the hesitation. Although Can I get the Wiki (whichever wiki) to send things like commit mails? I just e-mailed Andy Oliver about whether we can get the nagoya wiki to e-mail dev@ when the Ant or sub pages change. There is an RSS feed, at least. And certainly having an e-mail sent when a page changes is an easy thing to implement - so hopefully that kind of thing is already a feature of at least some wiki packages. I really do not want to browse dozens of pages (as we have dozens of tasks) every day to monitor them - and I certainly do not want to get mails for pages that do not contribute to the Ant manual, of course. No, I would not advocate either of those. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21948] - PropertyTest.Test5 failing -trying to connect?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21948.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21948
PropertyTest.Test5 failing -trying to connect?
[EMAIL PROTECTED] changed:
What|Removed |Added
Priority|Other |Medium
Summary|Test for property url |PropertyTest.Test5 failing -
|needs to work in offline|trying to connect?
|mode|
--- Additional Comments From [EMAIL PROTECTED] 2003-07-29 20:33 ---
I had filed this as an online/offline issue, but testing with network access
shows this is not the case...the problem still occurs.
I had more looks at the test code here. test5 is meant to resolve a file:: url,
but on my system XPSP1; Java(1.4.2), java is trying to connect to some remote
site:
[junit] --- Nested Exception ---
[junit] java.net.ConnectException: Connection timed out: connect
[junit] at java.net.PlainSocketImpl.socketConnect(Native Method)
[junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
[junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.jav
a:171)
[junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
[junit] at java.net.Socket.connect(Socket.java:452)
[junit] at java.net.Socket.connect(Socket.java:402)
[junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:139)
[junit] at sun.net.NetworkClient.openServer(NetworkClient.java:118)
[junit] at sun.net.ftp.FtpClient.openServer(FtpClient.java:423)
[junit] at sun.net.ftp.FtpClient.init(FtpClient.java:692)
[junit] at sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConne
ction.java:175)
[junit] at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpU
RLConnection.java:257)
[junit] at java.net.URL.openStream(URL.java:913)
[junit] at org.apache.tools.ant.taskdefs.Property.loadUrl(Property.java:
420)
[junit] at org.apache.tools.ant.taskdefs.Property.execute(Property.java:
386)
[junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.ja
va:272)
[junit] at org.apache.tools.ant.Task.perform(Task.java:401)
[junit] at org.apache.tools.ant.Target.execute(Target.java:347)
[junit] at org.apache.tools.ant.Target.performTasks(Target.java:374)
[junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1228)
[junit] at org.apache.tools.ant.BuildFileTest.executeTarget(BuildFileTes
t.java:273)
[junit] at org.apache.tools.ant.BuildFileTest.expectLog(BuildFileTest.ja
va:107)
[junit] at org.apache.tools.ant.taskdefs.PropertyTest.test5(PropertyTest
.java:99)
Even though the test URL is
property url=file://${basedir}/property3.properties/
FTP should not be getting a look in.
This is not a 'cant run the tests' problem, it looks more like correct behaviour
of the tests -and a potential problem in Java1.4.2...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.5.4 : Import
On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote: Personally, I don't see the real need for it, as the same can be done with correctly-written @importable files. In the specific, init values should be included rather than imported. Can you point me to some relevant use-cases? Ok, attached is a small test case which shows the failings of import when there are target name collisions. In this case the dependency of test to critical in b.xml is incorrectly replaced with a depenency on the critical target in a.xml. Target renaming doesn't help here. Having everything in a single project namespace remains a problem. I'd say the number of target name collisions between imported build files is going to be high because of the tendency to choose target names from a small pool of common names. Conor attachment: collision.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
