maybe i'm just not seeing it, but i'd like a way to "inject" the value for branch (externally somehow) for a set of predefined build projects.
we have builds configured for Project1, Project2 and Project3. But at any time, the projects may take from a different branch, based on merge schedules. i'd like to store the Project=>branch mapping in either an external file or database, then dynamically inject it into the config file when we do a ForceBuild.
The following block is used in all 3 project config files, which are referenced at the bottom (end) of the cnet.config file.
<cb:define name="cvs-block">
<sourcecontrol type="cvs">
<cvsroot>:sspi;username=johnDoe;password=passTheSalt;hostname=127.0.0.1;port=1776:/$(repository)</cvsroot>
<module>"$(module)"</module>
<executable>c:\Program Files (x86)\cvsnt\cvs.exe</executable>
<workingDirectory>D:\CruiseBuild\$(workingDir)</workingDirectory>
<branch>[SOME EXTERNALLY DYNAMIC VALUE]</branch>
<autoGetSource>true</autoGetSource>
<timeout units="minutes">20</timeout>
</sourcecontrol>
</cb:define>
<cb:include href="D:\CruiseBuild\ACME-project1.xml" xmlns:cb="urn:ccnet.config.builder" />
<cb:include href="D:\CruiseBuild\ACME-project2.xml" xmlns:cb="urn:ccnet.config.builder" />
<cb:include href="D:\CruiseBuild\ACME-project3.xml" xmlns:cb="urn:ccnet.config.builder" />
Just generate a file (injectpath.config) with a defined value:
<cb:define branchpath="yourpath"/>
...and then include it into your config file shown above at the top.
Change your [SOME DYNAMIC VALUE] to $(branchpath).
Related
I have created my Apache Velocity template under /resources/fileTemplates/internal/myTemplateClass.vm and would like to use it through:
final JavaDirectoryServiceImpl javaDirectoryService = new JavaDirectoryServiceImpl();
javaDirectoryService.createClass(myPsiDirectory,
"MyClassname",
"myTemplateClass");
So I added the following in my plugin.xml:
<extensions defaultExtensionNs="com.intellij">
<!-- Add your extensions here -->
<internalFileTemplate name="myTemplateClass"/>
</extensions>
However when I run my plugin it claims that it did not find a template with the name "myTemplateClass". I assume it is cause I haven't linked to the file perse. Where should I link this?
Thanks
If you have an <internalFileTemplate> with the name of "myTemplateClass" and you want to use it to create a Java class, the template needs to be stored as fileTemplates/internal/myTemplateClass.java.ft. So you need to change the extension of your file.
I'm planning on making my own Code Templates for when I generate my new scripts. Since SuiteCloud IDE is only configured for SuiteScript 1.0, I was hoping to create new templates for SuiteScript 2.0.
That said, I've got to the part where I can specify the directory for my custom templates, and I've gone ahead and created my templates, however, since I'm lacking the templates.xml, SuiteCloud IDE doesn't recognise my custom templates.
NetSuite Help doesn't really help that much except state that that file exists. But it doesn't say what it should contain, or even the structure of the data.
If anyone can help out here, it'd be much appreciated. TIA.
We've done the same exercise long ago for SuiteScript 1.0, and I've just recently done it for our SuiteScript 2.0 set.
You can find the default templates inside of P2_POOL_HOME/plugins/com.netsuite.ide.core_2016.2.0.e4.jar/templates/ where P2_POOL_HOME is usually ~/.p2/pool/
The general format of templates.xml is:
<configuration>
<templates>
<template label="TEXT YOU WANT IN DROPDOWN"
defaultFilename="DEFAULT NAME FOR FILE"
typesControl="radio|checkbox"
headerFilename="PATH/TO/FILE/HEADER"
startFilename="PATH/TO/START/FILE"
endFilename="PATH/TO/END/FILE"
rename="false">
<types>
<files label="TEXT LABEL FOR CHECKBOX" bodyFilename="PATH/TO/FILE/WHEN/SELECTED" />
</types>
</template>
</templates>
</configuration>
Here are two examples from our templates:
<configuration>
<templates>
<template label="2.0 Portlet"
defaultFilename="360CUSTOMER_PROJECT_PL_DESCRIPTION.js"
typesControl="radio"
headerFilename="header.ss2.js"
startFilename="portlet_start.ss2.js"
endFilename="portlet_end.ss2.js"
rename="false">
<types>
<files label="Render" bodyFilename="portlet.ss2.js" />
</types>
</template>
<template label="2.0 RESTlet"
defaultFilename="360CUSTOMER_PROJECT_RECORDTYPE_RL_DESCRIPTION.js"
typesControl="checkbox" headerFilename="header.ss2.js"
startFilename="RESTlet_start.ss2.js"
endFilename="RESTlet_end.ss2.js"
rename="true">
<types>
<files label="GET" bodyFilename="RESTlet_get.ss2.js" />
<files label="POST" bodyFilename="RESTlet_post.ss2.js" />
<files label="PUT" bodyFilename="RESTlet_put.ss2.js" />
<files label="DELETE" bodyFilename="RESTlet_delete.ss2.js" />
</types>
</template>
</templates>
</configuration>
For scripts that only have one entry point method (e.g. Suitelet, Portlet, Scheduled), you use radio for the typesControl setting and just have a single <file> tag under <types>. For those that have multiple entry points to choose from (e.g. Client, Map/Reduce, User Event), you use checkbox for the typesControl and then list each option that you want using <file> tags under <types>.
I do not actually know what the rename setting does.
The basic file structure of the generated file will be:
/* CONTENTS OF HEADER FILE */
/* CONTENTS OF START FILE */
/* CONTENTS OF ENTRY POINT 1 FILE */
/* CONTENTS OF ENTRY POINT 2 FILE */
/* ... */
/* CONTENTS OF ENTRY POINT N FILE */
/* CONTENTS OF END FILE */
I have tried the same thing using 2017. You will find some js and template files inside the jar file. I have modified the ss_2.0_suitelet.js and ss_header.js file.
Just pick those file from the jar and place in your own local library. Then modify. Dont forget to point the template directory in the preference->netsuite (eclipse ide).
You can also add Author and the Date. But not sure how to add the $filename in the comment as variable. Here is some sample.
Version Date Author Remarks
1.00 ${date} ${author} Initial version
I have a directory that contains both an uncompressed and a minified copy of jQuery. Depending on my deployment scenario, I may only want to distribute one or the other. Based on Seva Titov's answer, I have an ItemGroup with the following item:
<jQueryFiles Include="$(MSBuildThisFileDirectory)..\..\js\jquery\*.js"
Exclude="$(MSBuildThisFileDirectory)..\..\js\jquery\*.min.js" />
which will just grab jquery.2.1.1.js and exclude the minified version.
For the opposite, it is even simpler with just:
<jQueryFiles Include="$(MSBuildThisFileDirectory)..\..\js\jquery\*.min.js" />
which will only grab the minified version.
But what if I have a scenario where the folder also includes other files to copy like images?
I can generalize copying non-minified files with recursion by using:
<jQueryFiles Include="$(MSBuildThisFileDirectory)..\..\js\jquery\**\*.*"
Exclude="$(MSBuildThisFileDirectory)..\..\js\jquery\**\*.min.*" />
My question now is, how do I achieve the opposite effect and grab all files with ANY extension except plain ".js"? So I might want "jquery\images\foo.png" AND "jquery\jquery.2.1.1.min.js" but I want to exclude the unminified js files.
This is easy to accomplish using Exclude attribute for the item group element. E.g.:
<jQueryFiles
Include="$(MSBuildThisFileDirectory)..\..\js\jquery\*.js"
Exclude="$(MSBuildThisFileDirectory)..\..\js\jquery\*.min.js" />
I have a MSBuild proj file like below:
In PreBuild.proj, I create a dynamic property with UsingTask:
<GetBuildNumber Condition="'$(BuildNumber)' == ''" MajorVersion="2" MinorVersion="0" StartYear="2012">
<Output TaskParameter="BuildNumber" PropertyName="BuildNumber" />
</GetBuildNumber>
Now I want to pass this $(BuildNumber) to the PostBuild.proj.
How to do that?
Depends on how they are linked. Hopefully you have an overall orchestrating project that imports all you pre and post dependencies a la your standard Visual Studio-generated .csproj that imports all the neccesary .targets and .props and is the main entry point for MSBuild since you'd never call the .targets directly, they only make sense as part of a bigger build file. In case of such well-designed project file you just use a property, otherwise you can try Outputs or Returns or worst case scenario WriteLinesToFile & ReadLinesFromFile.
The MSBuild documentation hints in several places that Items aren't necessarily the same as files.
"MSBuild items are inputs into the build system, and they typically represent files."
"Items are objects that typically represent files."
However, I can't seem to find any examples where Items do not represent files. In particular, I would like to perform batching over a set of non-file items. But every item that I create, even from a custom build task, somehow acquires file-like metadata (FullPath, RootDir, Filename, Extension, etc.). Furthermore, I'm confused about the ramifications of setting the Inputs of a target to a set of items that aren't files, and what to use as that target's Outputs.
Does anybody have an example of using non-file Items to perform batching in MSBuild?
edit
Sorry for taking so long to come up with an example. I understand things a bit more, but I'm still uncertain (and there seems to be a complete lack of documentation about this). Everything here is going off my recollection; I'm not at my work computer right now, so I can't verify any of it.
In my experience, MSBuild doesn't like to build multiple configurations of a .sln file in one go. So, this:
msbuild.exe SampleMSBuild.sln /p:Configuration=Debug%3BRelease
(The encoded semicolon being necessary so that it doesn't try to define multiple properties.)
Produces this:
"D:\src\SampleMSBuild\SampleMSBuild.sln" (default target) (1) ->
(ValidateSolutionConfiguration target) ->
D:\src\SampleMSBuild\SampleMSBuild.sln.metaproj : error MSB4126: The
specified solution configuration "Debug;Release|Any CPU" is invalid.
Please specify a valid solution configuration using the Configuration
and Platform properties (e.g. MSBuild.exe Solution.sln
/p:Configuration=Debug /p:Platform="Any CPU") or leave those properties
blank to use the default solution configuration.
[D:\src\SampleMSBuild\SampleMSBuild.sln]
So, it seems like it should be possible to use batching and items to handle this.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
DefaultTarget="Rebuild"
ToolsVersion="4.0">
<ItemGroup>
<Configurations Include="Debug" />-->
<Configurations Include="Release" />-->
</ItemGroup>
<UsingTask TaskName="LogMetadata"
TaskFactory="CodeTaskFactory"
AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
<ParameterGroup>
<Items ParameterType="Microsoft.Build.Framework.ITaskItem[]"
Required="true" />
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">
<![CDATA[
foreach (var item in Items) {
Console.Write(item.ItemSpec);
Console.Write(" {");
foreach (string metadataKey in item.MetadataNames) {
Console.Write(metadataKey);
Console.Write("=\"");
Console.Write(item.GetMetadata(metadataKey).
ToString().Replace("\"", "\\\""));
Console.Write("\" ");
}
Console.WriteLine("}");
}]]>
</Code>
</Task>
</UsingTask>
<Target Name="Rebuild">
<LogMetadata Items="%(Configurations.Identity)" />
</Target>
</Project>
Which produces this:
Debug {
FullPath="D:\src\SampleMSBuild\Debug"
RootDir="D:\"
Filename="Debug"
Extension=""
RelativeDir=""
Directory="src\SampleMSBuild\"
RecursiveDir=""
Identity="Debug"
ModifiedTime=""
CreatedTime=""
AccessedTime=""
}
Release {
FullPath="D:\src\SampleMSBuild\Release"
RootDir="D:\"
Filename="Release"
Extension=""
RelativeDir=""
Directory="src\SampleMSBuild\"
RecursiveDir=""
Identity="Release"
ModifiedTime=""
CreatedTime=""
AccessedTime=""
}
As you can see, the items have all kinds of file metadata attached to them. I can't drop the Include attribute, since it's required, but I could synthesize the items in a custom task. HOWEVER, when I do that, they still somehow magically gain all the same file metadata.
What are the ramifications of this? Since I haven't specified these as Inputs or Outputs to a target, will the file metadata cause any problems? Will the build system skip over targets, or build more than it needs to, because the files specified in the Items' FullPath metadata do not exist? What if those files did exist? Would it cause any problems?
I use items to build several solutions after each other and doing some "manual" task with them, therefore I define my own items:
<ItemGroup>
<MergeConfigurations Include="project1\project1.SDK.sln">
<MergeOutAssemblyName>product1.dll</MergeOutAssemblyName>
<MergePrimaryAssemblyName>project1.Interfaces.dll</MergePrimaryAssemblyName>
<SolutionBinaries>project1\bin\$(FlavorToBuild)</SolutionBinaries>
</MergeConfigurations>
<MergeConfigurations Include="project1\project1.Plugin.sln">
<MergeOutAssemblyName>product1.dll</MergeOutAssemblyName>
<MergePrimaryAssemblyName>project1.Interfaces.dll</MergePrimaryAssemblyName>
<SolutionBinaries>project1\bin\plugin\$(FlavorToBuild)</SolutionBinaries>
</MergeConfigurations>
<ItemGroup>
Then I use a target to take the information and do what is necessary:
<Target Name="MergeSolution"
Inputs="%(MergeConfigurations.Identity)"
Outputs="%(MergeConfigurations.Identity)\Ignore_this">
<PropertyGroup>
<MergeSolution>%(MergeConfigurations.Identity)</MergeSolution>
<MergeOutAssemblyName>%(MergeConfigurations.MergeOutAssemblyName)</MergeOutAssemblyName>
<MergePrimaryAssemblyName>%(MergeConfigurations.MergePrimaryAssemblyName)</MergePrimaryAssemblyName>
<SolutionBinaries>%(MergeConfigurations.SolutionBinaries)</SolutionBinaries>
</PropertyGroup>
[....]
</Target>
Hope this helps to point you in the direction you need.
Tricky question. I'm an MSBuild noob, and found myself needing to understand batching recently, so figured I'd share some of what I found.
In general, yes, it seems that most everywhere you see samples and discussions about ITaskItems they tend to be about files. But the underlying implementation is very flexible and can deal with many other things as well. In my case, I've been working with strings and XML data.
This MS article gives some great examples of non-file ItemGroups and metadata.
This article was the best summary I can find that talks about the mechanics of Items and how they are different than Properties. It also covers the whole bit about # and % syntax, converting between strings and Items, and a hint as to where those file metadata properties are coming from - MSBuild is optimized for it.
Whenever you have an interface used as a parameter to a task or whatever, there is going to be a default implementation of that interface somewhere. My guess is that your code sample is newing up a number of these default objects under the hood and those define the metadata that are created by default. If you were to implement this interface yourself, I'll wager you could change this behavior. Probably beyond the scope of the question though =)