Re: IvyDE sources

[Xavier Hanin]

On Jan 7, 2008 1:59 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:

> On Jan 7, 2008 12:59 PM, Nicolas Lalevée <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > The IvyDE sources are not very patch friendly because of the space vs
> > tabs indentation and the missing svn:eol-style property. The following
> > command just return nothing within the IvyDE trunk.
> > find . -iname "*.java" -exec svn pl {} \;
> >
> > So could a developer make a big "Format" on every IvyDE sources and
> > add the proper "native" value to the svn:eol-style property ?
> > I looked into Jira, the only available patch is IVYDE-43, which is
> > outdated because it is against IvyDE 1.2. So I think it is a good time
> > to do it.
>
> You're absolutely right. I'll try to do it in the coming days.
>
Done, sorry for the delay.

Xavier


>
> Xavier
>
>
> >
> > cheers,
> > Nicolas
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/




-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

"Dominique Devienne" <[EMAIL PROTECTED]> writes:

> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> "Gilles Scokart" <[EMAIL PROTECTED]> writes:
>>
>> > I never thought to overwrite macro to customize a generic build script.  
>> > Can
>> > macro be overwritten?
>>
>> Sure, it's just another Ant task that has been defined.
>
> But my point is that most of the time, you never want to override
> things (macros or target), but augment them with some kind of pre or
> post processing.

Hey, I didn't say it was a good thing to do, I just pointed out that
technically you can override a macrodef'ed task just like any other
task.

> Peo's point of simply copy-pasting the "abstract" build code to
> fully override the target duplicates that code, and makes build
> maintenance all the more difficult.

I'm not convinced that we need something like this at the task level,
while I agree we need some better support for it at the target level.

Back during the Ant2 discussions we have been talking about adding AOP
like features to Ant at a well-defined "pointcut"s like target and
task invactions.  This may be overkill, though.

Having something like before/after/around advices (where around is the
same as an override that doesn't change the dependencies list) may
suffice and leave overwriting the whole target definition to the worst
case.

Stefan

-- 
http://stefan.samaflost.de/

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

Re: IvyDE sources

[Nicolas Lalevée]

Le lundi 14 janvier 2008, Xavier Hanin a écrit :
> On Jan 7, 2008 1:59 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2008 12:59 PM, Nicolas Lalevée
> > <[EMAIL PROTECTED]>
> >
> > wrote:
> > > Hi,
> > >
> > > The IvyDE sources are not very patch friendly because of the space vs
> > > tabs indentation and the missing svn:eol-style property. The following
> > > command just return nothing within the IvyDE trunk.
> > > find . -iname "*.java" -exec svn pl {} \;
> > >
> > > So could a developer make a big "Format" on every IvyDE sources and
> > > add the proper "native" value to the svn:eol-style property ?
> > > I looked into Jira, the only available patch is IVYDE-43, which is
> > > outdated because it is against IvyDE 1.2. So I think it is a good time
> > > to do it.
> >
> > You're absolutely right. I'll try to do it in the coming days.
>
> Done, sorry for the delay.

Well, thank you to take time to do it. :)

Nicolas

> > Xavier
> >
> > > cheers,
> > > Nicolas
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/



-- 
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Dominique Devienne]

On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Dominique Devienne" <[EMAIL PROTECTED]> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target definition to the worst
> case.

Thanks for reminding me of this issue Stefan. Indeed, something I
really didn't like about overriding the whole target, is that you had
to duplicate the dependency list as well...

Which is why I now remember that I now remember I used 4, not 3
targets, in the "abstract" build, the forth one being the target's own
content, separate from its dependency list:

So every concrete simple target like  became


 ... 



in the "abstract" build. Override -foo to replace just the target
content, without it's dependency list. Or override foo to have
complete control, but in my experience it's -foo that needed
overriding, not foo.

Note though that unlike before and after, around isn't as
representative a name. When I thought about this issue a while back, I
thought of using a magic name such as "super" in the depends attribute
to refer to the overridden target's dependency list, similar to using
 in the target's body to refer to the overridden target's task
list/content. --DD

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Reilly]

Why not have something simple like having a "before" and "after" attributes to
the  element.


...
  

   
  
   


  
 
   




Peter

On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > So every concrete simple target like  became
> >
> > 
> >  ... 
> > 
> > 
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> 
> 
>   
> 
>
> 
>   
> 
>   
> 
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> 
>   
>  before original foo ..
>
> 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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Xavier Hanin]

On Jan 14, 2008 5:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:

> > So every concrete simple target like  became
> >
> > 
> >  ... 
> > 
> > 
>
> This looks pretty ugly this me!

If I understand correctly, that's exactly what Dominique complained about
:-)

>
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> 
> 
>  
> 
>
> 
>  
>
>  
> 
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> 
>  
> before original foo ..
>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Wolfgang Häfelinger]

> So every concrete simple target like  became
> 
> 
>  ... 
> 
> 

This looks pretty ugly this me!

I believe that this whole discussion focusses too much on targets 
instead of macros. Macros are a very powerfull feature and they
deserve much more attention!

Why not simply:



   



  

  



If a user then really need to override "foo", he or she would simply
write in build.xml something like



  
 before original foo ..
 
   

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Dominique Devienne]

On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Why not have something simple like having a "before" and "after" attributes to
> the  element.

This is indeed something we discussed and proposed earlier in the
thread. (except I envisioned the before/after to be used instead of
the name attribute, although giving a more explicit name to the target
is a good optional think I now realize, and is independent of the
target being "injected" into the dependency chain at the correct
place).

But is it that simple? If you have several such before/after targets,
what order are they executed in? What is they are spread into several
files? And if you give them names, do these before/after targets
themselves become override-able?

Even this simple (very desirable!) feature can get hairy when one digs
a little before the surface. --DD

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Wolfgang Häfelinger]

Assume also:

   
  
   

Do you want this before your "start-server" or after it or 
in parallel?

And you you need to extend Ant with "before" and "after" of
course.


Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
[EMAIL PROTECTED]
http://www.epo.org




"Peter Reilly" <[EMAIL PROTECTED]> 
14-01-2008 17:52
Please respond to
"Ant Developers List" 


To
"Ant Developers List" 
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java 
projects






Why not have something simple like having a "before" and "after" 
attributes to
the  element.


...
  

   
  
   


  
 
   




Peter

On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > So every concrete simple target like  became
> >
> > 
> >  ... 
> > 
> > 
>
> This looks pretty ugly this me!
>
> I believe that this whole discussion focusses too much on targets
> instead of macros. Macros are a very powerfull feature and they
> deserve much more attention!
>
> Why not simply:
>
> 
> 
>   
> 
>
> 
>   
> 
>   
> 
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> 
>   
>  before original foo ..
>
> 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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Reilly]

On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> Assume also:
>
>
>   
>
>
> Do you want this before your "start-server" or after it or
> in parallel?
>

I would say that if the build file does not specify the order, then the order
is undefined.

If the order is important, then the build file can enforce an order by
using "depends".


   


Peter
> And you you need to extend Ant with "before" and "after" of
> course.
>
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> [EMAIL PROTECTED]
> http://www.epo.org
>
>
>
>
> "Peter Reilly" <[EMAIL PROTECTED]>
> 14-01-2008 17:52
>
> Please respond to
> "Ant Developers List" 
>
>
> To
> "Ant Developers List" 
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> Why not have something simple like having a "before" and "after"
> attributes to
> the  element.
>
> 
> ...
>   
>
>
>   
>
>
>
>   
>  
>
>
>
> 
>
> Peter
>
> On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > > So every concrete simple target like  became
> > >
> > > 
> > >  ... 
> > > 
> > > 
> >
> > This looks pretty ugly this me!
> >
> > I believe that this whole discussion focusses too much on targets
> > instead of macros. Macros are a very powerfull feature and they
> > deserve much more attention!
> >
> > Why not simply:
> >
> > 
> > 
> >   
> > 
> >
> > 
> >   
> > 
> >   
> > 
> >
> >
> > If a user then really need to override "foo", he or she would simply
> > write in build.xml something like
> >
> >
> > 
> >   
> >  before original foo ..
> >
> > > 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]
>
>

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Reilly]

On Jan 14, 2008 5:24 PM, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > Assume also:
> >
> >
> >   
> >
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>

This would be similar to the @Before and @After annotations in junit.
Peter

> If the order is important, then the build file can enforce an order by
> using "depends".
>
> 
>
> 
>
> Peter
>
> > And you you need to extend Ant with "before" and "after" of
> > course.
> >
> >
> > Regards,
> >
> > Wolfgang Häfelinger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. +31 (0)70 340 4931
> > [EMAIL PROTECTED]
> > http://www.epo.org
> >
> >
> >
> >
> > "Peter Reilly" <[EMAIL PROTECTED]>
> > 14-01-2008 17:52
> >
> > Please respond to
> > "Ant Developers List" 
> >
> >
> > To
> > "Ant Developers List" 
> > cc
> >
> > Subject
> > Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> > projects
> >
> >
> >
> >
> >
> >
> > Why not have something simple like having a "before" and "after"
> > attributes to
> > the  element.
> >
> > 
> > ...
> >   
> >
> >
> >   
> >
> >
> >
> >   
> >  
> >
> >
> >
> > 
> >
> > Peter
> >
> > On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > > > So every concrete simple target like  became
> > > >
> > > > 
> > > >  ... 
> > > > 
> > > > 
> > >
> > > This looks pretty ugly this me!
> > >
> > > I believe that this whole discussion focusses too much on targets
> > > instead of macros. Macros are a very powerfull feature and they
> > > deserve much more attention!
> > >
> > > Why not simply:
> > >
> > > 
> > > 
> > >   
> > > 
> > >
> > > 
> > >   
> > > 
> > >   
> > > 
> > >
> > >
> > > If a user then really need to override "foo", he or she would simply
> > > write in build.xml something like
> > >
> > >
> > > 
> > >   
> > >  before original foo ..
> > >
> > > > > 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]
> >
> >
>

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Dominique Devienne]

On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > Assume also:
> >
> >
> >   
> >
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> 
>
> 

It makes sense Peter. And this already works in Ant, provided we add
before/after support to .

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --DD

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Wolfgang Häfelinger]

> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

Ok, I'm not a committer - anyhow:

I disagree cause you can do the very same thing just with Macros. 
No need for new target attributes.

> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

This must be the soul of this whole upcoming framework. It's an
absolutley must.





Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
[EMAIL PROTECTED]
http://www.epo.org




"Dominique Devienne" <[EMAIL PROTECTED]> 
14-01-2008 18:39
Please respond to
"Ant Developers List" 


To
"Ant Developers List" 
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java 
projects






On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> 
wrote:
> > Assume also:
> >
> >
> >   
> >
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the 
order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> 
>
> 

It makes sense Peter. And this already works in Ant, provided we add
before/after support to .

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Reilly]

On Jan 14, 2008 5:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > > Assume also:
> > >
> > >
> > >   
> > >
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the 
> > order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> > 
> >
> > 
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to .

Opps, I just read the previous e-mails, and yes you have proposed this
syntax!.

>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?


>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

This is the  syntax?
I am a little dubious, but could be swayed.

Peter
>
> Both questions above are independent of using overriding macros... --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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Wolfgang Häfelinger]

> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

Dominique and Peter,

could you please explain why you see a need for target attributes "before" 
and "after" rather
than following the Macro path I proposed? 

Regards,

Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
[EMAIL PROTECTED]
http://www.epo.org




"Dominique Devienne" <[EMAIL PROTECTED]> 
14-01-2008 18:39
Please respond to
"Ant Developers List" 


To
"Ant Developers List" 
cc

Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java 
projects






On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> 
wrote:
> > Assume also:
> >
> >
> >   
> >
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build file does not specify the order, then the 
order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> 
>
> 

It makes sense Peter. And this already works in Ant, provided we add
before/after support to .

Q1: Does everyone agree that adding before/after to target to Ant 1.8
is useful and should be done before (in conjunction of) creating
generic build files?

Q2: Do others feel (like me) that we should also have a mean to
override a target's content (task list) while keeping the overridden
target's dependency list?

Both questions above are independent of using overriding macros... --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]

DO NOT REPLY [Bug 18732] - expand properties during -propertyfile processing

[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=18732





--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 10:00 ---
At minimum, the Ant documentation should warn people that in-line property
expansion does not work when -propertyfile is used.

-- 
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: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Dominique Devienne]

On 1/14/08, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> could you please explain why you see a need for target attributes "before"
> and "after" rather than following the Macro path I proposed?

I guess because I think in terms of targets and not macros. I've used
macros, but to define new "tasks", not to control the structure of the
build itself. For that, targets and dependencies are the building
blocks IMHO.

At this point I don't understand the macro approach that you advocate,
and even if it worked, I'd argue that it may not be the "natural" way
to add the flexibility we have been discussing about. Could very well
be that I'm wrong, but at this point it's my thinking.

The fact that your macro approach to extensibility works without
changes to Ant is nice but not a strong-enough point to me, if it
feels less natural that the before/after target approach that would
require changes in Ant. I.e. I care more about the user friendliness
and doing it in a simple and natural way, than the implementation
details. --DD

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

Re: ProjectHelper : parsing from InputStream

[Benjamin de Dardel]

Hi all,

Matt Benson a écrit :

One concept that I had discussed with someone here
(Kev?  Alexey?) was some kind of resource that would
deliver a tempfile for another resource.  This might
work in simple situations.  

I didn't expect that my question would re-open this discussion.
I think that it's possible to add some new sources without changing 
everything.


In class ProjectHelper2, there are some other sources : InputStream and 
InputSource, but they were commented.
As you can see in attachment, I implemented the InputStream one without 
changing the API.


For the basedir problem, the current directory seems to be use as 
default and it can be updated with project.setBaseDir method.



It also occurs to me that
certain resources might themselves implement
ResourceFactory, e.g. files and urls, which can pretty
easily return a relative file.  A buildfile specifying
no basedir would, IMHO, seem to be fairly well
represented by a FileResource that, as a
ResourceFactory, would resolve relative paths against
".".  So that might provide some opportunities as
well.

  
Even if I'm interested in getting experience with ant, I don't have a 
global comprehension of the problem, as you have. So, I will follow this 
discussion and may be I will be abble to help you !


Regards,
Benjamin


-Matt
  


ant-helper.tgz
Description: application/compressed-tar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fwd: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Markus M. May]

Hello,

I have build a large automatic and generic build system using ANT.
This build system got very complex, especially due to dependencies.

I definitly do like the before/after approach, but the already
suggested depends usage will add another step of complexity.
Furthermore, up until now, I thought, that there is no guarantee, in
which order the depends targets will be executed, am I wrong here?

R,

Markus

Zitat von Dominique Devienne <[EMAIL PROTECTED]>:


On 1/14/08, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:

> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

could you please explain why you see a need for target attributes "before"
and "after" rather than following the Macro path I proposed?


I guess because I think in terms of targets and not macros. I've used
macros, but to define new "tasks", not to control the structure of the
build itself. For that, targets and dependencies are the building
blocks IMHO.

At this point I don't understand the macro approach that you advocate,
and even if it worked, I'd argue that it may not be the "natural" way
to add the flexibility we have been discussing about. Could very well
be that I'm wrong, but at this point it's my thinking.

The fact that your macro approach to extensibility works without
changes to Ant is nice but not a strong-enough point to me, if it
feels less natural that the before/after target approach that would
require changes in Ant. I.e. I care more about the user friendliness
and doing it in a simple and natural way, than the implementation
details. --DD

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







- Ende der weitergeleiteten Nachricht -


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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Xavier Hanin]

On Jan 14, 2008 6:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]>
> wrote:
> > > Assume also:
> > >
> > >
> > >   
> > >
> > >
> > > Do you want this before your "start-server" or after it or
> > > in parallel?
> > >
> >
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> > 
> >
> > 
>
> It makes sense Peter. And this already works in Ant, provided we add
> before/after support to .
>
> Q1: Does everyone agree that adding before/after to target to Ant 1.8
> is useful and should be done before (in conjunction of) creating
> generic build files?

I agree, this seems easily understandable (even though when used in
conjunction with depends it may seem a bit complex, but this shouldn't be
needed very often) and use the usual Ant building blocks.

>
>
> Q2: Do others feel (like me) that we should also have a mean to
> override a target's content (task list) while keeping the overridden
> target's dependency list?

I do. And also add the  element you were talking about.

Xavier


>
>
> Both questions above are independent of using overriding macros... --DD
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Guntis Ozols]

> > > > Assume also:
> > > >
> > > >
> > > >   
> > > >
> > > >
> > > > Do you want this before your "start-server" or after it or
> > > > in parallel?
> > > >
> > >
> > > I would say that if the build file does not specify the order,
> > > then the order is undefined.

maybe document order and import tree can be used to define that order?

> > > If the order is important, then the build file can enforce an order by
> > > using "depends".
> > >
> > > 
> > >
> > > 
> >
> > It makes sense Peter. And this already works in Ant, provided we add
> > before/after support to .
> >
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't
> be needed very often) and use the usual Ant building blocks.
>
> >
> >
> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the  element you were talking about.
>
> Xavier

a) override="both"
b) override="content"
c) warn otherwise!

Guntis


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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

"Dominique Devienne" <[EMAIL PROTECTED]> writes:

> On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> "Dominique Devienne" <[EMAIL PROTECTED]> writes:
>> Having something like before/after/around advices (where around is the
>> same as an override that doesn't change the dependencies list) may
>> suffice and leave overwriting the whole target definition to the worst
>> case.
>
> Thanks for reminding me of this issue Stefan. Indeed, something I
> really didn't like about overriding the whole target, is that you had
> to duplicate the dependency list as well...
>
> Which is why I now remember that I now remember I used 4, not 3
> targets, in the "abstract" build, the forth one being the target's own
> content, separate from its dependency list:

I get away with two, but don't get the nice names you use.


...

and my overriding targets depend on the imported targets to get in the
correct place in the dependency chain.  I.e. a -post-foo target as you
use it would be

...

> Note though that unlike before and after, around isn't as
> representative a name.

In my case the names come from their usage in Common Lisp so they do
have some precedent.  I agree that around doesn't really describe what
it does.

> When I thought about this issue a while back, I thought of using a
> magic name such as "super" in the depends attribute to refer to the
> overridden target's dependency list, similar to using  in
> the target's body to refer to the overridden target's task
> list/content.

I don't have any problem with super as a magic target name, but I'm
still not convinced of .  Hmm, maybe we should spawn of
separate threads for the different topics.

 must in some way be taken into account when setting up the
dependency graph of the whole build file which makes it a different
beast from normal tasks.  With before and after attributes on target
you wouldn't need  anymore.

Stefan
-- 
http://stefan.samaflost.de/

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

Wolfgang Häfelinger <[EMAIL PROTECTED]> writes:

> Why not simply:
>
> 
> 
>
> 
>
> 
>   
> 
>   
> 
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
> 
>   
>  before original foo ..
>  
>

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

"Markus M. May" <[EMAIL PROTECTED]> writes:

> I definitly do like the before/after approach, but the already
> suggested depends usage will add another step of complexity.

Not sure which part of the depends uage you mean.

When overriding a target we generally have two different use cases

a) I want to override the target but keep its dependencies
b) I want to override the target and use my own depends list

and we should provide mechanisms to do either easily.  Today only (b)
can be done without special constructs in the imported build file.

> Furthermore, up until now, I thought, that there is no guarantee, in
> which order the depends targets will be executed, am I wrong here?

Yes, you are.

Targets in the depends list that are independent of each other are
executed left to right.

Stefan

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Stefan Bodewig]

"Peter Reilly" <[EMAIL PROTECTED]> writes:

> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
> 
>
> 

One thing we are not taking into account is the plugin approach that
is part of Xavier's initial EasyAnt vision.

If our base build file contains a compile target and several "plugins"
that I want to use need to do stuff before the compile target then we
need a way to have a defined order.  In the order my build file
requires the plugins, I guess.

Do we revert the order for after targets so the first one declared
gets executed last?

Also we will need to define how before/after an complete overriding of
targets interact.  Do before/after apply to the new definition of the
target or are they dropped?

Stefan

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

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

[Peter Arrenbrecht]

On Jan 14, 2008 9:37 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 6:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> I agree, this seems easily understandable (even though when used in
> conjunction with depends it may seem a bit complex, but this shouldn't be
> needed very often) and use the usual Ant building blocks.

I agree. Feels much more natural than macros.

> > Q2: Do others feel (like me) that we should also have a mean to
> > override a target's content (task list) while keeping the overridden
> > target's dependency list?
>
> I do. And also add the  element you were talking about.

I agree. For what it's worth, I think we should also have a means to
externally trigger just the body of a task (mainly during build script
debugging). I normally do

  tgt depend " -tgt"
  -tgt depend "@tgt-step1, @tgt-step2, ..."

Meaning I can call the building blocks @tgt-stepN from outside to
incrementally watch and refine their behaviour.

-peo

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