Closed vromero closed 6 years ago
I already saw such kind of errors, I'll try to understand how jgitver is launched when used inside IDEA, not sure it is launched as maven core extension as expected.
FWIW it seems to work fine on non-multi-module projects
On the other hand, I have no problems in IDEA for project: https://github.com/McFoggy/GuardEE
On the other hand, I have no problems in IDEA for project: https://github.com/McFoggy/GuardEE
Indeed, its a single module project. The problem seems to occur only in multi-module.
@vromero what do you mean? it is a multi-module wit 2 sub modules: impl
& tck-runner
You are right, my bad. 'm trying to download it and check I'll let you know. My co-workers also had experiences where it does work when the project was already imported into idea before jgirver is added.
Hi @McFoggy I work with @vromero your example multimodule project works because you use mvnw. After removing mvnw and importing the project from the scratch I get the same problem:
Funny enough, vanilla guardee doesn't work for me with no changes:
I need to dig/debug the loading mechanism of IDEA. The error states that the plugin is active but not as a core extension.
One possibility could be perhaps just to log the fact instead of throwing a build failure. I would prefer in such case to be able to detect the usage from within an IDE loading (badly) project metadatas than from normal usage where I would like to keep the error.
As stated in commit, you need a manual action in IDEA to skip jgitver execution
then the import should work
Notice that in this case for Intellij IDEA the project version will be the one in the pom (0 probably).
Manual intervention feels like a deal breaker for us. I tried to automate but of course didn't work as jgitver get initiated before the profiles (as it should be):
<profiles>
<profile>
<id>idea-only</id>
<activation>
<property>
<name>idea.version</name>
</property>
</activation>
<properties>
<jgitver.skip>true</jgitver.skip>
</properties>
</profile>
</profiles>
Sadly I'm not an expert in extensions, any idea if there is any kind of expression language or profiling that we can leverage there to automatically disable execution of jgitver if idea.version
is present?
Manual intervention feels like a deal breaker for us.
Where do you see a manual intervention? It is just a configuration of your IDEA installation.
And if really your developers cannot even modify a setting in their IDEA because you control all by automation, I am sure this settings is part of some IDE config file.
I really appreciate your help but having to change vm options in the IDE seems to manual intervention to me. Have you found the root cause of this issue while idea compiles with his own maven? Maybe there is a env var that we can set from outside the IDE.
Where do you see a manual intervention? It is just a configuration of your IDEA installation.
Hi @McFoggy, please don't missunderstand me, I'm grateful for the help and the software (that is great BTW).
I think we are on the same page on this, the manual intervention is the IDE manual configuration. This requires documentation that developers shall read (and very likely won't read).
Back in the day there was the idea maven plugin, I checked this morning and not its retired so AFAIK there is no way from maven to suggest a VM option to intellij but of course I might be wrong.
I think we can agree that automation is the ideal state to be pursued. Shall we perhaps raise this issue to intellij?
The problem is that IDEA or Eclipse or Netbeans, during loading of projects DO NOT exactly execute the normal build system, maven in our case. They use their own modified versions of those build systems in the best case to extract metadatas from the project descriptors, the poms here. In the worst case their just try to parse the descriptors manually. As jgitver is a core maven extension, ie something really deeply integrated in maven loading mechanism (and not that much used) perhaps IDEA loading does not trigger it in the same way maven is doing.
The parameter I proposed you to use has to be set only ONCE and interfere only with the loading mechanism not the builds. I think it is really something acceptable.
If it is not enough for you then please open an issue on IDEA side.
Sure thing, thanks
@McFoggy apologies for commenting in an closed issue.
I gave it another try using your approach with 1.1.6 and the aforementioned -Djgitver.skip=true
with no luck.
I'm doing the following:
Am I missing something?
I again see it also.
@vromero Please re-test with 1.1.7
once it is visible in central (or look directly in sonatype repo if in hurry).
Will do a bit later today. We are talking to the idea guys here, just in case you want to chime in.
@vromero as I stated before, the test to skip jgitver was made against maven session userproperties ; in IDEA it looks like this is not set and that's why I added a test in latest commit against System properties that were filled. Let's see what they will say.
@McFoggy we spoke with intellij guys and they found the main problem. Everything is explained in the issue that @vromero talked about before. We tested the latest version of the EAP which includes the fix and it works like a charm. If you like you can remove the flag that you added because of this issue. Thanks for your help and time.
P.S.: version can be found here: https://confluence.jetbrains.com/display/IDEADEV/IDEA+2017.3+EAP
Tested version:
IntelliJ IDEA 2017.3.4 EAP (Ultimate Edition)
Build #IU-173.4548.2, built on January 16, 2018
Licensed to MuleSoft / Federico Donnarumma
Subscription is active until April 20, 2018
JRE: 1.8.0_152-release-1024-b11 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.13.2
Thx I'll test it ASAP.
Hope you will be now able to work correctly with jgtiver inside IDEA as you expect.
@fededonna @vromero unfortunately I still have issues with this version if I remove the
-Djgitver.skip=true
flag
I still find that jgitver does load correctly with the embedded maven version of IDEA.
2018-01-18 11:20:33,053 [ 200527] INFO - #org.jetbrains.idea.maven - org.apache.maven.MavenExecutionException: detection of jgitver old setting mechanism
java.lang.RuntimeException: org.apache.maven.MavenExecutionException: detection of jgitver old setting mechanism
at fr.brouillard.oss.jgitver.JGitverUtils.failAsOldMechanism(JGitverUtils.java:216)
at fr.brouillard.oss.jgitver.JGitverExtension.afterProjectsRead(JGitverExtension.java:124)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl.loadExtensions(Maven3ServerEmbedderImpl.java:810)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl.access$400(Maven3ServerEmbedderImpl.java:121)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl$3.run(Maven3ServerEmbedderImpl.java:685)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl.executeWithMavenSession(Maven3ServerEmbedderImpl.java:633)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl.doResolveProject(Maven3ServerEmbedderImpl.java:652)
at org.jetbrains.idea.maven.server.Maven3ServerEmbedderImpl.resolveProject(Maven3ServerEmbedderImpl.java:586)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:346)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: jgitver must now use maven core extensions only
... 25 more
@McFoggy @vromero according to the idea guys the version with the fix has not been released yet. Here is the issue to keep track. It will be RC on the 23rd. https://youtrack.jetbrains.com/issue/IDEA-184983
Ok but I have tested the exact same version as you mentionned (the current EAP one) and it was not correct during my tests.
Yes, my mistake. I still had the flag. As they say in the last comment the version will be 173.4548.5 that is coming out as an RC on the 23rd of January.
@McFoggy @vromero 2017.3.4 RC is out. I tested it several times and jgitver is working. https://confluence.jetbrains.com/display/IDEADEV/IDEA+2017.3+EAP
I'll give it a try. Thx for info.
IntelliJIDEA released with the fix for this issue. https://youtrack.jetbrains.com/issue/IDEA-184983
Thanks @McFoggy and @vromero for your help.
Issue
version:
1.1.5
usage context:
2017.2.4
Problem description:
When using a multi-module maven project in the latest IntelliJ (older versions also tested) that uses jgitver-maven-plugin an error is reported in the Maven tab: "detection of jgitver old setting mechanism". This generates a number of problems for the user as most of the project data cannot be inferred.
The project does work correctly using the command line.
I have created a sample project in order to reproduce it, just follow these steps:
git clone https://github.com/vromero/jgitver-intellij-error.git