Filesets are a little different. Filelists can work with strings though.
On 3/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
Interesting. And does it work too for filesets? - Xavier On 3/26/07, Eric Crahen <[EMAIL PROTECTED]> wrote: > > 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 >
-- - Eric
