Re: my local version of supports filesystem resources now

[Stefan Bodewig]

On Tue, 27 Sep 2005, Matt Benson <[EMAIL PROTECTED]> wrote:

> I'd like to revisit this after your changes are
> committed.

Sure.

I've been in a train again yesterday and finished resource collection
support for subant, apply, xslt and unzip/tar (untar should actually
work for arbitrary resources).  Now I only need to find an hour or so
to rsync my stuff over and start commiting it ,,,

I added a new protected method to Expand for non-file resources, maybe
an approach like that will work for other tasks as well.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36835] New: - The task "waitfor" does not check test conditions if the condition is "istrue"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36835

   Summary: The task "waitfor" does not check test conditions if the
condition is "istrue"
   Product: Ant
   Version: 1.6.2
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


This script does not check if the value is true every 2 seconds, as specified. 
As a contrast, if you substitute the condition istrue to the condition isset,
the code will behave as expected.



 









-- 
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: suggestion refactor SCM

[Martijn Kruithof]

Hi,

The standard problem with any kind of refactoring is the backward 
compatibility requirement on source code level. There are a lot of 
constructs we'd like to remove, but upto now we have always weighted 
backward compatibility - even on source code level - over removing those.


Martijn

Kev Jackson wrote:


Hi

I've been playing with darcs recently and I've almost finished an 
antlib for it (though I keep being distracted, first Haskell, now 
Lisp).


'darcs get' is roughly similar to 'cvs checkout' or 'svn co'

I was wondering if it would make sense to refactor the SCM tasks into 
an interface (scm) and have a set of antlibs that implement that 
interface in a vendor specific manner.  Such that




is handled appropriately by each SCM system in it's own way, whilst at 
the same time exposing a common API to simplify this (very common) set 
of tasks.  I'm thinking it'd be similar to how the  task 
simplifies compiling regardless of which compiler you want to use.


Is this:
a - a stupid idea and a colossal waste of time
b - a not too stupid idea, but still a colossal waste of time
c - not stupid, a colossal waste of time, but it'd be worth doing anyway
d - none of the above

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]

DO NOT REPLY [Bug 34461] - problems with core task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34461





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 22:30 ---
Hi,

I can confirm this behaviour with ant 1.6.5. We got a bug report for
the debian ant package and my tests show that the java task with
fork="true" does not work in 1.6.5 anymore in the background.

For the debian bug report and possible followups and testcases
see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330292

Thanks,

Wolfgang

-- 
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: my local version of supports filesystem resources now

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I was offline for a week but had time to do some
> coding.  I finished
> resources support for  and  but
> don't have the time
> to commit it yet.  This is just a heads up so that
> Matt doesn't start
> to work on it (hope I'm not too late).

I had started more than once, actually, but have not
gotten that far yet.  My recent additions re
ResourceUtils were related.  I definitely appreciate
the help.
> 
> There've been several reasons to only support
> filesystem resources,
> supporting the old protected method signatures is
> one of them.

I'd like to revisit this after your changes are
committed.

Thanks again,
Matt
> 
> Stefan
> 
>
-
> 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: suggestion refactor SCM

[Martijn Kruithof]

Hi,

The standard problem with any kind of refactoring is the backward 
compatibility requirement on source code level. There are a lot of 
constructs we'd like to remove, but upto now we have always weighted 
backward compatibility - even on source code level - over removing those.


Martijn


Kev Jackson wrote:


Hi

I've been playing with darcs recently and I've almost finished an 
antlib for it (though I keep being distracted, first Haskell, now 
Lisp).


'darcs get' is roughly similar to 'cvs checkout' or 'svn co'

I was wondering if it would make sense to refactor the SCM tasks into 
an interface (scm) and have a set of antlibs that implement that 
interface in a vendor specific manner.  Such that




is handled appropriately by each SCM system in it's own way, whilst at 
the same time exposing a common API to simplify this (very common) set 
of tasks.  I'm thinking it'd be similar to how the  task 
simplifies compiling regardless of which compiler you want to use.


Is this:
a - a stupid idea and a colossal waste of time
b - a not too stupid idea, but still a colossal waste of time
c - not stupid, a colossal waste of time, but it'd be worth doing anyway
d - none of the above

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: NoClassDefFoundError when loading class from -lib

[Martin Gainty]

Jon-

Follow the log4j Install doc at
http://www.ingrid.org/jajakarta/log4j/jakarta-log4j-1.1.3/INSTALL
Marty-

"Life is what happens when you're busy making other plans" - John Lennon 

- Original Message - 
From: "Jon McLennan" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, September 27, 2005 3:47 AM
Subject: NoClassDefFoundError when loading class from -lib



I posted this to the users list, but didn't get any response. Maybe
someone on this list can help.

I've taken the source for org.apache.tools.ant.Launcher and modified it 
to call my own version of Main.java. Essentially, the only change I made 
with that class is to allow the user to specify which startup class is 
to be run. (The default is the standard org.apache.tools.ant.Main.) My 
version of Main can create menus from targets in the build file (plus 
some other features). I use log4j for logging debugging messages.


The problem I'm running into is when I call this line:

   Class mainClass = Class.forName(classmain, false, loader); 
   // classmain = my Main.java


I get this error:

   java.lang.NoClassDefFoundError: org/apache/log4j/Category
   at java.lang.Class.newInstance0(Native Method)
   at java.lang.Class.newInstance(Class.java:232)
   at com.clear2pay.releng.Launcher.run(Launcher.java:351)
   at com.clear2pay.releng.Launcher.main(Launcher.java:75)

I'm running Ant 1.6.1 (installed at D:\java\ant-1.6.1) and my external 
lib directory (D:\java\lib) is passed to Ant via the -lib command line 
arg. I have log4j-1.2.6.jar in that directory.


This is the command line I use:

   java !ANT_OPTS! -classpath  
   "d:\java\lib\releng.jar;

   d:\java\apache-ant-1.6.1\lib\ant.jar;
   d:\java\apache-ant-1.6.1\lib\ant-launcher.jar;
   d:\java\apache-ant-1.6.1\lib\xml-apis.jar;
   d:\bea\jdk131\jre\lib\rt.jar;
   d:\bea\jdk131\lib\dt.jar;
   d:\bea\jdk131\lib\tools.jar;
   d:\bea\jdk131\jre\lib\i18n.jar;" com.clear2pay.releng.Launcher
   -lib "D:\java\lib"
   -mc com.clear2pay.releng.Main


I put some debugging statements in com.clear2pay.releng.Launcher to see 
if org.apache.log4j.Category has been loaded by the ClassLoader


   Class myClass = loader.loadClass("org.apache.log4j.Category");
   System.out.println("myClass = " + myClass);

which outputs:

   myClass = class org.apache.log4j.Category

I even tested it by listing the methods available from that class.

So what I don't understand is, why is com.clear2pay.releng.Launcher able 
to find org.apache.log4j.Category when I get it from the loader, but it 
can't be found when I load a class that imports it? I can get this to 
work if I put all external jars I need directly in the Classpath, but 
this can cause problems on Windows if the value of Classpath gets too 
long and I'd like to avoid that.


Jon


-
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: suggestion refactor SCM

[JP Fiset]

It certainly is an interesting idea. I think the main challenge in this 
endeavour is to figure out what is the common denominator between all 
the SCM systems and then assess if it is encompassing enough to warrant 
abstracting it out.


I wish this effort will not be limited to tasks, but will also include 
file sets and file selectors, since I feel it is necessary in managing a 
source repository properly. For example, in svn-ant (the subversion ant 
lib), I implemented file selectors to discriminate files based on status 
such as: added, replaced, unversioned, ignored, etc. That, in itself, 
was not enough. I needed to also provide a file set, since subversion 
has a concept of "missing" and "deleted" files. Obviously, a classic 
file set can not predict files that are not present on the file system, 
so a custom file set had to be designed.


While tasks might have to be limited to common functionality (why 
develop a script based on a task that keeps failing on a majority of SCM 
systems), file selectors can combine the richness of all SCM systems. If 
a SCM system does not support a concept, then the related file selector 
would never tag any file. Scripts based on those file selectors would be 
valid, regardless of the underlying SCM system.


JP

Kev Jackson wrote:

Hi

I've been playing with darcs recently and I've almost finished an 
antlib for it (though I keep being distracted, first Haskell, now 
Lisp).


'darcs get' is roughly similar to 'cvs checkout' or 'svn co'

I was wondering if it would make sense to refactor the SCM tasks into 
an interface (scm) and have a set of antlibs that implement that 
interface in a vendor specific manner.  Such that




is handled appropriately by each SCM system in it's own way, whilst at 
the same time exposing a common API to simplify this (very common) set 
of tasks.  I'm thinking it'd be similar to how the  task 
simplifies compiling regardless of which compiler you want to use.


Is this:
a - a stupid idea and a colossal waste of time
b - a not too stupid idea, but still a colossal waste of time
c - not stupid, a colossal waste of time, but it'd be worth doing anyway
d - none of the above

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: suggestion refactor SCM

[Emmanuel Venisse]

Jose Alberto Fernandez a écrit :

I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.

The main reason for not having such a thing is the fact that each
project knows in advance what kind of repository is being in used. So
why do we need something abstract?

On the other hand, once you have such an abstracted functionality, I am
sure we could envision higher level tasks stored on other antlibs that
may provide project management style functionality irrespective of the
underlying repository. That would be a very good thing to have.

So I am all for it. The question is what are the concepts that can be
ported across all different SCMs?


In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, 
changelog...) in an abstract api, Each provider implement these beans for obtain an 
accessible command in framework for this provider.
We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena 
Dimension (PVCS).


I think it will be great if we can contribute together to it.

Maven-SCM is totally independant of an other framework, so it can simply be used in ant, 
maven, continuum, standalone app...


We actually use it in maven1, maven2 and continuum

Emmanuel



As per syntax, I would much prefer something like:

 

Now, can this be done in such a way as to figure out by itself what is
the underlying repository is. That would limit the need for magic stuff.

Jose Alberto



-Original Message-
From: Kev Jackson [mailto:[EMAIL PROTECTED]
Sent: 27 September 2005 07:34
To: Ant Developers List
Subject: suggestion refactor SCM

Hi

I've been playing with darcs recently and I've almost finished an


antlib


for it (though I keep being distracted, first Haskell, now Lisp).

'darcs get' is roughly similar to 'cvs checkout' or 'svn co'

I was wondering if it would make sense to refactor the SCM tasks into


an


interface (scm) and have a set of antlibs that implement that


interface


in a vendor specific manner.  Such that



is handled appropriately by each SCM system in it's own way, whilst at
the same time exposing a common API to simplify this (very common) set
of tasks.  I'm thinking it'd be similar to how the  task
simplifies compiling regardless of which compiler you want to use.

Is this:
a - a stupid idea and a colossal waste of time
b - a not too stupid idea, but still a colossal waste of time
c - not stupid, a colossal waste of time, but it'd be worth doing


anyway


d - none of the above

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]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: suggestion refactor SCM

[Phil Weighill Smith]

I would suggest having a separate (external) "typedef" (or whatever the
appropriate Ant concept would be):




...



Referencing this value by ID would allow programmatic and build script
level references to be made to such a repository without the need to
know the exact details of that repository implementation.

E.g.  could commit against SubVersion
since "xyz" has been mapped to an svn repository implementation.

Following Ant's norms, the scm:commit task could also have an embedded
repository definition instead and therefore not require the
refrepository attribute, or even have a nested repository element with a
refid attribute etc.

Phil :n.

On Tue, 2005-09-27 at 10:50 +0100, Jose Alberto Fernandez wrote:
> I think that it will be a very good idea, mostly as a stepping stone to
> higher level functionality.
> 
> The main reason for not having such a thing is the fact that each
> project knows in advance what kind of repository is being in used. So
> why do we need something abstract?
> 
> On the other hand, once you have such an abstracted functionality, I am
> sure we could envision higher level tasks stored on other antlibs that
> may provide project management style functionality irrespective of the
> underlying repository. That would be a very good thing to have.
> 
> So I am all for it. The question is what are the concepts that can be
> ported across all different SCMs?
> 
> As per syntax, I would much prefer something like:
> 
>  
> 
> Now, can this be done in such a way as to figure out by itself what is
> the underlying repository is. That would limit the need for magic stuff.
> 
> Jose Alberto
> 
> > -Original Message-
> > From: Kev Jackson [mailto:[EMAIL PROTECTED]
> > Sent: 27 September 2005 07:34
> > To: Ant Developers List
> > Subject: suggestion refactor SCM
> > 
> > Hi
> > 
> > I've been playing with darcs recently and I've almost finished an
> antlib
> > for it (though I keep being distracted, first Haskell, now Lisp).
> > 
> > 'darcs get' is roughly similar to 'cvs checkout' or 'svn co'
> > 
> > I was wondering if it would make sense to refactor the SCM tasks into
> an
> > interface (scm) and have a set of antlibs that implement that
> interface
> > in a vendor specific manner.  Such that
> > 
> > 
> > 
> > is handled appropriately by each SCM system in it's own way, whilst at
> > the same time exposing a common API to simplify this (very common) set
> > of tasks.  I'm thinking it'd be similar to how the  task
> > simplifies compiling regardless of which compiler you want to use.
> > 
> > Is this:
> > a - a stupid idea and a colossal waste of time
> > b - a not too stupid idea, but still a colossal waste of time
> > c - not stupid, a colossal waste of time, but it'd be worth doing
> anyway
> > d - none of the above
> > 
> > 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]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: suggestion refactor SCM

[Jose Alberto Fernandez]

I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.

The main reason for not having such a thing is the fact that each
project knows in advance what kind of repository is being in used. So
why do we need something abstract?

On the other hand, once you have such an abstracted functionality, I am
sure we could envision higher level tasks stored on other antlibs that
may provide project management style functionality irrespective of the
underlying repository. That would be a very good thing to have.

So I am all for it. The question is what are the concepts that can be
ported across all different SCMs?

As per syntax, I would much prefer something like:

 

Now, can this be done in such a way as to figure out by itself what is
the underlying repository is. That would limit the need for magic stuff.

Jose Alberto

> -Original Message-
> From: Kev Jackson [mailto:[EMAIL PROTECTED]
> Sent: 27 September 2005 07:34
> To: Ant Developers List
> Subject: suggestion refactor SCM
> 
> Hi
> 
> I've been playing with darcs recently and I've almost finished an
antlib
> for it (though I keep being distracted, first Haskell, now Lisp).
> 
> 'darcs get' is roughly similar to 'cvs checkout' or 'svn co'
> 
> I was wondering if it would make sense to refactor the SCM tasks into
an
> interface (scm) and have a set of antlibs that implement that
interface
> in a vendor specific manner.  Such that
> 
> 
> 
> is handled appropriately by each SCM system in it's own way, whilst at
> the same time exposing a common API to simplify this (very common) set
> of tasks.  I'm thinking it'd be similar to how the  task
> simplifies compiling regardless of which compiler you want to use.
> 
> Is this:
> a - a stupid idea and a colossal waste of time
> b - a not too stupid idea, but still a colossal waste of time
> c - not stupid, a colossal waste of time, but it'd be worth doing
anyway
> d - none of the above
> 
> 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]

NoClassDefFoundError when loading class from -lib

[Jon McLennan]

I posted this to the users list, but didn't get any response. Maybe
someone on this list can help.

I've taken the source for org.apache.tools.ant.Launcher and modified it 
to call my own version of Main.java. Essentially, the only change I made 
with that class is to allow the user to specify which startup class is 
to be run. (The default is the standard org.apache.tools.ant.Main.) My 
version of Main can create menus from targets in the build file (plus 
some other features). I use log4j for logging debugging messages.


The problem I'm running into is when I call this line:

   Class mainClass = Class.forName(classmain, false, loader); 
   // classmain = my Main.java


I get this error:

   java.lang.NoClassDefFoundError: org/apache/log4j/Category
   at java.lang.Class.newInstance0(Native Method)
   at java.lang.Class.newInstance(Class.java:232)
   at com.clear2pay.releng.Launcher.run(Launcher.java:351)
   at com.clear2pay.releng.Launcher.main(Launcher.java:75)

I'm running Ant 1.6.1 (installed at D:\java\ant-1.6.1) and my external 
lib directory (D:\java\lib) is passed to Ant via the -lib command line 
arg. I have log4j-1.2.6.jar in that directory.


This is the command line I use:

   java !ANT_OPTS! -classpath  
   "d:\java\lib\releng.jar;

   d:\java\apache-ant-1.6.1\lib\ant.jar;
   d:\java\apache-ant-1.6.1\lib\ant-launcher.jar;
   d:\java\apache-ant-1.6.1\lib\xml-apis.jar;
   d:\bea\jdk131\jre\lib\rt.jar;
   d:\bea\jdk131\lib\dt.jar;
   d:\bea\jdk131\lib\tools.jar;
   d:\bea\jdk131\jre\lib\i18n.jar;" com.clear2pay.releng.Launcher
   -lib "D:\java\lib"
   -mc com.clear2pay.releng.Main


I put some debugging statements in com.clear2pay.releng.Launcher to see 
if org.apache.log4j.Category has been loaded by the ClassLoader


   Class myClass = loader.loadClass("org.apache.log4j.Category");
   System.out.println("myClass = " + myClass);

which outputs:

   myClass = class org.apache.log4j.Category

I even tested it by listing the methods available from that class.

So what I don't understand is, why is com.clear2pay.releng.Launcher able 
to find org.apache.log4j.Category when I get it from the loader, but it 
can't be found when I load a class that imports it? I can get this to 
work if I put all external jars I need directly in the Classpath, but 
this can cause problems on Windows if the value of Classpath gets too 
long and I'd like to avoid that.


Jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion refactor SCM

[Jan Dvořák]

Hi,

it definitely is a good idea, and it's worth doing. SCM has become 
commonplace, just like databases. I think few people would object to 
lowering the barrier of moving to another SCM system and/or being more 
isolated from third-party SCM system changes.


Jan Dvorak


Kev Jackson wrote (shortened):

I was wondering if it would make sense to refactor the SCM tasks into 
an interface (scm) and have a set of antlibs that implement that 
interface in a vendor specific manner.  Such that




is handled appropriately by each SCM system in it's own way, whilst at 
the same time exposing a common API to simplify this (very common) set 
of tasks.  I'm thinking it'd be similar to how the  task 
simplifies compiling regardless of which compiler you want to use.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion refactor SCM

[Brett Porter]

On 9/27/05, Kev Jackson <[EMAIL PROTECTED]> wrote:
> d - none of the above

I know you are talking about an interface at the Ant task level, but I
should also point out that this was one of the things I was referring
to offering up Antlibs for if there was interest.

http://svn.apache.org/viewcvs.cgi/maven/scm/trunk/maven-scm-api/
http://svn.apache.org/viewcvs.cgi/maven/scm/trunk/maven-scm-providers/
(we don't currently have one for darcs...)

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]