I have a following problem. We have a central maven repository hosted on our company server. Our team is working on a project. Everyone here uses that repository to get the required artifacts. If something is missing at the moment and is required for the task that the developer is currently dealing with, he installs this artifact manually to the central repository, so that his commits don't break the automated builds.
Now, each developer also has Glassfish v2 installed on his machine. That is for testing and debugging purposes. Before committing the changes, developer makes the .ear for the project with Maven help. However, after the developer deploys the ear to it's local glassfish, frequent errors arise, because the set of glassfish libraries may not contain all the latest dependencies of the central company repository.
Right now in case of the error the developer simply reads the log and looks what exactly is missing. After that he manually copies the required jar inside his local $GLASSFISH_HOME$/lib dir. But that seems a little bit frustrating. How can this be done automatically?
Right now we are trying to implement the following solution. The developer has to synchronize his local maven repository gathering all the artifacts from the central one that are required by the project. This local repository has to be placed on the java classpath, so that glassfish would also see it. Is that a correct approach? Maybe there is a way to install directly all the required artifacts from the central repository inside $GLASSFISH_HOME$/dir and this can be done automatically during deploy?
About having to install dependencies. If the developers need to install dependencies missing from public maven repositories, take into account that usually maven proxies have the ability to cache public repos. For instance, archiva has a proxying cache. If the dependencies are your own project deliverables you should consider releasing and deploying with maven to your company repo.
About latest versions. You need to specify maven what version of dependencies should use. I would prefer editing my poms manually, anyway there's a variety of ways to achieve that.
The libraries should be part of the project, I think. If not standard libraries of glassfish, they should be included, for instance, in your war file as part of your project. If not standard but not part of your project (not the regular approach) consider managing this glassfish as a project on its own (own git/svn repo, own pom, own versions, own everything).
Good luck.
Related
As we just migrated all projects to maven projects, one question came up and I couldn't find any suitable solutions yet.
What if maven shuts down forever or just one artifact is not available anymore? Or what if some versions are not available anymore, and the software cannot run with the newer ones?
Since we're not hosting a copy of the artifacts locally, should we host copies of every jar somewhere for such a scenario?
Thanks
Unlikely, but if you build your artifacts with Maven, you already have a copy of each relevant artifact - in your local repository. If you backup it from time to time, you have the necessary level of security.
Alternatively, use a company repository manager (Nexus/Artifactory) to proxy MavenCentral. It will also keep copies of the used artifacts.
The situation:
We have several apps, which use a library developed by ourselves. All app projects as well as the library are under constant development.
Our goal is to have a local maven repository, which allows us to always build the apps with the latest library version, like all those dependencies listet in the Android-Studio dependency chooser here
We don´t want to use the central maven repository, as it makes our code public.
Is there any chance to have a lokal maven repository which is going to be fully compatible with Android Studio and Gradle or is there any other (easy) alternative?
Yes, you can use a local Maven repository manager, which will let you maintain a set of private artifacts for your organization. There's some documentation here: http://maven.apache.org/repository-management.html but the brief explanation is that you can set up a repository that's similar to Maven Central except it's private. There are various repository manager software packages, including Apache Archiva, Artifactory, and Sonatype Nexus.
My company has a policy that software deployed into production has be be built on a specific machine that has no access to the internet.
We're currently using Maven. When running build on development machines, maven automatically download the dependencies from central Maven repository without problem. Then before go production, we put all files in local Maven repository (.m2/repository) into source control, and then run offline build with
mvn -o -Dmaven.local.repo=<local repo dir> package
this method works, but managing thousands of files in source control is a real pain, particularly the dependencies for Maven plugins. Thus my question, how can I improve the workflow so as to make it easier to maintain the dependencies in the source control?
I'm considering switching to Gradle, mainly because it's more flexible and doesn't depend on plugin downloaded from repository. but then I found out the Gradle local cache directory is not transportable between computers, which means I cannot check it into source control.
Suggestions and recommendations are all appreciated.
Use internal repository manager like Nexus or Artifactory. Always put released artefact to production.
But building project on production machine is not good idea. Better use complete artefact like EAR or WAR with all dependencies included, or something like jar-with-dependencies or other assembled distros. Build project on your CI server and deploy complete package with one click to production server.
Given a group of developers, each one has the following requirements on the respective (local)Windows machines:
Through IDEs like Eclipse, STS etc., run Spring, Hibernate etc. projects
Quickly build, deploy , run, change if required, rebuild and redeploy(everything, preferably via IDEs) the projects available on Github
There are following constraints/objectives :
The individual developer machines have restricted or no Internet access
The developers must take the required jars from a single location which will store jars required across the team
Whenever required, a developer must be able to pull updated jars from the central location onto his local environment and continue to run the projects seamlessly
Within the IDE, build a Github project and run it (locally)
Attached is the image to give a clear idea of the work environment which I'm envisaging!
I have started reading Maven but quite overwhelmed - how should I proceed?
You should use an internal Maven repository. There is such applications as Nexus and Artifactory (those are probably the close numbers 1 and 2 in the business, just my opinion). You can set it up to use your proxy server.
It will be able to serve as a proxy for your Maven clients, and keep a copy of the artifacts that are downloaded. They will even allow you control over what kind of artifacts your developers pull in (although they may not always appreciate that).
It will also be able to store and serve your own artifacts that your developers can deploy (release) to it.
Maven is great at dependency management, and that is what most organizations start using it for. But as your process matures, there is also the opportunity for version/release management using Maven. Developers will build SNAPSHOT versions for themselves, or share these with the team through the repository. When they release their artifacts, they make a final version of the artifact available in the repository.
Maven has great support for your IDEs, myself I use Eclipse a lot, which has m2e to work with Maven.
Apache itself on 'Why do I need a Repository Manager?'
New tools require adaptation, sometimes culture shifts. And in the case of Maven, where many organizations come from scripted builds, it may require a paradigm shift. It sounds a bit as if you're at risk of being overwhelmed some more in the future. I think it will be worth your effort, but you may want to get some experienced help to get you on track.
More of a personal note: done with those proxy servers, alright!
As suggested by Sander Verhagen in another answer, what you should do is to use a repository proxy. Nexus and Artifactory is the most famous one. Here I will describe briefly steps you need to do for what you are looking for:
Set up Nexus in machine M
In Nexus, setup a proxy repository to Central (this should be available out of box), and other repositories that you want your developer to access. You may need to add http proxy setting when you are configuring the Repo Proxy.
(Optional, but recommended) setup a repository group which includes all the public repository proxies. Assuming URL of this proxy group is http://M/nexus/groups/public
In developer's machine, update ~/.m2/settings.xml, set http://M/nexus/groups/public as the mirror of central. If you created other internal hosted repositories in Nexus, you may add them in settings.xml as well.
That's all. You can use Maven as normal. Dependencies will now be fetched from Nexus in M.
Story
I know, that maven deploy command runs through the whole lifecycle. My problem, that it takes to much time in my case. Let me explain:
There is an application built up from a Server, and a single sourced Eclipse RAP&RCP client
The communication is defined by shared API projects which are built together
with the Server, but also needed by the GUI projects
The GUI projects are built by Tycho, so its impossible to build
both of them in one build (in one reactor, EDIT: since the P2 artifacts are different for RCP and RAP)
I build a release with a multi step Jenkins build. To make sure, that
everything is fine I first make a clean install for Server and the
GUI variations one by one, and then I deploy them, if nothing fails
Question
Building everything twice takes a lot of time. Is there anything like "please simply deploy all built artifacts as they are from my local repository to the POM defined repository with skipping the whole lifecycle"?
If you have the artifact already by the previous build, you may consider the deploy:deploy-file by following the Guide to deploying 3rd party JARs to remote repository. I always use this goal to publish some stable artifact to the developer public remote repository for letting other team to test/use.
I hope this may help.
I don't think that there is a pure Maven solution to this. The problem is that your deploy only build won't know which artifacts to deploy – AFAIK this information is only in the in-memory Maven model and not persisted to the target folder.
The problem can be solved with a Maven repository manager that supports staging, like the (commercial) Nexus Pro. Then, your build would deploy straight away into a staging repository, and only promote the artifacts to the (main) repository if everything succeeded.