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/
