In this small post I will show you how to deploy automatically some artifacts of your build into
Weblogic 10.3 by using the weblogic-maven-plugin
This plugin will support various tasks within the Weblogic 8.1 and 9.x environment. Such tasks as deploy, undeploy,clientgen,servicegen, and appc are supported as well as many others. The plugin uses exposed API's that are subject to change but have been tested in 8.1 SP 4-6 and 9.0 - 9.2 MP3. There are two versions of the plugin to support the two environments based on differences in the JDK. The 9.x version is currently being refactored to support the standard JSR supported deployment interface

If your Artifactory installation grows of many Gb each day - althought you do not deploy so many new artifacts. I suggest you to look under the repositories settings.
All your local repositories are configured as default with Snapshot Version Behavior = Non-Unique. As stated in the manual, all deployed SNAPSHOTS with be keep with unique time-stamp and build number suffix in the background (and you’ll only see one version in the tree).
I recommend you to switch to Non-Unique. In that mode Artifactory should only keep the N latest Snapshot of an groupid/artifact/name file. So you’ll be able to keep the repository size under control.
Read more: Limit number of snapshots artifacts stored in Artifactory
I compiled here a list of the major Apache Maven repositories (read an intro to repositories) for You, You can contact me, or post a comment if you would like to add a missing one to the list.
And of course mine at http://maven.waltercedric.com
On larger projects, additional dependencies often tend to creep into a POM as the number of dependencies grow. As dependencies change, you are often left with dependencies that are not being used, and just as often, you may forget to declare explicit dependencies for libraries you require. Because Maven 2.x includes transitive dependencies in the compile scope, your project may compile properly but fail to run in production. Consider a case where a project uses classes from a widely used project such as Jakarta Commons BeanUtils. Instead of declaring an explicit dependency on BeanUtils, your project simply relies on a project like Hibernate that references BeanUtils as a transitive dependency. Your project may compile successfully and run just fine, but if you upgrade to a new version of Hibernate that doesn’t depend on BeanUtils, you’ll start to get compile and runtime errors, and it won’t be immediately obvious why your project stopped compiling.
Privacy Statement | Copyright Notice | Licenses
© 1999-2012 Waltercedric.com. Designed by Cédric Walter. Sitemap
Reproduction without explicit permission is prohibited. All Rights Reserved. All photos remain copyright © their rightful owners. No copyright infringement is intended.
Disclaimer: The editor(s) reserve the right to edit any comments that are found to be abusive, offensive, contain profanity, serves as spam, is largely self-promotional, or displaying attempts to harbour irrelevant text links for any purpose.