I try to integrate scss conversion into our existing maven project.
I tried to add
<plugin>
<groupId>nl.geodienstencentrum.maven</groupId>
<artifactId>sass-maven-plugin</artifactId>
<version>${maven.sass.plugin.version}</version>
<executions>
<execution>
<id>generate-css</id>
<phase>generate-resources</phase>
<goals>
<goal>update-stylesheets</goal>
</goals>
<configuration>
<sassOptions>
<always_update>true</always_update>
</sassOptions>
<includes>
<include>${scssSourceInclude}</include>
</includes>
<sassSourceDirectory>${project.basedir}/src/main/webapp/scss</sassSourceDirectory>
<destination>${project.build.directory}/${project.build.finalName}/css</destination>
<!-- <destination>${project.basedir}/src/main/webapp/css</destination> -->
</configuration>
</execution>
</executions>
</plugin>
When I run mvn clean install command, it compiles correctly for destination which is set to "target" directory:
[INFO] --- sass-maven-plugin:2.12:update-stylesheets (generate-css) # ui.web ---
[INFO] Checked 1 files for d:\work\git\repository\project\src\main\webapp\scss
[INFO] Checked 0 files for d:\work\git\repository\project\target\ui.web\css
[INFO] Compiling Sass templates
[INFO] No resource element was specified, using short configuration.
[INFO] Queueing Sass template for compile: d:\work\git\repository\project/src/main/webapp/scss => d:\work\git\repository\project/target/ui.web/css
...
In case of using second (commented) destination it skips scss compilation:
[INFO] --- sass-maven-plugin:2.12:update-stylesheets (generate-css) # ui.web ---
[INFO] Checked 1 files for d:\work\git\repository\project\src\main\webapp\scss
[INFO] Checked 959 files for d:\work\git\repository\project\src\main\webapp\css
[INFO] Skip compiling Sass templates, no changes.
The only difference is that I need generated css files in src directories due to further processing (minification, concatenation, adding licence header, etc.)
Dir structure:
src
|-main
|-webapp
|-scss
|- common.scss
|- app.scss
|- admin
|- admin.scss
|-css
Can somebody explain to me why the files are not processed into src directories? Is there some missing configuration which I should apply?
I think your problem would be solved by upgrading version 2.22 or later. Here's why:
The console output of the build with <destination>${project.basedir}/src/main/webapp/css</destination> shows that you already have 959 files in the destination directory. Given that you have only a single file in src/main/webapp/scss I'm assuming that most of the 959 files in src/main/webapp/css are normal, non-generated CSS files and that you intend to add those generated by the plugin.
Looking at the source of the plugin, in versions prior to 2.22, the criteria for building given that files exist in both source and destination directories is that the source directory tree has a file younger than any of the files in the destination directory. See UpdateStylesheetsMojo#buildRequired() for the 2.12 implementation. Note that the plugin does not compare source and destination files by name, it only compares "extreme" timestamps. I suspect that the build that skips compilation finds no file in src/main/webapp/scss that are younger than all files in src/main/webapp/css. You could test my hypothesis by modifying one of the .scss files before building. Issue #136: Wrong "build required" analysis when source and destination are the same describes a very similar problem. This is solved by pull request #137:
add css filter at destination when checking buildrequired which is part of version 2.22. This should make your build actually compile .scss files even in the face of newer .css files in the destination directory.
Stepping back a bit, I would advise against modifying src/ during the build. As stated in Introduction to the Standard Directory Layout
The src directory contains all of the source material for building the project [...]
whereas
The target directory is used to house all output of the build.
Behavior is built around this convention. For example mvn clean removes target/ (or more generally ${project.build.directory}). It makes no attempt at removing files generated within src/. Looking at a developer reply on the issue mentioned above it's pretty clear that the developers of the plugin share this sentiment:
Why would anyone want to mix source code and compiled code at all?
Considering this convention, I would recommend you move the .scss files to src/main/sass (the default value of sassSourceDirectory) and let the plugin output .css files to e.g. ${project.build.directory}/generated-css-resources. Then let the plugins handling minification, concatenation and license header operate on this directory as well as src/main/webapp/css. If they don't support this with configuration, you can still likely achieve this with two executions of the plugins, one for each directory. An alternative is to aggregate the generated and non-generated .css files in a directory ${project.build.directory}/aggregated-css with the help of Maven Resources Plugin's copy-resources goal, making sure the generated come first, to avoid the initial problem, and use this directory as input to further processing. I'm sure there are other ways to solve this problem as well.
I am not sure about the solution, but I tried the workaround mentioned in this post https://github.com/jruby/jruby/issues/2498 and it worked for me.
Basically downgrade the sass-maven-plugin version to 2.0 and it should work.
Related
I am new to ASCIIDOC and just wanted to know WHERE the following problem comes from.
Setup:
Intellij with the neweset ASCIIDOC-Plugin
neweset asciidoctor-maven-plugin with preserveDirectories = true
I organized my asciidocs like this:
footer.adoc
header.adoc
index.adoc
subfolder
index.adoc
generated-docs looks like this:
footer.html
header.html
index.html
subfolder
index.html
Now, if I want the subfolder/index.html to include header & footer too, I thought I need to write include::../header.adoc[] into the adoc-file which is no problem for the Intellij-Plugin. But in the generated html you will find following error:
<p>Unresolved directive in index.adoc - include::../header.adoc[]</p>
So when I write the following into the adoc-file: include::header.adoc[] the generated html is happy but the Intellij ASCIIDOC plugin shows an error:
Unresolved directive in <stdin> - include::header.adoc[]
I am just wondering if this is a bug for the Intellij Plugin-Team or for the Maven-Plugin-Team. Or maybe someone has a workaround this problem?
And a little bonus question: Is it possible to configure the maven plugin to not generate header-/footer.htmls since they are already included into the actual htmls?
I have no experience with the maven plugin, but I do have lots of experience with AsciiDoc, the IntelliJ Plugin and the Gradle plugin.
The IntelliJ Plugin behaviour is correct. When you convert /subfolder/index.adoc, the includes are resolved relative to this file, so the include include::../header.adoc is correct.
You describe that you don't specify which file to render for the maven plugin (header.adoc is converted). This might be the problem with the maven plugin:
You just specify the source path and all documents are rendered relative to this source path and hence the /subfolder/index.adoc has the wrong source path.
With the Gradle plugin, you cann specify all documents to be converted. This would also avoid getting header.adoc converted. From the maven plugin docs I see that you can specify only a single file.
With this in mind, I would suggest to change your file structure in such a way that you have all the files to be converted in one folder. You can then specify this folder and the other files should not be converted. This also shoul dresolve your problem with the relative path name:
/src/docs/
|
+-common/
| |
| +-header.adoc
| +-footer.adoc
+-chapters/
+-main/
|
+-index1.adoc
+-index2.adoc
I know this is late, the answer is found in the documentation in the restdoc manual from Spring.io in the "Using the Snippets" section of https://spring.io/guides/gs/testing-restdocs/ There is some mention of this in the sample gradle project
The maven plugin configuration should be something like this:
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<version>1.5.8</version>
<executions>
<execution>
<id>output-html</id>
<phase>prepare-package</phase>
<goals>
<goal>process-asciidoc</goal>
</goals>
<configuration>
<sourceHighlighter>coderay</sourceHighlighter>
<backend>html</backend>
<attributes>
<toc/>
<linkcss>false</linkcss>
<snippets>
${project.build.directory}/generated-snippets
</snippets>
</attributes>
</configuration>
</execution>
</executions>
</plugin>
I'm following Maven's Standard Directory Layout for my project.
Is there a preferred directory to put my checkstyle.xml file? I've seen it on at least 3 possible locations:
src/main/resources/checkstyle.xml
src/main/checkstyle/checkstyle.xml - Example: Joda-Time
src/checkstyle/checkstyle.xml - Example: Spring Boot
Since this is mostly a file for developers, the first option gives me doubts. Would it make sense to include checkstyle.xml into the JAR file?
Thanks,
Fede
Putting checkstyle.xml in src directory doesn't really make sense, as it is not part of source code.
The most common convention I've observed in my projects is putting it into config/checkstyle/checkstyle.xml. Thousands of projects use it (filename:checkstyle.xml path:config/checkstyle) and Gradle uses this location by default.
Referring to https://stackoverflow.com/a/18585688/3639934 I've put the following in my POM to exclude generated source files, which exist in target/generated-sources/x/y/z.
</properties>
<sonar.exclusions>file:**/generated-sources/**</sonar.exclusions>
</properties>
In my logfile I see no files excluded, however there are files in my project's directory under target/generated-sources/x/y/z.
[10:14:39.346] Source paths: pom.xml, src/main/java
[10:14:39.346] Test paths: src/test/java
[10:14:39.347] Binary dirs: target/classes
[10:14:39.348] Source encoding: UTF-8, default locale: de_DE
[10:14:39.348] Index files
[10:14:39.363] Excluded sources:
[10:14:39.363] file:**/generated-sources/**
[10:14:39.484] 47 files indexed
[10:14:39.487] 0 files ignored because of inclusion/exclusion patterns
I'm using SQ 5.1.1, Maven 3.2.3, Java 8.
Can anyone enlighten me please?
Ok, the log fooled me. The generated-sources are no part of the analysis right from the start, so it did not show up any excluded files.
When I change the exclusion pattern to match a file from say "src/main/java" it logs the expected exclusion (and does not analyze the file.)
I want to run Sonar Runner only on some selected files only. I'm using SonarRunner Ant.
My project directory structure is :
MyProject
|
|-----src
|-----java
|-----A
|-----B
| |---<files>.java
|
|-----C
| |---<files>.java
|
|-----hello.java
Now I want to run Sonar Runner only on hello.java file.
sonar.sources=../../../MyProject/src // takes the source directory
sonar.sources=../../../MyProject/src/java/A/hello.java didn't work
sonar.exclusions=**/**/*.java // excludes all java files
// now I want to include only hello.java file
// didn't find any parameter for inclusion, but tried the following
sonar.inclusions=hello.java // didn't work
sonar.inclusions=java/A/hello.java // didn't work
Referred this article for analysis parameters.
One solution which crossed my mind is : exclusion of all the files but the required ones.
But here the structure is just a small part. In real I have more than 250 java files, and want to generate report for, say, 10 files only. Then, by this approach, excluding 240+ files doesn't look a good idea.
Is there anyway to generate sonar report on selected files, other than the mentioned approach?
If you're looking for specific files, you might try the same syntax as is listed to explicitly exclude files (Narrowing the Focus - at the bottom)
#Absolute Path
To define an absolute path, start the pattern with "file:"
#Exclude all the *.cs files included in /path_to_my_project/myProject/src/generated and its subdirectories
sonar.exclusions=file:/path_to_my_project/myProject/src/generated/**/*.cs
#Exclude all the java classes contained in a src/generated/java directory and its subdirectories
sonar.exclusions=file:**/src/generated/java/**/*.java
The my.properties file from my source (src/main/resources) folder keepa getting picked up and used when I try to run my JerseyTest ... whereas I would like the properties files in the test folder (src/test/resources) to be utilized.
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
try {
myProperties.load(classLoader.getResourceAsStream("my.properties"));
}
How can I configure this in Maven?
I'm using:
maven-compiler-plugin version 2.1
jersey-test-framework-grizzly2 version 1.13
UPDATE (Resolved based on accepted answer):
I noticed the text skip non existing resourceDirectory:
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) # xxx ---
[WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /xxx/xxx/xxx/xxx/src/test/resources
Turns out that I had misspelled resources, after fixing it, everything works as outlined in the accepted answer.
While I was wasting my time looking for workarounds, I did find some interesting links for configuring properties files based on profiles:
How can I change a .properties file in maven depending on my profile?
http://maven.apache.org/guides/mini/guide-building-for-different-environments.html
When running something from the src/test/java folder, the default behavior is:
It will pick up the files in src/main/resources;
Except when there is a file with the same name in src/test/resources.
So basically it will "overwrite" the content of src/main/resources with the content of src/test/resources:
If you got a file in both folders, the one in src/test/resources will prevail.
If you got a file only in src/main/resources, it will be used.
If you got a file only in src/test/resources, it will be used.