Return-Path: 
 <user-return-58544-apmail-ant-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-user-archive@www.apache.org
Received: (qmail 5489 invoked from network); 26 Oct 2006 07:06:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Oct 2006 07:06:51 -0000
Received: (qmail 53316 invoked by uid 500); 25 Oct 2006 04:57:31 -0000
Delivered-To: apmail-ant-user-archive@ant.apache.org
Received: (qmail 53277 invoked by uid 500); 25 Oct 2006 04:57:30 -0000
Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:user-unsubscribe@ant.apache.org>
List-Help: <mailto:user-help@ant.apache.org>
List-Post: <mailto:user@ant.apache.org>
List-Id: "Ant Users List" <user.ant.apache.org>
Reply-To: "Ant Users List" <user@ant.apache.org>
Delivered-To: mailing list user@ant.apache.org
Received: (qmail 53266 invoked by uid 99); 25 Oct 2006 04:57:30 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 21:57:30 -0700
X-ASF-Spam-Status: No, hits=0.6 required=10.0
	tests=NO_REAL_NAME
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [193.109.238.66] (HELO dnsinet.rzf-nrw.de) (193.109.238.66)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 21:57:17 -0700
Received: from z011100.bk.fin.local (z011104.bk.fin.local [172.18.101.140])
	by dnsinet.rzf-nrw.de (8.13.8/8.13.8) with ESMTP id k9P4urCD002391
	for <user@ant.apache.org>; Wed, 25 Oct 2006 06:56:53 +0200
Received: from z011134.bk.fin.local ([130.11.7.134]) by z011100.bk.fin.local
 with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 25 Oct 2006 06:56:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: AW: dynamic targets
Date: Wed, 25 Oct 2006 06:56:53 +0200
Message-ID: <B07F6610DABEA8438092ED2058D7F16603E1EEA3@z011134.bk.fin.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: dynamic targets
Thread-Index: Acb34WFE9nZ0kQ/mQomVC/mVLO5PCQAECm9A
From: <Jan.Materne@rzf.fin-nrw.de>
To: <user@ant.apache.org>
X-OriginalArrivalTime: 25 Oct 2006 04:56:54.0504 (UTC)
 FILETIME=[FDDE9680:01C6F7F1]
X-Virus-Checked: Checked by ClamAV on apache.org

I think a failonerror (default=3Dtrue for bwc) would help and would be =
easily to implement.
So just =20

     <macrodef name=3D"m-iter">
         <attribute name=3D"target"/>
         <attribute name=3D"patternsetref"/>
         <sequential>
             <subant target=3D"@{target}" inheritAll=3D"false" =
failonerror=3D"false">
                 <fileset dir=3D".">
                     <patternset refid=3D"@{patternsetref}"/>
                 </fileset>
             </subant>
         </sequential>
     </macrodef>

should do the job?


Jan


>-----Urspr=FCngliche Nachricht-----
>Von: Jacob Kjome [mailto:hoju@visi.com]=20
>Gesendet: Mittwoch, 25. Oktober 2006 04:58
>An: Ant Users List
>Betreff: Re: AW: dynamic targets
>
>At 08:05 AM 10/24/2006, you wrote:
> >same - write a common buildfile (maybe with empty=20
>implementation) and all the  >projects have all needed=20
>targets. Web project could overwrite the  >target implementation.
> >
> >Jan
> >
>
>Yep, <import> is powerful and extremely useful and I use it=20
>all the time.  I tried to keep my example specific and=20
>concrete so as not to complicate the question.  But it seems=20
>to have caused the original point of this exercise to be=20
>entirely missed.
>
>Think of this in an OOP way.   You let other=20
>classes know what you are capable of by implementing=20
>interfaces.  There are a million things that you might be=20
>capable of doing, all represented by methods you might=20
>implement.  Do you implement all possible methods and, for 99%=20
>of the ones you aren't really capable of doing, you just=20
>report that you aren't capable of the method (by returning=20
>null, logging a message, or throwing an exception, etc...)? =20
>Or do you implement only the interfaces having the methods=20
>representing the capabilities you do have?  If you said "the=20
>former", please stop here.  No need to keep reading.  If you=20
>said "the latter", then you're still with me.  Read on....
>
>
>In other words, please don't focus on the "war"=20
>target.  That's an implementation
>detail.  Although I have a master build file, each individual=20
>build is entirely independent and need not have any knowledge=20
>that the master or=20
>any other builds exists.   It might be a very=20
>unique build that implements a "blahblah"=20
>target.  What those of you who have commented are telling me=20
>is that I should have every build implement a "blahblah"=20
>target simply because one unique build does.  Yes, I could=20
>have all builds import a common build with the "blahblah"=20
>target and the build that cares about it could override it,=20
>but that's conceptually ugly.
>
>Let me put it this way.   When I run the=20
>individual build with "ant -projecthelp", I want to see *ONLY*=20
>the targets that are actually implemented in the build.  Not=20
>10,000 other dummy targets imported from some common dummy=20
>build file.  If the only capabilities I have in a build are=20
>"clean" and "compile", then all I want is...
>
>C:\dev>ant -projecthelp
>Buildfile: build.xml
>
>Main targets:
>
>  clean
>  compile
>
>Other targets:
>
>Default target: compile
>
>
>I do *NOT* want...
>
>C:\dev>ant -projecthelp
>Buildfile: build.xml
>
>Main targets:
>
>  clean
>  compile
>
>Other targets:
>
>  blahblah
>  war
>  sometargetyoudontcareabout
>  yetanothertargetyoudontcareabout
>  isthisgettingoldyet
>  amidrivingthepointhome
>  maybeacouplemore
>  icouldkeepgoing
>  youthinkicant
>  doyoudoubledogdareme
>  okyougotitmister
>  imstillgoing
>  youaskedforitandyougotit
>  onemorejustforoldtimesake
>  wowthisisstartingtogetannoyingnow
>  yepreallyannoying
>  butforsomereasonijustcantstop
>  okillstop
>  justforyou
>  hehgotchastillgoing
>  okimsickofwriting
>  illstop
>
>Default target: compile
>
>
>Does that make it a bit more clear?
>
>The dynamic targets would be generated only if the target is=20
>called on the build and it doesn't exist.  And the use-case=20
>for this would be mass target calling using <subant> to tell=20
>all build files to run a particular target.  Rather than=20
>having individual build files have to implement a target only=20
>to tell the caller that they don't really perform the task, I=20
>want a target to by generated on the fly just to satisfy Ant=20
>in order to continue on without build failure.  And, again,=20
>this would allow my master build file to be really stupid and=20
>generic because it wouldn't have to know which builds=20
>implement a "war"=20
>target or a "blahblah" target.  It would just mass call the=20
>target on the individual projects.  And the individual=20
>projects wouldn't have to worry about being the one that=20
>bombed out the mass build by not implementing dummy targets,=20
>nor would they be forced to report that they perform tasks=20
>that they don't really perform.
>
>Dynamic target functionality could also make it so that I=20
>could have a really short master build file that takes=20
>whatever target is called on it and pass it on to all the=20
>other build files without the master target having to=20
>implement each mass build target, but have a common=20
>infrastructure for doing so.  For instance...
>
><project name=3D"Build_master">
>
>     Dynamic target gets generated based on what the user=20
>entered.  The dynamic target calls <m-iter/> with the target=20
>provided to Ant on the command line
>
>     <macrodef name=3D"m-iter">
>         <attribute name=3D"target"/>
>         <attribute name=3D"patternsetref"/>
>         <sequential>
>             <subant target=3D"@{target}" inheritAll=3D"false">
>                 <fileset dir=3D".">
>                     <patternset refid=3D"@{patternsetref}"/>
>                 </fileset>
>             </subant>
>         </sequential>
>     </macrodef>
>
>     The alternative to the description above using the=20
>dynamic targets is, for instance....
>
>     <target name=3D"jar">
>         <m-iter target=3D"jar" =
patternsetref=3D"subant.build.patternset"/>
>     </target>
>
>     <target name=3D"test">
>         <m-iter target=3D"test"=20
>patternsetref=3D"subant.build.patternset"/>
>     </target>
>
>     <target name=3D"war">
>         <m-iter target=3D"war" =
patternsetref=3D"subant.war.patternset"/>
>     </target>
>
>      etc.... for every possible top-level target implemented=20
>by all builds in question, as well as taking pains to define=20
>the patternsets for the different types of build types which=20
>perform certain tasks that others might not implement.
>
></project>
>
>
>I can't explain it any better than that.  I hope my point was=20
>made more clear.
>
>
>Jake
>
>
> >>-----Urspr=FCngliche Nachricht-----
> >>Von: Markus M. May [mailto:mmay@gmx.net]
> >>Gesendet: Dienstag, 24. Oktober 2006 09:13
> >>An: Ant Users List
> >>Betreff: Re: dynamic targets
> >>
> >>Hello Jacob,
> >>
> >>why don't you just import a common build file and define=20
>the  >>common target there. Only when the target is not=20
>defined in  >>the build file, the common target gets executed.
> >>
> >>R,
> >>
> >>Markus M. May
> >>-------- Original-Nachricht --------
> >>Datum: Mon, 23 Oct 2006 22:28:35 -0500
> >>Von: Jacob Kjome <hoju@visi.com>
> >>An: user@ant.apache.org
> >>Betreff: dynamic targets
> >>
> >>>
> >>> Along the lines of....
> >>> =
http://marc.theaimsgroup.com/?l=3Dant-user&m=3D107429941032345&w=3D2
> >>>
> >>> Is it possible to create targets dynamically, deferring =20
>>>creation until  >>> such time as it is found that the=20
>project doesn't have the target  >>> already defined?  My=20
>use-case is using <subant> to iterate over  >>> sub-builds=20
>calling a target on each one.  My current strategy is to  >>>=20
>define <patternset>s for each type of project.  For instance,=20
>I add  >>> all web projects to a particular patternset and=20
>then reference that  >>> patternset when calling <subant>....
> >>>
> >>>              <subant target=3D"war" inheritAll=3D"false">
> >>>                  <fileset dir=3D".">
> >>>                      <patternset refid=3D"war.patternset"/>
> >>>                  </fileset>
> >>>              </subant>
> >>>
> >>>
> >>> As further fallback, individual builds may implement=20
>empty targets  >>> just so that they don't fail, just in case...
> >>>
> >>> <target name=3D"war">
> >>>      <echo message=3D"Unimplemented target"/> </target>
> >>>
> >>>
> >>> However, ideally, I'd like to be able to create the above=20
>target  >>> dynamically in the case that it isn't implemented=20
>already by the
> >>> build.   This would have 2 benefits:
> >>>
> >>> 1.  I wouldn't have to bother creating the patternsets. =20
>I'd  >>just call  >>> all the build files and let them either=20
>build the war file  >>or echo the  >>> "Unimplemented target" message.
> >>>
> >>> 2.  Individual builds that aren't web projects wouldn't=20
>have to have  >>> to know what a web project is.  If the only=20
>artifact generated is a  >>> simple jar library, it seems odd=20
>to have to implement a dummy "war"
> >>> target simply because some external master build file=20
>might  >>call "war"
> >>> on it.
> >>>
> >>>
> >>> Instead of Ant failing with the following message...
> >>>
> >>> BUILD FAILED
> >>> Target `war' does not exist in this project.
> >>>
> >>>
> >>> ...I'd like Ant to just run the above dynamically created=20
> >>target (not  >>> just the "war" target, but any target that=20
>might not exist), report  >>> the "Unimplemented target"=20
>message, and continue on.
> >>>
> >>> So, is this possible?  Where/how do I hook into Ant to=20
>know  >>the target  >>> isn't implemented and create it myself=20
>via a scriptdef before Ant  >>> gives me the build failure?
> >>>
> >>>
> >>> Jake
> >>>
> >>>
> >>>=20
>---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org=20
>For  >>additional  >>> commands, e-mail: user-help@ant.apache.org  >>
>=20
>>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For=20
> >>additional commands, e-mail: user-help@ant.apache.org  >>  >>  >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@ant.apache.org =20
>>For additional commands, e-mail: user-help@ant.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For=20
>additional commands, e-mail: user-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org