Thanks very much! Indeed, I was on maven 3.6.1 - reverting to 3.6.0 helped me move forward a lot! In general, where would a potential contributor find out about issues like "doesn't work with maven 3.6.1 or 3.6.2"? Normally when I try to contribute a new project, it's common that I'll bump into a build error on my first build. The first thing I do is put the error into the github search, and almost always an issue comes up which tells me the magic trick, and then I can be productive again.
For SWT, which searchbox should I type into to find out something like this? The email list works great ;-) but I feel bad that I'm dinging so many people for such basic questions. But since I've almost got a working build, I'll keep going! The CI box is running this command: https://ci.eclipse.org/platform/view/Gerrit/job/eclipse.platform.swt-Gerrit/230/flowGraphTable/ mvn -Pbuild-individual-bundles -DforceContextQualifier=zzz -Dnative=gtk.linux.x86_64 -Dcompare-version-with-baselines.skip=true -Dmaven.compiler.failOnWarning=true install When I run this command on a linux box, I get a successful build. Huzzah, thanks!! When I run it on a mac (changing -Dnative to cocoa.macosx.x86_64) , it really struggles with "tycho-snapshots". It downloads a few, then eventually gets [2]. It seems to download them over and over, failing in a different spot each time. By attempting ~20 times (not exaggerating!!!) it eventually ran mostly (but not completely) successfully. When I run it on a windows box (changing -Dnative to win32.win32.x86_64), it still tries to use gtk, and thus fails. [1] Any guesses why windows is using gtk / ways to fix? Any hints for making the mac build more reliable? Thanks very much! I'm collating all this info to put into the README [1] [ERROR] test_syncExecLjava_lang_Runnable_dispose(org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Display) Time elapsed: 0.353 s <<< ERROR! java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: no swt-gtk-4930r3 in java.library.path no swt-gtk in java.library.path Can't load library: C:\Users\ntwigg\Documents\dev\eclipse.platform.swt\tests\org.eclipse.swt.tests\target\.swt\lib\win32\x86_64\swt-gtk-4930r3.dll Can't load library: C:\Users\ntwigg\Documents\dev\eclipse.platform.swt\tests\org.eclipse.swt.tests\target\.swt\lib\win32\x86_64\swt-gtk.dll at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Display.test_syncExecLjava_lang_Runnable_dispose(Test_org_eclipse_swt_widgets_Display.java:1 [2] Caused by: java.net.UnknownHostException: repo.eclipse.org at java.net.InetAddress.getAllByName0 (InetAddress.java:1281) at java.net.InetAddress.getAllByName (InetAddress.java:1193) at java.net.InetAddress.getAllByName (InetAddress.java:1127) at org.apache.maven.wagon.providers.http.httpclient.impl.conn.SystemDefaultDnsResolver.resolve (SystemDefaultDnsResolver.java:45) Any tips for 1) How Ned Twigg Lead Software Architect, DiffPlug LLC 540-336-8043 (cell) 888-513-6870 (fax) 340 S Lemon Ave #3433, Walnut, CA 91789 ᐧ On Fri, Oct 4, 2019 at 1:54 PM Paul Pazderski <paul-ecli...@ppazderski.de> wrote: > And if it was not clear yet. There is no immediate need to build SWT > natives to work on SWT. Most parts are written in Java and you get the > native part from the SWT binaries repository. And to work on SWT Java > part Oomph setup will do all you need. > > Regards, > Paul > > Am 04.10.2019 um 22:47 schrieb Paul Pazderski: > > I have not build SWT on Mac, only Windows and Linux. What you can try is > > to get SWT projects build in Eclipse (best using Oomph as Ed described). > > Once build in Eclipse there should be a library folder in > > eclipse.platform.swt/bundles/org.eclipse.swt/bin with a script to build > > the native parts. As I said, never did it on Mac but that could work > > from my experience. > > > > For CI: > > Maybe the following two links are interesting for you. > > Jobs building natives: > > https://ci.eclipse.org/releng/view/SWT%20Natives/ > > Job building contributions to SWT: > > > https://ci.eclipse.org/platform/view/Gerrit/job/eclipse.platform.swt-Gerrit/ > > > > For building on command line: > > usually it is enough to run > > mvn verify -P build-individual-bundles > > in repository root (less sure for SWT) > > > > Note that both, maven 3.6.1 and 3.6.2 have breaking bugs for building > > Eclipse stuff. > > > > https://issues.apache.org/jira/browse/MNG-6642 > > https://issues.apache.org/jira/browse/MNG-6765 > > > > Regards, > > Paul > > > > > > Am 04.10.2019 um 22:43 schrieb Ned Twigg: > >> Thanks very much, very helpful!! > >> > >>> I think the problem is that the parent pom is often in another Git > >> repository, so it's never quite clear to me how one could actually do a > >> build locally for the platform's projects. > >> > >> I would love the answer to this question, if anyone has it. I'm also > >> very curious to know how CI runs. > >> > >> Ned Twigg > >> Lead Software Architect, DiffPlug LLC > >> 540-336-8043 (cell) > >> 888-513-6870 (fax) > >> 340 S Lemon Ave #3433, Walnut, CA 91789 > >> > >> ᐧ > >> > >> On Fri, Oct 4, 2019 at 1:25 PM Ed Merks <ed.me...@gmail.com > >> <mailto:ed.me...@gmail.com>> wrote: > >> > >> Ned, > >> > >> Comments below. > >> > >> On 04.10.2019 20:24, Ned Twigg wrote: > >>> Thanks for the help, we're off to a good start! One of my goals > >>> is to make sure the bug I encountered is reproduced in the test > >>> suite, and then fixed after the code change. Otherwise it will > >>> just break again. > >>> > >>> The problem with IDE-only is that inevitably there's a test that > >>> somebody was running in their IDE that isn't being tested by CI. > >> I'm not sure that's the case. I think (assume) all the JUnit tests > >> that one can run from within the IDE also run in the CI build (and > >> vice versa). The problem is often that there are no launchers > >> committed so one isn't exactly sure how one should run the tests > >> from within the IDE, but I don't think you should need to do a > >> command line build in order to write and run tests. If my ability > >> to contribute depended on first being able to do a command line > >> build, I would never have been able to contribute anything... > >>> So I wanted to first make sure that I can do the command-line > >>> build, and my next step was to get the IDE stuff going. Here is > >>> how I normally do that when I contribute to something: > >>> > >>> - look in the README > >>> - it points me to https://www.eclipse.org/swt/fixbugs.php, which > >>> doesn't say anything about the command-line build > >>> - a lot of the links on this page are out-of-date, which makes me > >>> question if the instructions are accurate or not > >>> - Tools link points to Eclipse 3.5 > >>> - Javadoc points to Eclipse Luna > >>> - Community has CVS links to the Fox widget port > >>> - Contact Us points to defunct mailing lists > >> Yes, documentation tends to get out of date. :-( > >>> - this makes me not trust this link, so I go to the next link in > >>> the README: > >>> > https://projects.eclipse.org/projects/eclipse.platform.swt/developer > >>> - this link says "This project is archived. Some links on this > >>> page may not work." > >>> - the next link in the README is the defunct > >>> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev > >>> - so next I go to CONTRIBUTING > >>> - which is how I found out about this list > >> That helped at least. :-) > >>> > >>> I appreciate the help on the IDE stuff - I can get it running in > >>> an IDE. But I'm still not able to run the command-line build. > >> > >> The builds are rather complicated. I'm not sure how to run a Maven > >> build. For EMF and for Oomph (my own projects), I have an external > >> launcher configuration committed into the repo that one can kick off > >> a maven build easily from within the IDE. This has not been done > >> for the platform. I think the problem is that the parent pom is > >> often in another Git repository, so it's never quite clear to me how > >> one could actually do a build locally for the platform's projects. > >> Of course someone will point out that it's quite easy, if one knows > >> the right magical (undocumented?) way to do that. > >> > >> I'm sure though that you will generally need to do that in order to > >> run the tests that you'd want to run. You should be able to do that > >> from just what's built in the IDE... > >> > >>> > >>> In my opensource projects, I try to make the repo self-sufficient. > >> Yes, but that's difficult in a project as complex as the platform > >> where there are so many separate Git repositories involved... > >>> External links to wikis and webpages and forums tend to go stale, > >>> so I try to make sure that all the information that anyone needs > >>> to run the build is right there in the repo. If someone wants to > >>> improve the instructions, they don't need to get admin on some > >>> wiki or forum, they can just update the repo. > >> That's also why I believe something like an automated setup is so > >> important, because no human really wants to read a lot of > >> documentation and then have to map that onto a long series of manual > >> steps to hopefully achieve the correct end result. > >>> > >>> As an > >>> example: > https://github.com/diffplug/goomph/blob/master/CONTRIBUTING.md > >>> > >>> So three questions: > >>> > >>> 1) Would this be a welcome contribution? > >> Keep in mind that are 24+ repositories that comprise the Eclipse > >> Platform SDK, so it's actually a lot of work to come up with > >> something consistent and actually useful for each one... > >>> If I update the README and CONTRIBUTING to be self-sufficient, > >>> rather than pointing out to external websites which are difficult > >>> for outside contributors to keep up-to-date? > >> One advantage of wikis is that they can be adapted and contributed > >> to easily as well. But in the end, *all *documentation becomes > >> stale with age, and anything the committers themselves don't use > >> will get stale even faster. > >>> 2a) How to I build at the command line? When I do `mvn > >>> help:describe`, I get > >>> > >>> [FATAL] Non-resolvable parent POM for > >>> eclipse.platform.swt:eclipse.platform.swt:4.14.0-SNAPSHOT: Could > >>> not find artifact > >>> org.eclipse:eclipse-platform-parent:pom:4.14.0-SNAPSHOT and > >>> 'parent.relativePath' points at wrong local POM @ line 16, column > 11 > >>> @ > >>> [ERROR] The build could not read 1 project -> [Help 1] > >>> [ERROR] > >>> [ERROR] The project > >>> eclipse.platform.swt:eclipse.platform.swt:4.14.0-SNAPSHOT > >>> (/Users/ntwigg/Documents/dev/eclipse.platform.swt/pom.xml) has 1 > error > >>> [ERROR] Non-resolvable parent POM for > >>> eclipse.platform.swt:eclipse.platform.swt:4.14.0-SNAPSHOT: Could > >>> not find artifact > >>> org.eclipse:eclipse-platform-parent:pom:4.14.0-SNAPSHOT and > >>> 'parent.relativePath' points at wrong local POM @ line 16, column > >>> 11 -> [ > >>> > >> Hopefully someone else will be able to answer this. This is an > >> example, I believe, where the parent pom comes from a different > >> repositoriy... > >>> 2b) Where can I see what CI is doing? If I want to duplicate a CI > >>> result on my machine, how do I go about that? > >> > >> This is the central index: > >> > >> https://ci.eclipse.org/ > >> > >> But I'm not sure which one is for SWT, and even if you found it, > >> people don't make a habit of making their build configuration > >> read-public, so you can't typically see how the builds are > >> configured. :-( > >> > >> So hopefully someone else can shed light on this theme. > >> > >>> > >>> Ned Twigg > >>> Lead Software Architect, DiffPlug LLC > >>> 540-336-8043 (cell) > >>> 888-513-6870 (fax) > >>> 340 S Lemon Ave #3433, Walnut, CA 91789 > >>> > >>> ᐧ > >>> > >>> On Fri, Oct 4, 2019 at 10:45 AM Ed Merks <ed.me...@gmail.com > >>> <mailto:ed.me...@gmail.com>> wrote: > >>> > >>> Ned, > >>> > >>> If it's an issue of setting up a local development environment > >>> that can be done automatically: > >>> > >>> https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning > >>> > >>> SWT is a bit tricky, with some renaming involved to set up the > >>> classpath in an OS-specific way, but that's handled > >>> automatically by the setup. > >>> > >>> The above will clone way more projects than you really need, > >>> but you can go back after the initial automatic selection, > >>> selectively choose which projects to actually clone; this > >>> particular setup chooses all the Eclipse SDK projects by > >>> default. You would actually only need the SWT project for > >>> your focused purpose, but it's super useful to have clones of > >>> all projects of the Eclipse SDK so that you can contribute > >>> anywhere and change anything. > >>> > >>> Take note of the instructions about getting a Gerrit account > >>> and changing the clone URIs to be Gerrit Read/Write URIs so > >>> that you can commit to Gerrit when you want to contribute > later. > >>> > >>> Regards, > >>> Ed > >>> > >>> > >>> On 04.10.2019 18:35, Ned Twigg wrote: > >>>> Hello! I really like SWT. I like contributing to open > >>>> source, and I have a hard time contributing to SWT. I would > >>>> like to help make it easier to contribute. > >>>> > >>>> I found and documented a simple bug two years ago. > >>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=520488 > >>>> > >>>> Today, Niraj very generously supplied a fix, but he cannot > >>>> test it because he doesn't have a mac. I figured the least I > >>>> could do was help test it, but I cannot get the build to > >>>> work. I tried to follow the README/CONTRIBUTING, but it > >>>> seems that a lot of the info there is stale. > >>>> > >>>> Is there anyone who can help get me setup? I will document > >>>> the process, and update the README / CONTRIBUTING. I also > >>>> plan to run a GitHub mirror with public CI, so that it is > >>>> easier for people like me to at least get started with > >>>> contributing back to SWT. > >>>> > >>>> Ned Twigg > >>>> Lead Software Architect, DiffPlug LLC > >>>> 540-336-8043 (cell) > >>>> 888-513-6870 (fax) > >>>> 340 S Lemon Ave #3433, Walnut, CA 91789 > >>>> ᐧ > >>>> > >>>> _______________________________________________ > >>>> platform-dev mailing list > >>>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > >>>> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >>>> https://www.eclipse.org/mailman/listinfo/platform-dev > >>> _______________________________________________ > >>> platform-dev mailing list > >>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > >>> To change your delivery options, retrieve your password, or > >>> unsubscribe from this list, visit > >>> https://www.eclipse.org/mailman/listinfo/platform-dev > >>> > >>> > >>> _______________________________________________ > >>> platform-dev mailing list > >>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > >>> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >>> https://www.eclipse.org/mailman/listinfo/platform-dev > >> _______________________________________________ > >> platform-dev mailing list > >> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > >> To change your delivery options, retrieve your password, or > >> unsubscribe from this list, visit > >> https://www.eclipse.org/mailman/listinfo/platform-dev > >> > >> > >> > >> _______________________________________________ > >> platform-dev mailing list > >> platform-dev@eclipse.org > >> To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > >> https://www.eclipse.org/mailman/listinfo/platform-dev > >> > > > > > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
