Anyone interested in the Gradle build, please comment on SOLR-13915

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Anyone interested in the Gradle build, please comment on SOLR-13915

Erick Erickson
In a nutshell, it doesn’t look like there’s any task that populates:

../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/

with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?

“gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:

assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
 
Assemble - Class in org.gradle.language.assembler.tasks
Translates Assembly language source files into object files.

so I haven’t a clue what’s up with that task.

Thanks,
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Dawid Weiss-2
I can handle this, Erick (on the branch). In short, "assemble" is a
task added by the "base" gradle plugin. This is just a placeholder for
things that should be "assembled" in the project. The java plugin puts
together a jar file from compiled classes, for example.

Gradle projects typically don't collect dependency jars anywhere (they
suck them in from caches without copying whenever they're needed). We
can copy them over though -- this is simple.

D.

On Sat, Nov 16, 2019 at 3:44 AM Erick Erickson <[hidden email]> wrote:

>
> In a nutshell, it doesn’t look like there’s any task that populates:
>
> ../solr/server/solr-webapp/webapp/WEB-INF/lib/
> ../solr/server/lib/ext/
> ../solr/server/lib/
>
> with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?
>
> “gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:
>
> assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
>
> Assemble - Class in org.gradle.language.assembler.tasks
> Translates Assembly language source files into object files.
>
> so I haven’t a clue what’s up with that task.
>
> Thanks,
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Martin Gainty
In reply to this post by Erick Erickson
good catch on what happens when my jar is not located in specified lib folder?

public repositories:
==============
all jars and model declarators should be discoverable in one of these public repositories
maven  https://central.maven.org/
ant        https://repo1.maven.org/maven2/ant/
gradle   https://repo.maven.apache.org/maven2/

local repositories:
=========================
during a build you will find jars (or redirects) being downloaded to local repository such as
maven $user.home/.m2/repository
gradle $user.home/.gradle/caches
ant $user.home/.ant/lib

but be aware gradle likes to reference module name instead of using gav maven coords
so say you are compiling minecraft
$user.home/.gradle/caches/minecraft/net/minecraftforge/forge/

be aware the label that gradle will reference to fetch from caches is 'minecraft'

but adding 'mincecraft' to gradle varies based on which ide you use..reference:
https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project


resolving version:
=============
plugins and dependency without versions in maven default to latest so in maven land
com.erickson
erick-1.0
        -1.1
<dependency>
 <groupId>com.erickson</groupId>
<artifactId>erick</artifact>
</dependency>
would pull 1.1 version (latest-version) from central repository(s)

when version not specified gradle will apparently resolves to newest (latest modification date) e.g.
com.erickson
 -erick 
   -1.0 modification date 11/16/2019
   -1.1 modification date 11/01/2019
sans version.... gradle will auto-select the latest mod-date (version of 1.0 version)

as this is clear as mud i invite correction

does this help?
M-


From: Erick Erickson <[hidden email]>
Sent: Friday, November 15, 2019 9:44 PM
To: [hidden email] <[hidden email]>
Subject: Anyone interested in the Gradle build, please comment on SOLR-13915
 
In a nutshell, it doesn’t look like there’s any task that populates:

../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/

with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?

“gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:

assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
 
Assemble - Class in org.gradle.language.assembler.tasks
Translates Assembly language source files into object files.

so I haven’t a clue what’s up with that task.

Thanks,
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Erick Erickson
Thanks both. So the gradle build will create a large number of jar files for our modules and, when working late on Friday a fella can find them scattered about and think “the dependency jar files must be in there too”. When they’re not ;). Just looked again and… there are indeed no jar files for our dependencies in the tree after the build. The one advantage to making mistakes like this is that I actually _remember_ the issue ;)

Eventually we need two things:
> get enough stuff in the right place for “bin/solr start -e techproducts” to work
> be able to add some libraries to a classpath and compile some custom SolrJ code. For this I always point to “dist” and “dist/solrj-libs”.  

executing “ant server” let’s me do both of these things. There’s also a “dist” target, but I’ve never understood why we have both

OK, I’ll see if I can get _ant_ tests to run for a while, the Korean one doesn’t work on the gradle branch.

Erick

> On Nov 16, 2019, at 8:16 AM, Martin Gainty <[hidden email]> wrote:
>
> good catch on what happens when my jar is not located in specified lib folder?
>
> public repositories:
> ==============
> all jars and model declarators should be discoverable in one of these public repositories
> maven  https://central.maven.org/
> ant        https://repo1.maven.org/maven2/ant/
> gradle   https://repo.maven.apache.org/maven2/
>
> local repositories:
> =========================
> during a build you will find jars (or redirects) being downloaded to local repository such as
> maven $user.home/.m2/repository
> gradle $user.home/.gradle/caches
> ant $user.home/.ant/lib
>
> but be aware gradle likes to reference module name instead of using gav maven coords
> so say you are compiling minecraft
> $user.home/.gradle/caches/minecraft/net/minecraftforge/forge/
>
> be aware the label that gradle will reference to fetch from caches is 'minecraft'
>
>
> but adding 'mincecraft' to gradle varies based on which ide you use..reference:
>
> https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project
>
>
> android - How to include module to the project? - Stack Overflow
> Clone the repository which you want to be included as a module. Provide the path of your cloned repository. Now suppose if I want to include Calendar module to my project.
> stackoverflow.com
>
> resolving version:
> =============
> plugins and dependency without versions in maven default to latest so in maven land
> com.erickson
> erick-1.0
>         -1.1
> <dependency>
>  <groupId>com.erickson</groupId>
> <artifactId>erick</artifact>
> </dependency>
> would pull 1.1 version (latest-version) from central repository(s)
>
> when version not specified gradle will apparently resolves to newest (latest modification date) e.g.
> com.erickson
>  -erick
>    -1.0 modification date 11/16/2019
>    -1.1 modification date 11/01/2019
> sans version.... gradle will auto-select the latest mod-date (version of 1.0 version)
>
> as this is clear as mud i invite correction
>
> does this help?
> M-
>
> From: Erick Erickson <[hidden email]>
> Sent: Friday, November 15, 2019 9:44 PM
> To: [hidden email] <[hidden email]>
> Subject: Anyone interested in the Gradle build, please comment on SOLR-13915
>  
> In a nutshell, it doesn’t look like there’s any task that populates:
>
> ../solr/server/solr-webapp/webapp/WEB-INF/lib/
> ../solr/server/lib/ext/
> ../solr/server/lib/
>
> with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?
>
> “gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:
>
> assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
>  
> Assemble - Class in org.gradle.language.assembler.tasks
> Translates Assembly language source files into object files.
>
> so I haven’t a clue what’s up with that task.
>
> Thanks,
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Dawid Weiss-2
In reply to this post by Martin Gainty

I don't think the details of how gradle locates (or stores) a particular dependency matter much. As long as the dependency is resolvable (and the signature matches the one initially added to the repository) we're fine.

For most things (running tests, sha checks, etc.) the dependency JARs don't have to be copied to the project (and why should they be). The only exception is packaging final distribution. 

The way we currently handle things in ant/ ivy (copying to lib/ folders local to the project) is only there because of technological legacy. I don't think we should stick to it.

Dawid

On Sat, Nov 16, 2019 at 2:16 PM Martin Gainty <[hidden email]> wrote:
good catch on what happens when my jar is not located in specified lib folder?

public repositories:
==============
all jars and model declarators should be discoverable in one of these public repositories
maven  https://central.maven.org/
ant        https://repo1.maven.org/maven2/ant/
gradle   https://repo.maven.apache.org/maven2/

local repositories:
=========================
during a build you will find jars (or redirects) being downloaded to local repository such as
maven $user.home/.m2/repository
gradle $user.home/.gradle/caches
ant $user.home/.ant/lib

but be aware gradle likes to reference module name instead of using gav maven coords
so say you are compiling minecraft
$user.home/.gradle/caches/minecraft/net/minecraftforge/forge/

be aware the label that gradle will reference to fetch from caches is 'minecraft'

but adding 'mincecraft' to gradle varies based on which ide you use..reference:
https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project

Clone the repository which you want to be included as a module. Provide the path of your cloned repository. Now suppose if I want to include Calendar module to my project.

resolving version:
=============
plugins and dependency without versions in maven default to latest so in maven land
com.erickson
erick-1.0
        -1.1
<dependency>
 <groupId>com.erickson</groupId>
<artifactId>erick</artifact>
</dependency>
would pull 1.1 version (latest-version) from central repository(s)

when version not specified gradle will apparently resolves to newest (latest modification date) e.g.
com.erickson
 -erick 
   -1.0 modification date 11/16/2019
   -1.1 modification date 11/01/2019
sans version.... gradle will auto-select the latest mod-date (version of 1.0 version)

as this is clear as mud i invite correction

does this help?
M-


From: Erick Erickson <[hidden email]>
Sent: Friday, November 15, 2019 9:44 PM
To: [hidden email] <[hidden email]>
Subject: Anyone interested in the Gradle build, please comment on SOLR-13915
 
In a nutshell, it doesn’t look like there’s any task that populates:

../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/

with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?

“gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:

assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
 
Assemble - Class in org.gradle.language.assembler.tasks
Translates Assembly language source files into object files.

so I haven’t a clue what’s up with that task.

Thanks,
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Uwe Schindler
+1

Uwe

Am November 16, 2019 4:09:57 PM UTC schrieb Dawid Weiss <[hidden email]>:

I don't think the details of how gradle locates (or stores) a particular dependency matter much. As long as the dependency is resolvable (and the signature matches the one initially added to the repository) we're fine.

For most things (running tests, sha checks, etc.) the dependency JARs don't have to be copied to the project (and why should they be). The only exception is packaging final distribution. 

The way we currently handle things in ant/ ivy (copying to lib/ folders local to the project) is only there because of technological legacy. I don't think we should stick to it.

Dawid

On Sat, Nov 16, 2019 at 2:16 PM Martin Gainty <[hidden email]> wrote:
good catch on what happens when my jar is not located in specified lib folder?

public repositories:
==============
all jars and model declarators should be discoverable in one of these public repositories
maven  https://central.maven.org/
ant        https://repo1.maven.org/maven2/ant/
gradle   https://repo.maven.apache.org/maven2/

local repositories:
=========================
during a build you will find jars (or redirects) being downloaded to local repository such as
maven $user.home/.m2/repository
gradle $user.home/.gradle/caches
ant $user.home/.ant/lib

but be aware gradle likes to reference module name instead of using gav maven coords
so say you are compiling minecraft
$user.home/.gradle/caches/minecraft/net/minecraftforge/forge/

be aware the label that gradle will reference to fetch from caches is 'minecraft'

but adding 'mincecraft' to gradle varies based on which ide you use..reference:
https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project

Clone the repository which you want to be included as a module. Provide the path of your cloned repository. Now suppose if I want to include Calendar module to my project.

resolving version:
=============
plugins and dependency without versions in maven default to latest so in maven land
com.erickson
erick-1.0
        -1.1
<dependency>
 <groupId>com.erickson</groupId>
<artifactId>erick</artifact>
</dependency>
would pull 1.1 version (latest-version) from central repository(s)

when version not specified gradle will apparently resolves to newest (latest modification date) e.g.
com.erickson
 -erick 
   -1.0 modification date 11/16/2019
   -1.1 modification date 11/01/2019
sans version.... gradle will auto-select the latest mod-date (version of 1.0 version)

as this is clear as mud i invite correction

does this help?
M-


From: Erick Erickson <[hidden email]>
Sent: Friday, November 15, 2019 9:44 PM
To: [hidden email] <[hidden email]>
Subject: Anyone interested in the Gradle build, please comment on SOLR-13915
 
In a nutshell, it doesn’t look like there’s any task that populates:

../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/

with jar files. So "solr/bin/solr start” simply can’t start since it defines CLASSPATH to point to them. Before I try to mimic the Ant build that populates these, should we re-think how these are populated and/or where they live?

“gradlew assemble” pulls the jars down, but I sure can’t find anywhere where that task is defined, and the Gradle javadocs say things like:

assemble() - Method in class org.gradle.language.assembler.tasks.Assemble
 
Assemble - Class in org.gradle.language.assembler.tasks
Translates Assembly language source files into object files.

so I haven’t a clue what’s up with that task.

Thanks,
Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Erick Erickson
In reply to this post by Dawid Weiss-2
bq. For most things (running tests, sha checks, etc.) the dependency JARs don't have to be copied to the project (and why should they be).

Sure.

bq. The only exception is packaging final distribution.

I’ve really got to disagree here when it comes to Solr. I dive into and out of building/running Solr many times a day. Having to package it all up then explode it just to check something and/or explore a problem is a waste.

And at this point I don’t see how to start Solr at all. Even if I execute the “packageDist” task and produce a tgz and zip file, when those are exploded the ../solr/bin directory isn’t there, so no ../solr/bin/solr script to start an instance etc.

So what it looks like to me is that the work has been done on running tests (a big job to be sure), but there’s nothing yet that’ll allow us to actually run Solr, either in a distro or as part of development. Perhaps making it work for the distro will also fix the development need. Of course I may be missing some obvious target, wouldn’t be the first time.

I’m open to working on Solr differently than I’m accustomed to, but I have to be able to make a change to Solr and then start Solr using that change conveniently. Going through the cycle of having to package it up and explode it just to do that is unacceptable.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Dawid Weiss-2
> I’ve really got to disagree here when it comes to Solr. I dive into and out of building/running Solr many times a day. Having to package it all up then explode it just to check something and/or explore a problem is a waste.

It's not really like this. With gradle you can set up a packaging
folder (under build/) so that it is synced with any required resources
(and this is done only if necessary, incrementally). Creating a
compressed package is just the finalizing step from that location. All
this is lighting fast.

I don't want to fight people who work with Solr -- I don't do much
development with Solr these days and like I said I don't even
understand why there are so many different "packaging" ant tasks and
what they actually do. My experience just tells me that keeping build
files mixed with source locations is not really convenient. Gradle
solves it in an elegant way (but sure - it's a subjective point of
view).

> And at this point I don’t see how to start Solr at all. Even if I execute the “packageDist” task and produce a tgz and zip file, when those are exploded the ../solr/bin directory isn’t there, so no ../solr/bin/solr script to start an instance etc.

I'll take a look at it this weekend, Erick, but you need to give me some time.

> Going through the cycle of having to package it up and explode it just to do that is unacceptable.

I need to take a look at the branch status vs. master first (vide your
remarks about tests failing). Then I need to understand how to package
Solr (from the various bits of ant code) and finally write this in
gradle. I'll let you know how far I can get this over the weekend.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Erick Erickson
Hmmm, I’ll have to start looking at this then. There may be two separate issues here:

1> for developers, a convenient way to just compile-and-go, i.e. starting a Solr instance after a build. I certainly won’t attempt to insist that I can do it the same way we did in the Ant world if there’s a better “gradle way”, and it sounds like there is.

2> The packageDist task seems incomplete given that when I tried that and unpacked the tarball, the usual way to start Solr was missing (no solr/bin/solr script to be specific).

<1> is more important IMO short term if we’re going to try to get people to kick the tires in their daily work, <2> is a blocker before cutting over completely some time in the future.

And I’ll happily take a break from this and see if I can figure out why the ant test fails for TestKoreanTokenizer. That’s what I was trying to do when I got sidetracked. Figured “Well, let’s merge things from master just to eliminate that possibility” and all hell broke loose.

Thanks again,
Erick



> On Nov 16, 2019, at 2:02 PM, Dawid Weiss <[hidden email]> wrote:
>
>> I’ve really got to disagree here when it comes to Solr. I dive into and out of building/running Solr many times a day. Having to package it all up then explode it just to check something and/or explore a problem is a waste.
>
> It's not really like this. With gradle you can set up a packaging
> folder (under build/) so that it is synced with any required resources
> (and this is done only if necessary, incrementally). Creating a
> compressed package is just the finalizing step from that location. All
> this is lighting fast.
>
> I don't want to fight people who work with Solr -- I don't do much
> development with Solr these days and like I said I don't even
> understand why there are so many different "packaging" ant tasks and
> what they actually do. My experience just tells me that keeping build
> files mixed with source locations is not really convenient. Gradle
> solves it in an elegant way (but sure - it's a subjective point of
> view).
>
>> And at this point I don’t see how to start Solr at all. Even if I execute the “packageDist” task and produce a tgz and zip file, when those are exploded the ../solr/bin directory isn’t there, so no ../solr/bin/solr script to start an instance etc.
>
> I'll take a look at it this weekend, Erick, but you need to give me some time.
>
>> Going through the cycle of having to package it up and explode it just to do that is unacceptable.
>
> I need to take a look at the branch status vs. master first (vide your
> remarks about tests failing). Then I need to understand how to package
> Solr (from the various bits of ant code) and finally write this in
> gradle. I'll let you know how far I can get this over the weekend.
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

Michael Sokolov-4
I would start by looking at this:
https://docs.gradle.org/current/userguide/application_plugin.html?

On Sat, Nov 16, 2019 at 5:02 PM Erick Erickson <[hidden email]> wrote:

>
> Hmmm, I’ll have to start looking at this then. There may be two separate issues here:
>
> 1> for developers, a convenient way to just compile-and-go, i.e. starting a Solr instance after a build. I certainly won’t attempt to insist that I can do it the same way we did in the Ant world if there’s a better “gradle way”, and it sounds like there is.
>
> 2> The packageDist task seems incomplete given that when I tried that and unpacked the tarball, the usual way to start Solr was missing (no solr/bin/solr script to be specific).
>
> <1> is more important IMO short term if we’re going to try to get people to kick the tires in their daily work, <2> is a blocker before cutting over completely some time in the future.
>
> And I’ll happily take a break from this and see if I can figure out why the ant test fails for TestKoreanTokenizer. That’s what I was trying to do when I got sidetracked. Figured “Well, let’s merge things from master just to eliminate that possibility” and all hell broke loose.
>
> Thanks again,
> Erick
>
>
>
> > On Nov 16, 2019, at 2:02 PM, Dawid Weiss <[hidden email]> wrote:
> >
> >> I’ve really got to disagree here when it comes to Solr. I dive into and out of building/running Solr many times a day. Having to package it all up then explode it just to check something and/or explore a problem is a waste.
> >
> > It's not really like this. With gradle you can set up a packaging
> > folder (under build/) so that it is synced with any required resources
> > (and this is done only if necessary, incrementally). Creating a
> > compressed package is just the finalizing step from that location. All
> > this is lighting fast.
> >
> > I don't want to fight people who work with Solr -- I don't do much
> > development with Solr these days and like I said I don't even
> > understand why there are so many different "packaging" ant tasks and
> > what they actually do. My experience just tells me that keeping build
> > files mixed with source locations is not really convenient. Gradle
> > solves it in an elegant way (but sure - it's a subjective point of
> > view).
> >
> >> And at this point I don’t see how to start Solr at all. Even if I execute the “packageDist” task and produce a tgz and zip file, when those are exploded the ../solr/bin directory isn’t there, so no ../solr/bin/solr script to start an instance etc.
> >
> > I'll take a look at it this weekend, Erick, but you need to give me some time.
> >
> >> Going through the cycle of having to package it up and explode it just to do that is unacceptable.
> >
> > I need to take a look at the branch status vs. master first (vide your
> > remarks about tests failing). Then I need to understand how to package
> > Solr (from the various bits of ant code) and finally write this in
> > gradle. I'll let you know how far I can get this over the weekend.
> >
> > Dawid
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]