Re: Undocumented Feature: Usage of negation for profile activation
Wendy Smoak-3 wrote: It could go on http://maven.apache.org/guides/introduction/introduction-to-profiles.html . Can you open a JIRA issue if there isn't one, and possibly suggest a patch? Done, cf. http://jira.codehaus.org/browse/MNGSITE-86 -- Thorsten -- View this message in context: http://www.nabble.com/Undocumented-Feature%3A-Usage-of-negation-for-profile-activation-tp23446509p23480546.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Undocumented Feature: Usage of negation for profile activation
Hello, I just found a---to my best knowledge---undocumented feature and though I should share it with the community in the hope that it will made its way into the Maven documentation. The feature is that you can use the negation symbol ! within a profile activation specifification not only to test the absence of a property but also within the os tag, for instance, to express something like activate the profile if the OS family name is _not_ xyz. The following example illustrates this: profiles profile idtools-jar-windows/id activation os familywindows/family /os /activation !-- ... -- /profile profile idtools-jar-unix/id activation os !-- We need to exclude Mac OS X since it is in family 'unix' -- familyunix/family name!mac os x/name /os /activation !-- ... -- /profile profile!-- Mac OSX Java JDK doesn't has separate tools.jar. -- idtools-jar-mac/id activation os !-- We can not only use 'family' discriminator since Mac also has 'family = unix' -- familyunix/family namemac os x/name /os /activation !-- ... -- /profile profiles So in this example I use name!mac os x/name to specify that the profile idtools-jar-unix/id should be applied to all UNIX family operating systems _except_ Mac OS X. This example was tested with Maven 2.0.9, 2.0.10, 2.1.0 on Windows, Linux, and Mac OS X and it works for all of them. Nice :-) Cheers, Thorsten -- View this message in context: http://www.nabble.com/Undocumented-Feature%3A-Usage-of-negation-for-profile-activation-tp23446509p23446509.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Vote] findbugs-maven-plugin v 2.0 release
-1 Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was released. I suggest to catch up with that release before releasing the plugin. -- Thorsten Garvin LeClaire-2 wrote: The Maven Findbugs team would like to release Maven Findbugs Plugin version 2.0 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are option to produce other XML outputs which are used by other plugins. Issues fixed in this release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=14335pid=11701status=6sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: dependency groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.0-SNAPSHOT/version /dependency *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Regards, Garvin LeClaire garvin.lecla...@gmail.com -- View this message in context: http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Activation of multiple profiles at the same time
Hello,
I'm facing some behavior regarding activation of multiple profiles within a
pom.xml, which is contrary to what I was expecting. Maybe someone can help.
I have a pom consisting of three profiles:
profiles
profile!-- Set tools.jar for most SUN JDKs. --
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
toolsJAR${java.home}/../lib/tools.jar/toolsJAR
/properties
/profile
profile!-- Mac OSX Java JDK doesn't has separate tools.jar. --
idtools-jar-mac/id
activation
activeByDefaultfalse/activeByDefault
os
familyMac/family
/os
/activation
properties
toolsJAR${java.home}/../Classes/classes.jar/toolsJAR
/properties
/profile
!--
Add external dependency to StAX API (JSR-173) and Woodstox (which is an
implementation of JSR-173). Both are not part of JDK 1.5. Starting from
JDK 1.6 the built-in implementation is used.
--
profile
idjdk1.5/id
activation
activeByDefaultfalse/activeByDefault
jdk1.5/jdk
/activation
dependencies
dependency
groupIdorg.codehaus.woodstox/groupId
artifactIdwoodstox-core-asl/artifactId
version4.0.3/version
/dependency
/dependencies
/profile
/profiles
What I want to achieve is that for platforms other than Mac OS _and_ Java
version 1.5.* the profiles default _and_ jdk1.5 will be activated. For
platforms other than Mac OS _and_ Java 1.6 only the profile default should
be activated. Finally, for the Mac OS platform the profile tools-jar-mac
_and_ jdk1.5 should be activated for Java 1.5; while only profile
tools-jar-mac should be activated for Java 1.6.
It seems to me that activation of profiles is exclusive, i.e., only one
profile is activated at a time. For instance, when using mvn
help:active-profiles on a Linux machine with Java 1.5 SDK, I see only
profile jdk1.5 activated, but what I was expecting is that default would
be activated as well. Is there any way to achieve automatic activation of
multiple profiles apart from explicitly stating profiles via -P on the
command line.
-- Thorsten
--
View this message in context:
http://www.nabble.com/Activation-of-multiple-profiles-at-the-same-time-tp22576838p22576838.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Doesn't suppress box around APT text
I can confirm your observation, i.e., it doesn't work for me either (using Maven 2.0.9 and site plugin 2.0-beta-7). But I havn't checked if there is already an issue about that in JIRA. -- Thorsten Czollli wrote: Hello, according to the APT format a text like this: Some text should look without box around in the html, but there is a box around... I tried the sample in the format description but the result is the same. Does it work for anybody? Or it can be a bug? Thanks a lot! Czollli -- View this message in context: http://www.nabble.com/Doesn%27t-suppress-box-around-APT-text-tp21931250p21932504.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to refer to SNAPSHOT timestamp from Web site
Hello,
I'm creating a project Web site using the Maven site plugin. The project is
currently in a SNAPSHOT state, that is, the assembly that I create (and
artifacts) have a timestamp suffix attached to their file name when the get
deployed to some Maven repository.
Assuming that the build process runs mvn deploy site-deploy I would like
the Web site to render the link referring the the current assembly file,
i.e., using the current snapshot timestamp. How can this be achieved? Is
there a property like ${timestamp} that I could use to get the current
value?
Thanks,
Thorsten
--
View this message in context:
http://www.nabble.com/How-to-refer-to-SNAPSHOT-timestamp-from-Web-site-tp21730328p21730328.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Hello, we face a rather advanced requirement regarding creation of various assemblies in a multimodule project. What we are trying to achieve is as follows. Assume there is a root project P consisting of multiple module projects M1, ..., Mn (hierarchy depth max. 1). From the root POM we create various assemblies in the usual way (one descriptor file for each assembly; not attached to the build lifecycle). That works fine. Now, we also need to create yet another assembly just for one module, say M1. Whatever we have tried so far, we were not able to get it working without the overall build to fail, or at least without achieving exactly what we need. The only configuration where the overall build did not fail is to put the assembly descriptor for M1 to the root POM together with the other ones. Unfortunately, the file name of the packaged assembly will then always start with the artifactId and version number of P, rather than the artifactId and version of M1. Whenever we put the maven assembly plugin in the POM of M1, in addition to the assembly plugin in the root POM, the build does fail with various error messages. We tried both to attach execution to the package lifecycle, or to use standalone execution using assembly:assembly on the command line. We also tried almost every combination of single, attached, and assembly mojo when execution is attached to the package build lifecycle. All without success. The question is whether this constellation was taken into account at design time of the assembly plugin, thus, whether it is possible at all. If not, should I file a feature request. BTW, we use assembly plugin 2.2-beta-3 and Maven 2.0.9. Regards, Thorsten -- View this message in context: http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp21602014p21602014.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Sorry, the subject of this posting is false. I used Nabble to post that message and for some strange reason it used a subject from an earlier posting. I re-posted this message with the correct subject. -- Thorsten TM wrote: Hello, we face a rather advanced requirement regarding creation of various assemblies in a multimodule project. What we are trying to achieve is as follows. Assume there is a root project P consisting of multiple module projects M1, ..., Mn (hierarchy depth max. 1). From the root POM we create various assemblies in the usual way (one descriptor file for each assembly; not attached to the build lifecycle). That works fine. Now, we also need to create yet another assembly just for one module, say M1. Whatever we have tried so far, we were not able to get it working without the overall build to fail, or at least without achieving exactly what we need. The only configuration where the overall build did not fail is to put the assembly descriptor for M1 to the root POM together with the other ones. Unfortunately, the file name of the packaged assembly will then always start with the artifactId and version number of P, rather than the artifactId and version of M1. Whenever we put the maven assembly plugin in the POM of M1, in addition to the assembly plugin in the root POM, the build does fail with various error messages. We tried both to attach execution to the package lifecycle, or to use standalone execution using assembly:assembly on the command line. We also tried almost every combination of single, attached, and assembly mojo when execution is attached to the package build lifecycle. All without success. The question is whether this constellation was taken into account at design time of the assembly plugin, thus, whether it is possible at all. If not, should I file a feature request. BTW, we use assembly plugin 2.2-beta-3 and Maven 2.0.9. Regards, Thorsten -- View this message in context: http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp21602014p21602133.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Assembly Plugin 2.2-beta-3 Released
This was eagerly awaited. Thanks for the good work!
However, I've found one minor difference that caused a change in my assembly
descriptors when upgrading from 2.2-beta-1 to 2.2-beta-3. So far, it was
possible to exclude an entire directory from a fileset just by listening its
name, as in the following exclude ('bin' folder):
fileSet
directoryassemblies/minimal/src/main/release/directory
outputDirectory//outputDirectory
excludes
excludebin/exclude
/excludes
/fileSet
With the upgrade to beta-3 this does not to work any longer because the
target assembly contained the bin folder (and its content). I had to replace
the exclude tag as follows:
fileSet
directoryassemblies/minimal/src/main/release/directory
outputDirectory//outputDirectory
excludes
excludebin/**/exclude
/excludes
/fileSet
I cross checked the maven-assembly-plugin Web site for documentation of the
pattern format without success. I guess, somewhere, it is documented, but I
couldn't find it (as fast as I would like to). It would be good to update
the documentation and add links to the place where the pattern format is
documented.
Regards,
Thorsten
John Casey-7 wrote:
The Maven team is pleased to announce the release of the Maven Assembly
Plugin, version 2.2-beta-3
This plugin is used to create custom archives using the build output,
dependencies, and other files owned by a Maven project. You can find
more information, including instructions and examples, at:
--
View this message in context:
http://www.nabble.com/-ANN--Maven-Assembly-Plugin-2.2-beta-3-Released-tp21298644p21329363.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.0.10-RC10
Multi-module project fails with NPE on assembly:assembly (assembly plugin
used 2.2-beta-1; command used was mvn clean install assembly:assembly
eclipse:eclipse). Same configuration works with Maven 2.0.9. Below you will
find relevant excerpt from the build trace.
Best regards,
Thorsten
[INFO]
[INFO] Building OSIRIS Next
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building OSIRIS Next
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 55 minutes 18 seconds
[INFO] Finished at: Mon Aug 25 17:18:11 CEST 2008
[INFO] Final Memory: 36M/126M
[INFO]
--
View this message in context:
http://www.nabble.com/-PLEASE-TEST--Maven-2.0.10-RC10-tp19117054p19146039.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Hello,
today I tried to upgrade the Maven assembly plugin from 2.2-beta-1 to
2.2-beta-2. However, I noticed that for my project which consists of
multiple modules the resulting binary assembly now contains dependency JAR
files multiple times. The assembly descriptor contains the following excerpt
(with changed module names):
moduleSets
moduleSet
includes
include${pom.groupId}:a/include
include${pom.groupId}:b/include
include${pom.groupId}:c/include
/includes
binaries
includeDependenciestrue/includeDependencies
unpackfalse/unpack
outputDirectory/lib/outputDirectory
/binaries
/moduleSet
/moduleSets
The projects a, b, c have several dependencies, whereby some of those
dependencies refer to identical artifacts (derived from a parent POM), e.g.,
commons-logging. The resulting ZIP and TAR.GZ assembly files then contain
those dependencies multiple times (in the lib folder) with equal names! Im
not sure if this is a bug or a feature and I might have missed something.
When I change the version back to 2.2-beta-1 it works as expected, i.e., all
files exist only once.
Any hints?
Thanks,
Thorsten
--
View this message in context:
http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp16720569s177p16720569.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two question regarding the Eclipse plugin
nicolas de loof-3 wrote: For 1), you should use exclusions to block transitive dependencies. For 2), any code generation plugin that runs before generate-resource phase will get executed by mvn eclipse:eclipse and the generated source folder added to the .classpath. If you don't get this behaviour, maybe you missuse the plugin, or this one is not compliant with maven standards. I'm sorry to say that but exclusions are not an option. The effort to maintain them for large projects are too high. I guess I have to live with that for the time being. Maybe I should open a feature request for the Eclipse plugin and see if there are more people wishing that. Regarding the second point: I tried to run mvn install eclipse:eclipse and it works, i.e., it will include the additional source folder. Thanks! Thorsten -- View this message in context: http://www.nabble.com/Two-question-regarding-the-Eclipse-plugin-tp15207989s177p15231842.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Two question regarding the Eclipse plugin
Hello, I'm facing two issues regarding the Maven Eclipse plugin for which I havn't found a soulution yet. 1.) Consider the simple scenario: project A depends on project B, B depends on JAR xyz. If I run mvn eclipse:eclipse for A it will add xyz to the classpath; so far so good. What if I want to prevent that xyz is added to A's classpath? Is this possible? I didn't find an option for that. The reason is that for complex project structures with lots of JARs and transitive JAR/project dependencies this will blow up the classpath with JAR's which are actually not referenced (if they derive from transitive dependencies). In the forum I found a solution that proposes to set the scope for JARs to 'optional'. But I consider this a hack and would rather prefer a switch like addTransitiveDependenciesToClasspath=true|false for the Eclipse plugin. 2.) I have a maven build that creates some source code (via jaxws-maven-plugin) which will be stored in a separate source folder (in order no to interfere with other source code under version control). This generated source code is referenced by some test code in the same project. Is there a possibility to add additional source folders to the Eclipse .classpath file when running mvn eclipse:eclipse such that I do not get compile errors in Eclipse, because Eclipse does not know of any other folders than the default ones. Many thanks in advance for your help, Thorsten -- View this message in context: http://www.nabble.com/Two-question-regarding-the-Eclipse-plugin-tp15207989s177p15207989.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse plugin and project references
Yes, when mvn eclipse:eclipse is run for a multi module project, the dependencies between the modules will be project dependencies. I see. After I started it from the root project it did work as wanted. Thanks. Still remains the (minor) question to me why does the plugin behaves different depending on whether it was started from the sub module resp. the parent project. In my opinion, this shouldn't make a difference. Thorsten -- View this message in context: http://www.nabble.com/Eclipse-plugin-and-project-references-tp14844945s177p14981288.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse plugin and project references
Hello, my question is about whether it is possible to let the Maven Eclipse plugin create the .classpath file in a way that it will directly reference dependency projects instead of referencing the JAR artifact from the local repository. The following example .classpath file for a project named foo illustrates this: ?xml version=1.0 encoding=UTF-8? classpath classpathentry kind=src path=src/main/java/ classpathentry kind=src output=target/test-classes path=src/test/java/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry combineaccessrules=false kind=src path=/common/ classpathentry combineaccessrules=false kind=src path=/system/ classpathentry combineaccessrules=false kind=src path=/api/ classpathentry kind=output path=target/classes/ /classpath The version above has three direct references to projects common, system, and api which are all sibling projects, i.e., are located in the same folder than project foo. Regarding Maven all four projects are modules of a parent project. When I now start mvn eclipse:eclipse in project foo it will create a .classpath file that looks like this: ?xml version=1.0 encoding=UTF-8? classpath classpathentry kind=src path=src/main/java/ classpathentry kind=src path=src/test/java output=target/test-classes/ classpathentry kind=output path=target/classes/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry kind=var path=M2_REPO/org/blahh/common/1.0/common-1.0.jar/ classpathentry kind=var path=M2_REPO/org/blahh/system/2.0/system-2.0.jar/ classpathentry kind=var path=M2_REPO/org/blahh/api/1.2/api-1.2.jar/ /classpath The three projects are now referenced by the JAR artifact from the repository. This is not optimal for me since changes to the code in one of the three projects are not instantly visible to project foo (provided that Eclipse' auto build is turned on); only after a Maven install rebuild. Is there any option that I can use to force the Eclipse plugin to reference dependency projects directly? If it doesn't exist yet, then take this as a feature request. Thanks, Thorsten -- View this message in context: http://www.nabble.com/Eclipse-plugin-and-project-references-tp14844945s177p14844945.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
