Community
Participate
Working Groups
Checking the project out and building it with Maven does not work. I see that the parent SNAPSHOT cannot be resolved. If the project needs something beyond git clone && mvn clean install I expect this info in the README. Steps to reproduce: rm -Rf ~/m2/repository/org/eclipse/eclipse-platform-parent git clone git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git cd eclipse.jdt.core mvn clean install # Expected: BUILD SUCCESS # Actual: [FATAL] Non-resolvable parent POM for eclipse.jdt.core:eclipse.jdt.core:4.10.0-SNAPSHOT: Could not find artifact org.eclipse:eclipse-platform-parent:pom:4.10.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 15, column 11
(In reply to Peter Palaga from comment #0) > Checking the project out and building it with Maven does not work. I see > that the parent SNAPSHOT cannot be resolved. If the project needs something > beyond git clone && mvn clean install I expect this info in the README. > > Steps to reproduce: > > rm -Rf ~/m2/repository/org/eclipse/eclipse-platform-parent > git clone git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git > cd eclipse.jdt.core > mvn clean install > > # Expected: BUILD SUCCESS > > # Actual: > [FATAL] Non-resolvable parent POM for > eclipse.jdt.core:eclipse.jdt.core:4.10.0-SNAPSHOT: Could not find artifact > org.eclipse:eclipse-platform-parent:pom:4.10.0-SNAPSHOT and > 'parent.relativePath' points at wrong local POM @ line 15, column 11 Most users, contributers etc. should almost never need to build JDT/Core using Maven. Existing pom files are mostly used during production builds (and on gerrit). I would us rather see us add a link to https://wiki.eclipse.org/JDT_Code_Setup_Using_Oomph which fully suffices for developing JDT/Core.
> Most users, contributers etc. should almost never need to build JDT/Core using Maven. This is repo contains code that is interesting outside of Eclipse platform. Once building without Eclipse IDE is possible, the README should contain the instructions. > I would us rather see us add a link to https://wiki.eclipse.org/JDT_Code_Setup_Using_Oomph which fully suffices for developing JDT/Core. Feel free to do it, but it won't solve the current issue.
(In reply to Peter Palaga from comment #2) > > Most users, contributers etc. should almost never need to build JDT/Core using Maven. > > This is repo contains code that is interesting outside of Eclipse platform. Sure, feel free to consume it from Maven Central. > Once building without Eclipse IDE is possible, the README should contain the > instructions. Experience tells me, once potential contributors find instructions concerning maven, they will try it and waste some days until they get it to work, where only a few clicks + 10 min. downloading+building where needed using Eclipse / Oomph. So, what is your use case? Do you want to develop / modify JDT, or just consume it, or s.t. entirely different?
> Sure, feel free to consume it from Maven Central. Nice to learn that is on Maven Central. I really appreciate the info because I have not expected this to be the case. It would perhaps be nice to to add this info to the README too :) This can be done using a shields.io badge that renders nice on Github - see the Maven example on https://shields.io/#/examples/version > Experience tells me, once potential contributors find instructions concerning > maven, they will try it and waste some days until they get it to work Great, sounds like a confirmation that the instructions for building with Maven are really needed ;) > only a few clicks + 10 min. downloading+building where needed using Eclipse / Oomph. As I said, feel free to do it, you'll probably help many people. But I am not asking for it here. > So, what is your use case? Do you want to develop / modify JDT, or just consume it, or s.t. entirely different? I want to check if I can use the JDT Java formatter in a headless tool. As usual with any freshly checked out project I want to see that the code actually works (read: builds on command line).
(In reply to Peter Palaga from comment #4) > > Sure, feel free to consume it from Maven Central. > > Nice to learn that is on Maven Central. I really appreciate the info because > I have not expected this to be the case. See also https://www.eclipsecon.org/europe2018/sessions/eclipse-artifacts-maven-central :) > I want to check if I can use the JDT Java formatter in a headless tool. Have you seen this: https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftasks-231.htm&cp=1_3_10_0 ? As to quickly "testing if it runs" I'm still not sure, maven is a good approach: If you build org.eclipse.jdt.core what you get is a jar file. Then what? It could actually be run - as a batch compiler. To run the formatter, you need to install jdt into a basic Eclipse - and be it a headless platform, because it has dependencies that are supposed to be wired using OSGi. Inside Eclipse we have wizards and launch configurations for all these tasks, which let you run that application with much less hassle. Please don't get me wrong, I don't want to make building JDT/Core harder or imply that this is a difficult thing to begin with. Just I want to avoid that users spent lots of time with a less-then-optimal approach to their goal. The purpose of the maven configuration is mainly for production builds of the entire IDE. That said, here's how our gerrit build invokes maven: $ mvn -U clean verify -Pbuild-individual-bundles -Pbree-libs -Ptest-on-javase-10 The last profile is used to configure tests for a particular JDK, if you're not interested in (long-running) tests, it should be safe to omit that. Let us know how valuable that information is. Unfortunately, I can't see the settings.xml that is used on the server (you may need some repository from repo.eclipse.org), nor do I see all toolchains-related configurations.
> See also https://www.eclipsecon.org/europe2018/sessions/eclipse-artifacts-maven-central Thanks for the effort! Is there a post I could retweet? > To run the formatter, you need to install jdt into a basic Eclipse I am interested in running the formatter outside of OSGi container, on a flat class path of a Maven/Gradle plugin or of an Ant task. I'll file separate issues if I see issues. > here's how our gerrit build invokes maven: > > $ mvn -U clean verify -Pbuild-individual-bundles -Pbree-libs -Ptest-on-javase-10 Thanks. Here is what worked for me and what I'd actually expect in the README. I mean the build passed like this, but I have not looked yet if the build produced something useful. It is quite possible that the last mvn command needs to be run with -Pbuild-individual-bundles -Pbree-libs How to build with Maven ----------------------- Prerequisites: * Java 8+ * Maven 3.5.4+ The root `pom.xml` of JDT Core assumes to find the `pom.xml` of `org.eclipse:eclipse-platform-parent` in the parent folder. So the way where/how you clone JDT Core and Releng Aggregator (which contains `eclipse-platform-parent`) matters. The easiest way to reach the right setup is to clone JDT Core as a git submodule of Releng Aggregator: ```shell # Clone Releng Aggregator git clone http://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git cd eclipse.platform.releng.aggregator # Clone JDT Core as a submodule git submodule update --init eclipse.jdt.core # Install eclipse-sdk-prereqs required by JDT Core cd eclipse.platform.releng.prereqs.sdk mvn clean install # And finally build JDT Core cd ../eclipse.jdt.core mvn clean install -DskipTests # You may try your luck also without -DskipTests ```
When building eclipse.jdt.core with mvn clean install -DskipTests -Pbuild-individual-bundles -Pbree-libs the pom.xml of org.eclipse.jdt.core-3.16.0-SNAPSHOT.pom installed in the Maven local repository has no dependencies declared (unlike the pom.xml in Maven Central [1]). Is there anything I can do to get the dependencies into the installed pom.xml? [1] http://central.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/3.15.0/org.eclipse.jdt.core-3.15.0.pom
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
