Xtext and update project created by wizard - eclipse-plugin

Create a new DSL with Xtext a project with the prefix repository.
Does this project create an update site for the plug-in?
If it is the case must the project be configure and how is it deployed?

The answer is:
Yes it creates a repo.
No there is no config needed unless you want to change contents. Then update category.xml
There is no deployment. You can e.g. upload the (unpacked) zip on a webserver or send it to your users via a file server
(Could you give some more hints why you are asking)

Related

GitLab Default Issue Template for all new Projects

I'm wondering if there is a way to set a default issue template for all new created projects? As a developer I often create new projects for every job I take. What I already have done is creating a default project template from which I create my new projects. So all the settings are always the same and I do not have to set the project up again from the scratch.
What I am missing is the part, where I can define default issue templates for all my projects, as the issue template is always the same, too. I know I can create a issue template for my projects by adding them to the issue-template directory in my repository. But how can i 'automate' this, to not have to add them manually?
Can anyone help me out?
Greets
Thomas
2020: The notion of template repository is only for GitLab premium.
Locally, you could define (git init --template) a template repo that would:
be used for any new repository
include your standard issue template file
be pushed to your new GitLab repo.
Update 2022, for all GitLab tier:
See GitLab 14.8 (February 2022)
Add default issue and merge request templates in a project’s repository
In addition to defining default issue and merge request description templates in project settings, you can now set default templates in the .gitlab
directory of a project’s repository.
Do it by creating a Default.md file in the issue or merge request templates folders.
If default templates exist in both the project’s settings and in the repository, the template in the settings
takes precedence.
Thanks for the contribution #davebarr!
See Documentation and Issue.

How to activate Unique Constraint on the RavenDB serverside?

I'm using version 3.5 and read the documentation here https://ravendb.net/docs/article-page/3.5/Csharp/server/bundles/unique-constraints#installation on how to install/activate it on the serverside.
But i dont understand any single step in this...
"Drop the Raven.Bundles.UniqueConstraints assembly in the Plugins directory". Where is the assembly and plugins directory?
"simply add Unique Constraints to Raven/ActiveBundles configuration in the global configuration file". Is it a string or what is it? And where is the global configuration file?
"or setup a new database with the unique constraints bundle turned on using API or the Studio". When i create a new database, it doesn't give me any option to turn on the unique constraints bundle, but it gives me options such as encryptions, replication etc...
Hope someone can help me out on this :-)
Thanks in advance!
Where is the plugins directory?
The docs on plugins shows that it's under ~/Plugins by default. That is, it should be a root folder under the RavenDB server directory. So, wherever you installed Raven server, you should create a Plugins directory under that.
Here's my working example:
it doesn't give me any option to turn on the unique constraints bundle
Put Raven.Bundles.UniqueConstraints.dll inside the Plugins folder. Restart your Raven server. Then, load up the Studio, and you'll see the option for Unique Constraints:

Custom Clickstart with Templates and Github

We are using Cloudbees dev#cloud service, and are looking to create a number of application based off of an archetype stored in Github. I would like to create a custom ClickStart in order to streamline the process.
We are currently forking the archetype, then using a Folder Template that I have created to provision a build pipeline for the application.
While I have been able to create a simple ClickStart, I would like to create one that:
Forks or copies the clickstart source into a Github repository, and not cloudbees forge. The GitHub API supports this.
Point to my folder template using the Jenkins XML API. Currently, not all attributes of a folder template are represented in the rendered XML.
Target a specific folder to create my new folder job under.
The ClickStart API and JSON doesn't seem that well documented, and I have gotten about as far as I can go with trial-and-error.
Is what I am looking to accomplish possible with the current state of the Clickstart API?
Forks or copies the clickstart source into a Github repository
I do not believe this is possible today. Certainly it has been proposed.
not all attributes of a folder template are represented in the rendered XML
Such as what? The config.xml of a folder, just like that of a job, should be definitive. (It does not include definitions of child items.)
Target a specific folder
Also not possible today that I know of. (Though the user of the ClickStart could always move the result into a subfolder after the fact.)

How to get RavenDB to recognize a plugin?

I'm trying setup the Versioning bundle in RavenDB: http://ravendb.net/bundles/versioning
The installation instructions are pretty straight forward:
Simply place the Raven.Bundles.Versioning.dll in the Plugins
directory.
I've tried this do this by creating a "Plugins" directory under the Server directory (the Server directory contains the Raven.Server.exe), and dropping Raven.Client.Versioning.dll into that Plugins directory.
However, when I run RavenDB after that (either from the command line or as a service), it doesn't give me any indication that it has recognized the plugin, and when I save/edit new documents no versioning is being applied.
I've tried running with the default plugin directory settings (which supposedly automatically looks in the Plugins directory), and I've tried manually adding the PluginsDirectory setting to Raven.Server.exe.config, to no avail.
Has anyone been able to get plugins working, specifically the versioning bundle? Do you hae to do anything special?
Mike,
It is supposed to just work. Take a look at the statistics, you should see the versioning trigger registered there.
It is important to ensure that:
You are using the same version of the dlls
You restarts RavenDB after copying the directory
You don't reference another Raven/PluginsDirectory in the configuration
It is probably better to follow this up in the mailing list.
For Raven v2, you'll also add the bundle name to the the Raven/ActiveBundles property on a database document. The names should be semicolon-delimited.
For example, I have a database called MidwestAnimalRescue. To enable the Periodic Backup bundle and the Versioning bundle, my document will look like this:

Teamcity 2 configurations merge and deploy

I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.