Re: Weird observation with echoxml w.r.t. order of node text
Thank you Dominique, Matt & Michael for your responses.
For the time being I simply wrapped the text inside tags
(since I'm trying to generate a time html file). I did not have any
special styles for the spans in the document, so this serves my
purpose for now.
I will look into details of the xslt task and check if I can provide
the xsl(t?) instructions inline with the build.xml. If that isn't
doable, then will place them in an adjacent external .xsl file and use
it using ${basedir}.
Thanks once again,
Parag Doke
Save paper, save trees. Do not print emails/documents unless
absolutely necessary.
On Sat, Apr 9, 2011 at 2:48 AM, Dominique Devienne wrote:
> On Fri, Apr 8, 2011 at 2:57 PM, Matt Benson wrote:
>>> So yeah, I'm afraid it's by design... A proper was need
>>> access to the full infoset provided by the parser, and thus require
>>> deeper changes into Ant core to provide that infoset. --DD
>>
>> EchoXML has, I'm afraid, been a largely unsuccessful experiment.
>> Experience has proven it fit only for simple tasks. Strangely, I
>> thought *I* authored it, but you're welcome to take the blame, DD! :)
>
> You totally did Matt! Sorry. See [1].
>
> I confused echoXML with XMLFragment [2], which underpins it and
> predates it by a few months.
>
> This was all a long time ago! --DD
>
> [1] https://fisheye6.atlassian.com/changelog/ant?cs=278356
> [2] https://fisheye6.atlassian.com/changelog/ant?cs=275702
>
> 67 /**
> 68 * Use this class as a nested element if you
> want to get a literal DOM
> 69 * fragment of something nested into your
> task/type.
> 70 *
> 71 * This is useful for tasks that want to
> deal with the "real" XML
> 72 * from the build file instead of objects.
> 73 *
> 74 * Code heavily influenced by code written
> by Dominique
> Devienne.
> 75 *
> 76 * @since Ant 1.7
> 77 */
> 78 public class XMLFragment implements
> DynamicConfigurator {
>
> -
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>
-
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
Re: setting classpath
Le 18 avr. 2011 à 15:56, Felix Drueke a écrit : > Hi, > > I think the usual procedure to set the classpath via Ivy is to use the > cachepath-task. > So I assume the following is a very common structure: > > > > > > > > > > classpathref="build.path" /> > > > > However if you do it like that Ant will always resolve prior to compiling. > Since resolving can potentially be very slow I wonder if there's a more > convenient approach > that allows to make the cachepath persistent somehow (e.g. I resolved last > week and > want to use that cachepath in the next ten compilations without resolving > again). See http://ant.apache.org/ivy/history/latest-milestone/use/postresolvetask.html """ If you want to to reuse the resolved data obtained through a call to resolve in another build (i.e. not the current one), then you have to set the organisation and module attributes. This work only if the cache was not cleaned since your last resolve call. This does not work with inline calls, which must be performed in the same build. """ Nicolas
Re: 'classpath url' in settings
Le 19 avr. 2011 à 17:08, Felix Drueke a écrit : > Can anyone confirm that the " http://ant.apache.org/ivy/history/latest-milestone/settings/classpath.html > actually works with IvyDE under Windows? > > I got it to work with ant and with IvyDE in Eclipse under Linux, but it > doesn't > work under Windows. > > I keep getting something like this: > > The ivy settings file 'file:/C:/ivysettings.xml' could not be parsed: > > failed to load settings from file:/C:/ivysettings.xml: > > impossible to define new type: class not found: my.customer.Resolver in > > [http://my.url/ivyconf/my.customer.Resolver.jar] nor Ivy classloader There is no reason to. Ivy the URLClassLoader from the jre. Nicolas
