I use 2 different DSL languages in my Project and reference them like described in this tutorial:
http://christiandietrich.wordpress.com/2012/08/07/xtext-referencing-elements-of-one-dsl-from-another-dsl/
My question is:
How to configure the build of the second language, to also rebuild the referenced first language?
If I choose 'Generate Xtext Artifacts' in the second language it should also trigger the workflow to rebuild the first one.
you can have multiple language sections in one workflow (have a look at Xtexts Xbase Project). but i dont see the usecase for that in your constellation
Related
I'm taking a glance over at the buildtools repo (https://github.com/bazelbuild/buildtools) and trying to understand the scope of its responsibilities as it relates to the three phases of a bazel build (loading, analysis, execution)
The repo's description states that it is A bazel BUILD file formatter and editor. I find much logic in the repo written in go-lang that lends complete support for an AST parser, starlark syntax interpreting capabilities, reformatting and rewriting of BUILD files and what not. Basically there's logic designed to operate upon a single starlark file at a time. Rereading that repo description in this light leads me to conclude that buildtools is really a single file scoped effort and presents tools that only intersect functionality wise (perhaps only partially) to those loading operations bazel conducts while building.
Question: Is it accurate that the focus of buildtools is upon the single starlark file?
If that's true then all the multiple starlark file analysis logic and so forth seems to actually be maintained over at https://github.com/bazelbuild/bazel/tree/master/src/main/java/com/google/devtools/build/lib and I should not expect to find any tools for the analysis phase and beyond in the buildtools repo. Is that right?
I don't work on Buildtools, but we agree: these tools seem to focus on BUILD / .bzl files in isolation. They let you process these files in parallel, to do similar operations on them.
If you wonder whether these tools understand relations between these files, the answer seems to be no.
If you further wonder what tools do then, the answer is Bazel's query, cquery, and aquery. I'm not aware of a programmable API for these queries though; you have to run Bazel to perform them.
buildtools has tools working on a syntactic level (it looks at the syntax tree). These tools are outside of Bazel and have no knowledge of Bazel build phases. In the future, we may expand the code to work on multiple files (for the static analysis), but it will still be independent from Bazel phases.
https://github.com/bazelbuild/bazel/tree/master/src/main/java/com/google/devtools/build/lib/ is the source code of Bazel. The syntax/ directory includes the code for reading and evaluating the Starlark files. The code there is called by Skyframe. The interpreter is called by Skyframe many times in parallel, both during the loading and the analysis phases.
If you have a more specific question (what are you trying to do?), I can help more. :)
So, at work, I frequently have to create virtually identical ant scripts. Basically the application we provide to our clients is designed to be easily extensible, and we offer a service of designing and creating custom modules for it. Because of the complexity of our application, with lots of cross dependencies, I tend to develop the module within our core dev environment, compile it using IntelliJ, and then run a basic ant script that does the following tasks:
1) Clean build directory
2) Create build directory and directory hierarchy based on package paths.
3) Copy class files (and source files to a separate sources directory).
4) Jar it up.
The thing is, to do this I need to go through the script line by line and change a bunch of property names, so it works for the new use case. I also save all the scripts in case I need to go back to them.
This isn't the worst thing in the world, but I'm always looking for a better way to do things. Hence my idea:
For each specific implementation I would provide an ant script (or other file) of just properties. Key-value pairs, which would have specific prefixes for each key based on what it's used for. I would then want my ant script to run the various tasks, executing each one for the key-value pairs that are appropriate.
For example, copying the class files. I would have a property with a name like "classFile.filePath". I would want the script to call the task for every property it detects that starts with "classFile...".
Honestly, from my current research so far, I'm not confident that this is possible. But... I'm super stubborn, and always looking for new creative options. So, what options do I have? Or are there none?
It's possible to dynamically generate ANT scripts, for example the following does this using an XML input file:
Use pure Ant to search if list of files exists and take action based on condition
Personally I would always try and avoid this level of complexity. Ant is not a programming language.
Looking at what you're trying to achieve it does appear you could benefit from packaging your dependencies as jars and using a Maven repository manager like Nexus or Artifactory for storage. This would simplify each sub-project build. When building projects that depend on these published libraries you can use a dependency management tool like Apache ivy to download them.
Hope that helps your question is fairly broad.
I have a Jenkins job that stores artifacts as a post-build action. Within these artifacts is a text file that tells which version of the software has been built. Is it somehow possible in a Jenkins project to get access to this text file and displaying its contents somewhere on the Jenkins build page somehow? This way the build manager would instantly see what software version this archived artifact contains. Thanks!
There are more advanced ways with GroovyScript, but I can suggest something like this:
Use Description Setter plugin. It uses RegEx to look at the console output (build log) for a pattern and sets the description (as seen in screenshot) accordingly.
If you don't have the version already printed in console log, you can print it out with either
cat filename (Linux) or type filename (Windows). No need to store a version text file as an artifact (unless you need it for other purposes)
To answer your question directly, in order to add text to actual build page, you can use Groovy Postbuild plugin, something like this:
def workspace = manager.build.getEnvVars()["WORKSPACE"]
String fileContents = new File('${workspace}/filename.txt').text
manager.createSummary("folder.gif").appendText("${fileContents }")
The plugin page has a lot of examples.
I got a revised proposal. Since all you really want is to include a semantic versioning information in your displayed build name and/or description, there is a simpler way to do this.
First of all I have stumbled upon a plugin that does the extraction of your version from the Maven or SBT build process quite nicely - the Semantic Versioning Plugin. This does what is advertised - extracting the version from POM or whatever and including this as a file and a variable in your build process. So you have the freedom to use both, either include the file in your build process and do what you heart wishes AND/OR use the variable to affect the build flow in Jenkins. Now, because this plugin still have couple of bugs I would like to point you for now to my own build of this plugin with fixes already in that can be obtained from here. I will take my own version down the moment that all fixes will be merged to the official plugin...
Then let's start with the name. As suggested previously the best way to do so is to use the Build Name Setter plugin. In order to use both plugins to set up a name for your build navigate to the configuration of the project and find an option named "Determine Semantic Version for project" in there, activate it and either use the default name of the variable or provide your own. When you're down scroll down a little bit to the option named "Set Build Name" and activate it. By default you will see the regular build naming convention there - #${BUILD_NUMBER}. You can use that variable as well as any other provided by any plugin, but in this specific case you need to use the environment variable that you have named above, i.e.:
#${BUILD_NUMBER} - ${ENV,var="SEMANTIC_VERSION"}
This will set the name of every build to something more meaningful, so in this case it may result in #76 - 0.0.76-SNAPSHOT. Obviously you're free to experiment on your own to tailor the name of the build to specific format you desire. Keep in mind that it might break your page flow a little bit since the name will be longer than usually, therefore it will push that table with latest builds on the left side of the screen as well it will affect your dashboard.
Now, in order to customize your build information further you might want to take a look at Description Setter Plugin as well. Personally, since I have started to investigate this case further, I use the combination of both at this time. You can use the same token expansion as the one listed above, the big difference is that you will need to create/maintain a file that will be used to create the description. What you will include in this description is only limited by all the variables or token published by Jenkins itself or any of the installed plugins (take a look here). Personally I am listing some information gathered from different places as well as some additional stuff created/provided by Maven during the build process. So it's pretty handy.
Both plugins mentioned above (Build Name Setter and Description Setter) can use other sources of information to build the name and description - it can be properties files, etc. For example one can use Job Exporter Plugin to drop a properties files to read all possible information about the build itself in the form of, as example:
${PROPFILE,file="hudsonBuild.properties",property="build.user.name"}
In this case this will resolve to user name of the user who have triggered the build.
Again, any variable visible to Token Macro plugin can be used.
Is there an equivalent of the Eclipse "Project" menu "Clean..." command in the Dart Editor? If not, how can a project be cleaned of the files generated by the various tools?
Never heard of such a functionality in Dart.
What files of what tools? I guess from Run as JavaScript?
I guess the development goes in the direction that files are generated only in the build directory.
These files will be purged before rebuild.
But this is WIP.
I have the same question. However I am coming to this question with a suggestion. I would like people to consider the build model implemented by Apache Maven for Dart builds.
The nice thing about the maven model is that you can:
Define custom actions aside from the built-in ones.
Implement custom handlers for actions.
As for the clean action in Eclipse -- Add my vote for Dart Editor.
Eclipse normally use either Apache Ant or Apache Maven for build actions. 'Clean' is a standard action and found its way to the Build menu at a very early stage. Which gives me an idea;
Add some UI meta-management to the Dart Editor
Build tool = Current Dart build (default), OR user specified: Ant, Maven, ...
Build menu = Set standard actions, allow custom actions against the current build tool; e.g. a "database load".
I know with new frameworks and languages there's always more things to do that time to do it. There are probably better examples than just And or Maven. I'm just pondering some flexible options to make the Dart development environment a little "future proof". ;-)
TFS build flow is defined in TFS 2010's build template(which in fact is Windows Workflow Foundation file with *.xaml extension).
It was pretty convenient for dealing with single build definition in simple project, but in the near future we'll have more complicated project where we'll have many very different build definitions, but in the same time some of them will have some significant common parts in logic.
And there is no wish to have common logic replicated in each build template, and on the other hand having one super-smart-parametrizable build is considered as not the best idea.
Long story short, but the questions is:
is there any possibility to put common logic into another build template/or_whatever and reuse it?
If not - do you have some approaches/recommendation regarding such situation?
UPDATE
As K.Hoff mentioned, there is a possibility to create custom activities, but I want to go deeper and reuse not only activities but sequences as well(put simply, similarly to like Ant or NAnt do - include one file into another, call one sequences from another, etc).
I would recommend you to check whether it is possible to write code activity which executes workfow (.xaml file) with common build functionality. As a result such code activity could be put into several "master" build templates so it is possible to reuse common flow.
Here is an example how to dynamically load and execute workflow - http://msdn.microsoft.com/en-us/vs2010trainingcourse_introtowf_topic8.aspx.
We have a similar situation, but since most of our build scenarios are similar (i.e. get->build->test->deploy) we have mostly solved it with one big definition and custom activities. But we also make use of the ExecuteWorkflow activity available from Community TFS Build Extensions.
This works well for "simple" scenarios, the reason we don't use this more extensively is because it's quite complicated to pass parameters between workflow executions. Here's a link to a problem I had with this (and further down the solution I found).
You can create custom code activities as explained here and reuse them in other build templates.
An other way is to implement good old msbuild scripts and put them in the msbuild execution activities to reuse them in many build process templates.
I can't find a quick way to reuse complete sequences, the only way we found is to write the acitvities as common as possible and inject parameters to get them run.
But I don't think it's a TFS problem it's a Workflow problem.