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

Hi Igor

You wrote:
"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."

I was curious how you would like to relax this limitation and if it will
meet
my needs. Do you have any idea, how to do it?

For me, in short, the question is, should the M2E import instruction
contain two points:
- import as Maven project,
- add Scala nature
or three:
- import as Maven project,
- add Scala nature,
- manually add source roots, because M2E does not support 'play2'
 packaging (and any other custom packaging without maven-compiler-plugin)

I don't like the last one, but if we agree, you can do nothing with this
problem,
I will accept it for now, stop continuing this thread (spamming list)
and learn
how to properly write custom M2E configurator for my packaging.

Thanks
Grzegorz

On 2013-12-06 15:38, Igor Fedorenko wrote:
> 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
>>
> _______________________________________________
> m2e-dev mailing list
> m2e-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-dev
>



Back to the top