My project requires some external libraries to build in in Eclipse. They live in /trunk/lib whereas my project is in /trunk/projectA. To get Eclipse to find the libraries on all machines we set a variable PROJECT_A_HOME.
Now I'm trying to get some builds going with maven and I can not figure out how to add that path (be it environmental variable or relative to $(basedir)) to the build. I really do not want to set up a repository for these dependencies, as I keep them in source control and want builds to continue to work in Eclipse.
I've seen talk about but that hasn't worked for me.
Ideas ?
You should put your static configuration files in resources/ dir. If you have your own or proprietary jars you should set a your own repository so you can download them from the repository or better yet just install them manually , here is how
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Setting up a file-based repository as suggested in this previous question would allow to keep the libs in your version control system and work seamlessly at the Eclipse level (the libs would be treated like any other dependency). The only problem I can think of could be at the continuous integration level: a build of projectA would require a checkout of trunk/lib. Many CI tools would allow to implement this though. And if not, moving the libs under projectA (or another mavenized project project if you need to share them between modules) would do the trick.
Related
Using IntelliJ IDEA, it is often a straight-forward task to check out a project from GitHub and get it to build locally.
Once the base project is imported from GitHub, the IDE will download artifacts which will allow the main project to run. The dependencies can be examined by using File > Project Structure... > Libraries.
So the IDE downloads dependencies to allow running, but not to build from source. The IDE is able to decompile classes, but the IDE will not automatically download the source code for those dependency libraries so that the programmer can alter the code.
This question is about the steps required in the IDE and project configuration such that a selected dependency will be built locally, and thus allow the programmer to alter the code.
What I tried was to import the project on which the main project was dependent, as a separate project, then configure the main project to utilize the local project instead of the downloaded artifact. The first step, downloading the sub-project and getting it to compile, was completed successfully.
So I ended-up with two projects, the main one, and the one on which the main project depended. The task at hand, if this was the appropriate way to get this done, would be to open the main project and take some action to convince the main project to use the local build, rather than the downloaded runtime "jar".
First, I edited the POM.xml to comment out the dependency for the sub project. Checking File > Project Structure... > Libraries, I could see that it was gone, and the build now failed (as expected).
I went to File > Project Structure... > Libraries > + (plus sign) and poked around with New Module, and Import Module, but I was not able to convince the original project to use the locally available sub project. The result from various attempts was that code in the base project was not able to import from the sub project (unable to compile).
What are the specific steps to take in the IDE to get what was a runtime dependency "jar file" to instead to build locally, and use that instead?
Use a SNAPSHOT version for the dependency (you'll need to change this in both your project's pom.xml and the dependency's pom.xml, so if the current version is 2.0.0 change it to 2.0.0-SNAPSHOT)
Then you can edit the dependency's code and run mvn install in the dependency to provide the new version of the dependency to your project.
TLDR: there is no simple and straight-forward way of downloading a project's code and the code of its dependencies to rebuild it in one go as a complete chain.
Your project depends on several other artifacts. From the screenshot, we may assume that this is a maven project, at least we can be sure that there artifacts with compiled classes available for download, because this happends during build. You can view the compiled classes of your dependencies, because Intelli has the capability of decompressing jars and decompiling code, obviously, but the contents you are viewing is read-only.
Sidenote: Maven convention is to create 3 separate jars for each project. One with compiled classes, one with source files only and one with generated documentation. By default intellij may not download these, but you can force it (right-click on pom.xml -> maven -> Download sources and documentation). This will attach the actual source code instead of decompiled classes to your IDE, so it's much easier to understand the code - but still, there is no option to modify it - it's still read-only extract from some jar.
So what if you want to actually edit the source? You have 3 options, all with its own set of problems that need human intelligence to solve:
You extract the decompiled source from classes jar
You extract the attached source from sources jar
You check out git repository of the dependency
Now, beware of the downsides of each approach:
You can be sure that the decompiled source matches your project dependency 1:1. But decompiled code is not easy to read, missing comments, etc. Also, some projects may not ship their build scripts with the classes jar. Anything more complex than mvn clean install may turn out to be a blocker.
You can be reasonably sure the code matches your project dependency, but this actually is not a given. There is a chance of human error, causing the sources to actually not match the compiled classes (build from different revision or whatnot). Much depends on the quality of the project, the discipline put into the build process and care to avoid environment specific configuration that is not part of the source. The larger and older is the project, the less chances are you are able to recompile it successfully using only src jar.
A sane man's approach. You should have your build scripts, readmes, tutorials, etc. Except, of course, if we are talking some obscure company internal project with zero effort put in its maintenance. Surely, there are the same issues as before: not all projects are rebuilt easily on any environment. There may be steps upon steps required for your workstation to be configured as expected. Hopefully, self-respecting open-source java projects are easy to build, but again - not a given - not all project are open-source, not all are self-respecting.
Important note: When checking out the git repo of your dependency - you must also make sure that you are using correct revision. If the project is maintained with respect for git tags/branches naming convention - you are in luck. Not a given by any means.
All the above is enough to discourage any attempts to automatically decompose dependencies to compilable units by your IDE, and all the burden is put into you. So let's assume the best - our dependency is a simple, self-contained java application that is easily built using simple mvn clean install. You have it checked out in a separate project in your IDE. You identified correct git revision that matches version your project depends on.
Now let's apply your little change and test it. First thing you want to do is change pom.xml of your project to use a made up version of your dependency. It should be a -SNAPSHOT version for clarity and tidiness. You may of course build your modified dependency with real release version - but please be wary of how maven manages dependencies. If you install version 1.0 yourself - it stays in your local repo forever. You will forget about it, and will be using your fake 1.0 version when building all other dependent projects unless you manually locate and remove it from repo. So stick to 1.1-SNAPSHOT.
Now every time you need to apply a small fix to your dependency, execute mvn clean install in its repo, then make sure your actual project depends on the correct new SNAPSHOT version, execute your maven clean install and that's it.
Note that all this has very little to do with Intellij. You are not expected to modify any library paths, advanced project settings, or links to jars. Stick to modifying pom.xml and you are set.
We have a core set of java libraries, published as jar files, that are used in multiple client projects. Both the library projects and the client projects are on our git server (GitLab EE). Sometimes clients and third-parties (such as sub-contractors) have access to the project source code, but we don't want them to have access to the source for the core java libraries.
So what I need to know is how to set up some kind of dependency or similar in git so that we can automatically pull in the latest version of the library file? I've been looking at git submodule, but that looks like it will pull in, or at least give access to, the full source of the library projects. I've also started looking at Maven, but I'm unclear whether that also needs access to the whole repository. Is there another/better way to do it? Or will Maven actually do what I want? Or do I need to publish my jar files somewhere else, and if so how can I automate that process, as I don't want to have to manually copy the jar file somewhere every time it's updated (which is often)?
Maven and a binary repository like Nexus is the common way to do what you're asking. Nexus stores binary files like .jar's .dll's etc and Maven has the capability to publish and retrieve specific versions of these binaries and include them when building the project. As Ryan commented, Maven Central is a public binary repository that you could publish to if you wanted the whole world access to your .jars, but with Nexus you have fine grained access control over your binaries.
If you build your own projects with Maven, you can configure it to build, test, and publish right to your Nexus repository with a single command mvn deploy. Then clients just have to update their project to point to the new version and Maven will download it and use it on the classpath. It's all very seamless, and I would definitely recommend refactoring your build process to use Maven or a similar product.
I have a maven-java project and I use git at the same time. Now I need to use some libraries which does not have any maven support. I have the .jar files of the libraries.
How will I add them to my maven project? and.. Will the other people who pull my code from my git repo be able to run my code without having the .jars?
If you have an artifact repository manager such as Nexus, Archiva, or Artifactory, you can deploy the jars to it. Then you can define them as dependencies in your pom.xml files.
If you don't, you can install them to your local repository using the maven-install-plugin using the install-file goal.
If you don't want to do that, there's also a not-recommended option of defining a dependency with <scope>system</scope> as illustrated here. Again, this is highly NOT recommended, as you would be expecting people would have the artifact on their file system and quite possibly, this jar might end up in your version control, which is really not the way to do it, but is also possible.
answer is that others will not be able to build your code unless some conditions are met.. As mentioned by carlspring, you would have to either install to your own local repo or put a system scope dependency.
if you add it to your local repo, then your local would have to be
some kind of common network writeable share/location that your entire team maps to in a standardized fashion in your development environment.
if you add a system scope dependency, you could actually put this jar into your codebase into a project relative lib directory and provide a path such as ${basedir}/lib/some.jar
I have a Netbeans Java Project under Subversion (svn). This is shared with another guy working on the project.
The project requires an external library that we have as a jar file. Now, when either of us makes a change and commits it, the project's library dependencies fail as we have different paths for the library ( as we are working on different machines the location of the jar file is different ).
This means that every time I update my repository, I have to resolve library dependencies.
Is there a way I can prevent this?
1st way: You can use NetBeans Library support.
Go to Tools->Libraries, and new Library with your jar. Name it the same way on both machines and include to your NB project as Library rather then direct path to jar.
2nd way: use relative path.
Agree on having jar located at ../lib/foo.jar and use this path in NB project
3rd way: use property file.
Add file named, for example, build.properties but don't commit it to svn. So both of you will have different local version of that file.
Content should be something like next:
myproject.library.foojar=C:/foopath/foo.jar
In your build.xml include this file:
<property file="../build.properties"/>
In your nbproject/project.properties find a reference to the jar -- it will look like:
file.reference.foo.jar=C:/foopath/foo.jar
change it to
file.reference.foo.jar=${myproject.library.foojar}
Also you may want to add build.properties into ignore list for svn to avoid commiting it.
I recommend you to use Maven to control library dependencies(jars). It is easy to use and NetBeans has a module to use it easily.
Maven download all the dependencies you declared into a local repertory so you don't need to worried about managing libraries, Maven do it for you.
Also with this module you can search libraries in the Maven repertory(Has a lot of java librarys) only you need to type the name and maven download it for you.
Here there are some links for how to use Maven With NetBeans:
http://platform.netbeans.org/tutorials/nbm-maven-quickstart.html
http://today.java.net/article/2009/10/14/working-maven-netbeans-671
I might be missing something but how do you manage Java projects in eclipse that need a lot of Jar files. I know maven manages libraries well if there are new updates but maybe I'm missing something, is there a way that eclipse can update new jar files (it would be especially useful for projects using apache-commons, say).
I don't want to sound like asking for a feature request, but I'm looking at if there are ways to keep libraries jar files that a Java project uses to keep them updated automatically the way maven does. With more languages coming with this type of features, finding the right Jar files probably should be easier than this.
Eclipse doesn't manage your jar versions for you, and as far as I know it won't do any auto-updating of jars that have newer versions out there. There's simply not enough information or infrastructure for Eclipse to recognize that a given jar you've added to the classpath is eligible for updating and that you want it updated.
However, there is a Maven plugin for Eclipse called M2Eclipse, which will read a POM and construct a classpath out of jars it finds in the local repository and any remote repositories you've configured. It behaves largely like Maven does in terms of finding the latest version for a given jar (if you've specified a version range in your POM).
You can create user libraries and change their content when new versions are available. That way you do not at least need to change the build path of every project. Or you can load sources of the libraries from their svn and use their trunk version. Remember that you can select multiple projects and svn update them at once.