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.
Related
Background
I'm using Handlebars templates in JavaScript that's part of a SpringMVC 3.x web application.
Project builds are done using ant.
Neither Node.js nor Ruby are available on the Linux server.
Problem
I want to precompile Handlebars templates into JavaScript as part of the build process.
That is, I don't want to precompile the templates locally and then have to check generated code into source control.
Without Node.js or Ruby, the server doesn't support the Handlebars npm package nor the Ruby gem, so I can't go the straight-forward route.
Attempts at resolution
Gems-in-a-jar worked well for Compass, but the Handlebars gem relies on native extensions and JRuby doesn't play nice with native extensions and wouldn't build them. I tried a couple of proposed solutions, but had no luck.
Other notes
I looked at Handlebars.java but that seems to be geared more toward using Handlebars templates application-wide, which feels like overkill for my purposes.
I'm looking for a light-weight solution that doesn't create a lot of dependencies and would like to avoid potential maintenance headaches as much as possible.
I put together a solution based on a blog post about precompiling Handlebars with Rhino. It consists of:
A bit of JavaScript that precompiles the Handlebars templates.
An ant task using Rhino to execute the JavaScript.
The original JavaScript expects all templates to be in the same directory and concatenates all the generated JavaScript into a single file. I have templates across multiple directories and wanted to precompile each of them into an individual file, so my JavaScript is a little different, as is the ant task:
<target name="handlebars">
<apply executable="java" dest="${javascript.dir}">
<arg value="-jar"/>
<arg path="${lib-ext.dir}/rhino.jar"/>
<arg value="${lib-ext.dir}/rhino-handlebars-precompiler.js"/>
<arg value="--handlebars"/>
<arg value="${javascript.dir}/handlebars/handlebars.js"/>
<arg value="--template"/>
<srcfile/>
<arg value="--output"/>
<targetfile/>
<fileset id="fileset" dir="${javascript.dir}">
<include name="**/*.tmpl" />
</fileset>
<mapper type="glob" from="*.tmpl" to="*.tmpl.js"/>
</apply>
</target>
I've just come across this problem myself (minus the ANT integration), and solved it using Phantom JS (which as a small standalone executable can easily be checked in with your code and executed from whatever build script you choose) and a small javascript runner - see this gist.
This will take a source HTML file containing one or more handlebars templates or partials wrapped in tags with an arbitrary class name to identify which scripts to pick up, e.g.:
<script type="text/x-handlebars-template" class="hbTemplate" id="MyFabulousTemplate">
<p>This template is FABULOUS - hello {{username}}!!!</p>
</script>
From the command line, it would be executed with something like:
phantomjs hbcompiler.js filewithtemplatesin.html hbTemplate hbPartial MyTemplates
Which would pre-compile all the templates in the source HTML and output them to stdout as something like:
if (MyTemplates === undefined) var MyTemplates = {};
if (MyTemplates.pcTemplates === undefined) MyTemplates.pcTemplates = {};
if (MyTemplates.pcPartials === undefined) MyTemplates.pcPartials = {};
MyTemplates.pcTemplates["MyFabulousTemplate"] = (pre-compiled-template-definition)
MyTemplates.pcTemplates["MySecondTemplate"] = (pre-compiled-template-definition)
...
Which you can then use in your JS with something like:
var template = Handlebars.template(MyTemplates.pcTemplates["MyFabulousTemplate"]);
// Then for e.g. execute the template and put the resulting output in the element with
// ID "target":
$("#target").html(template({ username: "CheeseMonger" }));
It's all a bit hacked together but it works for my use-case. As it stands, it needs jquery and (of course) the handlebars library in known locations (see lines 50-51 of the gist for the paths it's looking for them on), but that could easily be factored out to more parameters or whatever. You could easily re-write it to remove the need for jquery, I'm just lazy!
I have a projects in JAVA that I analyze using sonar. Some of the java packages that I have are all under source folder. I also have some test file that I have under a different folders. Now, in Sonar, I organize my projects under a different structure, i.e. for a project "search", I only wants to include "search" package. These exclusion is quite easy to accomplished using sonar.exclusion properties. My question, though, is how about the test? how can I exclude some of the packages? Because from my testing, even though my source and test folder are using the same structure, the test packages are not automatically excluded when I specified "sonar.exclusions".
my folder structure:
/src/com/domain/
-- search/
-- utils/
-- pooling/
-- category/
/test/src/com/domain/
-- utils/
-- pooling/
Sonar properties:
<property name="sonar.sources" value="${path}/src" />
<property name="sonar.tests" value="${path}/test/src" />
<property name="sonar.exclusions" value="com/domain/utils/**/*,com/domain/pooling/**/*,com/domain/category/**/*" />
So, I am trying to only include the "search" package. The code above works in a way that it causes SONAR to only analyze my "search" package. This package can be seen in the SONAR "Components" tab. Unfortunately, in addition to the "search" component, I can also see the "util" and "pooling" components. I have done some testing and certain that these two components (utils and pooling) are the result of "sonar.tests" properties. Just a note though, even though "util" and "pooling" shows up in components, SONAR shows zero files under both of them. So going back to my question, is there anyway that I can do to exclude "util" and "pooling" from showing up under "Components"? Maybe using properties (i.e. sonar test exclusions)?
Btw, I am using SONAR 2.11 and is running under Red Hat linux. I'm using SONAR-TASK 1.2.
Any help is welcomed and appreciated! Thanks!
You can define exclusions in the Configurations for the project directly in sonar.
From the documentation:
Since version 3.3, it is also possible to:
Exclude tests file from being analyzed:
go to Configuration > Settings > Exclusions and set > the sonar.test.exclusions property
The trick is:
sonar.exclusions: excludes files from sources directory (i.e.sonar.sources), it has no effect on tests directory.
sonar.test.exclusions: excludes files from tests directory (i.e.sonar.tests), it has no effect on sources directory.
See https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus
And, Using sonar.test.exclusions with Sonarqube 6.3
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'm trying to build my flex 4 project using ant. In Flash Builder 4, in project properties it's possible to set the "Framework linkage" to one of "Merged into code", "Runtime Shared Library (RSL)" or "Use SDK Default (Runtime Shared library)". How can I set the equivalent as mxmlc options in build.xml?
My current build.xml looks like this:
<target name="myapp">
<mxmlc
file="${PROJECT_ROOT}/myapp.mxml"
output="${DEPLOY_DIR}/myapp.swf"
actionscript-file-encoding="UTF-8"
keep-generated-actionscript="false"
warnings="false" optimize="true" incremental="false" >
<load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
<source-path path-element="${FLEX_FRAMEWORKS}"/>
<compiler.debug>true</compiler.debug>
<runtime-shared-library-path path-element="${FLEX_FRAMEWORKS}/libs/framework.swc">
<url rsl-url="framework_4.0.0.14159.swz"/>
<url rsl-url="framework_4.0.0.14159.swf"/>
</runtime-shared-library-path>
<compiler.source-path path-element="src"/>
<!-- List of external libraries -->
<compiler.source-path path-element="${MY_LIB}/src" />
<!-- List of SWC files or directories that contain SWC files. -->
<compiler.library-path dir="libs" append="true">
<include name="*.swc" />
</compiler.library-path>
<copy todir="${DEPLOY_DIR}" file="${FLEX_FRAMEWORKS}/rsls/framework_4.0.0.14159.swz"/>
<copy todir="${DEPLOY_DIR}" file="${FLEX_FRAMEWORKS}/rsls/framework_4.0.0.14159.swf"/>
</mxmlc>
</target>
I assumed that setting the runtime-shared-library-path directive and copying the framework swf, swz files into my target folder would make things work, but this does not seem to be the case.
The way I'm assessing whether this works is as follows: I use a custom preloader, and for it to work I need to have framework linkage as RSL. With "merged into code", my preloader gets stuck at a certain point and does not progress to my application swf. This is the same behavior i see when i use the above build.xml, which makes me think that the SWF is being built with framework linkage merged into code (rather than RSL linked).
A related question to this is how to determine if my swf is using RSL or not. I guess I could look at the size of the compiled output. But it seems there should be a way to tell if I'm using the external framework file or it's being bundled into the SWF somehow, without my knowledge.
This is a little tricky because the documentation is a little scarce on this. You probably need to set the following option either on the command line or a config file.
static-link-runtime-shared-libraries=false
The documentation from Adobe gives the following slightly cryptic description of what this option does.
Determines whether to compile against libraries statically or use RSLs. Set this option to true to ignore the RSLs specified by the runtime-shared-library-path option. Set this option to false to use the RSLs. The default value is true.
This option is useful so that you can quickly switch between a statically and dynamically linked application without having to change the runtime-shared-library-path option, which can be verbose, or edit the configuration files.
Here is a link to the documentation.
"About the application compiler options"
Note that from the documentation the default value is true. HOWEVER if you are loading a flex-config.xml file (default or custom) you should also check if this setting is present in that file and what it is. In my experience the default value for the frameworks/flex-config.xml is actually false. It appears however that in the example above that this may be set the other way.
(We use a different build system than ANT so I am not that familiar with the build.xml syntax you would need.)
I'm trying to use xmltask for ant to modify a file in a subdirectory:
project/path/to/file.xml
The file refers to a DTD like this:
<!DOCTYPE data SYSTEM "mydtd.dtd">
I don't have the flexibility to change these documents.
This DTD is stored in the same subdirectory, which has always worked fine:
project/path/to/mydtd.dtd
Unfortunately, xmltask is trying to locate the dtd in my project's top-level directory, which is where my build file is located, and where I run from:
[xmltask] java.io.FileNotFoundException: /home/me/project/mydtd.dtd (The system cannot find the file specified)
I see in the xmltask documentation that I can correct this with an xmlcatalog element to tell it where to look up the file. But I need to use a dtd element, and I can only find examples for this element, not documentation; the examples show only a publicId, and if I understand XML correctly this document does not have one. I shouldn't need to specify this, anyway, right, since my document already says my DTD is stored locally and shows right where it is?
Why isn't xmltask finding the DTD correctly? What's the best way to correct or work around this situation?
An XML Catalog is the way to go here, it just needs a bit more perseverance.
As you correctly pointed out, the standard Ant <XmlCatalog> type only allows you to specify public DTD references when using the inline syntax, which is of no use to you. However, <XmlCatalog> also lets you specify a standard OASIS-syntax catalog, which is far richer, including resolving SYSTEM DTD references.
An OASIS catalog (full spec here) looks like this:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="mydtd.dtd" uri="project/path/to/mydtd.dtd"/>
</catalog>
You can then reference this catalog from the <XmlCatalog>:
<xmlcatalog refid="commonDTDs"/>
<catalogpath>
<pathelement location="path/to/oasis.catalog"/>
</catalogpath>
</xmlcatalog>
And that's that. It's a good idea to build up a reusable OASIS catalog file, and refer to it from various XML-related Ant tasks, all of which can use <XmlCatalog>.
As an alternative, it looks like I can skip the whole validation by creating a blank file with the same name as the DVD file, and then deleting the file when I am done. Odds are I am going to go that route instead of using the catalog.
xmltask isn't finding it because it is looking in the current working directory. Ant allows you to specify a base directory using the basedir attribute of the <target> element. So I suggest you try this:
<target basedir="path/to" ...>
<xmltask...
</target>
It strikes me that it is not the XML/DTD that you really have the problem with, but getting xmltask to interact with the two of them as you want.
If that fails, you could use the Ant Copy task to copy the XML and DTD to the root folder before processing with xmltask, then copying back again.
Have you tried:
<!DOCTYPE data SYSTEM "./path/to/mydtd.dtd">
? Or an absolute path?
Also, you can find <dtd> description here.
I had a similar problem where an XML file had a doctype with SYSTEM reference that could not be changed.
<!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd">
I first went down the road and created a catalog file with the OASIS catalog as described above, but to be able to use external catalogs I had to include the Apache Commons Resolver 1.1 (resolver.jar) in the Ant classpath (see http://ant.apache.org/manual/Types/xmlcatalog.html).
Because I had multiple machines on which this build was supposed to run this seemed overkill, especially since xmltask worked fine if I just removed the doctype definition. I wasn't allowed to remove it permanently because the doctype was needed elsewhere.
Ultimately I used this workaround: I commented out the doctype definition using Ant's replace task, ran the xmltask, and then put the doctype back into the file.
<replace file="myxmlfile.xml">
<replacetoken><!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd"></replacetoken>
<replacevalue><!-- !DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd" --></replacevalue>
</replace>
<xmltask .../>
<replace file="${local.opencms.webapp.webinf}/config/opencms-modules.xml">
<replacetoken><!-- !DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd" --></replacetoken>
<replacevalue><!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd"></replacevalue>
</replace>