[
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
I would like to return to this thread and write my configurator.
I have a lot of questions, but what would help me most is to know how
can I debug project import/configuration build.
Can you help me?
Regards
Grzegorz
On 2013-12-06 16:18, Igor Fedorenko wrote:
> Don't use java configurator. Even if java configurator could be
> triggered for sbt-compiler-maven-plugin it will not magically learn what
> to do with Scala. Either use existing Scala configurator or write new
> configurator.
>
> --
> Regards,
> Igor
>
> On 12/6/2013, 10:13, Grzegorz Słowikowski wrote:
>> 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
>>>
>>
>> _______________________________________________
>> 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
>
