| Ah okay, understood. That’s probably easier (and quicker for me to see results) than getting a local full build running. I’ll have a look at the page.
Many thanks, John Normally you test your change by running an so called inner eclipse instance from within your workspace. No external build needed!
Tom
Von meinem iPhone gesendet Hi Tom,
Thanks for the info. I guess I could just submit patches and wait for the build infrastructure to deliver me a build, but I’m not confident enough in my abilities to understand the infrastructure and git (my Java’s fine, I think ;) to simply fire a patch off and hope for the best. Hopefully in the future I’ll get to the same place you guys are in :)
Thanks again! John Although having a local build running is a good thing in general most of us don't have one put test our patches against the projects unittest suite and then push to gerrit which for many project runs a build and the unit tests.
Tom
Von meinem iPhone gesendet Hi David, Thanh,
Yes, that failing hudson build log is exactly the same as my own. I did delete my local maven repo, as David suggested, but got the same error. Thankfully, I’m back home on my own VDSL now, so pulling deps didn’t take long :)
Actually what I’ve done so far is to clone the aggregator, which I guess is having the same effect (newest aggregator but old submodules), like this:
To be honest I’m not even sure what my git workflow is supposed to be at the moment - I’m still figuring that (and git) out. I would have thought cloning the aggregator would get me the HEADs of the submodules, but I guess not? The aggregator points somehow to a specific revision of its submodules?
I’ll try to pull the heads of the submodules just to see if I can get it building. If I actually generate a fix, I still need to figure out how to submit that (patch? against the aggregated I-build? or head?).
Should all else fail, I’ll just hang on until Tuesday midday ET (I’m in CEST=UTC+2, so I guess Tuesday evening) and rebase from the aggregator head.
Sorry for all the questions! It’s a learning curve ;)
Thanks both, -John
We have a nightly build [1] that runs
the CBI build the way someone following the wiki page would run
it. At the moment it's failing with org.eclipse.license issue. I'm
guessing either it's not fully resolved or perhaps just needs to
wait until the script that updates the submodules to run. To me
this sounds like a temporary issue that will be resolved soon.
Thanh
[1]
https://hudson.eclipse.org/platform/job/eclipse-aggregator-master/248/console
On 21/04/14 02:19 AM, David M Williams wrote:
The only thing I can
think of is an issue
with your "local maven repo" (which stores some "pre-reqs",
etc.) and not sure why, but sometimes I have noticed that
cleaning (i.e.
deleting) the local maven repo makes everything work, since then
it does
get the "freshest" version of everything.
Unless you specify otherwise, the
"local
maven repo" is under $[HOME}/.m2/repository, Just delete that
whole
"repository" directory ... and in doing so, your first build
will take longer ... hope you are still not on hotel wifi :)
If that does not fix the issue,
I'm
not sure what else might be wrong. If that does fix the issue,
let us know,
as I suspect that's a sign of something we (someone) isn't doing
quite
right, somewhere.
Oh, wait, I did think of
something else
-- which actually is more likely to be the problem. When you say
you are
"following the instructions" ... I suspect you essentially end
getting the code wtih "git submodule
update"?
That is, you do not get "HEAD"
of each submodule?
If so, this means you are getting
"HEAD"
of aggregator (where new license is specified) but getting last
week's
"I-build revision" of submodules, which are still referring to
"old" license.
We normally only update the
"submodules"
associated with aggregator during I-builds. If this is the
problem, there's
lots of "solutions" ... you can use I20140415-0800 revision of
aggregator ... or you can pull HEAD of each submodule after you
do the
"update" ... or .... you can wait until Tuesday noonish
(Eastern)
time, and as long as the I-build is "good", that'd give you a
"coordinated set" using your current method.
If you like history, we used to
recommend
people always use "tagged" version of aggregator ... either
milestone,
or I-build, ... because there is no telling what you are getting
using
"HEAD" of everything .... but when that suggestion was made,
several people "complained" that "it depends ... they always
prefer HEAD" ... so ... user beware, I guess.
Thanks ... and good luck!
From:
John Hawksley
<john.hawksley@xxxxxxxxx>
To:
Common-build Developers
discussion <cbi-dev@xxxxxxxxxxx>,
Date:
04/20/2014 07:21 AM
Subject:
Re: [cbi-dev]
Build is failing with unsatisfied dependency
Sent by:
cbi-dev-bounces@xxxxxxxxxxx
Hi David,
I did actually try to pull the git repo on Thursday
but
I was on hotel wifi so I gave up in the end. The pull which is
now
failing was done yesterday (Saturday). I've just deleted the
whole
folder and pulled it again (just to make sure) and it's still
failing with
the same exception. Yes I'm trying to do the whole build, from
the
top of the aggregator.
Unfortunately I'm a bit hampered by the fact that I
don't
(yet) know much about how Maven is interacting with P2 (I assume
it's used
as an artifact repository in some way) so I can't really start
to debug
it.
I have noticed that this line:
INFO] {osgi.os=linux, osgi.ws=gtk,
org.eclipse.update.install.features=true, osgi.arch=x86}
.. isn't actually correct - I'm on OSX. I tried
to run the build in a new Linux (Mint 64-bit) VM to eliminate
this as a
source of problems, and it also failed. So I guess that
eliminates
the platform and my local m2 repo as a source of problems.
Thanks again,
-John
On Sun, Apr 20, 2014 at 2:21 AM, David M Williams
<david_williams@xxxxxxxxxx>
wrote:
This sounds like maybe a
temporary issue,
perhaps as a function of exactly when you made your clone,
because on Thursday
we went through an exercise where all feature licenses were
changed ...
and took most of Thursday afternoon ... have you "pulled" since
then? Also, I'm assuming you are building "whole build". The
"build individual bundle" won't function right until the next
I-build.
HTH
From: John
Hawksley <john.hawksley@xxxxxxxxx>
To: cbi-dev@xxxxxxxxxxx,
Date: 04/19/2014
12:45 PM
Subject: [cbi-dev]
Build
is failing with unsatisfied dependency
Sent by: cbi-dev-bounces@xxxxxxxxxxx
Hi folks,
I thought I might dive in to Eclipse and start to have a look at
contributing
some fixes, and of course the first stage is to make get a
stable build
working.
I followed the instructions here:
https://wiki.eclipse.org/Platform-releng/Platform_Build#Running_the_build
But the build fails with the following exception:
org.apache.maven.InternalErrorException: Internal error:
java.lang.RuntimeException:
No solution found because the problem is unsatisfiable.: [Unable
to satisfy
dependency from org.eclipse.jdt.feature.group 3.10.0.qualifier
to org.eclipse.license.feature.group
[1.0.0,1.0.1).; No solution found because the problem is
unsatisfiable.]
(full build log here: https://gist.github.com/jhawksley/11089863#file-gistfile1-txt)
Thanks for any support.
-John
--
John Hawksley
john.hawksley@xxxxxxxxx_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
--
John Hawksley
john.hawksley@xxxxxxxxx_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev
|
