Here is a list of issues and solutions
Our internal repository is located at Linux box with https and ssh access
<servers> <server> <id>devlab-ssh</id> <username>root</username> <password>password</password> <configuration> <sshExecutable>D:\Progra~1\Utils\Putty\plink</sshExecutable> <scpExecutable>D:\Progra~1\Utils\Putty\pscp</scpExecutable> <sshArgs>-P 2222</sshArgs> <scpArgs>-P 2222</scpArgs> </configuration> </server> </servers>
If you do not specify password, Maven will ask for it. - I have to investigate this further, because it doesn't work for me.
If you use non standard port (port 2222 in this case) or need
another switches, use sshArgs
and scpArgs
.
If you have plink
and pscp
on your PATH, you do not need to specify full
path. If you specify path, don't use spaces.
The plink
is apparently used to create directory structure in your
repository, pscp
can only copy files.
pscp
It is a good idea to test if you can upload files with pscp
from command line.
mvn deploy:deploy-file -Durl=scpexe://yourhost.com/path/to/maven2/repository -DrepositoryId=devlab-ssh -DgroupId=javax.j2ee -DartifactId=javaee -Dversion=5.0.FCS -Dpackaging=jar -Dfile=e:/temp/javaee-5.0.FCS.jar
The repositoryId
is matched against server/id
section in settings.
Apparently there is no support for removing artefacts from repository. The fix is scheduled for Maven 2.2.
(by Brett Porter) I think the best way to clean in this case is to move your repository to a new location, and add the file:// location to your list of remotes. Once all your projects are building, your "local" one is clean so you can remove the old one.
Patched plugins with -INTERNAL are considered as normal artefacts, only artefacts with -SNAPSHOT are "snapshots". It means that -INTERNAL are downloaded from pluginRepositories.pluginRepository.releases and not from pluginRepositories.pluginRepository.snapshots and so on.
When the patched plugin is deployed to internal reposity as -INTERNAL, the POM is not downloaded from the repository, so the plugin doesn't work. So I decided to deploy SNAPSHOTS to internal repository. It means, that there is no need to change plugin version, jsut keep the -SNAPSHOT. Also the distributionManagement.repository must be chagned to distributionManagement.snapshotRepository so it will override any settings from parent POM.
The SNAPSHOTS from internal repository should not interfere with snapshots from central repository, because super POM default settings ignores SNAPSHOTS in central repository.
It's strange that -INTERNAL was chosen, because for example 1.2-SNAPSHOT is newer than 1.2-INTERNAL, see version comparison.
The xmlbeans-maven-plugin 2.0 depends on XMLBeans 2.0 and there seems to be no way how to use newer version. The plugin needs to be patched, see JIRA issue, some patch was already posted.
Get the xmlbeans-maven-plugin sources from SVN,
change the dependency in POM to xbean-2.2, build with mvn install
.
Follow the Patching Maven Plugins
- copy pom.xml
to pom-internal.xml
, version to -INTERNAL, modify the distributionManagement
and deploy
to internal repository with mvn -f pom-internal.xml deploy
.
The maven-ejb-plugin v2.0 doesn't support EJB3 (requires ejb-jar.xml). The 2.1-SNAPSHOT should support EJB3 but is not yet released. Download it from SVN and deploy it similar to xmlbeans-maven-plugin.
The xdoclet-maven-plugin 1.0-alpha-2
doesn't work well with Java 5 annotations. The problem is in xjavadoc
parser,
see JIRA issue.
Use xjavadoc-1.1-j5-v4.jar
.
The xdoclet-maven-plugin 1.0-beta-1 supports properties where one can specify version of xjavadoc to use. Unfortunately, beta-1 is not published. Download it from SVN, and deploy it similar to xmlbeans-maven-plugin.
I did not found a page with Maven 2 command line options. The command
line options can be obtained with:mvn --help
.
Here is output for maven 2.0.4:
usage: mvn [options] [<goal(s)>] [<phase(s)>] Options: -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match -P,--activate-profiles Comma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-end Only fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursive Do not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Update all snapshots regardless of repository policies -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debug Produce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information
The Better Bbuilds with Maven, page 61, first paragraph is unclear about version comparison: "A version that contains a qualifier is always considered newer than a version without a qualifier; for example, 1.2 is newer than 1.2-beta". Unfortunately this is in contradiction.
The version parser and comparator can be found in
org.apache.maven.artifact.versioning.DefaultArtifactVersion
,
that is part of maven-artifact.jar
. From the file I can read:
qualifier1.compareTo(qualifier2) , it means that
qualifier2 is newer (-SNAPSHOT is thus newer than -INTERNAL).
When the strings are same except ending, the shorter is considered
newer.
mvn help:describe -DgroupId=org.apache.maven.plugins -DartifactId=maven-compiler-plugin -Dfull=true
mvn help:effective-pom
mvn help:effective-settings
mvn -X package