I've been tyring to set up my csproj to generate the swagger json file as part of the build.
<Target Name="SwaggerPostBuildTarget" AfterTargets="Build" Condition="Exists('$(SolutionDir)')" Outputs="$(SolutionDir)Company.Project.Swaggergen/Api.json">
<Message Importance="High" Text="Running swagger tofile (RID is $(RuntimeIdentifier))..." />
<Exec Command="dotnet tool restore"></Exec>
<Exec Command="dotnet tool run swagger tofile --output $(SolutionDir)Company.Project.Swaggergen/Api.json $(ProjectDir)$(OutputPath)$(AssemblyName).dll api"></Exec>
</Target>
However, the json file produced is substantially different to the one on the web page at /swagger. The property names have been changed and many of the controllers are missing.
The initial letters of the property names have been downcased which means that the TypeScript client can't deserialise the HTTP responses into the model classes.
Missing controllers (added using a FeatureProvider) is obviously very stupid.
Can the proper json file be generated as part of the build?
Related
I need to retrieve all the properties' names from a properties file before loading it (using Ant)
I'll go into detail to explain the whole process:
A first properties file (let's name it as a.properties) is read and
all its properties loaded as project's properties.
#a.properties's contents
myvar1=1
myvar2=someTextHere
A second file (let's say b.properties) has to be loaded on the
project. Some already-set properties can also be contained in this
second file, so what we have to do is to update such variables with
the value found on it (by means of the ant-contrib's var target)
#b.properties's contents
myvar1=2 #updated value for a property that's is already set on the project
myvar3=1,2,3,4,5,6
So the expected subset (from a ANT project's properties perspective)
of property/value pairs would be:
myvar1=2
myvar2=someTextHere
myvar3=1,2,3,4,5,6
We cannot change the order in which those files are loaded on the project, which would be the easiest way of solving the issue (because of the behavior adopted by Ant when setting's properties)
Any feedback will be highly appreciated.
Regards
I assume that you need to read properties from different files before you build your source code
<target name=-init-const-properties description="read all properties required">
<propertyfile file="AbsolutePathToPropertyFile" comment="Write meaningfull
about the properties">
<entry value="${myvar1}" key="VAR1"/>
<entry value="${myvar2}" key="VAR2"/>
</propertyfile>
</target>
Note: you need to add proper AbsolutePathToPropertyFileand comment if required
In the target -init-const-properties you can add as many files you want to read and use this target as dependent target in which you going to use these property values. hope this will answer your question
I recommend having a standard file for build defaults called "build.properties". If you need to override any settings, then create an optional file called "build-local.properties".
My advice is to keep build logic simple. Using the ant-contrib extension to make properties act like variables is rarely needed in my experience.
Example
├── build-local.properties
├── build.properties
└── build.xml
Running the project produces the following output, where the value "two" is substituted:
$ ant
build:
[echo] Testing one, dos, three
Delete the optional file and it goes back to default values:
$ rm build-local.properties
$ ant
build:
[echo] Testing one, two, three
build.xml
The secret is the order in which the property files are loaded. If they don't exist then they don't create properties.
<project name="demo" default="build">
<property file="build-local.properties"/>
<property file="build.properties"/>
<target name="build">
<echo message="hello ${myvar1}, ${myvar2}, ${myvar3}"/>
</target>
</project>
build.properties
myvar1=one
myvar2=two
myvar3=three
build-local.properties
myvar2=dos
Finally, the approach I followed was to specify the second properties file (b.properties) from the command line:
ant <my_target> -propertyfile b.properties
So that's work fine to me...
Thanks all of you for your help.
I am on the verge of pulling all my hair out, someone please help me..
I am using JMeter 3.0 and am trying to generate the dashboard report from my jtl files, but I get the error -
result.jtl' does not contain the field names header, ensure the jmeter.save.saveservice.* properties are the same as when the CSV file was created or the file may be read incorrectly
my user.properites file contains -
jmeter.save.saveservice.output_format=csv
jmeter.save.saveservice.bytes=true
jmeter.save.saveservice.label=true
jmeter.save.saveservice.latency=true
jmeter.save.saveservice.response_code=true
jmeter.save.saveservice.response_message=true
jmeter.save.saveservice.successful=true
jmeter.save.saveservice.thread_counts=true
jmeter.save.saveservice.thread_name=true
jmeter.save.saveservice.time=true
jmeter.save.saveservice.timestamp_format=ms
jmeter.save.saveservice.timestamp_format=yyyy-MM-dd HH:mm:ss
jmeter.save.saveservice.print_field_names=true
these values are the same in the jmeter.properties file as well, just to ensure I haven't lost anything...
I really can't work out why I can't get the jtl to include the headers, I have followed every guide I can find, and I seem to be doing it right..
Can someone point to me what I am missing, or include a zipped version of their jmeter with it all working that I can try and point my ant project to?
Hope someone can help.
Double check <jmeter> section of your build.xml file. Default JMeter Ant Task assumes XML out put format for .jtl result files so if you have the following line:
<property name="jmeter.save.saveservice.output_format" value="xml"/>
just comment it out or delete it and your issue should be resolved.
I don't think JMeter Ant Task respects overrides via user.properties file, it is better to use jmeterproperties attribute or explicitly specify the relevant configuration in the Ant build file like:
<target name="test">
<jmeter
jmeterhome="${jmeter.home}"
testplan ="${testpath}/${test}.jmx"
resultlog="${testpath}/${test}.jtl">
<property name="jmeter.save.saveservice.output_format" value="csv"/>
<property name="jmeter.save.saveservice.print_field_names" value="true"/>
<property name="jmeter.save.saveservice.timestamp_format" value="ms"/>
<!--etc.-->
</jmeter>
</target>
I would also recommend choosing one of jmeter.save.saveservice.timestamp_format properties (either ms or yyyy-MM-dd HH:mm:ss as it might cause problems with the dashboard generation), having duplicate property names with different values is not a very good practice.
See Five Ways To Launch a JMeter Test without Using the JMeter GUI article for more information on running JMeter tests via Ant task and other ways of kicking off a JMeter test
I had noticed before you posted, but it is correct, the XML type was hardcoded in the build.xml, now I have changed that, all is working :)
I want to use an condition property to set the property value to X if another property is defined and Y otherwise. However, I don't want the user to be able to override the condition property from the command line.
How can this be achieved?
Starting from ant 1.8 for some use cases local task may be applicable. Since a property is made local it starts with an empty value. It's scope is limited to current target, but you may pass it to subsequent targets using param argument in antcall.
Nope, you can't override a property set on the command line. At least, it's not easy to do. The whole purpose of overriding properties on the command line is to allow users to override defaults in order to make modification in the way your project builds. For example:
<property file="${basedir}/build.properties"/>
<property name="javac.debug" value="no"/>
<target name="compile">
<javac destdir="${main.destdir}"
debug="${javac.debug}">
By default, the Java code is compiled without debugging information. Maybe this is done to make jar files smaller, or faster interpretation, or maybe to make the code harder to decompile and read. Whatever reason, this build won't put debug information into the classfiles.
However, developers do want this debugging information, so they want to be able to override this setting:
$ ant -Djavac.debug=true compile
Or, they can create a build.properties file and put the value in there.
This type of issue comes up when you're not using Ant for builds. I know several sites that use Ant scripts to do deployments. I usually discourage this because Ant isn't really made for this type of thing. For example, Ant doesn't have any built in logic or loops. Once a property is set, it can't be changed. These are good ideas for a build language, but a terrible idea for a general purpose programming language.
Also, developers shouldn't be doing builds for QA or production. Those should be done by a build server that won't override defaults.
Now how to destroy this whole well thought out system and cause absolute havoc:
You can use the ant-contrib tasks in your project. Doing this will allow you to access the Ant Contrib var task to unset properties.
Download the ant-contrib.jar file (whatever the latest version is), and put it in a lib directory under your project. Then you can do this:
<project name="danger-will-robinson" default="package" basedir="."
xmlns:ac="http://ant-contrib.sourceforge.net">
<!-- Define the Ant-Contrib tasks -->
<taskdef=resource="net/sf/antcontrib/antlib.xml"
uri="http://ant-contrib.sourceforge.net">
<classpath>
<fileset dir="${basedir}/lib">
<include name="ant-contrib*.jar"/>
</fileset>
</classpath>
</taskdef>
<!-- Unset Property "foo", so you can use it -->
<ac:var name="foo" unset="true"/>
Note that the <classpath> points to the ant-contrib jar in the ${basedir}/lib directory. If you check that into your source repository, it will allow everyone who checks out your project to be able to do the build without installing the ant-contrib jar on their system.
Note that I've defined a "ac" XML namespace, so Ant-Contrib tasks won't overlap other possible third party tasks.
Properties in ant once set are immutable by design. You may overwrite an existing property with any scripting language that provides access to ant api, i.e. javascript.
JDK >= 1.6 already ships with a javascript engine, so you may use something like :
<project>
<property name="x" value="whatever"/>
<script language="javascript">
project.getProperty('x') ?
project.setProperty('foo', 'true') :
project.setProperty('foo', 'false');
</script>
<echo>$$[foo} => ${foo}</echo>
</project>
out of the box.But that won't help if someone uses ant -f yourbuild.xml -Dfoo=bla !! as userproperties (those properties defined via -Dkey=value) have a special protection.
So your requirement "..However, I don't want the user to be able to override the condition property from the command line". is not fullfilled.
But the let task from Ant addon Flaka provides the possibillity to overwrite even userproperties :
<project xmlns:fl="antlib:it.haefelinger.flaka">
<property name="x" value="whatever"/>
<!--
:= defines a new property whereas
::= overwrites any existing property
even userproperties
-->
<fl:let> foo ::= has.property['x'] ? 'true' : 'false'</fl:let>
<echo>$$[foo} => ${foo}</echo>
</project>
Run both scripts with ant -f yourbuild.xml -Dfoo=bla to see the difference.
Ant api has also method project.setUserProperty(String,String) so you may use also:
...
<script language="javascript">
project.getProperty('x') ?
project.setProperty('foo', 'true') :
project.setProperty('foo', 'false');
project.getUserProperty('x') ?
project.setUserProperty('foo', 'true') :
project.setUserProperty('foo', 'false');
</script>
...
to prevent the foo property to be set via .. -D .. and it will work even if property x is defined on commandline -Dx=whatever You have to make your choice, script task with javascript out of the box or Flaka let task
oneline solution but Flaka jar needed.
I'm currently looking to run static analysis over a pre-existing project. As the project is created and supplied by an off-site company, I cannot change the build process radically.
The project is split into a lot of sub-modules, located in various places. For other analyisi tools (JDepend, Google Testability Explorer, etc.), I have dynamically detected all build JAR files into a path element as follows:
<path id="built-libs">
<fileset dir="${overall-base}">
<include name="${some-common-base}/**/lib/*.jar" />
</fileset>
</path>
<property name="built-libs-string" refid="built-libs" />
For some tools, I use the build-libs, for others I use the string (in classpath form; x.jar;y.jar).
The trouble is, FindBugs uses a completely different format to any other;
<class location="x.jar"/>
<class location="y.jar"/>
...
Now, I could list all the JAR files manually, but then run the risk of this list going out of synch with the other tool's lists, or of introducing typos.
Another complication is that I also want to run the reports in Jenkins, in this case the extract directory for individual modules will depend on the job that has previously built the module (pipeline builds, modules extracted from SCM and built in parallel, the reporting occurring at the end of the pipline).
I could make a call out to the OS to run FindBugs, passing in the JARs in a space separated list (as in Invoking FindBugs from Ant: passing a space-separated list of files to java). However, I prefer a, Ant solution to an OS <exec... hack.
Note I know I have a similar problem for the sourcepath element, however, I'm assuming that solving the class element problem also solves the sourcepath one.
Ideally, FindBugs should be taking a resource collection rather than separate class elements. I'm not familiar with FindBugs, so I can't comment on why they have chose to go the class element route instead of a resource collection, however your comment about using exec implies that using a resource collection is a valid design alternative.
I would try rolling your own Ant macro, which invokes FindBugs directly using the java task. This should give you the control you need and avoiding the redundancy that the FindBugs Ant task would introduce.
Another option (which is an ugly hack) is to use the fileset to write a mini ant file with a FindBugs target, which you then invoke using the ant task. shudders
The Findbugs Ant task allows you to specify a filelist which can be used to specify multiple files. Quoting from the Findbugs documentation
"In addition to or instead of specifying a class element, the FindBugs
task can contain one or more fileset element(s) that specify files to
be analyzed. For example, you might use a fileset to specify that all
of the jar files in a directory should be analyzed."
Example that includes all jars at ${lib.dir}:
<findbugs home="${findbugs.home}" output="xml" outputFile="findbugs.xml" >
<auxClasspath path="${basedir}/lib/Regex.jar" />
<sourcePath path="${basedir}/src/java" />
<fileset dir="${lib.dir}">
<include name="*.jar"/>
</fileset>
</findbugs>
I am coming up on the end stages of an Asp.Net MVC 1.0 project in VS2008 / Framework 3.5, and trying to do some performance optimizations. In my project, I have a few different "themes" that are used, depending on the role of the logged in user. My themes folder structure is like so...
\Themes
\Theme1
\Css
\Folder1
\CssFile1.css
\CssFile2.css
\Folder2
\CssFile1.css
\CssFile2.css
\Images
<Images go here>
\Theme2
\Css
\Folder1
\CssFile1.css
\CssFile2.css
\Folder2
\CssFile1.css
\CssFile2.css
\Images
<Images go here>
As new customers come on board, new themes will be added to this folder structure.
I am using the Yahoo! UI Library: YUI Compressor for .Net
(which is really cool) to minify and merge my css (and js) files.
I followed the example at http://yuicompressor.codeplex.com/wikipage?title=Sample%20MSBuild.xml%20File&ProjectName=yuicompressor to run an MSBuild script via a post-build event to do the minify/merge tasks.
Everything works great, except that when I use something like <CssFiles Include="..\Themes\**\*.css" /> in my ItemGroup to specify where to get the css files, all css files from every theme are merged into one file, like this...
\Themes
\SylesSheetFinal.css
What I want instead is to merge only the css under the themes, creating one css file for each...
\Themes
\Theme1
\StyleSheetFinal1.css
\Theme2
\StyleSheetFinal2.css
I am really new to MSBuild. Does anyone know how I can modify the sample to automatically walk over each of the theme folders and create a minified/merged stylesheet for each? The themes can be added or removed quite often, so I don't want to have to manually include each theme path to my ItemGroup. Instead, I want the MSBuild script to walk the subfolders underneath the Themes root automatically, regardless of the number of folders.
Thanks!
What you are trying to do can be accomplished with batching. Batching is the process of executing a specific task (or target) once for each unique batch. There are two types of batching; Task Batching and Target Batching. Task batching is the most common and what I think you need, based on the info provided here. Batching can be kind of confusing, but it is not too bad once you get a grasp on it.
Batching always involves the %() operator. Here is an example of Task Batching.
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Batching01.proj -->
<ItemGroup>
<Files Include="src\Src01.cs"/>
<Files Include="src\Src02.cs"/>
<Files Include="src\Src03.cs"/>
<Files Include="src\Src04.cs"/>
</ItemGroup>
<Target Name="Demo">
<!-- Not batched, i.e. Files is flattened and sent to the Message task -->
<Message Text="Files: #(Files)"/>
<Message Text="================" Importance="high" />
<Message Text="Filename: %(Files.Filename)" Importance="high" />
</Target>
</Project>
The output would be:
Files: src\Src01.cs;src\Src02.cs;src\Src03.cs;src\Src04.cs
================
Filename: Src01
Filename: Src02
Filename: Src03
Filename: Src04
It is too tough to fully describe batching in this post, but I've put together some really great resources available online at http://sedotech.com/Resources#Batching.