Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Maven Java project with custom packaging not imported properly

I don't think standard java configurator will help you much. You really
need something specific to sbt-compiler-maven-plugin. I am not familiar
with Scala, but I would assume existing configurator should work for
your packaging type, or at least can be made work, and this I believe is
a better solution than fooling java configurator. If existing Scala
configurator does not work for you for whatever reason, you will almost
certainly have to implement your own.

Projects that use code generation are particularly prone to endless
workspace build loops unless all builders correctly implement
incremental behaviour. For example, if you have java code generator
'codegen' that is not aware of incremental workspace build, the
following will almost certainly happen on any workspace save

* 'codegen' generates java sources
* java builder detects changes in generated sources and compiles them
** modified .class files trigger secondary incremental build
* 'codegen' regenerates java sources
* java builder detects changes in generated sources and compiles them
... and so on.

--
Regards,
Igor

On 12/6/2013, 5:10, Grzegorz Słowikowski wrote:
Hi Igor

Thanks a lot, you are great.
I've seen your recent Maven releases, so M2E 1.5 is very close. It would
be great
to solve my case before releasing it (as you said).

My notes inside

Regards
Grzegorz

On 2013-12-03 16:06, Igor Fedorenko wrote:
See inline

--
Regards,
Igor

On 12/3/2013, 8:38, Grzegorz Słowikowski wrote:
Thank You Igor

First I want to say, I'm looking for a way to configure everything
inside my Maven plugins (M2E lifecycle mappings files), so there will
be no
need for end users to write mappings in Maven projects.

I would like to avoid writing custom M2E configurators if it will be
possible
to avoid problems with making them available for M2E (I don't know where
and how I would have to deploy them).


FYI, m2e discovery catalog was meant to provide seamless extensions
installation during project import. It proved to be hard to maintain,
so yes, avoid m2e extensions unless you actually need them.
OK

More details below...

On 2013-12-02 13:55, Igor Fedorenko wrote:
Eclipse wiki [1] explains how to setup m2e development environment.
Thanks.

By default java builder is only enabled for projects that use
maven-compiler-plugin with compilerId=javac. If
sbt-compiler-maven-plugin configuration parameters are compatible with
maven-compiler-plugin, you should be able to use m2e standard java
configurator [2]. You will have to write your own configurator if
parameters are different.
My sbt-compiler-maven-plugin is similar to maven-compiler-plugin,
the main differences are:
1) it decides what to compile without need of additional help (from M2E
for example), SBT performs very sophisticated analysis, what sources
changed and what got invalidated because of those changes, it writes
analysis file and use it with next compilation
2) it compiles Java and Scala files

I examined sources of maven-compiler-plugin. Is it being called from
M2E or
only it's configuration is being read and JDT is being called?
Maven-compiler-plugin does not use BuildContext, so I guess it's not
being called by M2E when building project.


m2e does not execute maven-compiler-plugin, it reads compiler
configuration, makes necessary changes to workspace java project
configuration, but all compilation is handled by Eclipse JDT Java
Builder.
This explains, why maven-compiler-plugin executions are required in the
project.
You know, how to translate them to JDT Java builder.
1. M2E knows nothing about my sbt-compiler-maven-plugin even if I'm
trying to make it's
interface as similar as possible to maven-compiler-plugin.
2. I actually does not want M2E to add "javabuilder" to the project. I
want to have source roots
configured and "javanature" added. Why? Because the next step after
importing would be
adding "scalanature" (from Scala IDE plugin).
When I create new Scala project in Eclipse with Scala IDE installed it
looks like:

".project" file:
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
     <name>new_project_scala</name>
     <comment></comment>
     <projects>
     </projects>
     <buildSpec>
         <buildCommand>
             <name>org.scala-ide.sdt.core.scalabuilder</name>
             <arguments>
             </arguments>
         </buildCommand>
     </buildSpec>
     <natures>
         <nature>org.scala-ide.sdt.core.scalanature</nature>
         <nature>org.eclipse.jdt.core.javanature</nature>
     </natures>
</projectDescription>

".classpath" file:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
     <classpathentry kind="src" path="src"/>
     <classpathentry kind="con"
path="org.scala-ide.sdt.launching.SCALA_CONTAINER"/>
     <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
     <classpathentry kind="output" path="bin"/>
</classpath>

There is "javanature" and "scalanature", but no "javabuilder", only
"scalabuilder".
Lack of "javabuilder" does not prevent from adding source roots to
".classpath" file.

Now in M2E Java projects means Java project compiled by
maven-compiler-plugin.
As we see, this is not always true. I must admit, I don't know, what
"javanature" and "scalanature"
mean in reality. What are they responsible for. We can discuss, if Scala
project is Java project
too, but Scala project definitely needs (Java and Scala) source roots,
just like Java project

I've seen, M2E checks maven-compiler-plugin's configuration parameters:
source, target, encoding, includes, excludes, testIncludes, testExcludes.
sbt-compiler has only some of them (includes, excludes, testIncludes,
testExcludes) for now,
but I think they are not so important, they should be supported by
custom configurator if there
would be one. For now there is no custom configurator, so if they are
not interpreted by any of
M2E standard configurators, it's OK for me.

Maven resources plugin on the other hand uses BuildContext (indirectly,
by using org.apache.maven.shared:maven-filtering dependency classes)

Tell me, does M2E call compiler and/or resources plugins mojos or not?


m2e does execute maven-resources-plugin and relies on BuildContext to
make sure workspace and underlying filesystem are kept in sync.

I tried sbt-compiler integration with simple jar projects (no custom
lifecycle,
Java and Scala sources).
First I configured sbt-compiler plugin to execute "compile" and
"testCompile"
mojos and added a code to emit messaged to BuildContext. It worked
quite well, but I wasn't sure whether Java files are not being compiled
twice:
by JDT and by sbt-compiled.
I removed sbt-compiler compilation goals from lifecycle mapping,
installed
Scala IDE and added Scala nature to M2Eclipse projects. Everything
looked even better, so I think this is the right way (not to invoke my
compilation
mojos). Can you confirm?

I don't know much about Scala IDE, but generally, yes, it is better to
use Eclipse native tooling whenever available.


Tell me if I'm wrong, but I think I cannot use
"org.eclipse.m2e.jdt.javaConfigurator"
because it's implementation class AbstractJavaProjectConfigurator checks
"maven-compiler-plugin" and "maven-resources-plugin" plugins with
groupId
"org.apache.maven.plugins". These names are constants and I can only
write
similar configurator for my packaging, not use this one.


You are correct, m2e javaConfigurator does indeed only work for
maven-compiler-plugin, I forgot about that. Although I will likely relax
this limitation before m2e 1.5 is out, this probably won't help any with
Scala IDE integration.
My importing scenario is:
1. import as Maven project
2. add Scala nature
M2E does not need to do anything for Scala integration IMO. The only
thing I need
is adding source roots.
When defining custom packaging in Maven plugin you create
"components.xml" file
describing it
(https://play2-maven-plugin.googlecode.com/svn/trunk/plugin/play2-maven-plugin/src/main/resources/META-INF/plexus/components.xml).
There is:
     <component>
       <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
       <role-hint>play2</role-hint>

<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
       <configuration>
         <type>play2</type>
         <includesDependencies>true</includesDependencies>
         <language>java</language>
         <extension>jar</extension>
         <addedToClasspath>true</addedToClasspath>
       </configuration>
     </component>
section in my plugin. I think "<language>java</language>" declaration is
enough to treat it as Java project (with Java nature,
maybe with Java Builder maybe without).

Do you have any ideas, how to relax current limitations? I would like to
help you with this problem, but I don't know what could I do.

BTW, for now if I want to properly import any of my "play2" test
projects (for example
https://play2-maven-plugin.googlecode.com/svn/trunk/test-projects/play21/java/helloworld)
I have to add:
             <!-- TEMP - for M2Eclipse import only -->
             <plugin>
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-compiler-plugin</artifactId>
                 <version>3.1</version>
                 <configuration>
                     <skipMain>true</skipMain> <!-- skip compile -->
                     <skip>true</skip> <!-- skip testCompile -->
                 </configuration>
                 <executions>
                     <execution>
                         <goals>
                             <goal>compile</goal>
                             <goal>testCompile</goal>
                         </goals>
                     </execution>
                 </executions>
             </plugin>
to pom.xml. This snipped adds absolutely no functionality (plugin added,
but all mojos skipped), but is crucial for M2E.



As explained in wiki [3], most maven plugins require use
BuildContext in
order participate in eclipse incremental and configuration builds. This
is not enforced by m2e, but you are running risk of endless workspace
builds and/or generated files go missing unless all filesystem changes
go through BuildContext.
What exactly can be the reason of endless workspace builds?

If a mojo unconditionally generates its outputs every invocation, this
will trigger execution of other builders every time the mojo is invoked,
which in turn will trigger execution of the mojo again, which will
generate its output and trigger other builders, and so on forever.
I have several source and resource generators in my packaging, but I
don't know
how one of them could trigger another, they generate different
sources/resources
and don't relay on each other. Is my case safe?



[1] http://wiki.eclipse.org/M2E_Development_Environment
[2]
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/lifecycle-mapping-metadata.xml

[3] https://wiki.eclipse.org/M2E_compatible_maven_plugins

--
Regards,
Igor


One more funny thing. My test projects (jar packaging) for
sbt-compiler-maven-plugin
https://sbt-compiler-maven-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta2

work out of the box only because there is no way to remove
maven-compiler-plugin
from the Maven lifecycle.
There is:
              <plugin>
                  <groupId>org.apache.maven.plugins</groupId>
                  <artifactId>maven-compiler-plugin</artifactId>
                  <version>3.1</version>
                  <configuration>
                      <skipMain>true</skipMain> <!-- skip compile -->
                      <skip>true</skip> <!-- skip testCompile -->
                  </configuration>
              </plugin>
configuration in all of them to skip maven-compiler-plugin executions
entirely, but because
maven-compiler-plugin is still present in Maven jar lifecycle, all these
project are being imported
to M2E without problems (in contrast to test projects using "play2"
packaging, not containing
maven-compiler plugin in maven lifecycle at all).

Regards
Grzegorz Slowikowski

On 12/2/2013, 2:38, Grzegorz Słowikowski wrote:
Hi

I'm new to M2Eclipse integration, I'm adding it to my Maven plugins
now.
Some of them define custom packagings and I have problem with one of
them.

My plugin [1] defines custom packaging "play2" [2] producing Java
"jar"
file.
M2Eclipse lifecycle mapping metadata definition file is here [3].

When importing Maven project using "play2" packaging everything
seems to
work: source generators
work, there is nothing in Eclipse workspace log, but after import
there
is only ".project" file
with "maven2Builder" and "maven2Nature". No "javabuilder" and
"javanature" in ".project" file
and no ".classpath" file at all.

Is there possibility to debug M2Eclipse import process?

Current version 1.0.0-alpha6-SNAPSHOT deployed to Nexus Snapshot
repository so you can reproduce my problems.
Try importing of any of test projects [4], for example [5].

I have similar Maven plugin with "play" (without "2" suffix) packaging
[6] and with that plugin everything works as expected
(you can check with any of test projects [7], for example [8]).

[1] http://play2-maven-plugin.googlecode.com/svn/trunk/plugin
[2]
http://play2-maven-plugin.googlecode.com/svn/trunk/plugin/play2-maven-plugin/src/main/resources/META-INF/plexus/components.xml


[3]
http://play2-maven-plugin.googlecode.com/svn/trunk/plugin/play2-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml


[4] http://play2-maven-plugin.googlecode.com/svn/trunk/test-projects/
[5]
http://play2-maven-plugin.googlecode.com/svn/trunk/test-projects/play21/java/helloworld/



[6]
http://maven-play-plugin.googlecode.com/svn/trunk/plugin/play-maven-plugin/


[7] http://maven-play-plugin.googlecode.com/svn/trunk/test-projects/
[8]
http://maven-play-plugin.googlecode.com/svn/trunk/test-projects/findbugs/



Regards
Grzegorz Slowikowski

_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev


_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev



Back to the top