At my new gig, they use Ant and cannot be persuaded to move to Maven.
I've looked everywhere for a decent example of how a multi-project ant build system should be assembled. The apache site falls short. I'm looking specifically for best practices to:
Automatically build local projects that are dependencies of a project
Share artifacts from project to their dependents
Export a project's dependencies and generated artifacts (jars) to be inherited by dependent projects
Share third-party dependencies between projects
I'm sure I can do all this without using Ivy - what did people do before Ivy? I really don't want to have to set up a corporate repository or rely on external repositories - the engineers here are really against that and have all their third-party jars checked into src control.
Can anyone point me at a good open source example of a multi-project ant build?
I don't have too much hands on experience with building large numbers of dependent projects with Ant, but this tutorial looks like it will do what you need without any additional tools.
Related
Bazel is a multi-language build tool from Google that acts as a replacement for things like Maven, Gradle, Make, etc. There are articles written on how to migrate from Gradle to Bazel, for instance. But I wonder if this tool works with Grails.
Grails is a web app framework that uses Gradle, but from what I've seen it's a bit more than that. For lack of a better term, Grails itself acts as a "wrapper" for common tasks such as building an app as a WAR or JAR file, running the app locally with different profiles, or scaffolding new files and features. Popular IDEs such as IntelliJ have Grails plugins available to run these Grails commands. So it seems to me like it's perhaps tightly coupled to the Gradle build script that backs it.
It also seems to me that just because Bazel says it supports Gradle projects doesn't necessarily imply that it supports Grails projects, because of all these reasons regarding Grails being more than just Gradle. But I wanted to ask the community if my assumptions are true, or if, in fact, people are already using Bazel as a substitute for Gradle inside Grails projects. Can it be done?
Bazel could in theory be used to build grails projects as it is fundamentally agnostic to the type of thing being built. That said, grails probably works well with gradle out of the box and you'd have to re-implement a number of things yourself again and probably is not worth the effort. If you are a large shop and have multiple other languages that you need to support however, it may be worth investing in the effort.
https://github.com/pubref/rules_maven supports using a gradle file to determine transitive maven dependencies if you want to investigate further.
I have workspace with n projects. I want to use ant to build all the projects with one command. The projects are depend on each other
For example project A depends on project B, so I want B to compile first When I compile project An I need to use B's project classpath.
The dependencies between the projects are represented in a ivy.xml file
The main challenge is that I have my own repository where all those projects have artifacts, and using the example I just gave Project A compiles against the B project coming from my the repository and not Against the B project that just was compiled.
I use CI process and I don't want to publish any project to my repository before all of them compiled and the the the QA tests was passed
What is the best practice build several projects with dependencies using ant?
You can combine the ivy buildlist task with subant to build the sub-projects in the correct order, based on dependencies.
See the following answer for an example:
ivy simple shared repository
Using this approach it's possible to re-create how Maven works without switching build tools.
You can spend a significant amount of time fighting ant and ivy in order to achieve what you want, or you could just use Maven or Gradle which will handle all of this for you automatically.
I am trying to grasp Release Management vNext and dsc configuration 'management' (how to manage DSC configuration files). In the 'Deploy Using PS/DSC' dialog box while editing a vNext Release Template
Why is PSScriptPath relative?
Does it really mean, that I somehow have to get my scripts I want to use relative to my current drop folder? What is the best way to do achieve this? I want to be able to do:
Have a separate git repository for configuration files
Reuse configuration files across different projects
I've read a promising article Packaging DSC configurations for Visual Studio / TFS Release Management vNext but it seems to be out dated and some kind of hack from my point of view.
How does Microsoft want us to use this? How to achieve reusable configurations in a separate repository?
Thank you
Use a submodule to your separate configuration repository, then ensure the submodule is initialized during the build. You can then copy the configuration scripts to the build drop folder as part of your build script.
The reasoning is that your deployment scripts will evolve over time, and that evolution should be something that is captured. If you ever need to redeploy an old version of your software, that old version shouldn't be deployed using new scripts -- it should be deployed using the same version it used initially.
We are looking into adopting a more CI friendly approach to managing our on premise jar dependency file server or doing away with it entirely for a better alternative. Right now it is just a Linux server with some form of file structure for example:
http://server_name/vault/apache.org/axis/version_number/axis.jar
http://server_name/vault/apache.org/axis/version_number/jaxrpc.jar
http://server_name/vault/apache.org/axis/version_number/axis.jar
Was wondering what type of standard adopted enterprise CI practices for managing these dependencies when you are doing automated builds.
Would storing them in AWS S3 be a good idea?
Are there any applications that help manage the jar dependency library? (Looking for open source solutions preferably). For example something similar to where you simply add a jar you need, and pull it down using an API when doing a build.
Assuming that apache ant is used for building out the project. And if that doesn't play well in the CI realm, what would be a good alternative?
I would recommend using Apache ivy to manage your build's dependencies. Ivy can be configured to pull your dependencies from Maven repositories which is pretty much the defacto standard now for storing Java binaries.
Use public maven repository with ivy
Maven Central is the largest repository of Java binaries. To host your private binaries there are various ready made options: Nexus, Artifactory or Archiva
I would like each of my Git repositories to have their own build.xml file, but avoid having to copy paste a lot of macrodefs used by the different build scripts.
What would be the best way to organize this?
Adding the ant macrodefs to a seperate Git repository and make them available for all the build projects on my Jenkins server?
Adding them for instance to a directory of the Ant installation folder?
Does anybody have some experience with this kind of setup?
I do the same. I feel strongly that every project should be stand-alone and not depend on another source code repository. To achieve this I package my common macrodef's as an ANTLib. These are simply jar files that can be imported into the ANT build like other 3rd party tasks.
The following answer explains how to create an antlib:
How to manage a common ant build script across multiple project build jobs on jenkins?
The really big advantage of this approach is when you save the ANTlib jar in a versioned repository like Nexus. I use ivy to manage my dependencies and this allows my common build logic to be versioned, enabling me to safely change logic without breaking older builds. When you think about it this is the same kind of workflow implemented by Maven (which also downloads plugins).