I have designed a maven plugin which has two goals.However, I want to attach one of it as a preGoal to another i.e; everytime the second goal runs it should be preceeded by the first one automatically.Can anyone tell how to do it?
Referring the maven documentation under A Build Phase is Made Up of Plugin Goals
Note: In Maven 2.0.5 and above, multiple goals bound to a phase are
executed in the same order as they are declared in the POM, however
multiple instances of the same plugin are not supported. Multiple
instances of the same plugin are grouped to execute together and
ordered in Maven 2.0.11 and above
So, if you put Goal-A before Goal-B in your POM and bind these to the same phase of life-cycle. Then Goal-B would always be preceded by Goal-A.
Related
Is there a way we can add build with parameter option in jenkins for github organization project??
Appreciate for your answeres.
First, if you're using the GitHub Organization - It is deprecated and hasn't been updated in 2 years.
https://plugins.jenkins.io/github-organization-folder
So you might want to consider using the Multi Branch Pipeline (MBP) in conjunction with Job DSL instead.
Next - the idea is that the MBP is dynamically creating branch 'jobs' when it scans the repo you provide. I'm not sure that you can't put a parameter block in the pipeline you create, but if you did and it worked, I wonder if the job can be automatically triggered.
https://jenkins.io/doc/book/pipeline/syntax/#parameters
I have a flink job and it expects another dependency jar to be available at run time. Is it possible to submit a job with multiple jars in flink cluster. I can not build one common jar.
You could install the dependency jar on every flink node in the flink/lib folder as described here. That would make it available to user uploaded jars without the need for your users to bundle it with their jars.
Keep in mind that this would be handled entirely outside of the job submission API, so you would have to incorporate it into whatever system you're using to manage configuration on your flink nodes.
Given the case that you have a basic GUI that must be extensible by plugins not known when the generate run of the main GUI is done. Contributable plugins may consist of some manifest, resources, localization, some code that is executable in the GUI environment and can provide custom widgets.
From what I see in the moment, it could be done by
Let a plugin developer build against the ordinary source, generating a part for the plugin. Then manually register a qx.io.part.Part with the generated parts to the GUI running on the non developer side.
Just load a combined source JS for that plugin, containing the resources and load them manually via eval.
I'd personally prefere the first one, as it already includes everything that might be used by a plugin. But it uses a method that is marked as internal.
Are there any experiences with that? Are there other, more elegant ways to achieve that?
How can I get the current akka version in Play Framework 2.4.1? I've searched on all configuration files and I don't see any akka dependecy (although I can use akka in Play).
Within activator, use show compile:dependencyClasspath and you'll get a list of all jars used at compile time.
It's ugly and unformatted, but it works.
If you want to have something more structured, you can install sbt-dependency-graph to get more control.
Shut down activator
Add the following to ~/.sbt/0.13/plugins/plugins.sbt
addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.7.5")
Add the following to ~/.sbt/0.13/global.sbt
net.virtualvoid.sbt.graph.Plugin.graphSettings
You'll then have a bunch of different dependency-related tasks available in sbt/activator, such as dependency-graph.
I'm using TeamCity 6.5.4 and I need to have 3 build configurations for the same deployment package. I'd like to persist the version number across all three build configurations and be able to use that number to version the assembly, tag vcs, version the nuspec file, etc.
Here are the configurations and desired version numbers:
Configuration | Version
-------------------|---------
CI/Nightly Build | 1.1.*
Minor Release | 1.*.0
Major Release | *.0.0
It seems that TeamCity uses a separate build incrementer for each configuration. This means every time we have a major or minor release, I'd have to manually update the persisted values (1) in all of the subsequent configurations. I'm a programmer and I'm lazy. I want a single button to do everything for me.
I've seen examples of persisting the build number through build steps of a configuration with dependent snapshots, but that only works in the same configuration.
The Autoincrementer plugin bumps up the number every time you reference the ID. This is fine for the changing numbers (*), but not so good for referencing the persisted values (1).
Is there a way for TeamCity, either natively or via plugin, to allow me to read and write that version to a file or variable that can be persisted across build configurations?
You can reference the build number of the dependent ( artifact / snapshot) configuration using dep.btx.build.number where btx is the bt id of the latter. Once you have the build number, pass the build number to your script running in the configuration, parse the build number in the script and send service messages from the script to Teamcity to set the build number in the way you want. Do this parsing and setting number as the first step in your script / first step in the build steps.
Thanks for the suggestions. I opted to write a set of custom targets to use with my MSBuild script which maintains assembly metadata in a remote xml "manifest" file. When a new TeamCity project is created, my build script calls an Init target which creates a new manifest file from an unpopulated template.
<Copy SourceFiles="#(ManifestTemplate)" DestinationFiles="#(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" />
I'm using the MSBuild Extentions pack to read attributes like version information from the manifest file.
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="ReadElementText" File="$(ManifestFile)" XPath="/Package/Version/Major">
<Output PropertyName="PackageVersionMajor" TaskParameter="Value"/>
</MSBuild.ExtensionPack.Xml.XmlFile>
I have my TeamCity build configurations separated to CI, Test, Minor Release, and Major Release with different events triggering each. From the corresponding target in my project build script, I add a new target to DependsOnTargets attribute to call the custom target to update the appropriate version number and save it to the manifest file.
<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build">
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" />
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" />
The code in the custom target to handle the version update:
<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1">
<Output PropertyName="PackageVersionBuild" TaskParameter="Result"/>
</MSBuild.ExtensionPack.Science.Maths>
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/>
This file handles persistence of the version and other metadata thus ignoring the TeamCity build number. Since the XML metadata file is centralized, I can use the values to populate my Nuspec, AssemblyInfo, and WiX Installer metadata as well as pass the version and other pertinent information back to TeamCity through service messages.
I added a simple MVC web interface to allow my team to edit the file contents remotely if package details change. Now we have one single place to update things like Copyright information and any other metadata for a given build project. I can also give non-dev folks access to the MVC site to update branding information without allowing them access to my TeamCity build configurations.
With the exception of the service messages used to relay version to TeamCity, there's very little here that's coupled with TeamCity. I like having the functionality in custom targets and build scripts removed from TeamCity on the off chance we move to another build management solution. For that reason, I don't envision taking time to build a TeamCity plugin, but there could be a blog series coming soon.
I'll be happy to provide more code and further explanation to anyone interested.
Yes, you can create a plugin to do this easy. You can take my auto increment build number ( across configurations ) plugin and modify it to fit your need. The build number will be saved in a text file that is configurable from the admin screen in TeamCity.
http://github.com/ornatwork/tc_plugins/tree/master/unique
You can hit me up for input how to change it if you need.