I have a lot modules for my Jenkins build server. Instead of declaring new modules for each of them, I would like to share a common configuration and select my modules before starting my build in a tree view. Let's say my root parent project has A,B,C,D projects and each of them has A1,A2,B1,B2,B3 etc... I would like to choose B1,A1 only to build.
Is there any plugin for this?
Thanks
You can use a feature of Maven3 advanced reactor options and choose which project you would like to build, i.e.:
mvn -pl B1,A1
You can use additional switches to decide how to handle dependant projects:
-pl, --projects
Build specified reactor projects instead of all projects
-am, --also-make
If project list is specified, also build projects required by the list
-amd, --also-make-dependents
If project list is specified, also build projects that depend on projects on the list
In this scenario providing a list of projects is a piece of cake, using project parameters as the most obvious example. You can even create a plugin to support custom parameter type with Maven modules names and artifacts IDs as names/values.
Related
We build our application suite out of libraries and standalone uberjars, using Leiningen to build. We use the lein-parent plugin and have a parent project that sets versions for 3rd party dependencies and for our own libraries.
Our team is distributed and builds locally, using a central Artifactory for libraries. Consequently, we tend to set library versions to -SNAPSHOT qualifiers to ensure that everyone who thinks they're working at the head of the main branch is getting the latest library jars. The parent project itself has a -SNAPSHOT qualifier, since there is constant churn in 3rd party dependencies as we (for example) mitigate code vulnerabilities as found by tooling such as the OWASP vulnerability checker.
At release time, we need to freeze all this: the -SNAPSHOT qualifiers need to come off the parent project and each of the child projects. The lein release tooling does this just fine. Commands like lein release take care of project versions, and lein change :parent-project:coords set [groupid/artifactid "version"] can take care of references in child projects to the parent.
However, we can't find any Leiningen tooling that can automatically go into the :managed-dependencies vector of the parent project and update versions of specified child projects. It appears that lein change can only deal with values that are keyed in project maps.
Has anyone found a workable solution for managing interdependencies between parent and child projects during release tasks?
Leiningen 2.9.9-SNAPSHOT now supports editing the version of a specific dependency in a project's :dependencies or :managed-dependencies vector, in a parent or child project.
I need some help to add a .*lib file for my solution and this solution has many projects.
I am going to make it more clear. Lets i have a "ABC.sln" solution in visual studio 2010. This ABC.sln has several projects (VC++ Project (1,2,3....*vcxproj) and these 1, 2 and 3 projects required a 123comman.lib file in the linker option of their respective projects.
Currently i add this library file in all three projects and it works fine but i think there must be some way to set this library file as a common stuff for all projects inside a solution. So that i just set it once and all projects can share it.
Is it possible ? if yes how can we do that ?
Thanks!
VS2010 introduced the concept of Property Pages, which is distinct and separate from Project Settings. Property Pages are similar to Project Settings in that you can specify things like additional dependencies, language rules, optimization settings, etc. But unlike Project Settings, Property Pages use a different file to store these settings, and these files can be shared across all (or any) projects in your solution.
Documentation for Property Pages is here -- I'll leave the details up to you. But to get started, go to View > Property Manager, open up one of your projects, create a new property page for a given platform (x64 Debug, x64 Release, etc), and set your settings. Then you can use this Property Page in your other projects.
Projects can share configuration via property sheets. You can create them in the project configuration tree by right-clicking a project and selecting "add property sheet" or something like that (been a while). In a property sheet, you can specify the import, and then you can add the property sheet to all other projects as well.
This does not reduce the initial work: you still have to add something to every project. Solutions do not have the ability to inject anything into projects; they're a completely different file format.
However, it does save you work if you then have to do another task that is common to all projects, like changing the library name you want to include, or adding another library. Then you only have to do it once, in the property sheet.
Make a NuGet package out of this library, and use the package manager to add the dll to all projects.
An in-depth description of how to generate a NuGet package for C++ code can be found here.
If you do it this way, it only takes a single click per project (to enable the checkbox when adding the package in package manager) to add the library as dependency.
If your problem is only about sharing the same file among different projects in a single solution. You can add the file at solution level and then do add existing items in individual projects and choose to add them as link.
This way you have only one copy of file that is shared.
I'm building a Ruby C Extensions and I have to build for both Ruby 1.8 and Ruby 2.0. The source code is the same, but I have to link to different Ruby libs and set different build paths.
In Xcode I was able to set up a project where the project contained the common configuration. Then I set up two targets that configured different include paths and libs as well as different output (Debug/Release) paths.
When I build I will get two products built, one for each targeted Ruby version. When I build Release I get:
build/Release/1.8/Example.bundle
build/Release/2.0/Example.bundle
Now I am trying to do the same thing for Visual Studio 2010. I've been looking at the Configuration Manager and Property Sheets, but I'm struggling to fond out how I can make the same type of inheritance for the targets as I can in Xcode.
Is it possible to have multiple targets in VS, as you can in Xcode, that produce two products from the same project when you build?
Do I have to create a Debug and Release configuration for each Ruby core I want to target?
I think I know what you are looking for (but I can't be sure, as I have no experience with Xcode.)
If you are using Visual Studio, one way you can do something like this is to set up you project properties for a build configuration (e.g. for Release) and then copy that config into a new build type (e.g. call it "Release20") and go in and change the properties that you want for the new build. You can do this in "Configuration Manager". (When you select to add a new configuration, it lets you copy all properties from an existing one.)
However, it seems that you are already familiar with this, so I'm not sure what the problem is.
Another thing you should know is that the two build configs don't stay linked together (this is not a proper inheritance and overriding of properties, like using property sheets.) If you change something in one, it doesn't affect the other.
Precisely for these reasons (in addition to some others) I myself have foregone trying to wrangle the VS build system. I now use Premake and CMake for all my projects. But of course it's quite a chore building a build system for someone else's large code base.
I have a solution file that requires a third party library (open source). The containing solution uses the typical configuration names of "Debug" and "Release".
The third-party one has debug and release configurations for both DLL and static libraries - their names are not "Debug" and "Release".
How do I tell the solution to build the dependency first and how do I correlate which configuration to the dependent configuration?
That is, MyProject:Debug should build either 3rdParty:debug_shared or 3rdParty:debug_static.
UPDATE:
I do not wish to correlate from one to many. I just want to be able to pick one and stick with it. So in my case I would correlate Debug in the main project to 3rdParty:shared_debug.
How do I do that?
When I say build for the solution for debug I want the third-party stuff to build as well.
In the IDE there is "configuration manager" where you can stick project configurations with solution configurations. Also there is "build dependencies" tool to choose which project should be compiled first.
I do not think there is an easy way to have a single solution configuration switch between building different project configurations; if I understand correctly, you want
mySolution:debug -> myProject:debug, 3rdParty:debug_shared, ...
and at another point in time
mySolution:debug -> myProject:debug, 3rdParty:debug_static, ...
You could manually or even via macros change the build configuration for the solution each time you build, but isn't that a bit tedious?
If you follow the Visual Studio way, you create extra solution configurations, and change the settings in the build Configuration Manager to have them match to the third-part ones.
mySolution:debug_shared -> myProject:debug, 3rdParty:debug_shared, ...
mySolution:debug_static -> myProject:debug, 3rdParty:debug_static, ...
This does not change your own project's configuration in any way, and it's relatively easy to switch between them.
Edit: if your project depends on this third-party library, then shouldn't it also need two configurations? Suppose your project wants to use the third-party static library, then the linker needs to know its name and path. On the other hand if you want to use the DLL, the linker needs to know another name/path. How do you switch between these two without having two configurations? At some point you'll have to instruct the linker which library to use, so you'll just end up with something like
mySolution:debug_shared -> myProject:debug_using_shared_3rdparty, 3rdParty:debug_shared, ...
mySolution:debug_static -> myProject:debug_using_static_3rdparty, 3rdParty:debug_static, ...
We've got a program which runs separately, executed with an execvp command. So it needs a main method, but I believe that poses a problem to eclipse with a managed make. Do we have to keep this code segregated into a separate project, or is there a way to incorporate it into the same eclipse project?
Create a project for each executable that has a main() function, and create an additional project to represent the software as a whole (a "container" project of sorts). Eclipse allows you to specify projects as dependencies of other projects, and in this case you will want to set up the container project to list the other projects as "Referenced Projects".
To do this, create the container project, then right-click on the project in the left-hand column (project explorer) and click "Properties". A dialog box will appear. Select the "Project References" item in the list on the left-hand side and you will see a list of all projects that Eclipse is currently working with. Check the boxes next to the projects for your individual executables, then click OK. Now, when you perform a build on the container project, Eclipse should automatically perform a build on these dependent projects as well.
When using sub-projects in this manner, I have (personally) found it useful to create a working set that includes the container project and all of the sub-projects (this can make searching the entire software project easier).
Keep it in the same project and use preprocessor defines which you define differently depending on what kind of main you want to include in the current project. Here the mains are in the same file, but they can of course reside in different files.
#if defined(MAIN_ONE)
int main()
{
// Do stuff
}
#elif defined(MAIN_TWO)
int main()
{
// Do some other stuff
}
#endif
If the makefile being invoked doesn't compile the 2 main() methods into the same executable, it won't cause a problem. I don't know how eclipse projects are handled - if it's like VS, where "project" means a single executable or library, and "solution" is a group of "projects", then it would seem you'd need more than one project. If, OTOH, a "project" can contain different "subprojects" where a "subproject" is an executable or library, you should be able to handle that easily.
I am not aware of any easy way to build two mains using Eclipse build system. The smallest change you need to do might be to move to makefiles and use makefile targets to build.
Instead, I'd advise you to move to using CMake. CMake can be used to generate makefiles to be used with eclipse. The advantage you get from using CMake is that you can easily state how to build the libraries and link the libraries to form the executables. CMake can generate builds for Eclipse, Visual Studio, Code Blocks, or makefiles (so you can use command prompt).
This is built in the C++ language. You would have to modify it to get your result. There is something to do 2 things at once if that is what you want.