How can one exclude an aggregating project that does nothing but aggregating subproject from producing a jar file ?
You must disable the plugin for the aggregating project:
aggregatorProject.disablePlugins(AssemblyPlugin)
This will however disable the plugin for the aggregator and the aggregated projects.
You can enable the plugin for the aggregated projects by enabling them explicitly:
aggregatedProject.enablePlugins(AssemblyPlugin)
Related
I have an Artifactory with several projects, each having various versions of .jar files within.
How can I use Fortify to identify a vulnerability within a specific version of .jar file, say v1.2.1.
On top of this, I may have several latest versions.
Since v1.2.1 is identified to be having a vulnerability with the help of Fortify, how to identify the list of projects that internally use this v1.2.1 .jar file using Fortify ?
If you are using one of the Build integrations (i.e. generate a buildInfo) you can either:
1. Retrieve the BuildInfo json and extract the list of project dependencies from there (also, you can take a look here, here, and the best option, here). Or,
2. Use the Artifactory Query Language (AQL) to get a list of dependencies used in the project (Build).
p.s I work at JFrog
I am trying to create Team City build template which requires minimum customisation, and I want it to play nicely with legacy projects and projects developed with .NET Core/Standard and .NET CLI.
I am stuck with NuGet as there were some considerable changes in how things work.
Earlier we had to create nuspec file to pack project as a NuGet package. At least in that file we could define various package-related properties.
New csproj file format allows us to define all package properties inside itself. That's fine, but how then do we know which projects should be packaged and which should not?
So far our TeamCity's build step Pack NuGet just contained **.nuspec for Specification files: field. The very fact of nuspec file presence served like a flag pack & publish this project.
However, for dotnet pack we need to specify the project. There is no simple way to distinguish 'main' projects from 'auxiliary' ones on which mains depend. (Let us ignore that project-to-project references are currently not supported.)
We either could pack all projects specifying **.*proj (yet in that case we are to know which packages to publish) or we might specify projects explicitly in a build configuration, but I don't like this approach because you must edit build configuration each time new project is added to the solution.
I also considered the option Generate package on build and omit dot net pack step as package is created on build. The only thing left is publishing the packages with dotnet nuget push specifying **/%BuildConfiguration%/*.nupkg.
Unfortunately when starting build against solution without projects with enabled Generate package on build makes TC fail complaining that
Target files not found for pattern "**/Release/*.nupkg"
Hence, I either need another recipe for achieving the required result or an advice how to make TC consider empty result just as a NOP and mark build as successful.
Yet another option is to use nuspec even for new csproj...
Since TeamCity 2017.2 will be available option to associate build configuration with multiple templates. So you will be able to create different templates to create packages for old projects and new .NET CLI projects.
To specify paths for target .NET projects, which should be packaged, you could use build configuration parameters.
To set such parameters during the build you could send in the preceding build step service message. The value of this parameter could be set to the list of target project files which could be selected via script like that: https://stackoverflow.com/a/8153857/305875
I am new to alfresco-sdk. I am used to have old style AMP modules and then run ant script to combine them into alfresco WAR file.
I have followed tutorials of alfresco-sdk for
alfresco all in one
alfresco AMP
alfresco share
archetypes and it ran successfully.
I could not figure out if I have three different AMP modules, how can I combine them in one?
Say for example, currently I following AMP modules in my repo -
alfresco-DEF-AMP
alfresco-generic-AMP
alresco-ABC-AMP
What should I do such that when I give amp-to-war command, it takes customization from above three modules and puts then into alfresco WAR.
I think you should stick with using a seperate archetype alfresco (AKA repository) AMP for each of your existing modules.
By Running the alfresco SDK maven build with target mvn package on each module, will create an amp file for you. These amps can then be deployed to your alfresco instance (with apply_amps.bat), just like you probably are used to, with ant builds.
You don t have to execute the maven build via run.bat file, which starts alfresco with your module in an embedded container.
If you really want to combine them into one, I suppose you ll have to merge your code of the 3 modules into one module of type alfresco AMP, and still work the above way.
We can use alfresco All-in-one archetype for that.
We can use overlays to include our custom modules such as
alfresco-DEF-AMP
alfresco-generic-AMP
alresco-ABC-AMP
to generate single WAR file (alfresco/repo.war)
Below link is very useful
http://docs.alfresco.com/sdk2.1/concepts/alfresco-sdk-advanced-add-custom-amps.html
I'm making first steps with an SBT plugin.
object WoahPlugin extends Plugin {
override lazy val settings = commands += thingCommand
lazy val thingCommand = Command.command("thing") {state: State =>
println("this is the thing~!")
state
}
}
After defining a command, I want to try it out. Do I need to build the plugin and define a new project that uses it in order to try it out? Or can I open an SBT session in the plugin's project and import it directly?
tl;dr You can't have a plugin project and be able to test it out without another project that uses it.
A plugin enhances a build definition of a project so you set up a plugin that expands the project with capabilities you want - additional settings and tasks. See Plugins in the official documentation of sbt.
You set up plugins in meta-project under project directory, by convention usually in project/plugins.sbt (but any project/*.sbt file would do).
If you need to test a plugin you've got two notable choices that all boil down to having a separate project for the plugin and another to use it - the choice is about the place where the test project is as compared to the plugin project under test.
Plugin project in project metaproject
You can have the sources of the plugin under project/src/main/scala so they belong to their own project, but because of the directory they live in project, they automatically become part of the metaproject for another project one level up.
With the plugin's sources inside the meta-project project you can define a plugin dependency in project/plugins.sbt and have the plugin installed (given the recent changes to sbt since 0.13.5 it doesn't necessarily mean the plugin's enabled).
Plugin project anywhere
The plugin project is a sbt project and as such can be referenced from another sbt project using ProjectRef. If it's a git:// or file:// project, you declare the dependency on the plugin project using dependsOn and the project reference with ProjectRef.
See Can multi-projects from GIT be used as SBT dependencies? and How can sbt pull dependency artifacts from git?.
If you have a project that builds one project before building the next, but the next needs to know the 'path' of the first build, is it possible to get this?
For example:
Project A has Build Configuration A and Build Configuration B.
Build Configuration B has a dependency on Build Configuration A. From without the Build Configuration B it will need access to the path of Build Configuration A. Is there are a way to obtain this?
Most simple approach would be to define a custom checkout directory in the A and use the same hard-coded value in B.
If you use TeamCity snapshot or artifact dependencies, you can use %dep.btXXX.teamcity.build.checkoutDir% to get checkout directory of the dependency build. However, this will not work in 6.5.0-6.5.5 TeamCity versions, see details and workaround in the issue TW-18715.
However, you should really avoid accessing checkout directory of one build from another. If you need sources of A, you can checkout them in B; if you output of the A's build, then publishing the output as build's artifacts and then using TeamCity artifact dependencies is the way to go. In both cases additionally using TeamCity snapshot dependencies will ensure both builds use the same sources snapshot which is probably what you need.
If you have one agent, and only ever one agent then you could try and use the path from a previous build.
I wouldn't recommend doing this however because if you had two agents, or scaled up in the future to two agents, then it is possible your projects will be built on different agents; this would mean your dependency working directory won't be on the same machine, or it will be outdated as the latest was built elsewhere.
I assume you're after the path of the first build to get its output?
If so, the method we use to share dependencies between projects is to checkin the output from each project into our source control, then every project that requires the output simply has to check them out.