On 3/26/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
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?
I think this notion is very similar to the result of a resolve, and what
Maarten has already done to isolate its scope. The main difference I see is
that it allows to specify the settings file too, which is not possible with
the current Ivy trunk. There's also the vocabulary used, profile instead of
resolve. And maybe in your mind profile do not actually perform the resolve,
I don't know. Anyway, this isn't too far from what already exist in Ivy, and
could be interesting I agree.
<!-- 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
-->
What do you mean by programmatically? Inlining the settings? Or having a
really different syntax, using a scripting language for instance?
</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.
Probably, yes. But I think it makes things a little bit easier for simple
cases. For instance, when you want to use a custom antlib and want to use
Ivy to download it, you could do :
<taskdef resource="emma_ant.properties" >
<ivy:path organisation="emma" module="emma" revision="
2.0.5312"
inline="true" conf="ant" />
</taskdef>
instead of
<ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
inline="true" conf="ant" pathid="emma.classpath"/>
<taskdef resource="emma_ant.properties" classpathref="emma.classpath"
/>
which is more natural IMO.
---
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).
I thought properties were string only... I'm not familiar with the
difference between properties and reference enough to have an opinion.
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
I'm not sure to see how you can use properties and how to echo 'em.
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"/>
Maybe. We need to preserve backward compatibility anyway, so I think that
even if we provide properties, we should still provide reference.
- Xavier
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
