Hi Carl,
Not to nit-pick, but this is probably better a question for the users
mailing list than the dev mailing list.
I haven't tried this myself, but here's an idea:
1) You can configure IvyDE to retrieve your dependencies into the workspace
on resolve. It might be useful to create a special
Hey Maarten,
Just wanted to draw your attention to a bug in that we discovered
in the RC1 build just last night:
https://issues.apache.org/jira/browse/IVY-1203
I don't know if it's an issue for the release of RC1 or not (only users of
the new feature would be impacted), though it would be a prob
Hi Stefan,
I opened a bugzilla entry and attached a patch to it:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49168
cheers
jason
On Mon, Apr 5, 2010 at 8:56 PM, Stefan Bodewig wrote:
> On 2010-04-05, Jason Trump wrote:
>
> > Not sure if this is the right forum to dis
that's a clever formula. is there an 'ant cookbook' somewhere on the web to
collect stuff like this? sorry to be slightly off-topic, but seems like it
would be a valuable community resource.
jason
On Wed, Apr 14, 2010 at 9:01 PM, Stefan Bodewig wrote:
> On 2010-04-15, Jeffrey E Care wrote:
>
Hello,
Not sure if this is the right forum to discuss antunit development. I was
recently using antunit to test some ivy-based build scripts. This was
complicated by the fact that I could not get the AntUnit scripts to inherit
references from the parent project. Since you can inherit properties
Hi everybody,
Hope you don't mind a late join to the discussion.
There is some precedent for this kind of thing in Ant -- extension-points.
In fact, extension-points plus appendable paths / filesets is a potent
combination. You know:
* base script declares a few standard, empty data structures
wouldn't it be better to include the public ivysettings in your
project-specific ivysettings file (instead of the other way around), and do the
override logic that way? the "override" features requires that you know ahead
of time what is going to be overridden in the parent file. This will ten
That is definitely a cool idea. Another possibility would be to use embedded
Ivy to implement an auto-update feature for ant and/or ivy itself.
Not a "three-dialogs-per-day" kind of auto-update feature, of course.
jason
From: Martin Eigenbrodt [mailto:martinei
Hi Aleksey,
What are the exact values of ${version} and ${integr-version} from your publish
targets?
Also, can you share your ivysettings file? How your resolvers are configured
could make a big difference in which version gets chosen.
Jason
From: Alex
PM, Jason Trump <[EMAIL PROTECTED]> wrote:
> yeah, I think that using the resolver itself to retrieve the settings is
> elegant. another advantage is that the settings can be stored in the cache,
> so that building completely from cache remains possible with a remote
> setti
er ivy settings?
On Jan 4, 2008 10:15 PM, Jason Trump <[EMAIL PROTECTED]> wrote:
> New feature suggestion (obviously not for 2.0): allow some kind of
> optional ivy settings file on the ivy repository. This would allow for less
> configuration on the ivy client side, and make it ea
New feature suggestion (obviously not for 2.0): allow some kind of optional
ivy settings file on the ivy repository. This would allow for less
configuration on the ivy client side, and make it easier to update the
structure of your ivy repository. Things that could go in this file:
* artifa
Seems like checkModified / changingPattern / changingMatcher all change local
cache behavior in response to a particular remote repository. So the structure
comes from the rep, but the behavior is all about the cache. I think it might
be clearer what these properties do if they are moved to ca
13 matches
Mail list logo
