I like your idea for the first case, this is possible to accomplish but it
works differently in Ant 1.7 than it does in Ant 1.6 so doing this would be
a challenge. I would have to think about this a little - but I think I could
come up with something that might allow this work on both versions. I'll
come back to this.
The second idea is interesting; What do you think about the notion of a
profile?
<!-- Configure a profile -->
<ivy:profile name="profile-1" settings="settings.xml" ivy="ivy.xml" />
<ivy:profile name="profile-2" ivy="ivy.xml">
<ivy:settings>
<!-- maybe have the option to set these all programtically w/ no xml -->
</ivy:settings>
</ivy:profile>
<!-- Using existing tasks -->
<ivy:cachepath profile="profile1" conf="runtime"/>
<ivy:retrieve profile="profile1" conf="runtime"/>
<!-- Using possible future typdef -->
<javac ...>
<classpath>
<ivy:path profile="profile1" conf="runtime"/>
</classpath>
</javac>
This gives you a nice way to have several effective complete configurations
(where I'm using configuration to mean the ivysettings + an ivy descriptor)
so that I single build.xml could work with many projects, and alternate
settings.
--
Thinking about the first case, my use cases all involve at least a
compilation and unit test using at least two configurations. Even my
simplest projects,
<ivy:path profile="profile1" conf="runtime" id="runtime-deps"/>
<ivy:path profile="profile1" conf="build" id="test-deps"/>
<!-- Build library -->
<javac ... destdir="build/classes">
<classpath refid="runtime-deps"/>
<javac/>
<!-- Build tests, keep separate from the classes I plan to jar up -->
<javac ... destdir="build/tests">
<classpath>
<classpath refid="runtime-deps"/>
<classpath refid="test-deps"/>
<path path="build/classes"/>
</classpath>
<javac/>
<!-- Run tests -->
<junit|testng ...>
<classpath>
<classpath refid="runtime-deps"/>
<classpath refid="test-deps"/>
<path path="build/classes"/>
</classpath>
<junit|testng/>
compared to
<!-- Build library -->
<javac ... destdir="build/classes">
<ivy:path profile="profile1" conf="runtime"/>
<javac/>
<!-- Build tests, keep separate from the classes I plan to jar up -->
<javac ... destdir="build/tests">
<classpath>
<ivy:path profile="profile1" conf="runtime"/>
<ivy:path profile="profile1" conf="build"/>
<path path="build/classes"/>
</classpath>
<javac/>
<!-- Run tests -->
<junit|testng ...>
<classpath>
<ivy:path profile="profile1" conf="runtime"/>
<ivy:path profile="profile1" conf="build"/>
<path path="build/classes"/>
</classpath>
<junit|testng/>
I think it works out to be about the same amount of typing.
---
One thing I might consider for the future tasks is that the equivalent of
the cachepath/resolve task should allow a property to be set instead of a
reference - or perhaps only should set a property instead of a reference.
The overhead in Ant is exactly the same, the uses are all pretty much the
same too (set a classpathref= attribute or a classpath= attribute).
The one thing that makes me prefer the property is that its human readable
without an extra step. To me that's a big win, its real easy for people to
understand thing because they can be <echo>'d easily. Sure, you can still
use another ant task to turn a ref into a path you can read - but I think
that in the case of a path, there is very little reason to use the ref from
a users standpoint. I think the one case for a ref is that certain
operations if you assembling really complex paths might be slightly faster
Maybe the best option would be allow the user to pick
<ivy:cachepath profile="profile1" conf="runtime"
property="property-to-set"/>
<ivy:cachepath profile="profile1" conf="runtime" id="reference-to-set"/>
On 3/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
What I would like to see:
<copy todir="../new/dir">
<ivy:fileset conf="compile"/>
</copy>
<java classname="test.Main">
<arg value="-h"/>
<classpath>
<ivy:path conf="runtime"/>
<pathelement path="${java.class.path}"/>
</classpath>
</java>
But also maybe:
<ivy:resolve file="ivy.xml">
<ivy:settings file="path/to/ivysettings.xml" />
</ivy:resolve>
Or even the maybe ugly:
<ivy:retrieve conf="runtime">
<ivy:resolve file="ivy.xml">
<ivy:settings file="path/to/ivysettings.xml" />
</ivy:resolve>
</ivy:retrieve>
I see a real added value for the first example. For the two other ones,
I'm
not sure it's really better than setting an id when you call configure,
and
then using this settings id when you call resolve (or anything else).
WDYT?
- Xavier
On 3/26/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
>
> That's why I think we should start with what do we want to see in a
> build.xml. We can work backwards and figure out what it would take to
get
> us
> there...
>
> On 3/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> >
> > I'm interested too, not that I see a strong benefit of converting this
> > task
> > to a datatype, but more that I'm wondering about converting other
tasks
> > (like cachepath and cachefileset) to datatypes, and thus I'm
interested
> in
> > feedback about your experience.
> >
> > - Xavier
> >
> > On 3/26/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
> > >
> > > You can actually still do this for nested types. Do you think you
> could
> > > show
> > > me what you ultimately want syntax to see in a build.xml? I'm sort
of
> > > interested and might have some feedback that could be helpful.
> > >
> > > On 3/26/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Finally, I forget about using the datatype. It is more powerful
to
> > use
> > > an
> > > > ant task, with an id attribute. This really looks like a
datatype,
> > but
> > > > you
> > > > have the execute method where you can place the code that you
want.
> > > >
> > > >
> > > > Gilles
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric Crahen [mailto:[EMAIL PROTECTED]
> > > > > Sent: lundi 26 mars 2007 16:31
> > > > > To: [email protected]
> > > > > Subject: Re: ivy instances and ant properties
> > > > >
> > > > > On 3/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > On 3/24/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > I have found an additional issue with the <ivy:settings>
> dataype
> > > > > > > replacing the <ivy:configure>: When loading of the
> > ivy.properties
> > > > > > > file ?
> > > > > > >
> > > > > > > This was currently done at the beguining of the configure
> > task. I
> > > > > > > will try to do it as soon as the datatype is attached to a
> > > > project. I
> > > > > > > guess it is the earlier that I can do, and I hope it will
> still
> > > > allow
> > > > > > > to predefine properties with a property task placed before
the
> > > > > > > declaration of the ivy:settings.
> > > > > > >
> > > > > > > am I right?
> > > > > >
> > > > > >
> > > > > > I think so, but I don't know Ant datatypes very well, so I
don't
> > > know
> > > > if
> > > > > > this can be a source of a problem or not. Maybe you could ask
on
> > ant
> > > > > list
> > > > > > unless an ant expert reads this thread and can answer
directly.
> > > > >
> > > > >
> > > > >
> > > > > I've done quite a bit with ant so if you give me a slight bit
more
> > > > context
> > > > > I
> > > > > can give you an answer.
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > - Eric
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > - Eric
> > >
> >
>
>
>
> --
>
> - Eric
>
--
- Eric
