I'm having difficulty working out the correct properties for sonarQube for my project. The folder structure is as following:
mod/
framework/
Framework.java
rebuild2/
Rebuild2.java
sonar-project.properties
There isn't much yet in either java file but do have they do have package declarations (mod.framework and mod.rebuild2 respectively).
I've tried a variety of different ways to write the properties file but it always errors with "The source directory does not match the package declaration". It seems like it is expecting the folders to be mod.framework/ and mod.rebuild2/.
I've looked through the documentation on the main website but all their examples do not have package declarations. I've also searched through here but either the solutions do not work for this or they are maven/gradle configs.
Does anyone have any idea whether it is possible to set up the sonar-project.properties file for this situation?
# Required metadata
sonar.projectKey=mc:rebuild2
sonar.projectName=Rebuild 2
sonar.projectVersion=0.2
# The value of the property must be the key of the language.
sonar.language=java
# Encoding of the source code
sonar.sourceEncoding=UTF-8
sonar.modules=framework,rebuild2
framework.sonar.projectName=Framework
framework.sonar.projectBaseDir=mod
framework.sonar.sources=.
rebuild2.sonar.projectName=Rebuild 2
rebuild2.sonar.projectBaseDir=mod
rebuild2.sonar.sources=.
If Java file(say File.java) has package delacration like :
package com.abc.xyz;
for a file, It means that file should be inside folder structure like
com
abc
xyz
File.java
But in your case may be, this rule is voided. And your code should not compile too.
Please check, this may be the case.
There is something conceptually wrong in your configuration.
Either the 'Framework' and 'Rebuild 2' projects are separate modules (think sub-projects) that have separate source trees; or they are merely separate packages in the same source tree, in which case you can remove the lines below sonar.sourceEncoding=UTF-8.
Your configuration tries to define 2 modules in the same source tree, and I don't think this is supported by current analyzers, except using exclusions, e.g:
sonar.modules=framework,rebuild2
framework.sonar.projectName=Framework
framework.sonar.projectBaseDir=.
framework.sonar.sources=.
framework.sonar.inclusions=mod/framework/**
rebuild2.sonar.projectName=Rebuild 2
rebuild2.sonar.projectBaseDir=.
rebuild2.sonar.sources=.
rebuild2.sonar.inclusions=mod/rebuild2/**
See Multi-module Project configuration in the SonarQube documentation.
Related
I need to list a specific directory using wildcard logic within my Maven goals and options command.
Currently the root directory is:
mvn test -Dcucumber.options="C:/Users/Joe_Blogs/Desktop/AutoFramework/src/test/resources/features/Bookings/MakeBooking.feature"
I need to use ** to scan the project folders in order to search for a given feature file, as the folder name (Bookings) may change.
mvn test -Dcucumber.options="C:/Users/Joe_Blogs/Desktop/AutoFramework/src/test/resources/features/**/MakeBooking.feature"
In the example above ** will need to reference a variety of different folders, not just Bookings.
Any ideas?
Thanks for your help.
Maven supports the "any" and "any descendant" wildcard denoted by * and **, respectively. It is a subset of the <fileset> Ant convention.
The support comes from the Apache Maven Shared Utils library. The actual logic of walking directory trees, path normalization, pattern matching, etc. is grouped inside the org.apache.maven.shared.utils.io package. Those classes provides uniform file system handling across plugins supported by the the Maven Project.
As the references should demonstrate, wildcard processing is neither trivial logic, nor magically applied outside of Maven proper. Cucumber has to intentionally support the syntax somehow. Sorry, but it doesn't look like Cucumber supports the "any descendant" wildcard. The closest equivalent is /* at the end of a path.
However, one possible workaround is to use tags. Maybe it will seem silly to tag a single file, but doing so dispenses any concern about pathing. Example:
mvn test -Dcucumber.options="--tags #MakeBooking"
I know I am asking the very popular question. But I can not find the solution to the problem. I have a sandbox to which I added a code of the unit test MulticurveBuildingDiscountingDiscountAUDTest.java file and commented it.
Then I added the main method and I could successfully run the program (print something in a console).
Finally, I uncommented the code of the MulticurveBuildingDiscountingDiscountAUDTest.java file and I saw the following error:
The import com.opengamma.analytics.financial.instrument.index.GeneratorSwapFixedONMaster cannot be resolved.
And further in the code:
GeneratorSwapFixedONMaster cannot be resolved
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path. I believe the problem is with a build path options and specially with classes like GeneratorSwapFixedONMaster which were created specially for tests. I have been playing around with cleaning, rebuilding projects, reinstalling and as a result updating the JRE. I have visited these Import *** cannot be resolved [duplicate] and these Eclipse error: “The import XXX cannot be resolved” questions.
Do you know what shall I do to cure the following error?
I have many problems with other imports from the original MulticurveBuildingDiscountingDiscountAUDTest.java file as well.
Update: #1 is a location of my file. #2 is the location of classes this project uses. The MulticurveBuildingDiscountingDiscountAUDTest.java file is taken from the src/test/java
Update 2: one may see that in Libraries I have included all the dependencies I might need (at least I do not know what else to add). The Maven Dependencies contains the hole og-analytics package:
You included the source (src) folder og-analytics/src/main/java which contains the *.java files instead of the classes (bin or classes) folder with the *.class files (in your case, probably og-analytics/target/classes).
But instead using Add Class Folder... you should add the project og-analytics in the tab Projects. Or even better, in the Maven pom.xml file add the dependency to the project og-analytics like you did for og-util.
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path.
Perfectly explains your problem. In order to import any class, you must either have the source in your build path, or some directory that contains a compiled version of that class. It is that simply.
The answer is: get clear on your project setup. If you intend to use classes from somewhere, you have to make them available somehow. Otherwise it will not work. In your case: if your tests want to make use a certain thing - then you should probably add that "thing" to your test project (you should avoid putting test-only stuff to your "product" projects).
That is all there is to this.
It seems that in Java 9 it is not allowed to have so-called Split Packages, i.e. the same package being defined in two different modules. This causes a problem with my migration process: The (Gradle) project contains a Jar file that is called bootstrap.jar, with a structure like this:
bootstrap.jar
- com
- example
- Foo.class
- Bar.class
- Baz.class
The src directory contains a class com.example.Bar that depends on Foo as well as a module definition, for com.example. The bootstrap.jar file does not contain a module info, as it was compiled before Java 9, so it uses an automatic module called bootstrap. The problem is that now the package com.example is defined in both modules, com.example and bootstrap.
The reason there is this bootstrap.jar file, to begin with, is as follows:
The src/com/example folder actually contains Bar.java, Baz.java and another file, Foo.dyvil. The latter is written in a JVM-based programming language. So the dependency chain looks like this:
Bar.java -> Foo.dyvil -> Baz.java
During the build process, it gets compiled to Foo.class, which gets placed in a new Jar file that later replaces bootstrap.jar. The reason all these files are placed is that both the Java and Dyvil compiler cannot process the other languages files, so they require some access to the compiled classes from the previous build. So that is why there is bootstrap.jar.
Now for the actual problem: Since split packages are disallowed in Java 9, is there any way to achieve "split builds" using "bootstrap" jar files as described and used in my project? Or is there any other approach?
Though the long-term solution to this is resolving such packages to exist in a single module and then modularising the code.
As a temporary solution, you can make use of the option:-
--patch-module <module>=<file>(<pathsep><file>)*
as in your case
--patch-module com.example=bootstrap.jar
Do keep in mind though, the --patch-module option is intended only for testing and debugging. Its use in production settings is strongly discouraged.
I have a dashboard library that we use at our company. It has an Initializer. The wicket.properties file is stored in the same package as the rest of the code, not in a META-INF folder. After upgrading to Wicket 7 I started noticing the following warning:
/wicket.properties location is deprecated. Please move the file to /META-INF/wicket/ folder and give it a name that matches your packages' name, e.g. com.example.myapp.properties
So I thought, no problem, I'll just follow the instructions in the well written message and move the properties file and rename it. I renamed the file to com.redi.wicket.dashboard.properties and moved it to META-INF/wicket folder. Now I get the following warning:
/META-INF/wicket/*.properties doesn't work in OSGi and single-jar environments and is not supported anymore! Please see https://issues.apache.org/jira/browse/WICKET-5997 for more details and report an issue for the library that still uses it.
I looked at WICKET-5997, WICKET-6030 AND WICKET-5713 and tried to piece together what I was supposed to do.
I've noticed in the Application class there are deprecated methods regarding this and one, collectWicketProperties, that will be removed in 7.3.0. So I'd like to get this fixed while it is fresh on my mind and not have it bite me down the road when I upgrade.
So where do I put my initializer properties file and what do I name it?
Thanks
I figured it out by looking at the code for org.apache.wicket.Application. Here the developers mention that you should use the ServiceLoader class for Initializers. https://issues.apache.org/jira/browse/WICKET-5997. I noticed the Application.initInitializers method and saw the ServiceLoader class they were talking about.
So I read up on the java.util.ServiceLoader class and it states the following:
A service provider is identified by placing a provider-configuration file in the resource directory META-INF/services. The file's name is the fully-qualified binary name of the service's type. The file contains a list of fully-qualified binary names of concrete provider classes, one per line.
So I created a META-INF/services folder and put a text file named org.apache.wicket.IInitializer and inside the file I put the fully qualified class name of my IInitializer implementation.
The warning went away and my Initializer was called on application startup which is exactly what I wanted.
NOTE: If you are migrating from using wicket.properties make sure to take out the "initializer=" part of the file. The new way is not a properties file so it doesn't have key value pairs. It only has fully qualified class names separated by new lines. See the java.util.ServiceLocator documentation if you need more details.
Also if you are using maven, the META-INF/services folder will go in src/main/resources.
In Eclipse 3.5, say I have a package structure like this:
tom.package1
tom.package1.packageA
tom.package1.packageB
if I right click on an the tom.package1 package and go to Refactor->Rename, an option "Rename subpackages" appears as a checkbox. If I select it, and then rename tom.package1 to tom.red my package structure ends up like this:
tom.red
tom.red.packageA
tom.red.packageB
Yet I hear that Java's packages are not hierarchical. The Java Tutorials back that up (see the section on Apparent Hierarchies of Packages). It certainly seems like Eclipse is treating packages as hierarchical in this case.
I was curious why access specifiers couldn't allow/restrict access to "sub-packages" in a previous question because I KNEW I had seen "sub-packages" referenced somewhere before.
So are Eclipse's refactoring tools intentionally misleading impressionable young minds by furthering the "sub-package" myth? Or am I misinterpreting something here?
Eclipse can't possibly violate the JLS in this case, because it has nothing to do with compiling or running Java source or bytecode.
The refactoring tools behave as they do because that behaviour is useful to developers. The behaviour is useful to developers because, for many intents and purposes, we do treat packages as hierarchal (a.b.c has some kind of relationship with a.b, even if that relationship is not consistent from project to project). That doesn't mean Java treats them as hierarchal intrinsically.
One example where people treat packages as very hierarchal is in configuring a logging framework such as log4j. Again, it's not intrinsic to log4j, but that's how people use it in practice.
Java packages are not hierarchical in the sense that importing everything from package A does not import everything from package A.B.
However, Java packages do correspond directly to the directory structure on the file system, and directories are hierarchical. So Eclipse is doing the correct thing - it is renaming the directory, which automatically changes the name of the parent directory of the renamed directory's children (to state the very obvious).
even java itself has the concept of subpackage:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
java -ea[:<package name>"..." | :<class name> ]
Enable assertions. Assertions are disabled by default.
With no arguments, enableassertions or -ea enables assertions. With one argument ending in "...", the switch enables assertions in the specified package and any subpackages. If the argument is simply "...", the switch enables assertions in the unnamed package in the current working directory. With one argument not ending in "...", the switch enables assertions in the specified class.
If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. So, for example, to run a program with assertions enabled only in package com.wombat.fruitbat (and any subpackages), the following command could be used:
java -ea:com.wombat.fruitbat... <Main Class>
Java's packages are not hierarchical, but Eclipse stores packages on your system's file structure.
tom.package1.packageA is represented on a Windows file system as tom/package1/packageA.
When you ask Eclipse to refactor a package name, you're asking Eclipse to change the name of the file system directory structure.
You can have packages in Eclipse like:
tom.package1.packageA
tom.package2.packageB
tom.package3.packageC
You'll just have different 2nd level file system directories.