Re: so many jars
Danny Angus wrote: (...) The solution M$ have delivered appears to simply be a global registry (the Global Assembly Cache), but it is well thought out in respect to M$ probelm and is capable of maintaining multiple versions of the same Assemblies (think jars) and using the correct one, either the newest or a specified version. I haven't investigated it too deeply but I have a feeling that where two bits of the same application depend on different versions of the same assembly this is taken care of properly too. From what I can see it relies heavily on code signing to deliver secure name spaces and version identification, and prevent unintentional namespace conflicts. Thus anyone can download and install multiple versions (or your application installer can do it) where necessary, and you only need to install each required Assembly-version once per machine. I think per machine things belong to the configuration management and system administration concerns, and should be handled at this level. IMO, the approach of jpackage.org, making java rpms for linux and setting a repository of libraries(jars) under /usr/share/java, with a judicious use of symbolic links (much in the same way that .so files are managed under linux) offers a clean way to avoid duplication , while leaving decision power on what gets installed where, how and when to the sysadmin. Again IMO, any automated solution should not intrude into the ability of the sysadmin to control what is in her machine. Microsoft has always handled this problem in the wrong way ,assuming that an automated installer knows better than the system administrator and doing things without logging or asking first. Please, (generic broadcasted plea, not pointing to anyone in particular) make sure that any java solution to this problem respects the needs of systema administrators WRT configuration management and global auditing of changes in their (suposedly) managed systems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
Santiago Gala wrote: Again IMO, any automated solution should not intrude into the ability of the sysadmin to control what is in her machine. Microsoft has always handled this problem in the wrong way ,assuming that an automated installer knows better than the system administrator and doing things without logging or asking first. Oh I agree, perhaps I hadn't thought it all through, but my point certainly wasn't to suggest allowing users or installers free range to install anything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
On Fri, 2003-03-14 at 18:17, Dominique Devienne wrote: Could you please provide a link where to start looking to try to understand how you are doing it? Like maybe a ViewCVS link? Thanks, --DD Right now we use three approaches we have a WerkzResolver for short-lived graphs which we use for the CLI and a resolver based on the graph package in the commons-sandbox which will be used for long-lived graphs: http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/java/org/apache/maven/jelly/tags/maven/ What's in the Plexus plugin is just brute-force walking through POMs. I will eventually incorporate the use of the commons-graph package. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 5:08 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote: Why can't the POM be stored in the artifact itself? That certainly can be done and has been suggested, but the POM can be uesd for so many other things. It's certainly one of the routes we could go. Assuming most Maven projects generate JAR artifacts, couldn't you store the POM in the JAR, like in META-INF/maven/project.xml, and then use that info at runtime? Seems like all you would need is some bootstrap class (a modified forehead?) that knows where to find JAR artifacts (the runtime equivalent to the current maven.repository); When requested to start a main class from a given JAR, it would read the POM from the JAR, and start looking up the necessary runtime JARs dependencies (declared in the POM) in the repository(ies). If these JAR dependencies in turn also contain their own POM, you can fully resolve the dependencies (transitive closure). Or am I completely in left field? --DD Nope, that's what I'm doing to create avalon runtimes. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:53 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
so many jars
Hi, I'm setting up a developpement environment and a documentation system for a school. They need their tools to be open source so I'm using much of what is in the jakarta project. Right, now for my question : The dependancies for many projets are pretty much the same, projets come with the jars they depend on (and some do not) which makes for a lot of duplication. Is there a quick way around this, a quick way to avoid duplication? Should a standard be set to avoid such duplication? Or is this duplication justified? Cheers, David Salib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
On Fri, 14 Mar 2003 [EMAIL PROTECTED] wrote: Right, now for my question : The dependancies for many projets are pretty much the same, projets come with the jars they depend on (and some do not) which makes for a lot of duplication. Is there a quick way around this, a quick way to avoid duplication? Should a standard be set to avoid such duplication? Or is this duplication justified? A quick [though ultimately painful] way around it is to stick things into a shared classpath directory. With Java you can put things in your JRE/JDK's lib/ext directory, with tomcat there is a common/lib directory that serves much the same purpose for most things. The problem here comes with the clash in versions, which is why duplication is justified. One piece of code might need log4j 1.1.7 and might not work on 1.2.3 [i'm making up version numbers, but they're closeish], while the rest might happily upgrade to that version. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
You are looking for MAVEN, thats it Jar duplication is history http://jakarta.apache.org/turbine/maven/ Paulo Silveira http://www.paulo.com.br/ http://www.guj.com.br/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 14 de março de 2003 13:13 To: [EMAIL PROTECTED] Subject: so many jars Hi, I'm setting up a developpement environment and a documentation system for a school. They need their tools to be open source so I'm using much of what is in the jakarta project. Right, now for my question : The dependancies for many projets are pretty much the same, projets come with the jars they depend on (and some do not) which makes for a lot of duplication. Is there a quick way around this, a quick way to avoid duplication? Should a standard be set to avoid such duplication? Or is this duplication justified? Cheers, David Salib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. On Fri, 14 Mar 2003, Paulo Silveira wrote: You are looking for MAVEN, thats it Jar duplication is history http://jakarta.apache.org/turbine/maven/ Paulo Silveira http://www.paulo.com.br/ http://www.guj.com.br/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 14 de março de 2003 13:13 To: [EMAIL PROTECTED] Subject: so many jars Hi, I'm setting up a developpement environment and a documentation system for a school. They need their tools to be open source so I'm using much of what is in the jakarta project. Right, now for my question : The dependancies for many projets are pretty much the same, projets come with the jars they depend on (and some do not) which makes for a lot of duplication. Is there a quick way around this, a quick way to avoid duplication? Should a standard be set to avoid such duplication? Or is this duplication justified? Cheers, David Salib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
Take a look at centipede. Using a the Gump module.xml, jars are download and classpaths are handled automatically. -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
I would say check out Greebo http://www.discore.com/oz/new/index.htm a light-weight version of Maven (I'm grossly oversimplifying) and combine this with some of the other magic Ant gives you (described in section 8.4 Handling Versioned Dependencies of Erik Hatcher's Ant book). Together these should go a long way. The simpler approach would likely be to just use Maven (as suggested by others). Lance __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jaaron[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
I'm working on a solution for both, but I'm swamped at the moment. Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. On Fri, 14 Mar 2003, Paulo Silveira wrote: You are looking for MAVEN, thats it Jar duplication is history http://jakarta.apache.org/turbine/maven/ Paulo Silveira http://www.paulo.com.br/ http://www.guj.com.br/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 14 de mar?o de 2003 13:13 To: [EMAIL PROTECTED] Subject: so many jars Hi, I'm setting up a developpement environment and a documentation system for a school. They need their tools to be open source so I'm using much of what is in the jakarta project. Right, now for my question : The dependancies for many projets are pretty much the same, projets come with the jars they depend on (and some do not) which makes for a lot of duplication. Is there a quick way around this, a quick way to avoid duplication? Should a standard be set to avoid such duplication? Or is this duplication justified? Cheers, David Salib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
jaaron wrote: To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. I'll probably be flamed for saying this here :-) but M$.NET common language runtime , the .NET equivalent of the JVM, has a solution to this issue. As I've mentioned elsewhere I expect its because M$ have been plagued much more than Java with the versioning problem, manifested as DLL Hell in windows systems where new software could upgrade system DLL's and break installed applications which have specific dependance on the older versions. Java has less of a nightmare in this respect, but we pay the price of the same basic problem by living under an ever increasing mountain of duplicated jars. The solution M$ have delivered appears to simply be a global registry (the Global Assembly Cache), but it is well thought out in respect to M$ probelm and is capable of maintaining multiple versions of the same Assemblies (think jars) and using the correct one, either the newest or a specified version. I haven't investigated it too deeply but I have a feeling that where two bits of the same application depend on different versions of the same assembly this is taken care of properly too. From what I can see it relies heavily on code signing to deliver secure name spaces and version identification, and prevent unintentional namespace conflicts. Thus anyone can download and install multiple versions (or your application installer can do it) where necessary, and you only need to install each required Assembly-version once per machine. I expect anyone suggesting that jakarta, or anyone else java-esque, should mimic M$ would be rightly laughed off the pitch but as the problem is the same it would seem sensible to at least examine the GAC and consider its pros and cons when formulating ideas for a java jar management solution. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
Shame it's LGPL. At 03:59 AM 15/03/2003, you wrote: I would say check out Greebo http://www.discore.com/oz/new/index.htm a light-weight version of Maven (I'm grossly oversimplifying) and combine this with some of the other magic Ant gives you (described in section 8.4 Handling Versioned Dependencies of Erik Hatcher's Ant book). Together these should go a long way. The simpler approach would likely be to just use Maven (as suggested by others). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
Why can't the POM be stored in the artifact itself? Assuming most Maven projects generate JAR artifacts, couldn't you store the POM in the JAR, like in META-INF/maven/project.xml, and then use that info at runtime? Seems like all you would need is some bootstrap class (a modified forehead?) that knows where to find JAR artifacts (the runtime equivalent to the current maven.repository); When requested to start a main class from a given JAR, it would read the POM from the JAR, and start looking up the necessary runtime JARs dependencies (declared in the POM) in the repository(ies). If these JAR dependencies in turn also contain their own POM, you can fully resolve the dependencies (transitive closure). Or am I completely in left field? --DD -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:53 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote: Why can't the POM be stored in the artifact itself? That certainly can be done and has been suggested, but the POM can be uesd for so many other things. It's certainly one of the routes we could go. Assuming most Maven projects generate JAR artifacts, couldn't you store the POM in the JAR, like in META-INF/maven/project.xml, and then use that info at runtime? Seems like all you would need is some bootstrap class (a modified forehead?) that knows where to find JAR artifacts (the runtime equivalent to the current maven.repository); When requested to start a main class from a given JAR, it would read the POM from the JAR, and start looking up the necessary runtime JARs dependencies (declared in the POM) in the repository(ies). If these JAR dependencies in turn also contain their own POM, you can fully resolve the dependencies (transitive closure). Or am I completely in left field? --DD Nope, that's what I'm doing to create avalon runtimes. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:53 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so many jars
Could you please provide a link where to start looking to try to understand how you are doing it? Like maybe a ViewCVS link? Thanks, --DD -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 5:08 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote: Why can't the POM be stored in the artifact itself? That certainly can be done and has been suggested, but the POM can be uesd for so many other things. It's certainly one of the routes we could go. Assuming most Maven projects generate JAR artifacts, couldn't you store the POM in the JAR, like in META-INF/maven/project.xml, and then use that info at runtime? Seems like all you would need is some bootstrap class (a modified forehead?) that knows where to find JAR artifacts (the runtime equivalent to the current maven.repository); When requested to start a main class from a given JAR, it would read the POM from the JAR, and start looking up the necessary runtime JARs dependencies (declared in the POM) in the repository(ies). If these JAR dependencies in turn also contain their own POM, you can fully resolve the dependencies (transitive closure). Or am I completely in left field? --DD Nope, that's what I'm doing to create avalon runtimes. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 4:53 PM To: Jakarta General List Subject: RE: so many jars On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: at compile-time maybe :) But you still end up with jar duplication, you just get to avoid having to think about it too much when compiling. I agree that maven has an excellent jar dependency solution for compile-time, but I don't think there exists any (standard) solution for run-time dependencies in java. This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. Using a system level $CLASSPATH variable becomes painful (as was mentioned). The general solution seems to be a hierarchal set of /lib directories. To have a true run-time jar dependency solution you would need a standard installation and launch mechanism. I suppose something based on JNLP (WebStart) plus some sort of ports or emerge system could do this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so many jars
On Friday, March 14, 2003, at 06:08 PM, Jason van Zyl wrote: maven.repository); When requested to start a main class from a given JAR, it would read the POM from the JAR, and start looking up the necessary runtime JARs dependencies (declared in the POM) in the repository(ies). If these JAR dependencies in turn also contain their own POM, you can fully resolve the dependencies (transitive closure). Or am I completely in left field? --DD Nope, that's what I'm doing to create avalon runtimes. And component metadata? Please share code :) -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
