I'm very new to Maven, and have a question about building multiple Maven projects.
We have two Maven projects, Project A and Project B.
Project A depends on an artefact generated by Project B.
When changes to project A or B are checked into SVN, our local Hudson server builds the modified project (and any dependent projects) and uploads the artefacts into our local Nexus repository.
Now, consider two developers.
Developer 1 hacks away at project A only, and when Developer 1 builds project A locally, Maven goes and gets the latest project B snapshot artefact from our Nexus server.
Developer 2 hacks on both project A and project B simultaneously. When Developer 2 builds project A locally, we want maven to build project B with any local changes and use the resulting artefact to build project A. How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus? Is this a standard usage pattern for Maven?
How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus?
You can setup an updatePolicy for the snapshots artifacts per repository. Actually, Maven checks for SNAPSHOT updates only once a day by default. So if you build a version of B locally, you should be able to use it to build A for some time, even if a new SNAPSHOT is deployed to your Nexus. If this doesn't suit your needs, you can change this policy. You could also build offline (using the -o option).
PS: AFAIK, automatic updates will be disabled by default in Maven 3.x, you will have to explicitly ask for updates (with the -U option).
Related
Background: Gitlab 13.4 building/deploying Java Tomcat application using Maven using two runners (on the same machine)
Project A is the web application and buils/deploys a war file. it depends on Project B
Project B is a set of dependencies as a jar file
the .gitlab_yml file for project B kicks off a build/deploy of Project A after the 'deploy' stage is completed.
The problem is that Project A doesn't reliably have the latest version of the project B jar file
i updated the mvn command to include -U to force a retrieve all resources
We have two branches for our solution, a dev and a main branch. We use the built in NuGet feed in TeamCity which is consumed by Octopus Deploy. The problem we have is we have one feed but two build tasks, one that builds the dev branch and publishes the artifacts and one that builds the main branch to publish the artifacts. We need a way to distinguish these packages, we are using the OctoPack plugin to build the packages.
What we would like is to end up with an artifact named: package-dev.1.0.0.0.nupkg
Is there a way using TeamCity to rename an artifact in this sense to append -dev before the version? Happy to append to the front, as long as Octopus Deploy picks up the latest version.
The way I tackled this issue is by using unique version numbers across multiple builds with Auto Incrementer as a team city plugin.
This will ensure that each build that uses the autoincrementer has its own unique build number but this is where you just have to ensure your team is communicating well about which version is in which environment.
So if the autoinc is at 50 it should be something like :
-> Dev branch build outputs package.1.0.0.50 , then
-> Main Branch outputs package 1.0.0.51
In octopus it's the same project or entirely different project!
I have a project which has 20 different projects this was build using ant.now i want to move it to maven build.I have created jars for all the 20 projects + 1 main project.I need to build this main project to get the app running.I am working with NetBeans 6.7.1.How am i going to integrate this project and deploy it?Please help !
In maven, you can either create a multi-module project or add the other projects as dependencies.
I prefer the first approach, because it lets you build everything in one run (and that's exactly the reason why others prefer the second version, because they want their projects to be independent of each other).
Either way, run mvn deploy or use the maven-release-plugin on the individual projects or the root project of a multi-module project.
I have a couple of projects that I'm working on in Eclipse (or any IDE, so I don't want to depend on specific eclipse dependency maven capabilities). Some projects depend on other projects. Typically in Eclipse I would add the projects as references to other projects, but I'm not sure how to handle this when using Maven. In the deployment environment, there will be jars created and the maven build can pull the latest jars from the repository. Is there a way to reference another project's source code using maven while in the dev environment? For example...
I have this scenario:
Project A depends on B
I need to make a change to B and that will require an update to A. I don't want to make the change to B and check it in without checking in A since that will break A. And I would like to manage these dependencies through Maven -- any help would be appreciated.
thanks,
Jeff
The maven 2 eclipse plugin has 'workspace dependency resolution', where the dependencies are first looked up in the workspace, and then in the repository.
What I do is use SNAPSHOT version when doing my development. Project A depends on the latest SHAPSHOT version of Project B, so when I change Project B, I have Team City recompile and push out a new SHAPSHOT artifact to artifactory. Then I clean and compile project A to get the new Project B.
This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.
Environment
ClearCase - Version 7.0.1.2 of ClearCase.
Maven - All of them, from the Maven website.
Hudson - Version 1.307 downloaded straight from the Hudson website
Questions
Does Maven run from a VOB?
I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.
To prevent there being extraneous files, I used the -rnname flag in clearfsimport.
This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.
Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.
A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!
In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.
Does Hudson work with ClearCase?
I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.
I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.
In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.
This saves extra administration on both the part of me (the admin) and my users.
What Internal Repository Manager did you use?
I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.
I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.
But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)
That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
I am not using this SCM, but there is a Maven2 plugin called SCM that handles Clearcase.
I had a team building with Maven 2 and using Clearcase as the version control system. We used Archiva as the repository for built artifacts so the development team did not need to use the SCM plugin.
However, the continuous integration server was Continuum and that was relying on the SCM information in the POM. We had problems with the Clearcase SCM grabbing snapshot views using out branching strategy. One of my developers had to tweak the Clearcase SCM code to get it to work with our branches. We both moved on before we got round to contributing his fix.