I am very new to the industry, so apologies in advance for the very likely stupidity of the question.
In the team, we work with Intellij IDEA 13 as IDE, and use Maven 3 for our projects. We provide a few online services and portals, and I'm just starting to work on one: the project has several dependencies that are shared by other older projects, some are JAR archives, some are WARs...
To my questions re: how to edit those dependencies locally (e.g. editing a resources.properties was the case I had in mind) my tutor suggested turning the dependencies into snapshots and work with those.
What I managed to do was create a copy of the appropriate folders in my local repository and change wherever the version of the dependency was in the name or in the files, then modify my pom.xml files.
Now, this works perfectly if I open the JAR/WAR and edit some file, but I'd like to be able to do it from my IDE, also cause not being able to suggests I'm probably doing this in a wrong way. Do I need to somehow unpack the dependency to be able to do so? Is my entire approach wrong?
P.S.: I would ask someone in my office, but oddly enough none of those who could help are at work today anymore!
If none of your colleagues was able to help you, I am afraid there might be something else hidden.
However, let's try it!
I am guessing, here, that your resources.properties is a part of his own project. Project handled by Maven and expressed as a dependency in one of your main project.
I am also guessing that your main projects are WARs (Webapps mostly, services, portals) and the JARs are libraries, configurations, etc...)
Therefore, I am guessing that your webapps are referencing some libraries as Maven dependencies, to a specific version.
That said, IntelliJ (and other IDE) can easily handle modification of either JARs and WARs related to each other via Maven as long as the visioning is meaningful.
Note: Having -SNAPSHOT at the end of the version number tell to Maven NOT to cache the package. On the opposite, a definitive version number is considered as released and is only fetched from the cache. This is important because with a SNAPSHOT, you can publish an illimited number of time and it is guaranteed to have the latest version.
Note: Doing mvn clean install publish a package into your local Maven repository (generally located in ~/.m2) and is only available to you.
The general good practice is to have, in all the development branches of your DVCS, all your owned, often modified projects (Don't be too greedy, it depend on the situation) as SNAPSHOT. And during a release (Maven has a specific plugin for that) change all the versions to a final one, attributed in this precise moment (You never know if you will need a minimal version or a major).
Your code, then, has always the SNAPSHOT number of your expected next release.
Finally, I think that in your case, if you choose to change the pom.xml of one of your library for a SNAPSHOT, you should change the pom.xml of the root project to correspond.
If this dependency version is the same, then, you can add your library as a module within IntelliJ and the IDE will do the math to figure that the Maven dep and the Java module are the same entity.
I don't even know if that's help you (I'm not even sure if it's clear), but I hope it will make you ask more questions about what you need. Your co-workers will probably be able to help you more.
Related
I am currently working on several projects each one of them has different artifactory settings. So, when switching between them I have to go to maven folder and change settings file to correspond to correct corporate repository. I'm pretty sure that it is ineffective and most likely someone already have a simple solution for this problem. May be there is some IDEA settings that I need to switch, or maven itself has some way to store them?
So, my question is - does anyone know the simple way to use several settings.xml file in the same maven home folder?
Quick google and stackoverflow search doesn't provide any results so far.
I expect that when I open another project in Idea it will work with its own artifactory instead of using the one from previous project (since these are from different companies, obviously it is not correct to use the same one)
The answer above doesn't quite work for me, since I'm running project via IDEA and it's getting artifacts downloaded using single settings.xml
The usual way you work is to either:
put all repositories you need for all of your projects into your settings.xml so that it works for all projects.
use a Nexus/Artifactory that proxies all the repositories you need and put that as mirror into your settings.xml.
If a repository should really be only accessible for one project, you can put into the pom.xml of that project.
I don't understand how other developers should object to putting the repositories into the pom.xml because they need the very same repositories to run the project (if not, please comment and explain).
I have a multi-module maven project that I inherited from another team and am now migrating to a cloud solution. We were able to get it working in a co-worker machine and pushed it to git. However, after I pull the exact same version of the code, it fails to compile on my machine with the obvious
cannot find symbol
The missing class is packaged in a dependency jar that is not declared in the pom, so it can only be a transitive dependency. However, I can't generate an effective pom to check this (because of the compilation issues, I suppose).
This is only failing for me, not my co-worker, so it really can't be a problem with the dependency declaration in the pom file. I'm running maven 3.5.0, from the main project folder, with exactly the same vm args and profile as my co-worker, except that it works for him and not for me.
The only difference between the two machines is I'm in mac and he's in good old Linux.
Does anyone has any idea what is messing my local build or what I should try to look for next?
I know it's a very vague question, but I'm completely at a loss. Fully available to send any more information required to help me out with this. Maybe I'm simply doing smt really stupid I can't put my finger on. Or maybe not. Any ideas?
why use Maven when you have such quantity of local jars?
So we have a client that have a lot of private jars and custom jars.
For example commons-langMyCompanyCustom.jar which is commons-lang.jar with 10 more classes in it.
So on their environment we use 100% Maven without local dependencies.
But on our site we have the jars for development in Eclipse and have Maven build with the public ones, but we do not have permission to add their jars in our organizational repository.
So we want to use the Maven good things like: compile,test, build uber-jar, add static code analysis, generate java-docs, sources-jars etc. not to do this thinks one by one with the help of Eclipse.
So we have 70 jar some of them are public if I get the effective pom on their environment I found 50 of them in Maven Central, but the other 20 are as I called "custom" jars. I searched for decision of course but found this:
<dependency>
<groupId>sample</groupId>
<artifactId>com.sample</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/yourJar.jar</systemPath>
</dependency>
So for all 20 of them I have to add this in the development maven profile??
Is there a easy way like in Gradle where you can add all folder with its dependencies to the existing ones?
Also installing one by one in every developer's repo is not acceptable.
Please forget the system scope as mentioned before! Too problematic...
Ideally:
Ideally, all your developers have access to Repository Manager in your or their organization (if possible).
A central environment for your System Integration Testing, maybe?
Alternatively, you may have a central environment for testing where all the dependencies are provided. This approach can be used to simulate how a compilation would work as if it's in your client's environment. Plus you only setup jars once.
So on their environment we use 100% Maven without local dependencies.
But on our site we have the jars for development in Eclipse and have
Maven build with the public ones, but we do not have permission to add
their jars in our organizational repository.
According to what you're saying in the above-quoted excerpt I believe you want to have set in your build's pom.xml assuming that in the client setup the dependencies will be present.
Especially, as you indicate that the organization doesn't give you permission to add their jars in your repository, I would use the provided scope.
As stated in the Maven docs, the definition of a provided dependency is as followed:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
So basically you assume that these dependencies will be present at your client's setup. However, this has some limitations. Meaning you can build solutions independently but cannot test it locally because you won't have the dependencies on your workstation.
If you won't even have access to the jars to configure your central environment ask if your client can provide a DEV/SIT environment.
None of the above? Inherit a parent pom.
To avoid the whole constant copy-paste process for every single (related) project, maven has the tools to centralize dependency and plugin configurations, one of such is by inheriting the configuration of a parent pom. As is explaining in the following documentation it is quite simple:
First you create a project with just a pom.xml where you define everything you wish to centralize (watch out, certain items have slight differences in their constructs);
Use as property of packaging tag the option pom: <packaging>pom</packaging>;
In the pom's that have to inherit these configurations set the parent configuration tags in <parent> ... </parent> (documentation is very clear with this);
Now everytime you update any "global" pom configuration only the parent version has to be updated on every project. As a result of this, you only need to configure everything once.
You can also apply this together with the abovementioned solutions, this way combining to find a solution that fits best to your needs.
But there is a big Maven world out there, so I advise a good read in its doc's to further acknowledge your possibilities. I remembered these situations because I've been in a similar situation you seem to be now.
Good luck!
Another alternative is the project RepoTree.
This one creates a Maven repository directory (not a server) from another directory which contains just the .jars. In other words, it creates the necessary .pom files and directory structure. It takes into account only the precise information from metadata contained in the archives (MANIFEST.MF, pom.xml).
Utility to recursively install artifacts from a directory into a local
Maven repository Based on Aether 1.7
This is 5 years old, but still should work fine.
TL;DR: MavenHoe creates a Maven repository server (not a directory) which serves the artefacts from a directory, guessing what you ask for if needed. The purpose is to avoid complicated version synchronizing - it simply takes whatever is closest to the requested G:A:V.
I have moved the MavenHoe project, which almost got lost with the decline of Google Code, to Github. Therefore I put it here for availability in the form of a full answer:
One of the options you have when dealing with conditions like that is to take whatever comes in form of a directory with .jar's and treat it as a repository.
Some time ago I have written a tool for that purpose. My situation was that we were building JBoss EAP and recompiled every single dependency.
That resulted in thousands of .jars which were most often the same as their Central counterpart (plus security and bug fixes).
I needed the tests to run against these artifacts rather than the Central ones. However, the Maven coordinates were the same.
Therefore, I wrote this "Maven repository/proxy" which provided the artifact if it found something that could be it, and if not, it proxied the request to Central.
It can derive the G:A:V from three sources:
MANIFEST.MF
META-INF/.../pom.xml
Location of the file in the directory, in combination with a configuration file like this:
jboss-managed.jar org/jboss/man/ jboss-managed 2.1.0.SP1 jboss-managed-2.1.0.SP1.jar
getopt.jar gnu-getopt/ getopt 1.0.12-brew getopt-1.0.12-brew.jar
jboss-kernel.jar org/jboss/microcontainer/ jboss-kernel 2.0.6.GA jboss-kernel-2.0.6.GA.jar
jboss-logging-spi.jar org/jboss/logging/ jboss-logging-spi 2.1.0.GA jboss-logging-spi-2.1.0.GA.jar
...
The first column is the filename in the .zip; Then groupId (with either slashes or dots), artifactId, version, artifact file name, respectively.
Your 70 files would be listed in this file.
See more information at this page:
https://rawgit.com/OndraZizka/MavenHoe/master/docs/README.html
The project is available here.
Feel free to fork and push further, if you don't find anything better.
I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?
These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".
I have a bit of an issue with Spring 3 and it involves its dependencies or better said "their lack of...".
When you download Spring 2.5.x for example you get a spring-framework-2.5.6-with-dependencies.zip file containing the Spring distribution as well as its dependencies.
For Spring 3 there isn't one. You only get the distro while dependencies are managed in Maven repository and retrieved with Ivy. That was the decision springsource fellows took. Which brings me to my problem.
At work Maven repository has "forbidden access" written all over it and we don't use Ivy. We use Maven but with a local enterprise repository and nothing beyond that is allowed (security concerns yada yada which ultimately makes sense but makes my job as a developer harder). To put something in the local repository means approvals, deployments of resources, configurations, acces rights, time, money etc.
It is OK with a few JARS here and there but I imagine Spring dependencies mean more than a few JARs. So that will be approved and installed over o long period of time. Meanwhile we can't develop in Spring 3 (while everything is set up in the local repository) so we need the dependencies.
I found this page here:
http://static.springsource.org/downloads/nightly/snapshot-download.php?project=SPR
which contains some dependencies but i need it for release 3.0.5 not for nightly builds.
In short, I need a spring-framework-3.0.5-RELEASE-with-dependencies.zip file. Ho do I get one?
P.S. I must mention that I can't just download something home and bring everything on a stick which is the first suggestion that pops in mind. Other rules apply for this :D, so I need an official release to download.
Steps:
Go to http://s3.amazonaws.com/dist.springframework.org/release/SPR/spring-framework-3.0.5.RELEASE.zip
When you hit the URL, your download for jar files starts automatically
After unzipping, there is a folder called dist which contains the following jar files for spring 3.0.5
org.springframework.aop-3.0.5.RELEASE.jar
org.springframework.asm-3.0.5.RELEASE.jar
org.springframework.aspects-3.0.5.RELEASE.jar
org.springframework.beans-3.0.5.RELEASE.jar
org.springframework.context.support-3.0.5.RELEASE.jar
org.springframework.context-3.0.5.RELEASE.jar
org.springframework.core-3.0.5.RELEASE.jar
org.springframework.expression-3.0.5.RELEASE.jar
org.springframework.instrument.tomcat-3.0.5.RELEASE.jar
org.springframework.instrument-3.0.5.RELEASE.jar
org.springframework.jdbc-3.0.5.RELEASE.jar
org.springframework.jms-3.0.5.RELEASE.jar
org.springframework.orm-3.0.5.RELEASE.jar
org.springframework.oxm-3.0.5.RELEASE.jar
org.springframework.test-3.0.5.RELEASE.jar
org.springframework.transaction-3.0.5.RELEASE.jar
org.springframework.web.portlet-3.0.5.RELEASE.jar
org.springframework.web.servlet-3.0.5.RELEASE.jar
org.springframework.web.struts-3.0.5.RELEASE.jar
org.springframework.web-3.0.5.RELEASE.jar
NOTE : You can download any release of spring framwork just by modifying the release version to 3.0.1 or 3.2.5(any other versions according to your need)in the above mentioned URL
One of the main reasons that there isn't a big “Spring 3 with everything” build is that you probably don't need it. (It's absolutely huge!) Instead, you're supposed to identify the parts that you actually need and only include them. The problem is that this makes it hard for you.
Alas, the best way I see long-term for you is to get Spring 3 and its dependencies into your institutional Maven repository (switching to Ivy wouldn't really help; the institutional problem is not with Maven but with depending on unvetted external libraries). Yes, it's awkward but that's what you've got to work with. Sneaking things in the back-door won't help! Perhaps it would be reasonable to inquire whether there is a relatively rapid method to get things approved where previous versions have been found acceptable (which might be “yes, subject to there being no license surprises”)?
You'll probably need to use Maven (or Ivy, but I don't know it) to get the full list of dependencies first, so that you can describe exactly what changes are actually involved, and be aware that some of the dependencies might already be approved.
(I just wish I had a better idea for how to deal with your process, but working against both its spirit and letter is a way to get a corporate bureaucrat very upset. Life's not worth such things.)
I've shared the very origin file from Spring official site:
http://kuai.xunlei.com/d/QBEMGYUXOOKN
http://s3.amazonaws.com/dist.springframework.org/release/SPR/spring-framework-3.0.5.RELEASE-dependencies.zip
Create a project at home, add what you need in spring 3 to that, open the project with eclipse+m2eclipse and view the dependency hierarchy. That will then tell you what you need as dependencies on spring.
Chances are a lot of the dependencies are the same as they were in spring 2.5 as a lot of the spring 3 stuff didn't change.
You can ask your maven at home to download all the dependencies... and you'll have your own version of spring+dependencies