When you use the Google-Eclipse plugin to create a new Web Application Project, and you select the option to "Add support for listing on Google Apps Marketplace", the plugin automatically adds an apps-marketplace.jar file on your classpath.
Does this - at any point in time, for any reason - ever need to be bundled with your WAR? I ask because it contains a bundled version of SLF4J that is causing JAR hell issues with other dependencies that use a different version of SLF4J.
I bundled it into my WAR because I thought it was necessary, but if its something that is just used by the plugin, or is perhaps available as some service to GAE apps when they're running in production, then I don't need it and would like to remove it as a dependency. Thanks in advance.
This jar is not needed. You can remove it from your build path and your WAR directory. We need to fix the plugin so that it gets rid of this jar.
I have a feeling it was first added in to make it easy to access certain Google APIs from your Marketplace app. It included a bunch of classes for handling OAuth. However, I think that all of the classes in here are basically deprecated, and there are better ways to make these Api calls now.
Related
Can someone name me one mini framework in Java that will allow me to build a REST API? The thing is that all need maven installation or Gradle or something similar, but I need something that will "play" with a very simpler installation like installing just a jar or something similar.
Maven and Gradle are project management tools .Developers use them mostly to manage dependencies , but there is no any hard rule saying you must use it compulsory.So if you don't want to use them , you can neglect them ,but then as you asked you need to add all those JAR files externally by searching them through the internet or mostly in maven central repository.Best option would be spring boot application but if you don't like to use maven then I suggest you to go with Spring framework ,but then you should add all those JAR files manually.As an alternative JAX-RS + Jersy will also be fine .
I'm having trouble in implementing file upload handling with Jersey, Glassfish 4 and Netbeans. I know there are a lot of tutorials out there but all of them use maven projects.
Like we know that in Netbeans web application project, after we choose Glassfish as the server, we can use all of the JEE API cause automatically Netbeans add JEE API from Glassfish to our library (like in the picture below). I think its only for compiling and not included in the deployed war.
We can even make a new non web Java application and use JEE API by adding Java EE 7 API to our library, its just API for compiling, in the runtime all of the classes are provided by the server (like in the second picture ).
Now, I want to use the Jersey Multipart API for handling file upload. Glassfish already has the required jars in its modules folder, like jersey-media-multipart. (3rd picture), I know that they are provided in the runtime but I need them to compile my project. Simply adding the jars to the project library is not a proper way cause it gives me a lot of weird errors and we know we shouldn't cause Glassfish already provides them.
I need something like Jersey Multipart API to compile the project so that in the runtime the project uses all of the classes that Glassfish already provides. Just like the Java EE 7 API Library that Netbeans provides and work well.
Well, here's the solution...
If you only add the jersey-media-multipart, you'll get error HttpReader not found so you need to aadd all of the jersey jars in the glassfish modules.
Next, right click on the libraries folder in the netbeans project and in the compile tab, uncheck all of the jersey jars in the package column to make them get excluded when we build/ run the project .
Hope this helps anyone who have similar issue.
I need to put some old java class library code that I have into a repo, from where others can check it out and build it. You know, like any public repo.
But, I'm not sure what the best way to do this is in the java world. In old-fashioned projects, we just used to supply the build scripts and a list of dependencies. You gathered or installed the dependencies separately before running the build scripts.
But these days for many languages, you have package managers and the like that pull from remote locations and your build scripts need to include dependency fetching.
Basically, I'm not familiar with how java libs and programs are packaged.
Should I include the (dependency) libs in the repo? And update them whenever a new version is out?
Does java now have a package manager that will pull in the latest versions of the dependencies?
Do I leave it upto the people checking out to download the libs themselves before they run the build scripts?
I'd prefer it if the solution didn't involve installing a huge package manager. Gradle wants to pull in like 150MB+ of stuff and as far as I am aware, it isn't ubiquitous on java deployments.
Thanks.
Use Maven. I believe these days it's the #1 "package manager" (not a term that's usually used to describe it, but quite apt) by a large margin. It's built into Netbeans, IntelliJ IDEA, and I believe Eclipse.
However, it won't just "pull the latest versions" of your dependencies, since your application may break. Only the versions you specify. Therefore, you should periodically update (and test) your code to reduce incompatibilities when someone tries to use your library in an application which directly or indirectly pulls newer versions of the same libs (and they get into a bit of "dll hell"), or reduce your use of third-party libraries in general.
You should also consider publishing your library in a compiled form to Maven Central so that using your library would be as easy as adding a dependency to the pom.xml. The problem that Maven solves, after all, is not so much making it easy to build your library (since just bundling the dependencies gets you most of the way), but making it easy to use your library.
I have built a Java application that has some dependencies (~10). I would like to easily package this application up and deploy it as a single file to a CD or USB drive.
There doesn't seem to be any "nice" wizard to search the project, grab the dependencies and setup the classpath on the target computer. I have to do this manually.
Is there a better way? Something simple, easy and straight-forward. A link to a tutorial on this would be great.
Seems to me that this should be a built-in feature to eclipse. Deployment of a web application seems easy enough, but not a Java application.
Have a look at the Fat Jar Plug-In.
That's because desktop deployment isn't well defined.
You are heading into release issues which is a huge can of worms.
I assume you have some form of version control like SVN or git? If so check out maven with the release plugin and maven-assembly-plugin
It'll take a lot of work to setup, but once you get it going you'll be cross linking and deploying distribution packages in no time!
Plus you'll have access to the vast maven repos on the web right now
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.