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

Have you looked at m2eclipse-scala?
https://www.assembla.com/wiki/show/scala-ide/with_m2eclipse

Le 26 mars 2014 11:58, "Grzegorz Słowikowski" <gslowikowski@xxxxxxxxx> a écrit :
Hi

Thank you. Debugging m2e sources works perfectly.
>From my first tests it looks I have to implement
MyPackagingLifecycleMapping besed on JarLifecycleMapping, right?
I would like to add Scala nature to Eclipse project if Scala plugin
(Scala IDE) is installed, otherwise Java nature
(and probably emit some kind of info/warning message).
How should I check Scala plugin existence?

Regards
Grzegorz

On 2014-03-25 12:32, Igor Fedorenko wrote:
> This is really a PDE-users question, and there is several ways to do it,
> but to give you couple of pointers
>
> If you only want to step through m2e sources in debugger
> 1 install m2e "Extensions Development Support" feature as explained in
>   [1]
> 2 Import org.eclipse.m2e.core using "Plugins and Fragments" import
>   wizard as binary project with linked content
> 3 Run as eclipse application
>
>
> If you want to be able to change m2e sources, instead of steps 1 and 2,
> follow m2e development environment setup explained in [2].
>
> [1] https://wiki.eclipse.org/M2E_extension_development_environment
> [2] https://wiki.eclipse.org/M2E_Development_Environment
>
> --
> Regards,
> Igor
>
> On 2014-03-25, 5:25, Grzegorz Słowikowski wrote:
>> 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
>>>
>>
>> _______________________________________________
>> 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