Re: maven and ivy
Brett Porter wrote: I agree. But I don't think it's unnecessary, at least when used with ant, and it's the first aim of ivy. But if you feel it's unnecessary in maven, I'll never say you're wrong ! And if this is the case, I'm afraid we won't be able to use poms as metadata. I don't know how we keep coming back to this... I never suggested scope for configurations. I've suggested that Maven needs some sort of profile ability, that you could map configurations to that, and with that I think all the metadata is covered. I apologize for this, it's my fault. But I'd rather not rush that in as additions are not easily reversed, and it seems you're pretty happy with what you have, so that's fine. What you suggest is really fine for me. Keep me informed when you'll add this feature in maven, if you do. Cheers, Xavier Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = = Xavier HANINemail: [EMAIL PROTECTED] = = = JAYASOFT = = = = 22, rue Danton= = 33160 St Médard en Jalles = = Tél/Fax: 05.57.53.00.80 = = http://www.jayasoft.fr= = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
> I agree. But I don't think it's unnecessary, at least when used with > ant, and it's the first aim of ivy. But if you feel it's unnecessary > in maven, I'll never say you're wrong ! And if this is the case, I'm > afraid we won't be able to use poms as metadata. > I don't know how we keep coming back to this... I never suggested scope for configurations. I've suggested that Maven needs some sort of profile ability, that you could map configurations to that, and with that I think all the metadata is covered. But I'd rather not rush that in as additions are not easily reversed, and it seems you're pretty happy with what you have, so that's fine. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Brett Porter wrote: Test was only an example... in ivy, configurations are not limited (you can use the name you want), and we assume nothing about their transitivity. It's the developer who choose, by describing its configurations mapping: in my "buildtime" I need xdoclet "runtime", for example. So I can also say that in my conf "test" I need this component "test" configuration. It's very flexible, and we answer to many different needs with that. There is no need for build time as it is all done via plugins and is separate in Maven. We have runtime, which is used for distribution purposes, as well as tests, and we have the default compile. Once again, this was only an example. But I understand that in maven things are really different than in ant, and ivy has been primarly thought for ant integration. That's why we have focused on some needs you don't have. Is this (or will it be) possible with m2 ? There's a chance we'll add more later, or make it arbitrary if we introduce arbitrary classpaths. This would probably come with additional lifecycle phases - but I see little need for it. What other types of dependencies do you see than compile, runtime and test? Maybe integration test, when we have that, though most plugins will just select dependencies from the existing ones, and filters can be used to pick up the rare special case. I've no idea in mind, but configurations are also used as what you call a profile. So configuration mapping is also interesting in this case. Too much flexibility is not always a good thing, because when it is unnecessary it usually comes with added complexity. I agree. But I don't think it's unnecessary, at least when used with ant, and it's the first aim of ivy. But if you feel it's unnecessary in maven, I'll never say you're wrong ! And if this is the case, I'm afraid we won't be able to use poms as metadata. Xavier - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = = Xavier HANINemail: [EMAIL PROTECTED] = = = JAYASOFT = = = = 22, rue Danton= = 33160 St Médard en Jalles = = Tél/Fax: 05.57.53.00.80 = = http://www.jayasoft.fr= = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
> Test was only an example... in ivy, configurations are not limited > (you can use the name you want), and we assume nothing about their > transitivity. It's the developer who choose, by describing its > configurations mapping: in my "buildtime" I need xdoclet "runtime", > for example. So I can also say that in my conf "test" I need this > component "test" configuration. It's very flexible, and we answer to > many different needs with that. There is no need for build time as it is all done via plugins and is separate in Maven. We have runtime, which is used for distribution purposes, as well as tests, and we have the default compile. > > Is this (or will it be) possible with m2 ? There's a chance we'll add more later, or make it arbitrary if we introduce arbitrary classpaths. This would probably come with additional lifecycle phases - but I see little need for it. What other types of dependencies do you see than compile, runtime and test? Maybe integration test, when we have that, though most plugins will just select dependencies from the existing ones, and filters can be used to pick up the rare special case. Too much flexibility is not always a good thing, because when it is unnecessary it usually comes with added complexity. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Brett Porter wrote: Xavier Hanin wrote: I was just fixing that and about to put it in the user's guide... test dependencies are not transitive. Test was only an example... in ivy, configurations are not limited (you can use the name you want), and we assume nothing about their transitivity. It's the developer who choose, by describing its configurations mapping: in my "buildtime" I need xdoclet "runtime", for example. So I can also say that in my conf "test" I need this component "test" configuration. It's very flexible, and we answer to many different needs with that. Is this (or will it be) possible with m2 ? Xavier -- = = Xavier HANINemail: [EMAIL PROTECTED] = = = JAYASOFT = = = = 22, rue Danton= = 33160 St Médard en Jalles = = France= = Tél/Fax: +33 (0)5 5753 0080 = = http://www.jayasoft.org = = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven and ivy
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Friday, April 15, 2005 9:00 AM > To: Maven Developers List > Subject: Re: maven and ivy > > > Maczka Michal wrote: > > >I also think that splitting the pom of artifact into some > group is a bad > >idea. But group (composite) > >dependencies are about something else. They provide useful > shortcut method > >for including multiple artifacts in projects > >via declaration of just a single dependency. > > > > > Perhaps you should test things before posting such a lengthy response? > > Depending on pom already works. > Sorry no time for that these days. But the main reason why I have sent "lengthy response" was to explain to ivy people that the feature they are after is already supported by maven2 metadata (poms) as it was not well communicated and probably not so obvious even to early adopters of m2. I also wanted to explain to you what I meant by "group dependencies". > There are a couple of caveats: > 1) there is a bug where it attempts to include it on the compiler's > classpath. Will fix. So it only works for runtime in alpha-1 so now I am glad that I haven't tried to test it as I may had false impressions :) > 2) it might be more useful to pull in the modules instead of the > dependencies when doing this (e.g. depending on wagon-providers > would get > what you want, rather than creating another aggregating pom). I'll put > it in JIRA for alpha-3. > I haven't tested how this feature works in this version of maven but I did test it before and in fact I fell that few more additions are needed to make it useful. For example the necessity of saying that some dependency should not be resolved transitively (I know that you are thinking about including this feature). If you want to "to pull in the modules instead of the dependencies" it will also nice to have some control over it (e.g. different dependency type for that) Note also that in case of wagon providers there are two "competing" jars: http and http-lightweight. One of the reasons why group dependencies could be useful is exactly for giving the possibility of choosing only once which one of them should be used by default in your projects if you are using multiple wagons very often. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Xavier Hanin wrote: > Brett Porter wrote: > >> Depending on pom already works. >> >> > And how does it work ? I mean, if I depend on a pom which itself > defines a dependency on junit only for its tests, for instance, will I > get it ? > If yes, what if I do not use junit in my tests ? I was just fixing that and about to put it in the user's guide... test dependencies are not transitive. > > Regards, >Xavier > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Brett Porter wrote: Depending on pom already works. And how does it work ? I mean, if I depend on a pom which itself defines a dependency on junit only for its tests, for instance, will I get it ? If yes, what if I do not use junit in my tests ? Regards, Xavier -- = = Xavier HANINemail: [EMAIL PROTECTED] = = = JAYASOFT = = = = 22, rue Danton= = 33160 St Médard en Jalles = = France= = Tél/Fax: +33 (0)5 5753 0080 = = http://www.jayasoft.org = = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Maczka Michal wrote: >I also think that splitting the pom of artifact into some group is a bad >idea. But group (composite) >dependencies are about something else. They provide useful shortcut method >for including multiple artifacts in projects >via declaration of just a single dependency. > > Perhaps you should test things before posting such a lengthy response? Depending on pom already works. There are a couple of caveats: 1) there is a bug where it attempts to include it on the compiler's classpath. Will fix. So it only works for runtime in alpha-1 2) it might be more useful to pull in the modules instead of the dependencies when doing this (eg depending on wagon-providers would get what you want, rather than creating another aggregating pom). I'll put it in JIRA for alpha-3. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven and ivy
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Friday, April 15, 2005 1:48 AM > To: Maven Developers List > Subject: Re: maven and ivy > > > Michal Maczka wrote: > > > Group Dependencies (aka composite artifacts) is the feature which > > enables to define a single dependency on multiple artifacts. > > > > Depenedecny Group is the feature which allows to logically group > > dependencies in poms and for example > > mark some dependencies as optional. > > > > I do believe that the first feature is actually very useful and not > > at all against maven's philosophy and it > > can eliminate completly the need of having "dependency > groups". Simply > > if we take hiberante as example > > hibernate team can publish just one jar and multiple poms - for > > example: hibernate-full.3.0.pom, hibernate-minimal-3.0.pom, > > hibernate-jcs.3.0.pom etc. Those poms will list the > dependecies which > > are needed in diffrent cirumstances. > > Of couse jars like hibernate-full.3.0.jar will not exists. > > Michal, I'm confused. You seem to be talking about the latter, not the > first one. > > I think splitting the pom of an artifact is a very bad idea, > especially > if those jars don't exist. I also think that splitting the pom of artifact into some group is a bad idea. But group (composite) dependencies are about something else. They provide useful shortcut method for including multiple artifacts in projects via declaration of just a single dependency. With help of them for example I can create a pom which will contain a list of all known (or preferred) wagon providers. 4.0.0 my-favourite-wagons pom 1.0 here will go: http-wagon, scp-wagon, ftp-wagon, etc I can deploy it to the repository as /xx/yy/my-favourite-wagons-1.0.pom Then if I wanted to include all those wagons in some project I simply could do something like: xx.yy my-favourite-wagons composite (or simply type = pom) 1.0 and have all those wagons included in my project Of course my-favourite-wagons-1.0.jar does not really make sense so it won't exist. But really what happens here is an aggregation not splitting. If I understood this is more or less what happens in ivy and what ivy module are about. They used example of Spring Framework, which provides very many jars and it will be usefull to have a possibility of creating multiple "views" over that selection. For example if you were using spring (core), hibernate and tapestry in multiple projects in your company you could create a pom which contain appropiate entries, which describe that selection and import it to any project via declararation of single composite dependency. Other useful example: say that you are working with j2ee and you have to add to your projects: servlatapi, jms, jta, ejb etc. With help of group dependecies you could create pom like j2ee-1.3.pom, j2ee-1.4 pom which will include all required jars in appropiate versions. (forget that they are not in the repository :-/) reagrds Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
> Unfortunaetly I don't know Maven 2 dependency handling quite well > enough, but it seems to me that even Maven 2 doesn't go quite far > enough there. Can you give an example of where Maven 2 "doesn't go quite far enough", other than that we've already discussed? Maven2's transitive dependencies is not complete. It definitely works - but I think it was good to keep it simple for the first release, because nobody has tried this with such a large and varied amount of metadata (and because most of that metadata is not optimally marked up yet). The remaining features will be implemented for alpha-3, and are already in JIRA, and some have been started in code previously. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Michal Maczka wrote: > Group Dependencies (aka composite artifacts) is the feature which > enables to define a single dependency on multiple artifacts. > > Depenedecny Group is the feature which allows to logically group > dependencies in poms and for example > mark some dependencies as optional. > > I do believe that the first feature is actually very useful and not > at all against maven's philosophy and it > can eliminate completly the need of having "dependency groups". Simply > if we take hiberante as example > hibernate team can publish just one jar and multiple poms - for > example: hibernate-full.3.0.pom, hibernate-minimal-3.0.pom, > hibernate-jcs.3.0.pom etc. Those poms will list the dependecies which > are needed in diffrent cirumstances. > Of couse jars like hibernate-full.3.0.jar will not exists. Michal, I'm confused. You seem to be talking about the latter, not the first one. I think splitting the pom of an artifact is a very bad idea, especially if those jars don't exist. What we've suggested in the past, and I pointed out in my email, was that a "profile", similar to Ivy's concept of a "configuration" would be more appropriate. It could be used to split off optional dependencies, but I wouldn't recommend it - I'd recommend splitting out the code that used that if it were the case. It's main use would be for getting the appropriate dependency on a particular platform (JDK, OS, etc). - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Michal Maczka wrote: Xavier Hanin wrote: Hi all, To give a bit more of context on this discussion, the starting point was brett's blog titled "Ivy: do we really need more metadata?": http://blogs.codehaus.org/people/brett/archives/001023_ivy_do_we_really_need_more_metadata.html If I still agree that it would be much better to have only one repository, and one metadata for each project, I'm not sure this is possible for the moment. I'd be very happy to use poms in ivy, but for the moment the philosophy is still too different. I've gone a bit deeper in maven doc, and what makes a big difference between maven and ivy dependency management is that in ivy dependencies are declared on modules (= a project in maven), whereas in maven, as far as I understand, dependencies are declared on artifacts. So it's not so easy to share the same metadata with those two different approaches. Both have their advantages and drawbacks, I'm not claiming ivy is better, it's simply different. But in our day to day use in my company, we appreciate the advantage to have to declare only one dependency to get all the needed spring-framework jars and dependencies, and only the one required. And this is made possible with dependencies on module and the configuration directive. So I personnaly think it justifies to have our own metadata... and thus to provide ivyrep, unless you open a gate on ibiblio to publish our ivy files, in which case we would really be glad to use it. I think that there are two ideas floating around, which have similar names but are quite different: group dependencies and dependency groups Group Dependencies (aka composite artifacts) is the feature which enables to define a single dependency on multiple artifacts. Depenedecny Group is the feature which allows to logically group dependencies in poms and for example mark some dependencies as optional. I do believe that the first feature is actually very useful and not at all against maven's philosophy and it can eliminate completly the need of having "dependency groups". Simply if we take hiberante as example hibernate team can publish just one jar and multiple poms - for example: hibernate-full.3.0.pom, hibernate-minimal-3.0.pom, hibernate-jcs.3.0.pom etc. Those poms will list the dependecies which are needed in diffrent cirumstances. Of couse jars like hibernate-full.3.0.jar will not exists. It is true that in maven you can only declared dependecies on artifacts. But those artifacts can be files, which contain metadata which can be expanded to list of artifacts. Isn't it something which is already sufficient for ivy? If I rememebr group dependencies it is something, which was planned since a long time but I don't know if there are still plans to include that feature in m2. IMHO ivy can use poms to implement this feature even if maven won't support this feature. It can be helpful as we could then define a single dependecy on virtual artifact like "my-web-platform:1.0", which can for example include a web framwork, tag liblaries, logging liblary, ioc container, zip files with css and js files and what ever else which is commonly used for developing web applications inside some company. I've been playing around some with Ivy with the idea of using it for the Spring framework builds, until at least such a time as Maven2 might be ready and capable. Right now I find the dependency capabilities in Ivy very useful. Unfortunaetly I don't know Maven 2 dependency handling quite well enough, but it seems to me that even Maven 2 doesn't go quite far enough there. To give you an idea of what Ivy can do with dependencies, take a look at this view of an Ivy module declaration which lists dependencies (this is just a pretty view on an XML file) http://www.jayasoft.fr/org/modules/ivy/samples/ivy-sample-xslt.xml and the documentation for dependency declarations (this page lists all the elements, not just dependency stuff) http://www.jayasoft.fr/org/modules/ivy/ivyfile.php In any case, you can see why Ivy had to use an add-on repository (ivyrepo) to store extra info (basically the ivyxml files for vairous modules) in addition to the data available in the Maven POMs on iBiblio. Regards, Colin -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - "From the Source" http://www.springframework.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Xavier Hanin wrote: Hi all, To give a bit more of context on this discussion, the starting point was brett's blog titled "Ivy: do we really need more metadata?": http://blogs.codehaus.org/people/brett/archives/001023_ivy_do_we_really_need_more_metadata.html If I still agree that it would be much better to have only one repository, and one metadata for each project, I'm not sure this is possible for the moment. I'd be very happy to use poms in ivy, but for the moment the philosophy is still too different. I've gone a bit deeper in maven doc, and what makes a big difference between maven and ivy dependency management is that in ivy dependencies are declared on modules (= a project in maven), whereas in maven, as far as I understand, dependencies are declared on artifacts. So it's not so easy to share the same metadata with those two different approaches. Both have their advantages and drawbacks, I'm not claiming ivy is better, it's simply different. But in our day to day use in my company, we appreciate the advantage to have to declare only one dependency to get all the needed spring-framework jars and dependencies, and only the one required. And this is made possible with dependencies on module and the configuration directive. So I personnaly think it justifies to have our own metadata... and thus to provide ivyrep, unless you open a gate on ibiblio to publish our ivy files, in which case we would really be glad to use it. I think that there are two ideas floating around, which have similar names but are quite different: group dependencies and dependency groups Group Dependencies (aka composite artifacts) is the feature which enables to define a single dependency on multiple artifacts. Depenedecny Group is the feature which allows to logically group dependencies in poms and for example mark some dependencies as optional. I do believe that the first feature is actually very useful and not at all against maven's philosophy and it can eliminate completly the need of having "dependency groups". Simply if we take hiberante as example hibernate team can publish just one jar and multiple poms - for example: hibernate-full.3.0.pom, hibernate-minimal-3.0.pom, hibernate-jcs.3.0.pom etc. Those poms will list the dependecies which are needed in diffrent cirumstances. Of couse jars like hibernate-full.3.0.jar will not exists. It is true that in maven you can only declared dependecies on artifacts. But those artifacts can be files, which contain metadata which can be expanded to list of artifacts. Isn't it something which is already sufficient for ivy? If I rememebr group dependencies it is something, which was planned since a long time but I don't know if there are still plans to include that feature in m2. IMHO ivy can use poms to implement this feature even if maven won't support this feature. It can be helpful as we could then define a single dependecy on virtual artifact like "my-web-platform:1.0", which can for example include a web framwork, tag liblaries, logging liblary, ioc container, zip files with css and js files and what ever else which is commonly used for developing web applications inside some company. Michal --- Wzmocnij swoja komorke. Najwiekszy z silaczy na tapecie? Sprawdz: >> http://link.interia.pl/f1872 << - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
Hi all, To give a bit more of context on this discussion, the starting point was brett's blog titled "Ivy: do we really need more metadata?": http://blogs.codehaus.org/people/brett/archives/001023_ivy_do_we_really_need_more_metadata.html If I still agree that it would be much better to have only one repository, and one metadata for each project, I'm not sure this is possible for the moment. I'd be very happy to use poms in ivy, but for the moment the philosophy is still too different. I've gone a bit deeper in maven doc, and what makes a big difference between maven and ivy dependency management is that in ivy dependencies are declared on modules (= a project in maven), whereas in maven, as far as I understand, dependencies are declared on artifacts. So it's not so easy to share the same metadata with those two different approaches. Both have their advantages and drawbacks, I'm not claiming ivy is better, it's simply different. But in our day to day use in my company, we appreciate the advantage to have to declare only one dependency to get all the needed spring-framework jars and dependencies, and only the one required. And this is made possible with dependencies on module and the configuration directive. So I personnaly think it justifies to have our own metadata... and thus to provide ivyrep, unless you open a gate on ibiblio to publish our ivy files, in which case we would really be glad to use it. Ok, they are completely different. This is like what one user has been asking for in dependency groups, asked about today on the users list. I don't believe it is a good idea - taking your Hibernate example, it is the responsibility here for the hibernate project to declare these groups responsibly - really, you need to give the client the power to control what they are getting, if anyone. If Hibernate declares no groups, the client takes all dependencies, right? In this case you can filter out what you don't want, using include/exclude features. But that's not the philosophy, so it's much better when the component developer as thought about the use that can be done of his component. And it's often the case... going back to hibernate example, writing the ivy file was only a matter of traduction of what is written in hibernate lib README.txt to an ivy file. But once more I understand your philosophy, it's just that it doesn't fit our needs (and maybe the needs of our users, but they are less numerous than yours ! ;-) ) Cheers, Xavier -- = = Xavier HANINemail: [EMAIL PROTECTED] = = = JAYASOFT = = = = 22, rue Danton= = 33160 St Médard en Jalles = = France= = Tél/Fax: +33 (0)5 5753 0080 = = http://www.jayasoft.org = = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and ivy
(context - email from Xavier Hanin, Ivy developer, regarding using m2 POMs in Ivy) Xavier Hanin wrote: > I understand, I have no request for the moment cause I don't have > enough knowledge of m2 poms. And that's why I am asking for help from > your side... if you could point me to a doc where i could see how > scope mapping is described in poms, i think i would be able to make > ivy understand poms. It's autogenerated, and needs some improvement: http://maven.apache.org/maven2/project-descriptor.html#Dependency example of scope: http://maven.apache.org/maven2/getting-started.html#Multiple_Modules (towards the end) In m2, scope is the inclusion of JARs depending on whether they are used to compile, run, or test the project - profile could be reused for that, but they have special meaning (ie compile is runtime and test, runtime is test, etc). As I'll explain, it is different from your configuration directive. >> Though the minimal valid POM is really just: >> >> >> ... >> ... >> ... >> >> >> >> (where dependencies is optional) - so it's not too much to ask :) >> >> > Not too much, you're right ! We have the same minimal requirements... > maybe we'll finally manage to only have poms. It's too early for the > moment, but we are not against the idea if it's better for the community. Ok, I'll look forward to hearing from you. > > Actually "test" doesn't mean anything for ivy. Nothing more than > "default", or "myscope". Ivy let the user define their own > configurations depending on their needs. It only uses them to > structure the dependencies, to separate them in several reusable sets. > It is used too avoid getting dependencies which are not actually > required, which otherwise could be very expensive (in download time, > especially), with transitive dependencies. > Ok, they are completely different. This is like what one user has been asking for in dependency groups, asked about today on the users list. I don't believe it is a good idea - taking your Hibernate example, it is the responsibility here for the hibernate project to declare these groups responsibly - really, you need to give the client the power to control what they are getting, if anyone. If Hibernate declares no groups, the client takes all dependencies, right? In an ideal world, when a library has optional dependencies, they should split the optional code out into a separate library. One of maven's aims is to make building more concise libraries together easily, keeping clear separation of concerns (though allowing a project to bundle up all its libraries where it is appropriate for distribution). I agree this "configuration" is useful when you need to change dependencies based on JDKs/platform (like JCA in Hibernate, or SWT). We'd certainly like to add this (it's been on the feature list for both m1 and m2 a long time), but haven't decided how to declare it yet. Maybe we could work that out here. Certainly a profile or "configuration" seems consistent with how we've been planning similar metaphors. HTH, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
