I'm building a plugin that will contain sharable code and configuration for several applications. One things that I'm trying to share is the data source information. Basically I need the application to not have to define it's own data source and instead use the plugin's data source. The best way that I can think of doing this is to take advantage of the external configuration functionality that's available in Grails (http://grails.org/doc/latest/guide/conf.html#3.4%20Externalized%20Configuration). However, I'm not exactly sure how to do this. All the examples I can find online show you how to do this when using an external file on the file system somewhere. I want to use configuration files from the plugin.
According to the documentation linked to above you can specify a "config script" class to use like this:
grails.config.locations = [com.my.app.MyConfig]
This would probably work, however, I can't find documentation on what a "config script" class actually is and how to create one.
By default, the DataSource file of your plugin will not be used (it's ignored in the package stage) but you can create another file that ends with "DataSource" (eg MyPluginDataSource). This is also true for BootStrap and Config.
You will probably need to leave the application DataSource file empty.
Related
I am trying to figure out if there is a difference between the two pre-defined variables in TFS Online 2017: $(Build.Repository.LocalPath) and $(Build.SourcesDirectory). I have a build that uses these two variables and didn't know if I could use them interchangeably or not.
Looking at Microsoft's documentation the descriptions are as follows:
$(Build.SourcesDirectory): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
$(Build.Repository.LocalPath): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
Are these representing the same thing or am I missing something?
They're synonyms. Most standard templates and tasks use the $(Build.SourcesDirectory), so that is what I tend to use.
They often result in the same but not necessarily. As described in the docs:
If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable):
The description for Build.SourcesDirectory on the same page contains a similar note.
Basically if you want to define a custom path for the self checkout and still not need to specify the extra dir, you specifically need Build.Repository.LocalPath.
For clarity, you can still use Build.SourcesDirectory to resolve to the full path if you have the usual
- checkout: self
path: s
and I'd recommend using it whenever possible if so. If you have something like
- checkout: self
path: main_project
then you'd need $(Agent.BuildDirectory)/main_project to reach the same.
I was playing a bit with Cygnus, and I was wondering how to properly configure it. I’ve seen both agent_<id>.conf and cygnus_instance_<id>.conf files are needed. I understand the purpose of the first one, but not the second one. In addition, what about the grouping_rules.conf file? Is there any other configuration file?
File by file:
agent_<id>.conf file is the main configuration file for Cygnus. It inherits the syntax from Apache Flume, the base technology used by Cygnus, thus it is used to declare and specify the sources, channels and sinks of your Cygnus agent.
cygnus_instance_<id>.conf file is used to configure other Cygnus parameters that cannot be configured as part of the agent configuration, such as the logging file, the management interface port, etc. Cygnus service will run as many instances as cygnus_instance_<id>.conf files are configured. That's why an <id> must be provided, since this <id> will be used to find the proper agent_<id>.conf file.
grouping_rules.conf file is used when the Grouping Rules advanced feature is wanted to be used. Usually, this file may be empty (but it must exist) and Cygnus will run after all.
flume-env.sh file has been inherited from Apache Flume, and it is used in order to configure certain Flume paramters such as the classpath overwritting the default one, some Java options (-Xms, -Xmx, etc)...
I am trying to override the main messages.properties file during runtime. My current task requires me to package application based on a product brand. For eg, if i pass a argument like "grails dev run-app -Dbrand=a", i should be able to change the messages in .properties file based on the brand.
Another requirement is that I need have one master .properties file which contains all the messages and I want to create a seperate folder to store the messages based on brand.
For eg, my master .properties file will contain A,B,C,D and my brand .properties file will be a subset of master which will only contain A. (Th message string for A in master will definitely be different than message string in .properties file present under the brand folder). For eg, A.productName in .properties file for master could be "hello" and A.product name in .properties file could be "world".
When I do run-app with brand=a as argument, I need to be able to laod the A.product name from the .properties file under brand folder without disturbing the current state of the master .properties file.(This is so that changes do show up in git).
I looked at some approaches and the only good solution I found required getting messages from DB which I dont want to do. I want a way to override using some grails configuration or event listener.
I am assuming there needs to be a way to override the messages in the memory during run-time in grails.
Hope, my I asked my question in detail.
Please help, I am really new to grails.
I think you should look at how Localizations plugin handles this. It implements
org.springframework.context.support.AbstractMessageSource
It looks up the original message source from properties, if it is not found in a database table. Sounds like you want to archive some of the same functionality.
Grails in it self uses either
org.codehaus.groovy.grails.context.support.ReloadableResourceBundleMessageSource
or
org.codehaus.groovy.grails.context.support.PluginAwareResourceBundleMessageSource
I have not looked into wich of them is injected into the artefacts in the application.
I'd like some environment variables to be set in Sublime Text when I open the project. This is for the most part just for some plugins that require them to be set.
I believe that there is a feature request for this, but I was still wondering if this isn't possible in some way or another.
http://sublimetext.userecho.com/topic/103881-sublime-project-should-also-be-able-to-set-environment-variable/
I'm asking this specifically in relation with the GoSublime plugin, for which I'd like to change the GOPATH between projects.
I see that you linked my request to sublime userecho.
Unfortunately nothing really happened over there, so I developed my own plugin to do that.
If you are still interested, please look at this:
https://bitbucket.org/daniele-niero/sublimeprojectenvironment
I have also made a pull request to Package Control to make the plugin available with it.
I am a total Grails noob trying to configure the db-reverse-engineer plugin for my first project. Documentation for the plugin indicates that I need to configure it, but I don't see where I am supposed to edit configuration.
Is there a configuration file in my project I need to edit? I have searched through the ./grails-app/conf folder for grails.plugin (the prefix for this plugin's configuration) and found nothing. An SO or Google search for how to configure grails plugins also returns void. I know this is a lame question, but how do I configure this plugin? Is there a UI I need to use, or are there files somewhere to edit?
You need to configure your database in grails-app/conf/DataSource.groovy. In particular, you'll need to provide the JDBC URL, the database dialect and the databases's username and password.
You'll also have to add some extra db-reverse-engineer configuration to grails-app/conf/Config.groovy. This file will already exist. Just append the new properties at the end.
Finally, run the reverse engineer script to generate your domain classes:
grails db-reverse-engineer
The right place for that would be the file grails-app/conf/Config.groovy.
Just add what you need at the bottom.