I have inherited an old project that using ant to build against weblogic.jar. I am moving this into a more modern maven based build environment and I don't want to check in weblogic.jar ( which is 34MB ) into my private artifact repository and I don't want to add it to my local repository either. I am not sure what it is using from this, the project is one monolithic code base over 500,000 lines of code.
We won't actually have Weblogic on our local development machines, we are deploying to remote virtual machines to test because of corporate network topology to get the services our application needs to talk to.
What alternative do I have to building against weblogic.jar.
Using system scope is usually considered a bad practice. However, I would say in the case of weblogic.jar, using system scope makes sense. The reason is that the the weblogic.jar does not contains all the classes provided by WLS installation. If you open weblogic.jar and take a look at the MANIFEST.MF file inside, it contains a long list of jar files in the Class-Path: entry. These jar references are all using relative path. It means that if you put the weblogic.jar into the maven repository, the relative path is broken and you need to a lot more WLS jar files into your maven repository.
The catch is that if your system-scoped dependency points to the weblogic.jar in your WLS installation, you need to standardize the WLS installation directory for all your developers. Otherwise your build is not portable in other developers' machine.
Since maven downloads everything it tries to resolve into your local repository the only way (afaik) would be wrapping the existing ant task using maven-ant-task.
Personally I would prefer to add the weblogic stuff into the maven repository.
If you don't want to put it into your local repo, you could refer to it using system-scoped dependency, in which case you'd just refer to it from your disk. I'm not sure why that would be better option, but since you asked for it, you might have a solid reason.
However assuming you don't want to use weblogic.jar at all: it's not really possible to say what alternatives to building against it you have without knowing what you need from it. That needs to be found out first. If you use weblogic-specific stuff, you do need the reference.
Related
When using lein install or e.g. boot pom jar install, a Clojure project is packed inside a jar and installed to the local maven repository. Which is stored as a folder structure of several jars for instance under ~/.m2
These installations are mutable, meaning a project of a specific version (e.g. 0.1.0) can be overridden by calling the same command after something has changed inside the project but without the version being changed.
When pushing to a public repository such as clojars, this is not possible. There I guess only *-SNAPSHOT versions one can override existing pushs.
Wouldn't it be desirable to have this immutability already in a local repository? Are there ways to archive this?
I run a copy of Nexus an an AWS instance for this purpose, though it woule make sense to run it on your own computer. Most of the benefits (except protection against the loss of this computer) with lower latency. The price is right as well.
I have two different projects using maven 3.2.5/3.0.5 (3.2.5 locally, 3.0.5 on build server). The first creates jar files needed to compile the second. Both projects will run in an environment and so my second project doesn't need to have the most current version, it just needs to them to compile against.
This seems like I'm making it way harder than it needs to be. I was using system and specifying a system path, but evidently maven feels like that is substandard structure and it quit working.
We tried using our organization's artifactory instance, but that was a disaster. Probably something in their implementation of it.
I tried creating a repository for the project, and using a file URL, but it appears when you do this, that it ignores the other repository and uses that directory exclusively.
So seriously, I just need to add a couple of jar files to the path. Isn't there a way to do this in maven?
JBoss has the jbossall-client.jar which can be used in client applications for JNDI lookups and more... It is available in the JBoss maven repository.
How should one do it when using Glassfish 3 in a dependency managed environment?
The FAQ says in step 3 that one should refer directly to gf-client.jar in the installation directoy of glassfish. The gf-client.jar only has relative references to other JARs in glassfish installation directory. So putting the gf-client.jar in a private repository is no option, unless you are willing to put alls the refered JARSs into the repository, too. But that is no good, because then you have to put the manually to the correct relative location.
There is a package-appclient script which generates a appclient.jar, which is not directly usable in a classpath, because it mainly just a ZIP-file containing all needed JARs for a client. Of course you could put appclient.jar in the repository and then do all the extraction and classpath-building in a build script, but should I really do it this way?
Is there any other way to do it, or better how it is intended to use this appclient.jar?
Have I overseen a "glassfishall-client.jar"?
I'm not familiar with your exact problem but I can speak on one of your statements:
So putting the gf-client.jar in a
private repository is no option,
unless you are willing to put alls the
refered JARSs into the repository,
too. But that is no good, because then
you have to put the manually to the
correct relative location.
I manage our local repository and I can tell you, it's very easy to include "alls the refered JARSs into the repository." To do so, you run the install task with transitive set to true. That looks like this:
<ivy:install organisation="[orgName]" module="[modName]" revision="[rev]"
from="myRepositoryChain" to="myLocalResolver" transitive="true" />
It's hard to tell from your question but I'm guessing the problem is that some of those dependencies are only available directly from JBoss? As long as you include the appropriate repository in your "myRepositoryChain," it all will work, effortlessly.
If these jars are hard to access, then that's all the more reason to pull them into your local repository, somewhere.
I hope that helps, in some way.
Here's a great resource for more info on managing a local ivy repository.
I'm confused about the use of maven in development and production environments - I'm sure it's something simple that I'm missing. Grateful for any help..
I set up maven inside eclipse on my local machine and wrote some software. I really like how it's made things like including dependent jars very easy.
So that's my development environment. But now I want to release the project to production on a remote server. I've searched the documentation, but I can't figure out how it's supposed to work or what the maven best practice is.. Are you supposed to:
a) Also be running maven on your production environment, and upload all your files to your production environment and rebuild your project there? (Something in me baulks at the idea of rebuilding 'released' code on the production server, so I'm fairly sure this isn't right..)
b) use mvn:package to create your jar file and then copy that up to production? (But then what of all those nice dependencies? Isn't there a danger that your tested code is now going to be running against different versions of the dependent jars in the production environment, possibly breaking your code? Or missing a jar..?)
c) Something else that I'm not figuring out..
Thanks in advance for any help!
You're supposed to have your code under version control (and you never "upload" files to another machine, you "download" them from the Version Control System if required).
You're supposed to package your code in a format (a WAR, an EAR, another kind of bundle) that can be deployed on the production environment for execution. Such bundles typically include the dependencies. To build more complex bundles, the Maven Assembly Plugin can help.
Maven generated artifacts (JARs, WARs, whatever) should be shared via a remote repository (and thus deployed - I mean mvn deploy here - to this remote repository). A remote repository can be a simple file system served via a web server or a more advanced solution like Nexus.
Development is usually done using SNAPSHOT dependencies (e.g. 1.0-SNAPSHOT). At release time, you're supposed to change the version into a "fixed" version (e.g. 1.0) and some other bits from your pom.xml, run the build to check that everything is ok, commit the modified pom.xml, create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g. 1.1-SNAPSHOT) in the pom.xml, commit the new pom.xml in the VCS. The entire process require some work but this can be automated using the Maven Release Plugin.
On the production environment, get the artifacts to be deployed from the remote repository and deploy them (some projects automate the deployment to the production server using Maven but that's another story).
Of course, there are variations around this (deployment to production is most of time company specific) but the general idea is there.
You need to look into the Maven Assembly Plugin and the Maven Release Plugin.
When building artifact you usually state what scope the dependency has. In default scope it should be packaged in your archive. If you do not want it, use scope "provided" - in such case you have to prepare runtime environment providing the dependency. It's generaaly a bad idea to rebuild a package only for deployment.
As for deploying, you can use maven's antrun plugin to copy files locally or via scp .
Quite new to maven here so let me explain first what I am trying to do:
We have certain JAR files which will not be added to the repo. This is because they are specific to Oracle ADF and are already placed on our application server. There is only 1 version to be used for all apps at anyone time. In order to compile though, we need to have these on the class path. There are a LOT of these JARS, so if we were to upgrade to a newer version of ADF, we would have to go into every application and redefine some pretty redundant dependencies. So again, my goal is to just add these JARs to the classpath, since we will control what version is actually used elsewhere.
So basically, I want to just add every JAR in a given network directory (of which devs do not have permission to modify) to maven's classpath for when it compiles. And without putting any of these JAR files in a repository. And of course, these JARs are not to be packaged into any EAR/WAR.
edit:
Amongst other reasons why I do not want to add these to the corporate repo is that:
These JARs are not used by anything else. There are a lot of them, uncommon and exclusive to Oracle.
There will only be one version of a given JAR used at anyone time. There will never be the case where Application A depends on 1.0 and Application B depends on 1.1. Both App A and B will depend on either 1.1 or 1.2 solely.
We are planning to maintain 100+ applications. That is a lot of pom.xml files, meaning anytime we upgrade Oracle ADF, if any dependency wasn't correctly specified (via human error) we will have to fix each mistake every time we edit those 100+ pom.xml files for an upgrade.
I see three options:
Put the dependencies in a repository (could be a file repository as described in this answer) and declare them with a scope provided.
Use the dirty system scope trick (i.e. declare the dependencies with a system scope and set the path to the jars in your file system.
Little variation of #2: create a jar with a MANIFEST.MF referencing all the jars (using a relative path) and declare a dependency on this almost empty jar with a system scope.
The clean way is option #1 but others would work too in your case. Option #3 seems be the closest to what you're looking for.
Update: To clarify option #3
Let's say you have a directory with a.jar and b.jar. Create a c.jar with a Class-Path entry in its META-INF/MANIFEST.MF listing other jars, something like this:
Class-Path: ./a.jar ./b.jar
Then declare a dependency in your POM on c (and only on c) with a system scope, other jars will become "visible" without having to explicitly list them in your POM (sure, you need to declare them in the manifest but this can be very easily scripted).
Although you explicitly stated you don't want them in the repository, your reasons are not justified. Here's my suggestion:
install these jars in your repostory
add them as maven dependencies, with <scope>provided</scope>. This means that they are provided by your runtime (the application server) and will not be included in your artifacts (war/ear)
Check this similar question
It is advisable that an organization that's using maven extensively has its own repository. You can see Nexus. Then you can install these jars in your repository and all developers will use them, rather than having the jars in each local repository only.
(The "ugliest" option would be not to use maven at all, put put the jars on a relative location and add them to the classpath of the project, submitting the classpath properties file (depending on the IDE))
if you are developing ADF (10g / 11g I guess) components, I suppose you'll be using JDeveloper as IDE. JDeveloper comes with a very rich Library Management Tool that allows you to define which libaries are required for compiling or which ones should be packaged for deployment. I I suppose you will already know how to add libraries to projects and indicate in the deployment profile which ones should be picked while packaging. If you want to keep your libraries out of maven, maybe this could be the best approach. Let´s say the libraries you refer too are the "Webcenter" ones, using this approach will guarantee you you have the adequate libraries as JDeveloper will come with the right version libraries.
Nevertheless, as you are using maven I would not recommend to keep some libraries out of control and maven repositories. I´d recommend choose between maven and Oracle JDeveloper library management. In our current project we are working with JDeveloper ADF 11g (and WebCenter) and we use maven, it simply make us library management easier. At the end of the day, we will have a big amount of third party libraries (say Apache, Spring, etc.) that are useful to be managed by maven and not so many Oracle libraries really required for compiling in the IDE (as you would only need the API ones and not their implementations). Our approach has been to add the Oracle libraries to our maven repository whenever they are required and let maven to control the whole dependency management.
As others say in their answers if you don´t want the dependencies to be included in any of your artifacts use <scope>provided</scope>. Once you configure your development environment you will be grateful maven does the work and you can (almost) forget about dependency management. To build the JDeveloper IDE files we are using the maven jdev plugin, so mvn jdev:jdev would build generate our project files and set up dependencies on libraries and among them to compile properly.
Updated:
Of course, you need to refer to ADF libraries in your pom files. In our project we just refer to the ones used on each application, say ADF Tag Libraries or a specific service, not the whole ADF/WebCenter stack. For this purpose use the "provided" scope. You can still let JDeveloper to manage your libraries, but we have found that it's simpler to either have a 100% JDeveloper libraries approach or a 100% maven approach. If you go with the maven approach it will take you some time to build your local repo at first, but once that's done it's very easy to maintain, and the whole cycle (development, build, test, packaging and deployment) will be simpler, having a more consistent configuration. It's true that in a future you'll have to update to later ADF versions, but as your repository structure will already be defined it should be something fast. For future upgrades I'd recommend to keep the ADF version as a property on the top pom, that will allow you to switch faster to a new version.