|
Ned,
Comments below.
On 05.10.2019 01:23, Ned Twigg wrote:
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"?
I was aware of this issue because of notes to from monitoring
this mailing this and having seen this email:
https://www.eclipse.org/lists/cross-project-issues-dev/msg17101.html
Of course you'd have not way to noticing this (and it's unlikely
anyone would update any documentation for this hopefully transient
problem).
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.
It's a broader problem with Maven Tycho builds I believe, so
unlikely to find something specifically related to SWT in this
regard. Google is so helpful if you just know the right search
term!
And you shouldn't feel bad. It's good that the committers
understand the barriers to entry for contributors so that we can
help try to lower them.
But since I've almost got a working build, I'll keep
going!
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!!
Given the CI builds run on Linux I would hope and expect that one
generally works.
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.
Networks can be nasty things. :-(
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]
Likely no one really tried to do a full build on Windows so there
could well be some configuration problems. Normally the build runs
on CI and it is able to build all the different native things for
all the supported architectures.
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
Someone with more expertise than me will hopefully have a clue.
[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)
That just seems like a network issue. Certainly that site is
responsive for me at the moment.
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
![]() ᐧ
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.merks@xxxxxxxxx
>> <mailto:ed.merks@xxxxxxxxx>>
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.merks@xxxxxxxxx
>>> <mailto:ed.merks@xxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:platform-dev@xxxxxxxxxxx>
>>>> 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@xxxxxxxxxxx
<mailto:platform-dev@xxxxxxxxxxx>
>>> 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@xxxxxxxxxxx
<mailto:platform-dev@xxxxxxxxxxx>
>>> 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@xxxxxxxxxxx
<mailto:platform-dev@xxxxxxxxxxx>
>> 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@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
|
