Re: [VOTE] Ivy 2.0.0-rc2 Release

[Xavier Hanin]

On Tue, Oct 28, 2008 at 11:53 PM, Maarten Coene <[EMAIL PROTECTED]>wrote:

> I have built a second release candidate for Ivy 2.0.0
>
> You can download it from this URL:
> http://people.apache.org/~maartenc/ivy/staging/2.0.0-rc2/
>
> A maven 2 staging repo with this release is available here:
> http://people.apache.org/~maartenc/m2-staging-repo/
>
> A staging eclipse update site with this release is available here:
> http://people.apache.org/~maartenc/updatesite-staging/
> The bundle version is 2.0.0.cr2.
>
> Do you vote for the release of these binaries?
>

[X] Yes

+1

Xavier


>
> [ ] No
>
> Regards,
>
> Maarten Coene,
> Ivy 2.0.0-rc2 release manager
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Xavier Hanin - 4SH France
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/

Re: EasyAnt project

[Xavier Hanin]

On Wed, Oct 29, 2008 at 6:30 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On Tue, 28 Oct 2008, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > Your example would read just as well, if not better, written as
> > 
>
> I agree.  I think part of the reason for the name "phase" is that it
> is used to create a concept similar to Maven phases in EasyAnt.
> Still, we should choose names that make sense inside Ant IMHO.

I like the target-group name too, and I don't think it's a problem for the
EasyAnt project to use this name instead of phase.

Xavier

AW: Where next: 1.7.2 or 1.8.0?

[Jan.Materne]

>> Are there any defects so traumatic in Ant 1.7.1 that an urgent fix
>> is needed?
>
>traumatic is a strong word.  See yourself
>&component=Other&component=Wrapper+scripts&target_
milestone=1.8
>.0&long_desc_type=substring&long_desc=&bug_file_loc_type=substr
ing&bug_file_loc=&keywords_type=anywords&keywords=&bug_status=RESOLVED&b
ug_status=CLOSED&resolution=FIXED&emailassigned_to1=1&emailtype1=substri
ng&email1>=&emailreporter2=1&emailtype2=substring&email2=&bugidtype=incl
u
de&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&
order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0
-0-0=>
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 is an
>important one for Mac users since Apple decided to use funny symlinks
>in JAVA_HOME.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=45194 is a deadlock
>in logging code.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=45675 is a bit
>silly but makes Ant 1.7.x unusable for certain projects.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=42389 is 
>serious IMHO,
>but then again it has been in there since 1.7.0 and we didn't get that
>many complaints.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=44889 will become
>more important over time.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=43892 makes Ant
>misreport failures for JUnit4 tests.
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=42275 has been
>mentioned on the user list a couple of times.
>
>DirectoryScanner's speed improvements.
>
>I'm not too eager on merging myself.


Basically I would prefer a release earlier than the last time.
1.7.1 was released on 2008.06.27, so we could wait if there are no
urgent fixes.

I havent a look at these fixes yet ...


Jan

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

bootstrap error

[Matt Benson]

Has anyone else ever seen a problem with "duplicate
class" errors (on optional tasks, seemingly) during
the compilation "phase" ;) of a bootstrap build?

Thanks,
Matt


  

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

Re: EasyAnt project

[Jean-Louis BOUDART]

>
> FWIW, I'm not fond of the "phase" name either. What you describe is
> better described as a target-group, with any target being able to join
> the group at will, and where there's no implicit intra-group
> dependencies, and no "body" to the target-group (i.e. the group is
> "abstract" in a way).


I like the target-group name too :)
I think  should only depend on another 




 Just as you seem to propose, I'd be in favor of requiring your 
> or my  to be explicitly declared before it can be
> referenced. This would avoid typos implicitly creating groups
> unbeknown to the build writer / fat fingered individual ;-)

I agree, we must declared it explicitly!


Just Stefan pocking gentle fun at me, because I vehemently argued for
> what you propose when import was introduced. If you look back at the
> archives, I was strongly against using the import*ed* build file name
> in the import*er*, as it needlessly coupled the two, when good
> compartmentalization is essential to flexible and scalable designs (I
> even proposed the ability of the import*er* to give its own prefix as
> well). I also argued for separate import/include, just like in XSLT.
> In both cases my objections were ignored. So it's interesting that a
> separate group of Frenchmen now wants these same changes in Ant.

Is this a French invasion ? :p


 When I argue what I believe is the right way to do something, and my
> point is being dismissed in favor of a lesser design (at least to me),
> this typically leaves me frustrated. Stefan "remue le couteau dans la
> plaie" comme on dit chez nous ;-) --DD

Ok now i understand


2008/10/29 Stefan Bodewig <[EMAIL PROTECTED]>

> BTW, targets (and your phase variant of it) are not tasks.

My bad, i wanted to write "abstract target" but my fingers has wrotten
something different. Maybe i've taken too much coffee yesterday.
(Interresting my fingers can write something different of i'm thinking
about... )

 I like Dominique's target group more than the name "phase".  And I
> understand that EasyAnt builds on the Maven concept to make things
> easier for users switching.  Without EasyAnt, the name would be a bad
> choice inside Ant.

There is no problem to rename "phase" concept in "target-group".
I think as you said target group is more self-explicit.


We'll probably need support and feedback on others modifications/concept on
EasyAnt that could be included in ant or ivy.
For example we need :
- to add "visibility" feature on target (something close to private /
public) (ant related)
As we want to introduce prefix on some kind of import it could be nice to
have a way to display only "public" target when you type "ant -p".
And to provide a way to see All targets (public / private) when we type "ant
myPrefix -p" that should display all the targets available for the import
we've called "myPrefix".

-  to provide support for parent module (ivy related)
This is probably close to this issue
https://issues.apache.org/jira/browse/IVY-742
Even if i think support for parent module is not only related "dependency".
We could imagine that parent support allow you to inherit dependencies /
configurations / licences / homeurl / etc ...?


What do you think about that?

Cheers!

Re: EasyAnt project

[Matt Benson]

--- Xavier Hanin <[EMAIL PROTECTED]> wrote:

> On Wed, Oct 29, 2008 at 6:30 AM, Stefan Bodewig
> <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 28 Oct 2008, Dominique Devienne
> <[EMAIL PROTECTED]> wrote:
> >
> > > Your example would read just as well, if not
> better, written as
> > >  depends="...">
> >
> > I agree.  I think part of the reason for the name
> "phase" is that it
> > is used to create a concept similar to Maven
> phases in EasyAnt.
> > Still, we should choose names that make sense
> inside Ant IMHO.
> 
> I like the target-group name too, and I don't think
> it's a problem for the
> EasyAnt project to use this name instead of phase.

I am thinking a less invasive approach would be:

1.  Allow arbitrary properties of a Target object to
be set using IntrospectionHelper.
2.  Delegate Target instantiation to Project.
3.  Define an ant.project.class magic property to
easily allow the user to specify an extended Project
class to use.
4.  EasyAnt has its own Project, Target, and Executor
implementations that know about phases.

-Matt

> 
> Xavier
> 



  

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

Re: bootstrap error

[Stefan Bodewig]

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote:

> Has anyone else ever seen a problem with "duplicate
> class" errors (on optional tasks, seemingly) during
> the compilation "phase" ;) of a bootstrap build?

Not really.

Sounds as if you had a .java file in a place where it shouldn't be.  I
once had this when I placed a class in the wrong package and then
copied the file but forgot to remove the original one.

Current trunk bootstraps just fine for me.

Stefan

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

Re: bootstrap error

[Matt Benson]

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

> On Wed, 29 Oct 2008, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> 
> > Has anyone else ever seen a problem with
> "duplicate
> > class" errors (on optional tasks, seemingly)
> during
> > the compilation "phase" ;) of a bootstrap build?
> 
> Not really.
> 
> Sounds as if you had a .java file in a place where
> it shouldn't be.  I
> once had this when I placed a class in the wrong
> package and then
> copied the file but forgot to remove the original
> one.
> 
> Current trunk bootstraps just fine for me.
> 

I have several partially-completed changes in my
current workspace.  :(  Obviously I've hosed myself in
some way.  I'm starting fresh from trunk to isolate
the problem, but thought I'd ask just in case.

Thanks,
Matt

> 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: EasyAnt project

[Stefan Bodewig]

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote:

> I am thinking a less invasive approach would be:

Sounds good to me.

> 1.  Allow arbitrary properties of a Target object to
> be set using IntrospectionHelper.
> 2.  Delegate Target instantiation to Project.

Why?

I have a toy project that I hope to be pushing into the sandbox sooner
or later which contains a custom ProjectHelper.  It heavly relies on
the ProjectHelper to be able to create its own subclass of target.

> 3.  Define an ant.project.class magic property to
> easily allow the user to specify an extended Project
> class to use.
> 4.  EasyAnt has its own Project, Target, and Executor
> implementations that know about phases.

If EasyAnt used a ProjectHelper of its own, it probably could get away
without a custom Project.  A custom Executor may be a good idea,
though.

EasyAnt would need its own wrapper script or an invocation would
become cumbersome, though.

Stefan

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

Re: EasyAnt project

[Matt Benson]

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

> On Wed, 29 Oct 2008, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> 
> > I am thinking a less invasive approach would be:
> 
> Sounds good to me.
> 
> > 1.  Allow arbitrary properties of a Target object
> to
> > be set using IntrospectionHelper.
> > 2.  Delegate Target instantiation to Project.
> 
> Why?

Precedent.  The Project instance is responsible for
creating its own subproject Project instances; this
seemed similar.

> 
> I have a toy project that I hope to be pushing into
> the sandbox sooner
> or later which contains a custom ProjectHelper.  It
> heavly relies on
> the ProjectHelper to be able to create its own
> subclass of target.
> 

I see; however let me ask you this:  which is more
straightforward, creating a custom ProjectHelper or
extending Project and/or Target?  I guess the answer
depends on how comfortable you are with the SAX APIs. 
Personally, for me, it's the latter.  Without tipping
your hand, can you give any more information about
what requirements drove you to implement your custom
ProjectHelper?

> > 3.  Define an ant.project.class magic property to
> > easily allow the user to specify an extended
> Project
> > class to use.
> > 4.  EasyAnt has its own Project, Target, and
> Executor
> > implementations that know about phases.
> 
> If EasyAnt used a ProjectHelper of its own, it
> probably could get away
> without a custom Project.  A custom Executor may be
> a good idea,
> though.
> 
> EasyAnt would need its own wrapper script or an
> invocation would
> become cumbersome, though.

How is a custom Project class(name) more cumbersome to
configure than a custom ProjectHelper?

br,
Matt

> 
> 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]

ProjectHelper (was Re: EasyAnt project)

[Stefan Bodewig]

hijacking a thread.

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote:

> I see; however let me ask you this: which is more straightforward,
> creating a custom ProjectHelper or extending Project and/or Target?
> I guess the answer depends on how comfortable you are with the SAX
> APIs.

Who said I was using SAX?  I'm not even using XML.  The main reason to
write it is to show that Ant doesn't need XML at all.

My "build file" is going to look like this (I'm making up half of it):

@Project(Name="example", DefaultTarget="echo")
public class BuildFile extends JavaFrontBuildFile {
public BuildFile(Project p) {
super(p);
}

@Target
public void echo() {
getProject().log("Hello world");
}

@Target(Name="-setproperty")
public void setProperty() {
taskBuilder().newProperty().withName("world").andValue("world")
  .execute();
}

@Target(Depends="-setproperty")
public void moreComplexExample() {
taskBuilder().newEcho().withMessage("Hello ${world}").execute();
}
}

My Target class extends Target and gets a Runnable in its constructor
which is then run in execute() (it completely ignores nested tasks).

Stefan

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

Re: EasyAnt project

[Stefan Bodewig]

On Wed, 29 Oct 2008, Matt Benson <[EMAIL PROTECTED]> wrote:

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

>> On Wed, 29 Oct 2008, Matt Benson
>> <[EMAIL PROTECTED]> wrote:

>> > 3.  Define an ant.project.class magic property to
>> > easily allow the user to specify an extended Project
>> > class to use.
>> > 4.  EasyAnt has its own Project, Target, and Executor
>> > implementations that know about phases.
>> 
>> If EasyAnt used a ProjectHelper of its own, it probably could get
>> away without a custom Project.  A custom Executor may be a good
>> idea, though.
>> 
>> EasyAnt would need its own wrapper script or an invocation would
>> become cumbersome, though.
> 
> How is a custom Project class(name) more cumbersome to
> configure than a custom ProjectHelper?

Not at all, sorry, I didn't mean to say that.  EasyAnt would need a
wrapper anyway in order to configure Project class/ProjectHelper,
Target class and Executor.

Stefan

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

Re: ProjectHelper (was Re: EasyAnt project)

[Matt Benson]

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

> hijacking a thread.
> 
> On Wed, 29 Oct 2008, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> 
> > I see; however let me ask you this: which is more
> straightforward,
> > creating a custom ProjectHelper or extending
> Project and/or Target?
> > I guess the answer depends on how comfortable you
> are with the SAX
> > APIs.
> 
> Who said I was using SAX?  I'm not even using XML. 

Touche.  :)

> The main reason to
> write it is to show that Ant doesn't need XML at
> all.
> 
> My "build file" is going to look like this (I'm
> making up half of it):
> 
> @Project(Name="example", DefaultTarget="echo")
> public class BuildFile extends JavaFrontBuildFile {
> public BuildFile(Project p) {
> super(p);
> }
> 
> @Target
> public void echo() {
> getProject().log("Hello world");
> }
> 
> @Target(Name="-setproperty")
> public void setProperty() {
>
>
taskBuilder().newProperty().withName("world").andValue("world")
>   .execute();
> }
> 
> @Target(Depends="-setproperty")
> public void moreComplexExample() {
> taskBuilder().newEcho().withMessage("Hello
> ${world}").execute();
> }
> }
> 
> My Target class extends Target and gets a Runnable
> in its constructor
> which is then run in execute() (it completely
> ignores nested tasks).

This looks like it's friends with my concept of an Ant
DSL except mine is pretty much just a de-XMLization of
the status quo, no OO stuff as you show above.  But
there's no telling when I'll get around to finishing
that.  :(

Okay, what say we move the Project instantiation to
ProjectHelper then, so that custom ProjectHelpers can
influence the Project class used if needed?  This
still doesn't alleviate the problem that EasyAnt will
need a little custom configuration to install the
ProjectHelper and, probably, an Executor.  But these
are both handled with system properties, so this could
either be done with hook scripts or an EasyAnt Main
class that calls Ant Main after setting the necessary
properties.

-Matt

> 
> 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: ivy settings classpath always creates new classloader when used with subant

[Derek Baum]

Hi Gilles,

I have been unsuccessful in changing my buildscript in order to have the 
ivysettings defined only once.


Am I doing something wrong, or should I raise Jira to change the 
behaviour of ivysetting/classpath?


Thanks,

Derek

Derek Baum wrote:

Hi,

Thanks for your response.

Are you suggesting:

1) if I satisfy the prerequisite,  then I won't need my suggested 
patch, or

2) my patch will only work if the prerequisite is satisfied?

Assuming 1), I tried this, but when I didn't explicitly load 
ivysettings, a default was loaded instead and the build failed.


Here's my subant target for the example multi-project/build.xml:

  description="compile, jar and publish all projects in the 
right order">


  

  

  


Here's the Ivy taskdef:










and here's the build output, notice the loading of default settings in 
new-ivy-version:



[multi-project]$ ant publish-all
Buildfile: build.xml

load-ivy:
 [echo] Loading Ivy ...

buildlist:
[ivy:buildlist] :: Ivy 2.0.0-rc1 - 20080916082609 :: 
http://ant.apache.org/ivy/ ::
:: loading settings :: file = 
/Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/common/ivysettings.xml 



publish-all:

clean-build:
   [delete] Deleting directory 
/Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build 



load-ivy:

ivy-new-version:
No ivy:settings found for the default reference 'ivy.instance'.  A 
default instance will be used

no settings file found, using default...
:: loading settings :: url = 
jar:file:/opt/apache-ivy-2.0.0-rc1/ivy-2.0.0-rc1.jar!/org/apache/ivy/core/settings/ivysettings.xml 



version:
[mkdir] Created dir: 
/Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build/classes 



I therefore had to change the load-ivy target to always define 
ivysettings:


   
   
   

which is why I concluded that a change to the ivysettings/classpath 
command was needed.


Thanks,

Derek



Gilles Scokart wrote:

There will be a prerequisite for that to work : You must be sure that
that ivy itself is not loaded in two ClassLoader.  For that, your
taskdef for ivy should itself use a loaderRef, and the subant must
have the right options that make the id shared accross the projects.

And if that prerequisite is valid, in most case you can arrange your
buildscript in order to have the ivysettings defined only once.



2008/10/16 Derek Baum <[EMAIL PROTECTED]>:
 

Hi,

I have a custom Ivy resolver that keeps a static cache because it is
time-consuming to initialise.

However, this cache doesn't work in a multi-project build, because the
ivysettings/classpath command is creating a new URLClassLoader for each
subant iteration, so all static class fields are reset.



 

 classname="org.cauldron.bld.ivy.SigilResolver" />


 ...




I'm building multiple projects, using ivy:buildlist and subant, as 
in the

Ivy multi-project example.

Each iteration of subant, causes IvySettings to reload.
IvySettings.classloader is thus null and so a new URLClassLoader is 
created.


I temporarily worked around this by loading my plugin at the same 
time as

Ivy (i.e. not using settings/classpath), but I'd really like the
setting/classpath method to work too.

One possible solution would be to add a "loaderRef" attribute to
settings/classpath, similar to the Ant taskdef/typedef tasks, to 
make it use

the same ClassLoader.

Alternatively, IvySettings could simply be changed to only create a new
URLClassLoader if the list of URLs  has changed. I attach a simple 
patch to

IvySettings.java that does this and seems to work OK.

If this is valid and useful, let me know and I'll raise it in Jira.

Thanks,

Derek














Index: src/java/org/apache/ivy/core/settings/IvySettings.java
===
--- src/java/org/apache/ivy/core/settings/IvySettings.java  
(revision

705243)
+++ src/java/org/apache/ivy/core/settings/IvySettings.java  
(working

copy)
@@ -644,13 +644,19 @@
}
}

+private static Map loaderCache =  new HashMap();
+
private ClassLoader getClassLoader() {
if (classloader == null) {
if (classpathURLs.isEmpty()) {
classloader = Ivy.class.getClassLoader();
} else {
-classloader = new URLClassLoader((URL[]) classpathURLs
+classloader = (ClassLoader) 
loaderCache.get(classpathURLs);

+if (classloader == null) {
+classloader = new URLClassLoader((URL[]) 
classpathURLs

.toArray(new URL[classpathURLs.size()]),
Ivy.class.getClassLoader());
+loaderCache.put(classpathURLs, classloader);
+}
}
}
return classloader;


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

Re: svn commit: r708930 - /ant/core/trunk/src/main/org/apache/tools/ant/Target.java

[Dominique Devienne]

On Wed, Oct 29, 2008 at 11:27 AM,  <[EMAIL PROTECTED]> wrote:
> allow custom propertyhelpers to supply a Boolean for Target if/unless as an 
> alternative to specifying a property NAME
>
> Modified:
>ant/core/trunk/src/main/org/apache/tools/ant/Target.java
>
> ==
> --- ant/core/trunk/src/main/org/apache/tools/ant/Target.java (original)
> +++ ant/core/trunk/src/main/org/apache/tools/ant/Target.java Wed Oct 29 
> 09:27:00 2008
> @@ -347,30 +347,32 @@
> public void execute() throws BuildException {
> +if (!testIfAllows()) {
> project.log(this, "Skipped because property '" + 
> project.replaceProperties(ifCondition)
> + "' not set.", Project.MSG_VERBOSE);
...
> +if (!testUnlessAllows()) {
> project.log(this, "Skipped because property '"
> + project.replaceProperties(unlessCondition) + "' set.", 
> Project.MSG_VERBOSE);

The message is still using project.replaceProperties

> @@ -425,7 +427,7 @@
> +PropertyHelper propertyHelper = 
> PropertyHelper.getPropertyHelper(getProject());
> +Object o = propertyHelper.parseProperties(ifCondition);
> +if (o instanceof Boolean) {
> +return ((Boolean) o).booleanValue();
> +}
> +return propertyHelper.getProperty(String.valueOf(o)) != null;

while the tests themselves no longer use project.replaceProperties,
but a different logic and possibly parsing.

So assuming a PropertyHelper accepts if="${verbose}==true" and returns
a Boolean when the verbose property looks like a boolean (on/off,
true/false, yes/no), and in this case verbose is no, then the verbose
log will read:

Skipped because property 'no==true' not set.

Which will be confusing. Sure, this is made up (I don't really know
when a PH will return a Boolean. Any example?), but I'm just trying to
point out there's a disconnect now between the evaluation of the
condition, and the verbose logging on that condition.

I'm not too sure how to "fix" it either. --DD

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

Re: svn commit: r708930 - /ant/core/trunk/src/main/org/apache/tools/ant/Target.java

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On Wed, Oct 29, 2008 at 11:27 AM, 
> <[EMAIL PROTECTED]> wrote:
> > allow custom propertyhelpers to supply a Boolean
> for Target if/unless as an alternative to specifying
> a property NAME
> >
> > Modified:
> >   
>
ant/core/trunk/src/main/org/apache/tools/ant/Target.java
> >
> >
>
==
> > ---
>
ant/core/trunk/src/main/org/apache/tools/ant/Target.java
> (original)
> > +++
>
ant/core/trunk/src/main/org/apache/tools/ant/Target.java
> Wed Oct 29 09:27:00 2008
> > @@ -347,30 +347,32 @@
> > public void execute() throws BuildException {
> > +if (!testIfAllows()) {
> > project.log(this, "Skipped because
> property '" + project.replaceProperties(ifCondition)
> > + "' not set.",
> Project.MSG_VERBOSE);
> ...
> > +if (!testUnlessAllows()) {
> > project.log(this, "Skipped because
> property '"
> > +
> project.replaceProperties(unlessCondition) + "'
> set.", Project.MSG_VERBOSE);
> 
> The message is still using project.replaceProperties
> 
> > @@ -425,7 +427,7 @@
> > +PropertyHelper propertyHelper =
> PropertyHelper.getPropertyHelper(getProject());
> > +Object o =
> propertyHelper.parseProperties(ifCondition);
> > +if (o instanceof Boolean) {
> > +return ((Boolean) o).booleanValue();
> > +}
> > +return
> propertyHelper.getProperty(String.valueOf(o)) !=
> null;
> 
> while the tests themselves no longer use
> project.replaceProperties,
> but a different logic and possibly parsing.
> 
> So assuming a PropertyHelper accepts
> if="${verbose}==true" and returns
> a Boolean when the verbose property looks like a
> boolean (on/off,
> true/false, yes/no), and in this case verbose is no,
> then the verbose
> log will read:
> 
> Skipped because property 'no==true' not set.
> 
> Which will be confusing. Sure, this is made up (I
> don't really know
> when a PH will return a Boolean. Any example?), but
> I'm just trying to
> point out there's a disconnect now between the
> evaluation of the
> condition, and the verbose logging on that
> condition.

Here's an example of use:




  

  

  

  

  
ifMe
  

  
unlessMe
  




I'll make the message a little better tomorrow, sorry
for that.

-Matt


> 
> I'm not too sure how to "fix" it either. --DD
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  

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

Re: svn commit: r708930 - /ant/core/trunk/src/main/org/apache/tools/ant/Target.java

[Dominique Devienne]

On Wed, Oct 29, 2008 at 5:38 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Here's an example of use:

Thanks for the example. I can't say I like the syntax that much, for
the reason that it's not obvious you're crossing the "normal Ant"
line, to go into "locally customized Ant" land. With XSLT for example,
when you use a custom function, you typically notice the non-standard
function from the function's XML namespace prefix. Here, you don't
really know what's going on unless you have intimate knowledge on how
the build was put together, which PtyLpr is/are in effect, etc... I
guess you don't even know which PtyLpr will do the evaluation if there
are several of them. tough to follow... --DD

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