exclude src/main/java from compiling with maven-compiler-plugin - java

Is anybody known how to remove a Source roots from maven-compiler-plugin ?
[DEBUG] Source roots:
[DEBUG] C:\Workspace\Dev01\Internet_Login\src\main\java
[DEBUG] C:\Workspace\Dev01\Internet_Login\target\generated-sources\delombok
Because I generate source with lombok-maven-plugin from C:\Workspace\Dev01\Internet_Login\src\main\java but the maven-compiler-plugin use both Source roots and i get a compilation error.
After compiling, I use Aspectj so I need to do that this way, 'cause Lombok and Aspectj are "incompatible".
Is anybody got a solution.
EDIT :
I've got a solution. Just define the sourceDirectory in build and the compiler gonna use this directory.
<build>
<sourceDirectory>${project.build.directory}/generated-sources/delombok</sourceDirectory>
...
</build>
Thx

did you try with excludes ?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<excludes>
<exclude>src/main/java/</exclude>
</excludes>
</configuration>
</plugin>

As Chrylis suggested, you ought to place any classes with Lombok annotations into src/main/lombok when using that plugin. This is clearly documented on its usage page.
There is also a sample project where you can see how plain Java classes without Lombok annotations are placed in src/main/java and the Lombok targets in src/main/lombok.
Just follow the instructions and you should be fine with regard to Maven Compiler plugin. As for AspectJ, it depends on how you want to weave your aspects (compile time, binary weaving, load time) and whether the aspects reside in the same or another module.

Related

Syntax for excluding deprecated directories with Maven

I have a few directories in my Java project that hold deprecated code: com.company.deprecated and com.partner.company.deprecated. I want to exclude everything in these two "deprecated" directories from Maven compilation, regardless of content or directory structure inside them, so I have created a build tag like this at the very end of my POM:
<!-- Exclude directories that hold deprecated code -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/com/company/deprecated</exclude>
<exclude>**/com/partner/company/deprecated</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
This POM handles a module inside a larger project, but the deprecated code isn't used anywhere else inside other modules, so I don't think there are any conflict issues going on with other POMs. I have tried putting the "build" element at the end of either the specific module POM or the project POM, and get the same compilation errors each time.
As far as I can tell, this should exclude the deprecated directories from my Maven build, but I keep getting compilation errors in files within the "deprecated" directories. I have tried the double asterisk syntax above, absolute paths, and wildcards after "deprecated" but nothing seems to work. I've gone through StackOverflow and haven't found anything exactly like what I'm trying to do, although I am still relatively new to Maven so it is very possible there is something I'm just being dense about.
Can anyone please help me with the proper syntax (or perhaps a different plugin?) for this issue? Thank you!

Generate javadoc for test classes of Maven project in Netbeans

I think that the title is pretty self explanatory, how can I achieve that? By default Maven's javadoc plugin generates documentation only for "normal" classes.
You can set additional source paths for the maven-javadoc-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<sourcepath>${basedir}/src/main/java;${basedir}/src/test/java</sourcepath>
</configuration>
</plugin>
You may also want to tweak other javadoc:javadoc goal settings. You get set the complete list of options at its official site.
I've managed to solve my problem. To generate javadoc of test packages you have to go to properties of Maven project->Actions->Generate Javadoc and there add the goal: javadoc:test-javadoc.

Maven compile does not create class files

I have a 3 module maven project with parent pom. From parent when I run a maven clean-compile-test. It fails at test phase and gives tons of compilation errors saying "symbol not found" for my local classes.
I discovered using IntelliJ ide if I use the "Make Project" button before I run a maven test, then maven test works!
Edit: Now I figured out that probelem is maven compile does not create class files in target folder for some reason this is my maven compiler plugin configuration in parent pom file:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<excludes>
<exclude>**/*.*</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
Any ideas?
One more thing.
Look in pom.xml, tag <packaging>. If it sets in pom, Maven shouldn`t create class-files for you. Change it for appropriate package - jar, war ...
Maven doesn't care about missing symbols in the package phase; missing symbols will only be reported during the compile phase (= when the Java compiler is run by Maven).
To find out why it can't find the symbols, you need to examine one of the errors. Look into the folder target and check if the missing class exists in there (at the right place).
mvn clean deletes this folder but mvn compile should put new files in there.
If you can't see anything obvious, then save a list of all the files in the target folder somewhere. Then build the project in IDEA. Again create a list of all files.
Sort both lists and then compare them. That might give you an idea what is wrong. My guess is that you configured Maven in an odd way (moving source folders or target folders).
EDIT The configuration
<excludes>
<exclude>**/*.*</exclude>
</excludes>
tells Maven "ignore all source files" which is equivalent to "don't do anything". Remove this and try again.

Adding folders in maven project

let us say I have a standard maven project with the standard four Directories
src/main/java
src/main/resources
src/test/java
src/test/resources
Now let us suppose, I create a subdirectory named "clojure" under "src/main".
Are then the source files under "src/main/clojure" automatically compiled when a build is run or do I somehow have to tell to maven, via configuration of some plugin (e.g. build-helper-maven-plugin), that it also has to compile the sources under "src/main/clojure"?
In others words, does the creation of any folder that is not ".../java" or ".../resources" require an explicit configuration in the pom.xml so that the sources there are taken into account by maven??
Any help would be appreciated.
Regards,
Horace
A Maven project is usually built with a single compiler, which looks for all its source files in those folders known as source folders to Maven. Depending on the project, such source folders may be added automatically, e.g. src/main/java. If a different compiler is used, additional folders may automatically be added, e.g. src/main/groovy.
Sometimes Maven integrations in IDEs (like Eclipse or IntelliJ) do not pick up folders for non-Java projects, even though the correct Maven plugins are in the POM, say e.g. for building a Groovy project.
So even though a build on the command line may run nicely with files in src/main/groovy, the folder may not be detected as a source folder when importing the project in an IDE. In such cases you may have to add the additional source folders, e.g.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Yes, maven needs to "know" what those directories mean, though a clojure build plugin may use that directory by convention - see for example: https://github.com/talios/clojure-maven-plugin
Apache maven has a Standard Directory Layout which it understands out of the box.
To make maven understand any other structure than the above, you'll have to override these settings in pom.xml.
Look at this section of POM reference.

Is it necessary to have .java files in /src/main/java when compiling with maven?

I tried to convert a project to a maven one... it has its .java files in other location than /src/main/java , when i run maven install, all the files (.hbm , .xml) except those .class occurs in my jar.
This is build part from pom.xml :
<build>
<resources>
<resource>
<directory>${basedir}/src</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<fork>true</fork>
<compilerVersion>1.5</compilerVersion>
<compilerArguments>
<encoding>UTF-8</encoding>
</compilerArguments>
</configuration>
</plugin>
</plugins>
</build>
Using the above code, .class files are missing from my jar... and no error messages are displayed on console, is it necessary to move them to /src/main/java package structure ?
Also, what could be the reason for this behavior , some missing dependencies ?
I did a change moving them to , src/main/java and i got some exceptions on console , but i am still confused if i "must" add them to this "src/main/java" structure...
Please give me an idea about this...
Thanks
You can configure the source directory to be the same as the resources like this:
<build>
<sourceDirectory>${basedir}/src</sourceDirectory>
<resources>
<resource>
<directory>${basedir}/src</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
</build>
It not strictly necessary - its configurable - but Maven comes with a standardized project layout and it is highly recommended to embrace it, like others Maven conventions (don't fight against Maven, adopt it).
I understood that you are migrating from Ant to Maven but you are IMO not on the right path, bending Maven to make it fit in your existing project structure/workflow is just not the recommended approach:
Maven strongly suggests using its conventions (over configuration) to ease things. Not doing so makes things more complicated and generate useless configuration overhead.
When deviating from the defaults, you're kinda on your own.
Not using defaults might result in bad surprises, some (poorly) implemented plugins might be using hard-coded paths (like src/main/java, target/classes, etc) and won't like changing defaults.
etc, etc, etc.
The recommended way would be to transform your existing structure into a maven compatible modular structure and to adopt the standard Maven layout.
Adopting Maven standards and conventions will just make your Maven life easier in the long run and you get a standardized structure, which Maven is much about.
I think enough people wrote similar advices so I won't insist more. But you should listen to these advices (and not insist trying to make Maven fit in your existing structure), especially since you're new to Maven. From my point of view, you're not migrating from Ant to Maven, you're trying to migrate Maven to an Ant build.
See also
How to convert from Ant to Maven in 5 minutes
Convert Ant Projects into Maven Safely in Five Phases
Have a look at the Super POM. That is the place you get the 'convention' from. You might have to change some settings in your project POM if you have a differnet project layout but it is no good advice as mentioned here before.
By far the easiest solution (if possible in your circumstances) is to move the code to /src/main/java, since that is where maven expects it. It that is not possible, you at least need to tell maven where to find the sources. From your POM I don't see anywhere where you did that.
If you want to use Maven, the path of least resistance is adhering to the Maven conventions. Surely you can have a different source path, but it is definitely more complicated (it seems that the only way is to pass the source directory as a compiler argument), and what do you gain? I believe moving your source directory is much easier.

Categories

Resources