The mailing list seems to have rejected my log, but that's ok. In
digging through the code, I think I've found a couple of possible
sources of the issue.
>From what I can tell:
1) The resolution process starts by resolving:
A -> 1.1
B -> 2.1 (requires A 1.0)
2) Seeing the conflict between A
El 01/07/2010 16:44, Stefan Bodewig escribió:
On 2010-07-01, Carlos Garcés wrote:
There is other way to represent the null char on ant script?
Unfortunately there isn't - and you can't even legally add a NUL
character to any XML file either (for example� would be invalid).
A custom
> -Original Message-
> From: Bailey, Darragh
> Sent: 08 July 2010 15:52
> To: Ant Users List
> Subject: Including external class files in a compile?
>
>
> Have a component that needs classes from another component
> that currently only builds a war.
>
> I know that these should really
I tried last night from a trunk source build and this morning with 2.2.0
rc1 with no change. The original attempt was on 2.1.0. I quickly tested
on 2.0.0-beta1 and the issue is there as well, so it's not likely a
regression.
I've attached an ant run with debug logging enabled just in case it's of
Have a component that needs classes from another component that currently only
builds a war.
I know that these should really be split out into a separate jar, but that's
not going to happen straight away. Instead for the moment I want to be able to
pick up these class files and include them in
At this point, it sounds like a standard matter of Ivy debugging. Try
running an ivy:report against the dep-for-ear conf and see where the
provided confs otherwise show up.
When you mention you use ivy:cachefileset for compilation, I'm presuming you
mean ivy:cachepath.
And you're right in implyin
So,
I have it close. See my example below.
The only issue is that we currently use a globally defined patternset
and reference it when we retrieve a remote file list. I can't figure out
how to replace the hardcoded selectors in the example with a reference
to a globally defined patternset, or so