We have a root POM in one of our project which more and more people consume. So we're now considering to extract this into a real parent POM (i.e. without <modules> and specific build commands).
Now the question is where should this new parent POM go? I see two options:
A new project
Into a folder parent/ inside of the framework project.
I looked at Maven and it uses a distinct project for the parent POM (here is the latest release).
But that means the relativePath is most often wrong (I really don't want developers to have to checkout the parent POM with this approach).
What are the differences/advantages/drawbacks of the two approaches?
The simple reason having a separate project for such company pom is based on the release cycle of such a pom cause it's different of all other projects/artifacts within the different projects. A release is necessary to have a released version which means a defined state of the company pom. This release is simply being deployed into your company repository manager and can be consumed by many projects. During the time updates are comming in like plugin updates etc. so you can decide making a new release of your company pom. And the different projects can decide to pick the update by simply changing the version or not.
Related
Here is my use-case:
Assume that I have multi-module maven project in which I make a change only in one of its sub-modules. After the change has been made, I want to release only a new version of this sub-module and not releasing the whole project.
Is there a way to do that in maven?
What maven recommends in this case as a best practice?
Is it a good practice to have different sub-module versions?
First as you asked. The idea of a multi module build is to have the same version of all modules which might mean releasing modules which haven't been changed.
BUT:
If you start to have different versions in child modules you will loose the idea and the support which leads to manual work....
Furthermore if you release different versions of the childs you have to asure that different versions of childs work correctly together which means in other words you have to do testing on different version combinations of that which would increase the testing effort dramatically.
if you use only a single version of the modules a customer can chose simply one version and can be sure the components working correctly together...I assume you have some unit/integration tests within your build...
I was wondering if anyone could help.We have the following project structure in our company :
Code/Common
Code/Project1
Code/Project2
etc...
When the Common Project builds, it has a PostBuild Event that copies all the relevant files into the Code/Common/Binaries folder. Then all the other Projects reference the Common components in this folder.
However, what we are struggling with is that when TFS Online checks-out the solution it does so to c:\a\src and the Common binaries are placed in c:\a\src\Binaries. Now, when the other projects (Project1 etc) do their build it cannot find the Common Assemblies, as not only are they removed, but the paths are different from what it expects them to be in c:\a\src\Common\Binaries instead of c:\a\src\Binaries.
Is there anyway to tell the build server to not delete those files in the "Binaries" directory and to specify the folder location to checkout to? Or how one one go about solving such a problem?
Thanks very much
A build server is a transient thing, you cannot rely on files to be there.
You need to either Create Nuget Packages for you common output and then consume these in your other projects (the 'proper' way), or you will need to check your dependencies into source control after each build so you can then reference them in subsequent builds (the 'really frowned apon' way).
Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.
I want to be able to have one set of build/props files that will build as many EAR projects as I tell it to.
Each EAR project will have its own set of modules, WARs, JARS, etc.
I'm want to set in a props file what each EAR project consists of, and I want to tell the build each time which EAR(s) to build.
In general, what is a good way to structure the build/props files?
So far, I have one build.xml file and one props file.
In the props file, I have an entry for each EAR project, for example:
Foo=fooWar, foojar
Bar=barWar, barJar1, barJar2
Not sure if that's a good idea or not, and I'm thinking how to tell the build which projects to build.
Since it could be many projects, I'm thinking I would want another props entry like:
projectsToBuild=Foo, Bar
And then before each build, the build person would edit "projectsToBuild".
Is this a good road to go down?
If you're building multiple projects in one hit, then it sounds like you don't have any proper dependency management in place. Have a look at using Apache Ivy to publish and retrieve from a shared repository (e.g. Artifactory), so that you can decouple your project and build them independently.
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)