I have a project with three modules and I want to push all the modules to one repository, but IDEA suggests me 3 different ones. Ho
Related
In my company we have teams working on services which are built using maven pom's and gradle build scripts. The problem I have is that when the team's build their web applications, the jar files that get's created by one team member needs to be available for other team members in their pom files.
What we were thinking was to have a local nexus repo and then push the built jar files to nexus so that when any other team member builds they also can refer the same jar file.
However this could lead to versioning problems as two team members could be generating the same jar file if they change different files in the same project.
What I would like to know is are their any best practices in doing these types of builds and versioning.
There are many different opinions and strategies on how to manage this process. Some aspects are relatively common, however.
I'd say there are two key elements:
* Proper use of version definitions and references
* Automated builds and nexus deployments
If you have work ongoing for a specific artifact, for a specific release, then those changes should all go into a specific numbered version of the artifact. While work is ongoing, that version should end with "-SNAPSHOT". When the work for a release is completed, that version number should remove the '-SNAPSHOT". You also likely want to have separate repositories in the Nexus server for "snapshot" and "release" artifacts.
Concerning pushing artifacts to Nexus, this should always be done through automation. Manually pushing artifacts should be very rare. When a regular build is done for ongoing work, that should automatically deploy the "-SNAPSHOT" artifact to the snapshot repo. When your build automation is running a "release" build, those artifacts will deploy the release artifact to the release repo.
There are many other options and details you'll want to examine. Only implement features in this process that provide clear value in your situation. It's very easy to set up a process that is more complicated than you need.
My project is git version control enabled. I have a problem if I add something from cloned third-party repository.
The problem is that files have their repositories and they appears in Source Control -> Working Copies and make some problems.
Can I have them added to project from some local cloned git-repository and ignore their repositories without making copy of those files?
Sounds like you want to use git submodules. This basically stores a reference to the dependency's git repo and the commit you have decided to use of that dependency, within your own git repo.
It does not store the dependency's git repo as a whole and means you can easily choose to use an earlier commit than HEAD of that dependent repo.
Reference (many others available on the internet).
trojanfoe's answer is definitely the way to go for straight repos, but if the projects are available via CocoaPods or Carthage, I'd recommend doing that instead of using submodules.
I'm using sonatype nexus repo hosting and I have two artifacts where A depends on B but they are separate projects (not multimodule). I staged B as 1.0.0 but now I want to stage A with a dependency on B-1.0.0 and not on its snapshot; however, because B is still just staged and not released, maven complains that it can't find B-1.0.0. What is the correct way to do this? It doesn't make sense to me to have to release the dependency (B) without it being tested as part of another project (A)
What am I doing wrong? IIUC, staging repos are dynamically created, so adding the (temporary) staging repo as a <repository> in project A doesn't sound good either
as a secondary question, I also would like to know if I am supposed to stage the main artifact (A) in the same staging repo as B or if I should close B and stage A in a new staging repo
You should have a separate repository group from public and have it configured as the target group for your staging profile for project A.
Then when you build project B you use that group and it will be available for building that project.
I know how to do it for an external repository but not for my local repository, since I don't have a <repository> for my local repository in my settings.xml.
I use snapshot versions for my sub-projects, so when I re-build the parent project I want maven to get all the sub-projects snapshot versions from my local repository not only once a day (which seems to be what happens by default) but always.
If I'm understanding your comment, I think #FrVaBe may have the correct answer. When you change code for a child project on your development machine, it's up to you to rebuild the snapshot and get it into your local artifact repo (via mvn install) so it's available for the parent project to use.
If, however, you want your parent project build to pull in changes made by your teammates and published to the corporate remote repository more often than once per day, read on.
Here is a summary of how Maven central (and kin), remote repositories (e.g a company instance of Nexus or Artifactory) and your local repository work together. If you always want the latest version of snapshots to download on every build, go into your settings.xml file, find <snapshot> repository containing the snapshot you want, and change the <updatePolicy> value to "always". Personally I rarely do this, I simply add the '-U' option to my mvn command line when I want to ensure I have the latest version of a snapshot from my remote repo.
There is no update policy for the local repository!
The local repository is just a bunch of files. When you install to your local repository your local projects already reference the artifacts directly. There is no update that needs to be performed except that maybe your IDE needs to be refreshed to pickup the newer files.
In this manner you can build local snapshots all day long with no versioning headaches, no updates required and no old artifacts left hanging around afterwards. Nice and clean but not so obvious if you're new to Maven and still getting to grips with all these repositories and their fancy update mechanisms.
I think you missunderstood something. Maven will always take the latest/newest SNAPSHOT from your local respository. But in your project setup (Project Inheritance) you need to build the sub projects on their own if you changed something.
An automatical build of the sub project only happens on a Project Aggregation layout.
The difference is explained in the Project Inheritance vs Project Aggregation section of the documentation.
I am using a local maven repository to house some code I am using to develop a project. I have cited this repository in my project.clj file, and am now able to rely on local jars in this way (how to do this in a previous question of mine).
Since I am actively developing these projects, I have my project.clj file looking for the LATEST version. But, in order to update a dependency, I still have to increment the version number of that dependency and then run lein install to build it to the maven repository.
Does leiningen have a way to do this where this is automatically done for me when I build the project that depends on things from the maven repo? Can lein just look for those things and rebuild them as needed?
If you want to develop two projects in parallel, with one depending on the other, you can use symlinks in a checkouts directory to avoid having to install snapshots all the time.
To quote from the Leiningen README:
Q: I want to hack two projects in parallel, but it's annoying to switch between them.
A: Use a feature called checkout dependencies. If you create a directory called checkouts in your project root and symlink some other project roots into it, Leiningen will allow you to hack on them in parallel. That means changes in the dependency will be visible in the main project without having to go through the whole install/switch-projects/deps/restart-repl cycle. Note that this is not a replacement for listing the project in :dependencies; it simply supplements that for tighter change cycles.
Are your dependencies version snapshots? Maven should update all *-SNAPSHOT dependencies on build automatically.