For a project I have a set of old .properties files, some are templates with
${placerholder} values and some are the "real" properties files that have key-value settings.
Depending on the start parameter, the .properties template files have to be filled with the real values.
The placeholder can be written with one or more dot annotations such as ${acount.money.euro} etc.
I cant seem to find a gradle way of filling those properties if:
the value is missing or should just be empty or have the placeholder
the value is written in dot annotation
I can do it in ANT but cant find a way to do it in gradle. Either the value cant be found for the dot annotations or the values are not filled at all or the missing value for the placeholder is making the script crash.
Anyone knows the right way to configurate .properties in gradle style? There are no real tutorials for it.
Did you try to use ant task? or write a custom task or a groovy class? or search on stack overflow? at least google? there are millions of answers on this, its one of the most common questions I think.
What do you mean:
There are no real tutorials for it.
Please check those links, try something show us your effort and then come back if you are stuck.
How can I transform a .properties file during a Gradle build?
Different ways to set properties
Gradle write properties
Groovy Reading a writing to properties file
and on, and on, and on....
I'm using sonarqube and I've kind of messed up the rules inside the sonar way profile. Is there a way to put it back as it was before ? Like updating the java plugin. Because I don't find the list of rules inside the default "sonar way" profile on the sonarqube web site.
Thanks.
On the profiles page, there's a down-arrow next to the 'Create' menu at the top of the column on the left. It offers two options:
Restore Profile - restore a single, specific profile from a backup file that you'll upload
Restore Built-in Profiles - restore all default profiles for a single, specific language.
You want the latter.
I want to add my new java related rules.
But on SonarQube GUI, I am not getting any option for the same.
I go to QualityProfiles->Java Profile->Sonar way.
It shows existing rules but nothing is there to add a new one..
Please help on this.
Since SonarQube 4.4, custom rules are not managed through the Quality Profiles page, but rather through the Rules page. See Custom rules menu doesn't seem to be present
I've got following structure in Eclipse project
- /src/main/java
- /src/test/java
When I open call hierarchy or using java search, search result contains classes from /src/test/java classes. The same true for type hierarchy and others searches.
There are numbers of unit tests and I don't want to see classes from /src/test/java packages in search result.
The most straightforward way - simply exclude it from build path. Also there are filters for call hierarchy, however I was not able to find them for simple java search. Also filters relies on name pattern, which is not very good though.
I am looking for more convenient way
Right click on your test folder, go to properties and check the "Derived" checkbox. Then click ok.
Or you can create 2 working sets. 1 set for your code and a second one for your tests. Then when you search, you can search only the working set that holds the code.
Open Search dialog (ctrl+h)
Change search scope to Working Set
Click Choose ...
Click New to create a new Working Set with the what you want searched (or Add All and then remove the ones you want filtered
What is the difference between Java working set and Resource working set in Eclipse?
The Resource working set is more general and it can include not only the Java applications / projects, but let me put it this way:
Let's assume a daily life of a Java developer. Do you suggest him/her to use Resource working set over Java working set? Is there any specific situation in which you prefer one over the other?
It sounds like this should have answered the question:
http://www.avajava.com/tutorials/lessons/what-is-a-working-set-and-how-do-i-use-it.html
A Working Set is a subset of your Eclipse projects. You can create
different Working Sets and then select which Working Set to display in
the Navigator view.
Specifically:
"Working set" (in this particular context), is an "Eclipse thing"
The purpose of Eclipse working sets is to help organize your projects
A project consists of "stuff": source code, bitmap graphics files, WSDL's, CSS style sheets - just about anything imagineable.
Consequently, Eclipse projects are organized (glancing at my J2EE perspective, for example) into subsections like "src", "WebContent", "Services" and so on. A project itself can be one of many different types: a "Java project", a "Java Swing Design project", and "Dynamic Web Project" and so on.
Similarly, an Eclipse Working set can be one of several different types: a "Java working set", a "Breakpoint working set ... and a "Resource working set".
As with Eclipse "Views" and Perspectives", you can usually access any project resource you need any time you need it. Selecting one or another perspective simply makes the object (e.g. "Problems pane" or "Build list") easier to get to.
Which kind of "Working Set" you choose - or whether or not you use working sets at all - is largely just a matter of personal preference and convenience.
Please let us know if you still have any further questions.
PS:
Additional links:
https://www.ibm.com/developerworks/library/os-eclipse-visualstudio/
As mentioned, many developers load all their projects into a single
Eclipse workspace. It's convenient, but it can sometimes create too
much clutter. In addition to closing unnecessary projects, you can
define working sets: groups of elements (projects, folders, classes,
etc.). Eclipse can use working sets in different views (such as
Package Explorer) and operations (like searching).
...and:
help.eclipse.org: Working Sets
A working set in the context of eclipse is a logical grouping of related projects to ease search and organize views within the IDE.
A resource working set can capture all types of resources - maybe java source, html, xml, javascript, images - anything that exists within the scope of the projects included into the working set.
The Java working set is a different working set (it is NOT a subset of a resource working set!) which captures only those java files which belong to a source folder and are being compiled into the classpath, or those java files which belong to a module (library) in the build path. Hence, it lets you lookup java "classes" which are in the classpath. Note that all java file in your project may not necessarily be built into the classpath (for example when you exclude a java source file, it does not get built any more). But a java source file which is not included in your classpath can still be detected by a resource working set (you will notice that the icon for an included java source file is a solid J, while for an excluded java source, it is a hollow J).
Example:
Say you have two projects p1 and p2 of which p1 belongs to the working set but p2 does not. So:
MyClass.java (belongs to p1 and included in build path) - Shows up in java type search (Ctrl + T) and also in resource search (Ctrl + R).
MyOtherClass.java (belongs to p2 and included in build path) - Does not show up in java type search nor in resource search.
MyExcludedClass.java (belongs to p1 and excluded from build path) - Does not show up in java type search but shows up in resource search.
MyExcludedClass.class (belongs to a dependency jar in the build path of p1) - Shows up in java type search but does not show up in resource search.
MyWebPage.html (belongs to p1) - Does not show up in java working set but in resource working set.
MyOtherWebPage.html (belongs to p2) - Does not show up in java type search nor in resource search.
MyConfig.xml (belongs to p1) - Does not show up in java type search but shows up in resource search.
So, in the context of a Java developer's use: I use Java working sets to look up types / classes defined in Java, whereas the resources working set to lookup all different types.
One difference between the working sets is that they provide different editing wizards (as stated here: http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcworkset.htm). If you edit a resource working set and a java working set respectively you will see they use different screens for selecting which resources/projects are included.
Apart from this I haven't found any other difference. It also does not seem to differ which resources you can choose in any way. So to answer your question which one would be recommended I would answer "it doesn't matter" since they behave the same way.
A working set is a subset of your workspace and is a way to organise all your projects. With the different types of working sets you have also different types of editing wizards as described here.
Editing wizards
For java projects the Java working set is a more comfortable way to work. Let's assume you have a bunch of java projects in a java working set and you have just opend the editing wizard of the Java Working set:
First of all you can see everything what is in the working set at the moment in the right table. If you now want to include another project you can simply select the project(s) and press CTRL+a. To remove a project you can press CTRL+r
In the Properties of a Resources Working set you don't know what is in the working set until you have scrolled to the bottom of the tree view. This is impossible for people who have 300+ projects in their workspace.
Structure
A benefit from having two types of working sets is structure. There are situations in a daily workflow where it is useful to have different types of working sets, because they have different icons. If you have resources like config files you can create a Resource working set namend 'config files' and put all the files in there.
Afterwards you can open your File Search and search in your config files. This is possible because you can define a working set as a scope for a search.
There are several parts in Eclipse where you can select your working set with the Select working set dialog.
I'll try answering from the perspective as a plugin developer. From the API:
A working set is intended to group elements for presentation to the user or for operations on a set of elements.
This can be any kind of element and does not have to be a project. Working sets are provided by plugins, which can decide what kind of elements can be added and which provide wizards for adding elements as well as operations that can be performed.
It doesn't really matter for a project in which working set(s) it is in. A Java project is still a Java project if it in a resource working set. It only affects some views, dialogs and operations that filter for certain types of working sets.
Besides Java and Resource working sets, there are also Breakpoint, Task, Plugin and C/C++ working sets (depending on your Eclipse setup of course). Some views only show certain types of working sets while other views don't seem to filter them. For example the "Open Type" and "Open Resource" dialogs seem to display all types of working sets. The "Open task" dialog only shows task working sets.
So what is the actual difference between Java and Resource working sets? I haven't seen any functional differences yet. All standard views and dialogs either seem to handle both or none of these two working set types. Most plugins don't seem to care about the distinction at all - but that doesn't mean some plugin could handle both types differently.
On the other hand resource working sets seem to be a catch-all for any type of project, so it makes sense that most plugins don't make a distinction here.
For example if I were to create a plugin that provides an option to analyze Java projects, I would add that operation to the context menu of Java working sets but certainly not to C/C++ working sets. But some people might use resource working sets because they have both Java and C projects in the same working set. So I have to add the Java-specific operation to the context menu of resource working sets too.