Re: Maven2 workflow
On Fri, 22 Apr 2005, Brett Porter wrote: About the resource problem: just add your src/main/resources/ directory to the runtime classpath in the Run-Run.. - Classpath-tab, then you should be able to load it using the ClassLoader.getResource(); Though this shouldn't be necessary, since resources are copied to the target/classes/ directory, which is (should be) in the Runtime classpath autmatically. Greetings, Kenney Westerhof I'm quite new to Maven. I've decided to directly start using Maven 2.0, I can avoid a migration that way. Ok, we're happy to help out early adopters, but please keep in mind that Maven2 is alpha software, not expected to have a final release until August - so you may have to do a little work get things going properly. But what is the best workflow to use maven (2) ? For example I have an existing software project which I want to develop very incremently. Suppose I would like to do a release every week. Performing a release means: building and packaging and deploying on my own repository. We have some tools in Maven 1.0 to help prepare releases that we will be adding to 2.0-alpha-2. This manages updating the POM, tagging, etc. You may also like to use the SNAPSHOT facility to publish incremental builds, perhaps even have your continuous integration environment do that, then promote builds to be releases. Though focused on m1, these general principles might help: http://maven.apache.org/using/bestpractices.html http://maven.apache.org/using/releasing.html But I guess I can also use maven to commit my changes to cvs dialy ? You could, though I think this is really more useful for automated changes and releases. Generally, it's better to use your existing IDE and tools to review and commit changes. Does that already works with maven 2 ? Not yet, no. Question is : can I use maven for everythin except editing code ? Theoretically, but you should find the balance that best suits you :) One little thing I find annoying is this: I have restructured the layout of my sources according to the guidelines : resulting the logo of my app ending up in the directory : src/main/resources, when I compile my program using maven that is ok ofcourse. But when I want to run it from eclipse it is not. Usually there is a way to add resources to be copied to the output directory in Eclipse - I'm not sure what it is, though, being an IDEA user. Hope this helps. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Ha! Should've waited until Shakiyama Porter had his say. Could've saved myself some typing. :) -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
On 4/22/05, Kenney Westerhof [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Hmmm... The same argument could be made for removing the artifactID - so maybe it should be /artifactId/version/.jar :)) You're right, but then you have an inconsistency between how snapshots and others look, and if you were to download it over the web, you lose that version information in the filename. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How would I read a non-standard property file?
Jörg Schaible [EMAIL PROTECTED]
21-04-2005 08:52
Please respond to
Maven Users List users@maven.apache.org
To
Maven Users List users@maven.apache.org
cc
Subject
RE: How would I read a non-standard property file?
Hello,
thanks for the feedback. Will try some proposals and given feedback later.
Cheers,
Wolfgang.
Arik Kfir wrote on Wednesday, April 20, 2005 8:23 PM:
Jörg Schaible wrote:
This won't work in general. E.g. a property like maven.repo.remote is
evaluated before the first goal ever executed. Additionally if you
load properties, they are nor available in the reactors e.g.
inherited by the subprojects in multiproject. You'll have to play
with this.
If you load your properties into the current context (via the
properties tag), and then somehow translate that to a Map, you can
put it into maven's POM context (or plugin context) via
${pom.context.setVariables(myMap)}
Wouldn't that work?
Try it and give feedback ;-)
-
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: Maven2: dependencies with non-conformant file names.
Just chiming in for the first time since I started using Maven 1 (Other than asking new user questions). I have had a love/hate relationship with Maven ever since I started using it on a large project integrating the output of 4 different development groups. One of the things that has constantly frustrated is the way the enforcement of best practices interferes with the integration with tools that don't follow those best practices or interferes with the integration of existing Corporate best practices differing from Maven's own. Maven 2 already appears to have switched things over so that Maven's best practices are the easiest route to go, but not the only one. So when I deal with a tool that mandates that Jar names not contain a '-' I can make it all work. It looks like you have beaten the adages about 2.0 rewrites. Congratulations and thank you! Jim Mochel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One little thing I find annoying is this: I have restructured the layout of my sources according to the guidelines : resulting the logo of my app ending up in the directory : src/main/resources, when I compile my program using maven that is ok ofcourse. But when I want to run it from eclipse it is not. Usually there is a way to add resources to be copied to the output directory in Eclipse - I'm not sure what it is, though, being an IDEA user. The best way I've found to handle non-code resources in the classpath within Eclipse is to add a class folder. The way to do this is to open the properties for your project, select Java Build Path, then the Libraries tab. Once here, click on the Add Class Folder... button, and select your resources directory/directories, then click Ok (you can simply check off the folders you want added to your classpath). Using this approach allows you to have access to those resources from your classpath, without getting into issues of duplicate files on your sourcepath. HTH, john -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCaPQmK3h2CZwO/4URAs05AJwPxL6h+MJ0am2EGCvvzc8iw7+lpACaAtlk kzVMC/H3Pw+KolXfXpn8Q2c= =caY+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
scp vs scpexe
I have a bit of a problem understanding why these 2 (scp and scpexe) behave so differently. I know the scpexe actually calls the command while the other runs from java, but with my setup (Fedora Core 3, jdk 1.5, maven 1.0.2), the scpexe takes a very long time to complete, but works every single time. While the scp executes much faster but gives me sporadic SSH_MSG_DISCONNECT errors, sporadic in the sense that it never occurs at the same place, but still consistent enough to break any build that implies 2-3 artifact deployment. Are those known issues? I can keep things working using scpexe, but I'd really prefer getting the speed of scp... Any suggestions? Thanks, Steve
RE: Maven2: dependencies with non-conformant file names.
I am glad I started this discussion. I believe it is very useful for many developers. I totally agree with arguments for using versions; I like the structure and discipline, and I agree that it will reduce the number of errors. Software vendors like Tibco and Oracle may reconsider their artifact names when more developers use maven2. They may even use maven2 themselves and store their artifacts in accessible repositories. For now, I will just rename those few files, no big deal. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, April 24, 2005 5:50 AM To: Maven Users List Subject: Re: Maven2: dependencies with non-conformant file names. On Fri, 2005-04-22 at 09:36 +0200, Kenney Westerhof wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Here's my take on it: http://blogs.codehaus.org/projects/maven/archives/001052_why_maven_uses_ jar_names_with_versions.html -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven.test.skip help request
I am in a quandary. My junit tests require a database to run. My hibernate:schema-export task needs to have compiled java class files to run My junit tests kick off when I try to compile the java source files So there isn't a database for my junit test (or rather there is an out-of-sync one) I would like to do the following build steps (basically have more control over when my tests are run) 1) compile/war application 2) do a hibernate:schema-export 3) run tests I understand that I can set the maven.test.skip to false, but can I set it to true/false willy nilly any time that I want? Am I going against the maven currents by doing it this way? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven2 jar classpath
Kenney, You said But beware, only dependencies with scoperuntime/scope get included in the classpath.. It really behaves like that, but 1. It creates a problem. If I specify runtime then it does not compile. I managed to see runtime for the manifest when I compiled without runtime, then put it in and did deploy again. 2. It was not meant to be this way, because on http://maven.apache.org/maven2/dependencies.html it says that with default compile scope the artifact will be in all classpaths. So, I suspect it is a bug. -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 10:29 AM To: Maven Users List Subject: Re: Maven2 jar classpath On Tue, 19 Apr 2005, Ilyevsky, Leonid (Equity Trading) wrote: use this: build plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /build But beware, only dependencies with scoperuntime/scope get included in the classpath. Greetings, Kenney Westerhof As my dependency list grows, I would like maven 2 to automatically generage class path in the manifest from dependency information. How should I specify it in pom.xml? If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - 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: Maven2 jar classpath
The problem is that artifacts with the compile scope don't get into the runtime classpath, so when I use addClasspathtrue/addClasspath, they do not show up in the manifest. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 5:41 PM To: Maven Users List Subject: Re: Maven2 jar classpath 2. It was not meant to be this way, because on http://maven.apache.org/maven2/dependencies.html it says that with default compile scope the artifact will be in all classpaths. correct So, I suspect it is a bug. I don't see anywhere in the thread that you describe a bug. What's the problem? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 22, 2005, at 12:19, Mykel Alvis wrote: If the manner of accessing the repository were abstracted, one might be able to write a repository manager that would retrieve dependencies arbitrarily from a service rather than from the filesystem. For instance, someone could write a manager that, when supplied with a particular dependency, went and retrieved that dependency from a blob in a database, and was therefore referenced by an id rather than a filename. Not that the two things are different, mind you. You still have to provide some indicator for versioning as part of the id. However, based on the property service that I think we're going to work on internally here at my company, I can see a dependency service that works in a similar fashion. I don't think there's anything standing in the way of that now. Such a repository manager would simply have to speak HTTP. For instance, you define your local repository as being at the URL http://www.example.com/cgi-bin/repository. The repository script/executable receives the rest of the URL (for instance, /commons-collections/jars/commons-collections-3.1.jar) as extra path info, and can parse it or split it up or whatever and use that information to retrieve or generate the dependency as needed. I would think the biggest concern with generating dependencies on the fly would be keeping the HTTP connection from timing out. Interesting idea, though. - -- Craig S. Cottingham [EMAIL PROTECTED] OpenPGP key available from: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7977F79C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCaThTEJLQ3Hl395wRAsX6AJsF77NG6S9BX5mbWCZTmQhLnaHMgwCgrANz hebGSf/XE7xR/YIBnR2n32I= =6Px8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scp vs scpexe
Wow, the change in sshd_config had no effect (I think Protocol 2,1 is actually default), but turning on nscd seems to have solved my problem... Thanks! Steve On Fri, 2005-22-04 at 11:10 -0400, eblack wrote: It probably has more to do with the authentication method on the server. Our developers recently were experiencing problems with cvs within eclipse, where the ext method worked fine(system command ssh) but not with extssh(eclipse builtin) after our sysadmin changed over to LDAP authentication. The problems were similiar to what you describe. Our system admin turned on nscd(name service cacher) and in the /etc/ssh/sshd_config file on the server, uncommented the line that said Protocol 2,1 since the default for ssh is protocol 2 but Eclipse uses protocol 1. Assuming that Eclipse uses some basic Java ssh/scp api and Maven does the same, the problem may be the same. Hope this helps. Eric On Fri, 2005-04-22 at 10:19 -0400, Maven Users List wrote: I have a bit of a problem understanding why these 2 (scp and scpexe) behave so differently. I know the scpexe actually calls the command while the other runs from java, but with my setup (Fedora Core 3, jdk 1.5, maven 1.0.2), the scpexe takes a very long time to complete, but works every single time. While the scp executes much faster but gives me sporadic SSH_MSG_DISCONNECT errors, sporadic in the sense that it never occurs at the same place, but still consistent enough to break any build that implies 2-3 artifact deployment. Are those known issues? I can keep things working using scpexe, but I'd really prefer getting the speed of scp... Any suggestions? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 jar classpath
On 4/23/05, Ilyevsky, Leonid (Equity Trading) [EMAIL PROTECTED] wrote: The problem is that artifacts with the compile scope don't get into the runtime classpath, I'm pretty sure they do. so when I use addClasspathtrue/addClasspath, they do not show up in the manifest. Ok, there was a bug in the addClasspath handling. Fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven.test.skip help request
phillip rhodes wrote: I am in a quandary. My junit tests require a database to run. My hibernate:schema-export task needs to have compiled java class files to run My junit tests kick off when I try to compile the java source files So there isn't a database for my junit test (or rather there is an out-of-sync one) I would like to do the following build steps (basically have more control over when my tests are run) 1) compile/war application 2) do a hibernate:schema-export 3) run tests I understand that I can set the maven.test.skip to false, but can I set it to true/false willy nilly any time that I want? Am I going against the maven currents by doing it this way? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Add to your maven.xml postGoal name=test:prepare-filesystem ... jelly code to setup your database .. /postGoal This will be run after test has setup the directories but before the unit tests are run. -- Erik Husby Senior Software Engineer Broad Institute of MIT and Harvard Rm. 2192 320 Charles St, Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227, email: [EMAIL PROTECTED] AIM: ErikAtBroad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scp vs scpexe
Steve, I think the SSH_MSG_DISCONNECT problem can be solved by upgrading the dependency on jsch. Cheers, Brett On 4/23/05, Steve Molloy [EMAIL PROTECTED] wrote: Wow, the change in sshd_config had no effect (I think Protocol 2,1 is actually default), but turning on nscd seems to have solved my problem... Thanks! Steve On Fri, 2005-22-04 at 11:10 -0400, eblack wrote: It probably has more to do with the authentication method on the server. Our developers recently were experiencing problems with cvs within eclipse, where the ext method worked fine(system command ssh) but not with extssh(eclipse builtin) after our sysadmin changed over to LDAP authentication. The problems were similiar to what you describe. Our system admin turned on nscd(name service cacher) and in the /etc/ssh/sshd_config file on the server, uncommented the line that said Protocol 2,1 since the default for ssh is protocol 2 but Eclipse uses protocol 1. Assuming that Eclipse uses some basic Java ssh/scp api and Maven does the same, the problem may be the same. Hope this helps. Eric On Fri, 2005-04-22 at 10:19 -0400, Maven Users List wrote: I have a bit of a problem understanding why these 2 (scp and scpexe) behave so differently. I know the scpexe actually calls the command while the other runs from java, but with my setup (Fedora Core 3, jdk 1.5, maven 1.0.2), the scpexe takes a very long time to complete, but works every single time. While the scp executes much faster but gives me sporadic SSH_MSG_DISCONNECT errors, sporadic in the sense that it never occurs at the same place, but still consistent enough to break any build that implies 2-3 artifact deployment. Are those known issues? I can keep things working using scpexe, but I'd really prefer getting the speed of scp... Any suggestions? Thanks, Steve - 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: Maven2 jar classpath
2. It was not meant to be this way, because on http://maven.apache.org/maven2/dependencies.html it says that with default compile scope the artifact will be in all classpaths. correct So, I suspect it is a bug. I don't see anywhere in the thread that you describe a bug. What's the problem? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Craig S.Cottingham wrote: On Apr 22, 2005, at 12:19, Mykel Alvis wrote: If the manner of accessing the repository were abstracted, one might be able to write a repository manager that would retrieve dependencies arbitrarily from a service rather than from the filesystem. For instance, someone could write a manager that, when supplied with a particular dependency, went and retrieved that dependency from a blob in a database, and was therefore referenced by an id rather than a filename. Not that the two things are different, mind you. You still have to provide some indicator for versioning as part of the id. However, based on the property service that I think we're going to work on internally here at my company, I can see a dependency service that works in a similar fashion. I don't think there's anything standing in the way of that now. Such a repository manager would simply have to speak HTTP. In maven2, we use RepositoryLayout's and Wagon's to accomplish artifact and metadata resolution against some ArtifactRepository. There is nothing (from an API perspective) standing in the way of using any implementation of any of these: * RepositoryLayout: Simply returns a formatted access path for a given artifact. This has some conceptual ties to a filesystem, but those definitely could be worked with to implement a DB-based repo, for instance. * Wagon: These are the workers of the resolution world. You could implement a Wagon to retrieve an artifact from a DB, where the ArtifactRepository might contain a URL to connect to the db, and the RepositoryLayout implementation might represent a way of contstructing either query params or a fully-formed SQL query...then the wagon executes, and retrieves the artifact to a file on localhost. Again, in the API this is already possible. HOWEVER ;), there is currently a partial implementation of Wagon accessibility in Maven2 alpha-1, in that it expects to use HTTP. We haven't made that part configurable yet, I don't think. But it's coming... - -john -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCaT8aK3h2CZwO/4URAhCYAJsEeD2c7VgDhwyED2A6lZes3xsGDwCgpSXD knqyz2RLUDoHbVRWLX2eqJE= =5XG1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: changelog problem in maven 1.0.2
Is there anything in changelog.xml under your target directory? I got this same issue when I wasn't correct authentication with subversion. Successful build but no changelog.xml. On 4/22/05, Paul Roberts [EMAIL PROTECTED] wrote: The maven-changelog-plugin report is not generating a report for me. My environment is as follows: cvs 1.12.10 running on Solaris 9 maven 1.0.2 maven-changelog-plugin-1.7.2 I use ssh to connect to the cvs repository. The scm tasks within maven (scm:checkout-project and friends) work as expected. I can run the cvs command to see the activity in the repository (cvs log -d 2005-04-01) without any problems. I do not currently have a repository defined in my project.xml. I have tried putting one in there, but the results were the same. Running maven site:generate I see the following: site:run-reports: [echo] Generating the Change Log... maven-changelog-plugin:report: I do not see any cvs command-lines echoed back to me. There are no changelog xml files generated. I receivce no errors. When I run site:generate in debug, I do see this: Loading plugin 'maven-changelog-plugin-1.7.2' and maven-changelog-plugin:register: Other reports are generated without issues. Maven returns a BUILD SUCCESSFUL message. Any help appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll add my $0.02: http://blogs.codehaus.org/people/jdcasey/archives/001053_dependencies_to_version_or_not_to_version.html Cheers, - -john Jason van Zyl wrote: On Fri, 2005-04-22 at 09:36 +0200, Kenney Westerhof wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Here's my take on it: http://blogs.codehaus.org/projects/maven/archives/001052_why_maven_uses_jar_names_with_versions.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCaSa1K3h2CZwO/4URAvXNAKCcqaDKFFbXQMI1CpOIE3muiR8zdgCfRxNg HmLrtnEgcRsyy37U0Ndvz3E= =xp5B -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
