Hi, Now that alpha-2 is out, I'm trying to catch up. I'd like to apply the documentation you sent - just wanted to check whether you'd made any changes after getting those clarifications?
Could you attach it to a JIRA ticket? It's preferred over email for tracking and history. Thanks, Brett > On 5/5/05, J. Matthew Pryor <[EMAIL PROTECTED]> wrote: > > OK so my (hopefully) last question then is "How do I tell what the canonical > > list of 'Implied plugins like maven-compiler-plugin' is"? > > > > Thanks for the clarification (of the clarification ;-) > > > > Matthew > > > > > -----Original Message----- > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 05, 2005 3:01 AM > > > To: Maven Users List > > > Subject: Re: [m2] POM inheritance > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Alright, this is the part where I print a complete retraction > > > of everything I just emailed to the list... :) > > > > > > Next time, I promise, I'll actually re-read the code and/or > > > do some Right-Click -> References -> Project in Eclipse for a > > > given piece of code before I shoot my mouth off. In reality, > > > Brett is 100% correct (he should be, he's looking at the code > > > right now :). Implied plugins like maven-compiler-plugin will > > > also trigger the configurations in <pluginManagement/> on a > > > plugin-by-plugin basis. So, in reality, both of the examples > > > that I gave below will work to configure the compiler plugin. > > > > > > Sorry for the confusion, and I'll try not to yell my comments > > > in from the other room next time. :) > > > > > > john > > > > > > John Casey wrote: > > > > I have a refinement or two to this... > > > > > > > > Brett Porter wrote: > > > > > > > >>>John has just made a final fix. So, to summarise the > > > behaviour here: > > > >>> > > > >>>- <pluginManagement /> is inherited > > > >>>- <configuration/> elements are merged together during inheritence > > > >>>- <plugins/> is NOT inherited > > > >>>- the final plugin management values are merged into the > > > <plugins/> > > > >>>element of the POM being built. > > > > > > > > > > > > This is critical: the <pluginManagement/> configurations are ONLY > > > > activated if you declare a corresponding <plugin/> entry in > > > the build > > > > section's <plugins/> stanza. pluginManagement is an opt-in > > > system; it > > > > will only affect your build if you specifically invite it in. Also, > > > > you cannot opt-in for all of the managed configuration at one go. > > > > > > > > To be clear: The only way to use the configuration declared within > > > > <pluginManagement/> section is to declare a corresponding <plugin/> > > > > entry within <build><plugins/></build>. The minimal information > > > > necessary to link a build's actual plugin to the > > > corresponding managed > > > > plugin information is <groupId/> and <artifactId/>. > > > > > > > > This WILL NOT configure the source/target properties of the > > > > maven-compiler-plugin: > > > > > > > > <project> > > > > ... > > > > <build> > > > > <pluginManagement> > > > > <plugins> > > > > <plugin> > > > > <groupId>org.apache.maven.plugins</groupId> > > > > <artifactId>maven-compiler-plugin</artifactId> > > > > <version>1.0-alpha-1</version> > > > > <configuration> > > > > <source>1.5</source> > > > > <target>1.5</target> > > > > </configuration> > > > > </plugin> > > > > </plugins> > > > > </pluginManagement> > > > > </build> > > > > </project> > > > > > > > > The managed information will ONLY be used when you opt-in for that > > > > configuration by declaring the plugin for use in the build > > > section, like so: > > > > > > > > <project> > > > > ... > > > > <build> > > > > <pluginManagement> > > > > <plugins> > > > > <plugin> > > > > <groupId>org.apache.maven.plugins</groupId> > > > > <artifactId>maven-compiler-plugin</artifactId> > > > > <version>1.0-alpha-1</version> > > > > <configuration> > > > > <source>1.5</source> > > > > <target>1.5</target> > > > > </configuration> > > > > </plugin> > > > > </plugins> > > > > </pluginManagement> > > > > > > > > <!-- THIS IS REQUIRED TO "OPT IN" TO THE MANAGED CONFIGURATION. --> > > > > <plugins> > > > > <plugin> > > > > <groupId>org.apache.maven.plugins</groupId> > > > > <artifactId>maven-compiler-plugin</artifactId> > > > > </plugin> > > > > </plugins> > > > > </build> > > > > </project> > > > > > > > > Looking at this, I'm not 100% convinced that the implicit > > > > configuration of maven-compiler-plugin is not > > > appropriate...the only > > > > question in that case is how to undo this configuration, > > > which has the > > > > same answer as undoing any configuration element: don't put > > > it in the > > > > shared configuration in the first place. All I'm attempting > > > to do here > > > > is describe the way the current process functions...this > > > may change in > > > > the future. > > > > > > > > > > > >>>The downside here is that there is no way to exclude > > > something that > > > >>>has already been declared in a parent. This is intended - > > > if you come > > > >>>across the situation you can redefine it with a different > > > value, or > > > >>>you should not inherit the value. > > > >>> > > > >>>Why was this chosen, given the downside? > > > >>> > > > >>>The downside of going the other direction (where > > > configuration would > > > >>>completely replace anything given by the inherited > > > version) was much > > > >>>more confusing: options set for inheritence would have disappeared > > > >>>from children. > > > >>> > > > >>>If anyone has any questions, please say so. J. Matthew Pryor has > > > >>>volunteered to help document this, so it should be > > > available on the > > > >>>web site in time. > > > >>> > > > >>>Cheers, > > > >>>Brett > > > >>> > > > >>>On 4/28/05, Peter van de Hoef <[EMAIL PROTECTED]> wrote: > > > >>> > > > >>> > > > >>>>Hi John, > > > >>>> > > > >>>>I've been away for a while and see that a lot of activity > > > has been going on in the meantime! > > > >>>>Since I am just an m2 newbee, I cannot oversee if the > > > issues arround > > > >>>><plugins> and <pluginManagement> sections have been > > > resolved now. So > > > >>>>I filed the <pluginManagement> issue anyway > > > (http://jira.codehaus.org/browse/MNG-362). Please ignore it > > > if it has already been fixed now. > > > >>>> > > > >>>>I will try to build the latest from SVN and perform some > > > tests with my own projects. > > > >>>> > > > >>>>Thanks for all the good work. > > > >>>>Peter van de Hoef > > > >>>> > > > >>>>John Casey wrote: > > > >>>> > > > >>> > > > >>>I'm looking at: > > > >>> > > > >>>- > > > >>>org.apache.maven.project.inheritance.DefaultModelInheritanc > > > eAssembler > > > >>>- org.apache.maven.project.injection.DefaultModelDefaultsInjector > > > >>> > > > >>>and here's what I see: > > > >>> > > > >>>- Combination of inherited <pluginManagement/> sections > > > (both parent > > > >>>and child have <pluginManagement/> stuff defined): > > > >>>----------------------------------------------------------- > > > ---------- > > > >>>- > > > >>> > > > >>>Everything is merged, with locally specified elements overriding > > > >>>ancestor-specified elements in the event of a tie. > > > >>> > > > >>>NOTE: There was a problem with the <configuration/> of a > > > plugin not > > > >>>being merged. I'm fixing this as we speak, although it's > > > not going to > > > >>>be in alpha-1 obviously... :) > > > >>> > > > >>> > > > >>> > > > >>>- Combination of local POM's <plugins/> with [inherited] > > > >>><pluginManagement/> section: > > > >>>----------------------------------------------------------- > > > ---------- > > > >>>- > > > >>> > > > >>>HOW IT WORKS: <configuration/> elements (both on <goal/> and on > > > >>><plugin/>) are combined, with ties going to the local > > > configuration > > > >>>(if the elements collide, the local specification wins). > > > The list of > > > >>>goals is accumulated, with the previous note applying to > > > collisions of goals. > > > >>>That is, if the <pluginManagement/> section specifies some > > > goals and > > > >>>their configuration for a given plugin, and the <plugin/> section > > > >>>specifies some goals, the goal definitions from the > > > >>><pluginManagement/> section are merged into the one from > > > the plugin specification itself. > > > >>> > > > >>>NOTE-TO-SELF: Now that I look at this, it might not be a > > > Good Thing(tm). > > > >>>For instance, how would I suppress a goal that was declared in > > > >>><pluginManagement/> but allow other goals from that plugin to run? > > > >>>How would I suppress plugin configuration declared similarly? > > > >>> > > > >>>HOW I'M FIXING IT TO WORK: Any <configuration/> or > > > <goals/> element > > > >>>specified within a plugin in a local POM will negate the > > > usage of the > > > >>>corresponding element in the <pluginManagement/> section for that > > > >>>plugin. This allows users to specify local overrides > > > without having > > > >>>to deal with the accumulation of common settings which are > > > wrong for > > > >>>the local case but which are not overridden in the local > > > POM. It also > > > >>>makes the override mechanism more consistent with > > > <dependencyManagement/>. > > > >>> > > > >>>These changes will not be available to -alpha-1, obviously, but > > > >>>should work on the svn-trunk in a few minutes. > > > >>> > > > >>> > > > >>>Hope this clears things up somewhat. :) > > > >>> > > > >>>Cheers, > > > >>> > > > >>>-john > > > >>> > > > >>> > > > >>>J. Matthew Pryor wrote: > > > >>> > > > >>> > > > >>> > > > >>>>>From the docs here > > > >>>>http://maven.apache.org/maven2/project-descriptor.html#Bui > > > ld about > > > >>>>the <pluginManagement/> element > > > >>> > > > >>>>Any local configuration for a given plugin will override the > > > >>>>plugin's entire definition here. > > > >>> > > > >>>>So what constitutes 'local configuration'. If I am to > > > reference the > > > >>>>plugin, enough to invoke the configuration supplied in a parent > > > >>>><pluginManagement/>, how do I do that without overriding > > > the plugin's entire definition? > > > >>> > > > >>>>Also am I understanding correctly that <build><plugins/> > > > setting are > > > >>>>never inherited? > > > >>> > > > >>>>BTW I am making good progress writing all this up for the > > > user docs. > > > >>>>Definitely need this clarification > > > >>> > > > >>>>jmp > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>-----Original Message----- > > > >>>>>From: Peter van de Hoef [mailto:[EMAIL PROTECTED] > > > >>>>>Sent: Wednesday, April 27, 2005 6:32 PM > > > >>>>>To: Maven Users List > > > >>>>>Subject: Re: [m2] POM inheritance > > > >>>>> > > > >>>>>Hi John, > > > >>>>> > > > >>>>>Thanks for your help. So <pluginManagement> is used for > > > specifying > > > >>>>>plugin versions and configuration parameters, whether > > > they are used > > > >>>>>or not. This will be inherited by child projects. The <plugins> > > > >>>>>section is just a list of plugins that will actually be > > > used. This > > > >>>>>list has to be repeated in a child project though, whenever a > > > >>>>>setting of build-section has to be changed. > > > >>>>> > > > >>>>>Now, I have specified a <pluginManagement> section in the parent > > > >>>>>POM, in the hope that it gets inherited by derived > > > projects, but it > > > >>>>>does not; in the child project, the java compiler starts > > > >>>>>complaining about assertions again. > > > >>>>> > > > >>>>>The only way to solve this is to repeat myself by > > > inserting a copy > > > >>>>>of the <pluginManagement> section of the parent into the child. > > > >>>>> > > > >>>>>If I look at 'DefaultModelInheritanceAssembler.java' it appears > > > >>>>>that the assemblePluginManagementInheritance() > > > >>>>>function correctly takes care of <pluginManagement> > > > sections of the > > > >>>>>parent. > > > >>>>>What is going wrong here? Did I miss something in the > > > project defs? > > > >>>>> > > > >>>>>The parent POM looks like: > > > >>>>> > > > >>>>><project> > > > >>>>> > > > >>>>> <name>Parent POM</name> > > > >>>>> > > > >>>>> <groupId>_test</groupId> > > > >>>>> <artifactId>parent</artifactId> > > > >>>>> <version>1.0</version> > > > >>>>> <packaging>pom</packaging> > > > >>>>> > > > >>>>> <modules> > > > >>>>> <module>child</module> > > > >>>>> </modules> > > > >>>>> > > > >>>>> <build> > > > >>>>> <sourceDirectory>src</sourceDirectory> > > > >>>>> > > > >>>>> <pluginManagement> > > > >>>>> <plugins> > > > >>>>> <plugin> > > > >>>>> > > > >>>>><groupId>org.apache.maven.plugins</groupId> > > > >>>>> > > > >>>>><artifactId>maven-compiler-plugin</artifactId> > > > >>>>> > > > >>>>><version>1.0-alpha-2-SNAPSHOT</version> > > > >>>>> <configuration> > > > >>>>> <source>1.5</source> > > > >>>>> <target>1.5</target> > > > >>>>> </configuration> > > > >>>>> </plugin> > > > >>>>> </plugins> > > > >>>>> </pluginManagement> > > > >>>>> > > > >>>>> <plugins> > > > >>>>> <plugin> > > > >>>>> > > > >>>>><groupId>org.apache.maven.plugins</groupId> > > > >>>>> > > > >>>>><artifactId>maven-compiler-plugin</artifactId> > > > >>>>> </plugin> > > > >>>>> </plugins> > > > >>>>> </build> > > > >>>>> > > > >>>>></project> > > > >>>>> > > > >>>>>And the child, which inherits from the parent: > > > >>>>>The <build> section is overridden with a different > > > >>>>><sourceDirectory> and, since the <plugins> of the parent > > > gets lost, > > > >>>>>it is repeated. > > > >>>>> > > > >>>>><project> > > > >>>>> > > > >>>>> <name>Child POM</name> > > > >>>>> > > > >>>>> <groupId>_test</groupId> > > > >>>>> <artifactId>child</artifactId> > > > >>>>> <version>1.0</version> > > > >>>>> <packaging>pom</packaging> > > > >>>>> > > > >>>>> <parent> > > > >>>>> <groupId>_test</groupId> > > > >>>>> <artifactId>parent</artifactId> > > > >>>>> <version>1.0</version> > > > >>>>> </parent> > > > >>>>> > > > >>>>> <build> > > > >>>>> <sourceDirectory>src2</sourceDirectory> > > > >>>>> <plugins> > > > >>>>> <plugin> > > > >>>>> > > > >>>>><groupId>org.apache.maven.plugins</groupId> > > > >>>>> > > > >>>>><artifactId>maven-compiler-plugin</artifactId> > > > >>>>> </plugin> > > > >>>>> </plugins> > > > >>>>> </build> > > > >>>>></project> > > > >>>>> > > > >>>>>Thanks in advance, > > > >>>>>Peter van de Hoef > > > >>>>> > > > >>>>>John Casey wrote: > > > >>>>> > > > >>> > > > >>>>Sorry, I forgot all about the design decisions surrounding > > > >>> > > > >>> > > > >>>>>>this... :) > > > >>> > > > >>> > > > >>>>Actually, our original decision was to disallow > > > inheritance of any > > > >>>>plugin configuration, since plugin configuration can (and usually > > > >>>>will) modify the build lifecycle for that project. In light > > > >>> > > > >>> > > > >>>>>>of this, > > > >>> > > > >>> > > > >>>>inherited plugin configuration could lead to somewhat > > > >>>>counter-intuitive build behavior. > > > >>> > > > >>>>We have a <pluginManagement/> section of the POM for common > > > >>>>configuration of plugins for use within a typical > > > >>> > > > >>> > > > >>>>>>multiproject-style > > > >>> > > > >>> > > > >>>>setup. It would be used like this: > > > >>> > > > >>>>parent-pom.xml > > > >>>>------------------- > > > >>>>... > > > >>>><pluginManagement> > > > >>>> <plugins> > > > >>>> <plugin> > > > >>>> <groupId>org.apache.maven.plugin</groupId> > > > >>>> <artifactId>maven-something-plugin</artifactId> > > > >>>> <version>1.4</version> > > > >>>> <configuration> > > > >>>> <someParam>someValue</someParam> > > > >>>> </configuration> > > > >>>> </plugin> > > > >>>> </plugins> > > > >>>></pluginManagement> > > > >>>>... > > > >>>>------------------- > > > >>> > > > >>>>child-pom.xml > > > >>>>------------------- > > > >>>>... > > > >>>><parent> > > > >>>> <groupId>test</groupId> <!-- Pretend that all of > > > >>>> <artifactId>test-root</artifactId> | this resolves to the > > > >>>> <version>1.0</version> | parent-pom.xml above --> > > > >>>></parent> > > > >>>>... > > > >>>><build> > > > >>>> <plugins> > > > >>>> <plugin> > > > >>>> <groupId>org.apache.maven.plugin</groupId> > > > >>> > > > >>>>>><!-- groupId, > > > >>> > > > >>> > > > >>>> <artifactId>maven-something-plugin</artifactId> | > > > >>> > > > >>> > > > >>>>>>artifactId > > > >>> > > > >>> > > > >>>> </plugin> | > > > >>> > > > >>> > > > >>>>>>enough here. > > > >>> > > > >>> > > > >>>> > > > --> </build> > > > >>>>... > > > >>>>------------------- > > > >>> > > > >>>>If you need to override some setting from the pluginManagement > > > >>>>section, just specify it locally; more local specification in an > > > >>>>inheritance hierarchy wins. > > > >>> > > > >>>>Will this solve your problem? > > > >>> > > > >>>>HTH, > > > >>> > > > >>>>john > > > >>> > > > >>> > > > >>>>Peter van de Hoef wrote: > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>Thanks for your reply. > > > >>>>>Now I see why the complete <build> section is inherited > > > when it is > > > >>>>>absent in the child: > > > >>> > > > >>>>> *if* ( childBuild == *null* ) > > > >>>>> { > > > >>>>> child.setBuild( parentBuild ); > > > >>>>> } > > > >>>>> *else* > > > >>>>> { > > > >>>>> /// A lot of fields are inherited, except <plugins> > > > >>>>>/ } > > > >>> > > > >>>>>I understand that inheriting plugins is problematic, since > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>Maven does > > > >>> > > > >>>>>not 'know' about the plugin parameters and cannot decide their > > > >>>>>inheritance rules. > > > >>>>>Wouldn't it be possible to inherit the complete <plugins> > > > >>>>> > > > >>>>>>section if > > > >>> > > > >>>>>it is not specified in the child, just like you do with > > > <resources> > > > >>>>>and <testResources>? > > > >>>>>That seems IMHO more in line with the situation where > > > there is no > > > >>>>><build> section at all. In that way it is possible to > > > 'tweak' the > > > >>>>>build settings slightly without losing the major build logic. > > > >>>>>- Peter > > > >>> > > > >>>>>Jason van Zyl wrote: > > > >>> > > > >>> > > > >>> > > > >>>>>>On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote: > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>Hi all, > > > >>> > > > >>>>>>>I have a question about which elements of the POM are > > > >>> > > > >>>>>>inherited by > > > >>> > > > >>> > > > >>> > > > >>>>>>>derived POM's. > > > >>>>>>> > > > >>> > > > >>> > > > >>>>>>The law on inheritance resides here: > > > >>> > > > >>>>>>http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- > > > >>>>>>project/src/main/java/org/apache/maven/project/inheritance/ > > > >>> > > > >>>>>>DefaultMod > > > >>> > > > >>>>>>elInheritanceAssembler.java?rev=164217&sortdir=down&view=log > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>>>In my parent POM I have a <build> section which specifies > > > >>> > > > >>>>>>the source > > > >>> > > > >>> > > > >>> > > > >>>>>>>directory and some parameters for the java compiler: > > > >>> > > > >>>>>>><build> > > > >>>>>>> <sourceDirectory>src</sourceDirectory> > > > >>>>>>> <plugins> > > > >>>>>>> <plugin> > > > >>>>>>> <groupId>org.apache.maven.plugins</groupId> > > > >>>>>>> <artifactId>maven-compiler-plugin</artifactId> > > > >>>>>>> <version>1.0-alpha-2-SNAPSHOT</version> > > > >>>>>>> <configuration> > > > >>>>>>> <source>1.5</source> > > > >>>>>>> <target>1.5</target> > > > >>>>>>> </configuration> > > > >>>>>>> </plugin> > > > >>>>>>> </plugins> > > > >>>>>>></build> > > > >>> > > > >>>>>>>In a derived POM, the source directoriy is different, so a new > > > >>>>>>><build> section is specified: > > > >>> > > > >>>>>>><build> > > > >>>>>>> <sourceDirectory>module/src</sourceDirectory> > > > >>>>>>></build> > > > >>> > > > >>>>>>>The overridden source directory is effectuated in this > > > >>> > > > >>>>>>second POM, > > > >>> > > > >>> > > > >>> > > > >>>>>>>but it appears that the java compiler settings have > > > >>> > > > >>>>>>disappeared (it > > > >>> > > > >>> > > > >>> > > > >>>>>>>starts e.g. complaining about JDK 1.4 features like > > > >>> > > > >>>>>>assertions). If > > > >>> > > > >>> > > > >>> > > > >>>>>>>I do not specify a <build> section in the derived POM, > > > >>> > > > >>>>>>the settings > > > >>> > > > >>> > > > >>> > > > >>>>>>>of the base POM are inherited. > > > >>> > > > >>>>>>>It appears that the <build> section is (completely) > > > >>> > > > >>>>>>inherited if it > > > >>> > > > >>> > > > >>> > > > >>>>>>>is not present in the derived POM, but if a <build> section is > > > >>>>>>>specified in the derived POM, everything from the base > > > >>> > > > >>>>>>POM is thrown > > > >>> > > > >>> > > > >>> > > > >>>>>>>away and only the settings of the derived POM are used. > > > >>>>>>>Is this correct? > > > >>>>>>> > > > >>> > > > >>> > > > >>>>>>We selectively choose what to inherit and the > > > >>> > > > >>>>>>configuration for the > > > >>> > > > >>>>>>plug-ins are a little trickier because they free form > > > >>> > > > >>>>>>configurations > > > >>> > > > >>>>>>essentially. We need to do a more careful merge of the > > > >>> > > > >>>>>>configurations > > > >>> > > > >>>>>>but this might not work generally so if we need to allow > > > >>> > > > >>>>>>the plugin > > > >>> > > > >>>>>>to determine how a configuration should be inherited then we'll > > > >>>>>>probably have to come up with some way to decide this > > > >>> > > > >>>>>>using notations > > > >>> > > > >>>>>>we have for plugins. Anyway, I see you posted a JIRA issue > > > >>> > > > >>>>>>so we'll > > > >>> > > > >>>>>>take a look at it. > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>>------------------------------------------------------------ > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>--------- > > > >>> > > > >>>>>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] > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.2.6 (GNU/Linux) > > > > > > iD8DBQFCeP/jK3h2CZwO/4URArckAJ9Lv8DBo65+87mwf6jAKtSk7acbPwCeJ6I2 > > > H1xB7lP+X2nSRxzimJOJO24= > > > =XWhd > > > -----END PGP SIGNATURE----- > > > > > > --------------------------------------------------------------------- > > > 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]
