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.
Related
I have a Maven project that is distributed commercially that offers the ability to connect to many different databases via JDBC. Normally the customers place the necessary JDBC drivers in their web server's lib directory to make them accessible. We can't include certain jdbc drivers in the pom, for example Oracle, due to it's license type.
I'm trying to use an Oracle JDBC connection in the app while running in Eclipse. I need to get the JDBC jar on the class path and for some reason can't seem to be able to do that without adding it to the pom.xml via maven dependency.
I thought for sure going to Properties-->Java Build Path --> Libraries --> Add External JARs would work. When added to the build path in that way it shows correctly in the package explorer but if I run Class.forName at run time it throws ClassNotFoundException. Why isn't it on the class path at that point?
Take a look at the following descriptive article, which gives the shortcuts to setting a classpath to your throw-away code or to have a modest solution to manage your classpath dependencies and then to a complete and a professional solution to manage and even automate your classpath dependencies - should there be a need to have these automated for a larger projects.
It is a better way to set your CLASSPATH variable if you are not going to change any of those jar versions very frequently or else you might end up hours of your valuable time debugging the wrong side of the problem.
Hope this helps you understand and also resolve your problem!
I would include the relevant jars into the pom, but make them <optional>. Then, they are not packaged into the application but they can be provided by the user.
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.
We have been using Ivy for a few months and have our own hosted "Ivy Repo" on a web server here in the office. All of our projects are configured to go to this repo to resolve dependencies.
We have several "commons" type JARs that are used by many of our projects. Because of this, and because we only have 1 repo, we're finding a lot of ugly overhead coming from the following scenario:
A developer is given a task to add a feature to Project 1 (which depends on a Common jar)
During the course of developing Project 1, the developer realizes he/she needs to make changes to the Common jar
Common jar changes are made
Common jar has to go through code review and normal code promotion
Build master publishes new Common jar
Project 1 can resume development now that Common jar has been updated
This is becoming ridiculous and painful for our team.
To me, the obvious solution is to provided ant targets in each project that allow the developer to publish/resolve locally (to and from their file system). That way they can break the Common jar 9 ways to Sunday, but without losing 2 - 4 days while waiting for Common to get published. This way, the developer makes local changes to both Project 1 and Common, and the code goes through our promotion process all at once.
I know this is possible with Ivy, but I'm so new to it I wouldn't even know where to begin.
Currently we use a global ivy.settings file for all projects. In the settings file, we use a chain resolve that has 1 url resolver inside of it, which connects to our "ivy repo".
I believe the following is the only change that will be necessary, but I'm not 100% sure:
In ivy.settings we will need to add a local file system resolver before the url resolver gets called; this way we check the local file system for dependencies before moving on to the ivy repo (web server)
Configure each project's ivy.xml with an option somehow that allows local cache publishing
Tweak the Ant builds to have a publish-locally target that exercises the option mentioned above
I believe these changes will allow us to: (1) always look locally for dependencies before looking to the web server, (2) publish locally as a build option (target).
If this is not true, or if I am missing any steps, please advise! Otherwise, I can probably figure out how to add a file system resolver from the Ivy docs, but have no idea how to get the publish-locally target to work. Any ideas? Thanks in advance!
I too would prefer Marks approach.
As to publish-locally you can tell the publish task which resolver(resolver="local") to use. This way it can publish to the local filesystem or to any defined resolver.
<ivy:publish
resolver="local"
overwrite="true"
revision="${project.version}">
<artifacts pattern="dist/[artifact]-[revision].[type]" />
</ivy:publish>
And if you use a chain resolver you should set returnFirst="true" so that resolving will stop when something was found locally.
Ivy supports dynamic revisions:
Stable code would reference the latest approved version of the commons jar:
<dependency org="my-org" name="commons" rev="latest.release"/>
Unstable (in development) code would reference the latest unapproved version of the code
<dependency org="my-org" name="commons" rev="latest.integration"/>
So you need to change the build process for your commons module to have two publishing targets. One for unstable snapshots of your code the other for formal releases.
(See the status attribute on the ivy publish task)
Note:
In Maven you have two types of repository, release and snapshot. Ivy support for this concept is more subtle and more powerful IMHO.
I am developing a web-app and use maven for dependency management (duh). Some of the needed jars are already available in the server lib folder, but do not match the "maven naming scheme", ie missing the version suffix.
I would like to use them for development and deployment, but..
1. i cant point maven to them because maven seem to need a version suffix. I cant omit it in the pom.
2. If i define the dependency outside maven then maven is obviously unable to build.
3. Renaming the files inside the server distribution sounds like a kludge.
What would Brian Boitano do? I mean, there sure is an elegant solution that im not aware of, or at least a good argument for one of the three solutions above.
Thank you
PS. i am using jboss 5.1 and maven 2.2.1 atm, but its subject to change
You can provide those jars as a dependency with a system scope if you want explicitly to identify where they live. For more info have a look here
IF those are not proprietary libs you are using, I'd recommend you use official versions of those from maven repository.
If they are proprietary you can manually install jar to your local repository using maven(you can use your version, suffixes, group names, artifactid etc) and then use them in your pom.
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.