-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Quick-Fix to enable execution if not connector is found #1190
Comments
Yes that would be good. 👍🏽 I especially like the processing-instruction based mappings because they are far less verbose and more focused. |
I think "incremental" is even the same as "full" this is a bit confusing and eclipse itself actually has a clean build option so actually it would be good to have:
By the way is there any configuration / code reference on this part of m2e? I haven't found one just the usual lifecyclemapping references, so maybe we can have at least a small wiki page describing this. |
It is indeed not very clear. There is a release note from long ago: That doc tells something different than I thought would happen if one only has Nevertheless I think it can be good to have an execution only on full builds for things that are too heavy weight to execute on incremental, but should happen more often than only on configuration/initialization. E.g. build some documentation. If possible we could add some details in the view, which pops up when you hover over elements in the pom-editor, that describes the processing-instruction. |
I'd like to second using the processing-instructions. Is this issue sufficient to tackle it, or does it need a separate issue to request changing the |
@dstango yes this issue can / should be used for this and using processing instructions seems most "lightweight" if added to the pom. |
@laeubi sounds good. It also prevents the warning maven usually prints because of the non-existent lifecyle-mapping plugin, which has never been fixed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=367870 Actually I think it would be great to have an additional quick-fix in the pom-editor to transform existing lifecycle-mapping-entries into the appropriate processing-instructions. |
@dstango dreams can come true with just opening a PR :-D |
hehe ... ;-) I contributed last year a little something to the eclipse platform, but when everything moved from gerrit to github I got lost on the way... so I guess I'd need to start all over with a current setup. |
@laeubi thanks, I'll check it out |
@laeubi so I set it up (yet skipped RCPTT for the moment, hope that's okay), and tried m2e-core--build, resulting in: Where can I go from here? PS: I tried to change the version of org.eclipse.m2e.archetype.common/pom.xml to 3.2.104-SNAPSHOT, which resulted in my build running longer, but ending up in a similar error message for some other pom ... so this seems to be like rabbit hole to me ... ;-) |
@dstango in the log there should be a table mentioning why a version change is suggested, can you take a look here and maybe provide the file in question as a zipped item here? If you change the version in |
@laeubi thatnks, here's the message table:
here's the zipped jar file: If there were a change in the A little above the table there are some warnings - don't know if they are of interest:
Regarding:
I only tried to change the version in the pom.xml - can't find it anywhere else. Where exactly else should I look? I only found MANIFEST.MF-entries with version ranges, that seemed to match. I found one reference to org.eclipse.m2e.archetype.common, though and changed that to 3.2.104-SNAPSHOT. The I run into the next issue with a new table:
Of course I could try to manually tweak with these versions ad infinitum, but I wonder if I'm doing something basic wrong here, as I somehow expected cloning the master branch should result in a compilable build ... ;-) Next thing I'm gonna try is simply going back in git to some released version like 2.2.1 and see if that's buildable. |
We have some issues in the baseline checks regarding windows line endings recently, I'll check that! |
@laeubi thank you! And sorry for hijacking this issue with my build issues ... |
@dstango no problem, but I would need your local files (about.html & META-INF/sisu/javax.inject.Named) as a zip to better understand the issue not the jar file :-) |
I reverted to the original versions and this is the whole folder of org.eclipse.m2e.archetype.common: org.eclipse.m2e.archetype.common.zip Can't find the META-INF/sisu/javax.inject.Named though (probably will only show up if I fiddle with the versions first and do another build?!?) |
Yes it should be generated during the build. |
As you mentioned line endings I tried to re-clone the repository with autocrlf=false:
... but that didn't help :-(. So I went back to a manual change of that version 3.8.701-SNAPSHOT -> 3.8.702-SNAPSHOT in *.archetype.common, to get to sisu's name ;-). So here's the zipped target-directory (I removed some jars, as github complained the file being too big) to give you some context around: |
BTW: Wikipedia has something to tell about sisu -- https://en.wikipedia.org/wiki/Sisu:
I don't know why this somehow seems to fit quite well :-P ... |
This should hopefully be fixed by this PR: So we just need to be patient until it is merged and a new snapshot is there (usually about 3 hrs ...) |
That would be great. It would allow to make changes like apache/mina-sshd#337 automatically. Thinking about that. Maybe we should add another m2e-processing instruction that can be placed at top level of a project pom that specifies the default execution behavior in that case? This would simplify the case were non default behavior is wanted.
AFAICT there is not much more relevant possible, but it would be good to verify this when working on that feature. If you indeed fine something, we could also consider to enhance the processing-instructions. |
thank you! I'll try again later! :-) |
@laeubi looks like the fix might be blocked: I tried a rebuild with update of dependencies, and run into the same issue |
It is now merged, but will take some time unless a new snapshot build is available: |
ah, cool. Thanks! |
the new snapshot build seems to be available, and the build progressed some more.
Do you need any more zipped files? Or are the samples sufficient to probably add some more filenames/extensions to |
I guess we might run into some more surprises, considering the number of bundles left:
Please let me know if I can support in decrease the number of roundtrips necessary to catch the variations, if I can do that easily. |
I'll try to look into those as well, for the class file changes, can you tell what java version+vendor you used for compilation? Usually its better to start "from the top" even though its a bit slower it prevents from getting some false positives that are a result of the previous failure. |
thanks. I think this should give you all information:
I can try some other version, if you want me to. Just tell me which. |
Thanks I'll try to investigate on this and let you know when you can retry the build. This reminds me that @HannesWell also wanted to enable a windows build, if it becomes to complicated to get win/linux equal we can even think about disabling the baseline check for windows all together ... but first let us see how far we can get. |
@HannesWell can you tell what these |
@laeubi thank you!!! |
That's right. I started this in #1163, where you can also see the issues with building on windows (not only the baseline but also the GH runners themself).
I believe that the entire Regarding the ecore and genmodel files, that depends. If they are registered in an extension so that downstream consumers can use that to generate models based on that model, then yes they have to be in the binary artifact. And least for the genmodel in m2e.model.edit I see such registration. And according to the build.properties only the genmodel is binary included. |
If it is inside a source folder it gets included regardless of bin includes. |
Next round of optimization / aliasing: for the class-changes I have no good explanation yet, but just in case its the only change left then I think we can just increase the minor version here .... |
I just checked and get the same baseline problem under Linux and with the current source of m2e, so something seem to have changed in the compilation that results in different bytecode here :-\ |
@HannesWell I now have locally disabled the baseline-mojo, but the p2-plugin complains as well:
|
@dstango unless we have sorted this out I would suggest to edit
part from it. |
@laeubi Thank you! After your additional tycho-changes for me only the class files are left. So I set the baseline-check to skip=true, and now the build works. I ran into some issue as maven wanted to spawn a subprocess with java 11 that failed, but that was due to my JAVA_HOME setting. (I guess it would be nice to have a variable to reference the JAVA_HOME of the currently used Runtime JRE in a launcher btw ... this way the launcher could be configured more self-contained, independent from the user's environment variables. Or did I miss that variable?) I also noticed that the launcher |
For dev-time you usually can skip the tests first and if you are quite happy with your change and at best want to enhance the existing ones run them individually. The CI will then run all tests. |
The classes issue should now be fixed! |
@laeubi thanks! :-) I guess it takes the usual 3 hours to be available?!? Regarding "if you are quite happy with your change" I'm a little lost, how I can do some first manual exploratory tests ... I tried "Run As -> Eclipse Application" on some of the many projects, but I never seem to be able to pick the right one. |
It should already be in place if you rebase your code with the master.
The best is to have a little reproducer project that shows your specific issue. This can later then be transformed into an test for example here: https://github.com/eclipse-m2e/m2e-core/tree/master/org.eclipse.m2e.core.tests |
ah, this time it's not a change in tycho ... thanks! The build continues and has something new to offer:
Maybe my question wasn't clear: Yes, I want to do something with a reproducer project -- that was my intention. My problem is: I'd like to start Eclipse and then import my reproducer-project, but I fail with that:
When trying to import an existing Maven-Project I get this: Or do I have to use another Eclipse-Installation and update the m2e-Installation from my own build? I guess I can figure out how to do that, but it feels like there must be an easier way ... ;-) |
Currently if a mapping is missing, the user is presented with the following options:
This only let the user find a connector or disable execution, but actually the user probably want to configure it in a way to execute the mapping using
<?m2e execute onConfiguration?>
(or incremental) as described here #1013 (comment))The text was updated successfully, but these errors were encountered: