It works the same way as a Path works. When you do something like set the classpath attribute of a javac task you are using a string. This can be 10 miles long if you'd like it do be, it doesn't matter too much. Ant will assemble the same command line from this to run the compiler as it would if you pass it a reference to a Path object. The same is true for pretty much every other task.
In fact, when you write an Ant component that accepts a Path you can pass it a property and Ant will coerce a Sring value into a Path for you (it just wraps a string with a Path). This is how javac and others can accept string values from attributes. We use properties for even extremely long paths where I work because its just more versatile and easier on the user. You can print them, stick them in tasks that take Paths, dump them into files, etc. Paths only fit in path shaped holes. On 3/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 3/26/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > I had originally the following syntax in mind: > > <ivy:settings settingsId="my-settings" settings="settings.xml" /> > <ivy:resolve resolveId="my-resolve" settingsId="my-settings" /> > <ivy:cachepath resolveId="my-resolve" settingsId="my-settings" /> > ... > > But now that I see your suggestion, I think it's an interesting one as > well... > > the big difference between the resolveId and the settingsId is that you > don't necessarily need to define the resolveId in the same build, which > isn't the case with the settingsId. This is because the resolve metadata is > persisted by the ivy core after a resolve and can be reused in a later > phase, where the settings are not persisted. The ability to do a resolve in > another build and reuse the results later on is really important. +1, I think we should preserve this, and allow the kind of syntax you're talking about, Maarten. Having another syntax like what Eric suggests would be nice if users can still do something similar to what you suggest. For the properties vs reference thing, I'm wondering how it work. The path contains a lot of information (possibly hundreds of file names) so I'm surprised you can use a String with no problem... - Xavier - Xavier regards, > Maarten > > ----- Original Message ---- > From: Xavier Hanin <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, March 26, 2007 8:48:55 PM > Subject: Re: ivy instances and ant properties > > 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 > > > > > > > > > > ____________________________________________________________________________________ > Never miss an email again! > Yahoo! Toolbar alerts you the instant new Mail arrives. > http://tools.search.yahoo.com/toolbar/features/mail/ >
-- - Eric
