In-House, Commercial-License Remote Repository
Sometimes licensing issues prevent projects from being as portable as they could be, forcing your teams to manually download and install the artifact. Normally, this would earn your project a spot in the non-portable category, but the Maven team has reduced this issue to only a minor annoyance. Say that you licensed a closed-source JAR named "sometool.jar". You could install it within an in-house repository as follows, allowing other coworkers to access the JAR just like any other Maven artifact:
mvn deploy:deploy-file -DgroupId=com.closedsource -DartifactId=sometool -Dversion=1.0 -Dpackaging=jar
-Dfile=sometool.jar -DgeneratePom=true -Durl=scp://inhouse/maven -DlocalRepository=inhouse
Viola! Your non-portable project is now portable in-house, subject to licensing restrictions.
Getting javax.*
All javax.* packages once required you to manually download and install the artifacts from the Sun Web site due to licensing restrictions. This is no longer the case, as
java.net has created public Maven 1.x and 2.x repositories containing some packages, such as javax.mail and javax.persistence. You may access both repositories with the following added to your project's POM (notice the layout element in the Maven 1.x repository):
<repository>
<id>java.net</id>
<url>https://maven-repository.dev.java.net/nonav/repository</url>
<layout>legacy</layout>
</repository>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>https://maven2-repository.dev.java.net/nonav/repository</url>
</repository>
Your once non-portable project using the email API is now widely portable, with no manual installs required.
The Dream of Portability
Thanks to Maven, you can begin standardizing the build process itself. While not perfect, Maven is taking a giant leap forward for Java development, making the dream of pure, simple portability a reality.
Previous Page
