ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciramella, Edward" <ECirame...@emptoris.com>
Subject Patch solution?
Date Thu, 30 Jan 2003 21:01:11 GMT
how about putting in your init target (or whatever you're using) different
ways to set up the classpath based on whether or not that patch variable is
set.

If true, look to the build.property files for the patch.classpath setting.

You may have something like this:

patch.classpath = path/to/patch2:path/to/patch1.........

In your init method, if the patch property is set to true, then classpath
would equal:

${patch.classpath}:other/stuff

And I'm saying, keep all the source together - simply redirect the compile
to another location...

-----Original Message-----
From: Dan Gardner [mailto:Dan.Gardner@emap.com]
Sent: Thursday, January 30, 2003 3:38 PM
To: 'Ant Users List'
Subject: RE: copy,fileset,mapper


Ahhh I think I see what your saying, and this is possibly the *other* way to
look at it that I was missing.

So your saying compile the patch within the patch directory.  Of course
ensuring that the javac classpath can see my release(plus previous patches)
in the build directory.  That way, when finished, I don't need to pick out
*just* the changed stuff from the build directory but pull all the .class
files from my patch directory.

I would just need to ensure that the patch-directory was higher (? :)) up
the classpath than my build directory.

cheers

P.S. - In the name of completion;  the problem with the hacked target was
that the pathconvert/map was leaving a preceding "/" on my file lists.  In
the fileset/includes this was total rooting. :)  To fix - map became: <map
from="${from.location}/" to="" />.

_______________________________
Dan Gardner        Emap IT - UK



>-----Original Message-----
>From: Ciramella, Edward [mailto:ECiramella@emptoris.com]
>Sent: 30 January 2003 20:25
>To: 'Ant Users List'
>Subject: RE: copy,fileset,mapper
>
>
>Wait, you just want the changed files off in another 
>directory, correct?
>
>put a patch = true/false entry in your build.properties file 
>(if you are
>using one)
>create a target called "patch" that only works if the patch 
>value is true
>(but gets called buy compile)
>this target would also have a javac task, but it would output 
>to another
>directory.
>
>Doing it this way, you can always rebuild the patch files 
>without affecting
>your core binaries...
>
>Am I waaaaay off base here?  You're trying to build only the 
>files that have
>changed into a patch, no?
>
>
>-----Original Message-----
>From: Dominique Devienne [mailto:DDevienne@lgc.com]
>Sent: Thursday, January 30, 2003 2:55 PM
>To: 'Ant Users List'
>Subject: RE: copy,fileset,mapper
>
>
>Maybe... but I feel it's doable in one fell swoop thanks to 
>the power of
>selectors and mappers. You're solution, if I'm right about the 
>above, would
>much more hack'ish (no offense meant ;-). If you could give 
>more info about
>how the files are laid out on disk, what dir to compare 
>against what other
>dir, where the classes are (relative to two previous of dirs), 
>and where
>they should go, then we could all try to solve your problem ;-)
>
>But if I'm wrong, then your solution becomes *the* solution, 
>or you write a
>little task that does it for you. --DD
>
>-----Original Message-----
>From: Dan Gardner [mailto:Dan.Gardner@emap.com] 
>Sent: Thursday, January 30, 2003 1:25 PM
>To: 'Ant Users List'
>Subject: RE: copy,fileset,mapper
>
>I originally thought the mapper would do it, but now I've 
>formed the opinion
>(hopefully wrongly) that the mapper will just change the file 
>name during a
>copy of move routine.
>
>I need to identify a file list.
>Change that filelist.
>Use the changed filelist as the definition of my source files.
>
>I think I can do what I want using 
>1	a pathconvert, with a map element to change the 
>directory location.
>
>2	Then write to a file.
>3	Use the replace task to change the .java to .class
>4	read it back in
>
>_______________________________
>Dan Gardner        Emap IT - UK
>
>
>
>>-----Original Message-----
>>From: Dominique Devienne [mailto:DDevienne@lgc.com]
>>Sent: 30 January 2003 19:06
>>To: 'Ant Users List'
>>Subject: RE: copy,fileset,mapper
>>
>>
>>Sounds like a job for something along the lines of:
>>
>><property name="builddir" location="build" />
>><property name="patchsrc" location="source/patch_1" />
>><copy todir="patches/patch-directory">
>>  <fileset dir="${patchsrc}">
>>    <include name="**/*.java" />
>>    <depend targetdir="other source dir" />
>>  </fileset>
>>  <mapper type="regexp" from="${patchsrc}(.*)\.java"
>>                        to="${builddir}\1.class" />
>></copy>
>>
>>but since I'm not sure I followed you, I might be off. --DD
>>
>>-----Original Message-----
>>From: Dan Gardner [mailto:Dan.Gardner@emap.com] 
>>Sent: Thursday, January 30, 2003 12:18 PM
>>To: 'Ant Users List'
>>Subject: copy,fileset,mapper
>>
>>I'm having trouble doing the following.
>>
>>1	Identify a list of changed .java files in a 
>>source/patch-directory.
>>This is a subset of the complete list for the release.
>>2	Use that list to copy the *relevant* resultant .class 
>>files in the
>>build area into a patches/patch-directory.
>>
>>I was hoping I could do the following:
>>
>>1	identify the changed .java files with a fileset [yes]
>>/source/patch_1/com/bla/foo.java
>>/source/patch_1/com/bla/bar.java
>>
>>2	pathconvert the fileset into a property containing the 
>>files as a
>>comma separated list.  Apply a map within the pathconvert to 
>change the
>>directory location from the source directory to the build directory.
>>${filelist}=/build/com/bla/foo.java,/build/com/bla/foo.java
>>
>>3	replace the *.java extension with *.class somehow {shrug}
>>${filelist}=/build/com/bla/foo.class,/build/com/bla/foo.class
>>
>>4	use this as a fileset includes entry to copy the changed .class
>>files into a patch directory.
>>
>>
>>I'm starting to hit a wall on this one.  Any ideas ?
>>cheers
>>dan
>>
>>_______________________________
>>Dan Gardner        Emap IT - UK
>>
>>
>>** For great Emap magazine subscription & gift offers visit
>>http://www.emapmagazines.co.uk **
>>
>>---------------------------------------------------------------
>>-------------
>>----
>>The information in this email is intended only for the 
>>addressee(s) named
>>above.
>>Access to this email by anyone else is unauthorised.
>>If you are not the intended recipient of this message any disclosure,
>>copying, 
>>distribution or any action taken in reliance on it is 
>>prohibited and may be
>>unlawful. 
>>
>>Emap plc and or its subsidiaries do not warrant that any 
>>attachments are
>>free from 
>>viruses or other defects and accept no liability for any 
>>losses resulting
>>from 
>>infected email transmissions.
>>
>>Please note that any views expressed in this email may be those of the
>>originator 
>>and do not necessarily reflect those of this organisation.
>>---------------------------------------------------------------
>>-------------
>>----
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: ant-user-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: ant-user-help@jakarta.apache.org
>>
>
>
>** For great Emap magazine subscription & gift offers visit
>http://www.emapmagazines.co.uk **
>
>---------------------------------------------------------------
>-------------
>----
>The information in this email is intended only for the 
>addressee(s) named
>above.
>Access to this email by anyone else is unauthorised.
>If you are not the intended recipient of this message any disclosure,
>copying, 
>distribution or any action taken in reliance on it is 
>prohibited and may be
>unlawful. 
>
>Emap plc and or its subsidiaries do not warrant that any 
>attachments are
>free from 
>viruses or other defects and accept no liability for any 
>losses resulting
>from 
>infected email transmissions.
>
>Please note that any views expressed in this email may be those of the
>originator 
>and do not necessarily reflect those of this organisation.
>---------------------------------------------------------------
>-------------
>----
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: ant-user-help@jakarta.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: ant-user-help@jakarta.apache.org
>


** For great Emap magazine subscription & gift offers visit
http://www.emapmagazines.co.uk **

----------------------------------------------------------------------------
----
The information in this email is intended only for the addressee(s) named
above.
Access to this email by anyone else is unauthorised.
If you are not the intended recipient of this message any disclosure,
copying, 
distribution or any action taken in reliance on it is prohibited and may be
unlawful. 

Emap plc and or its subsidiaries do not warrant that any attachments are
free from 
viruses or other defects and accept no liability for any losses resulting
from 
infected email transmissions.

Please note that any views expressed in this email may be those of the
originator 
and do not necessarily reflect those of this organisation.
----------------------------------------------------------------------------
----


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message