Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Next turn of the crank ... runtime compatibility bundle

Hi

Eclipse Scout will be jumping on the release by Neon M4. We will activating the scout.b3aggrcon file then. scout-rap.b3aggrcon will be deleted as we do not deliver a rap ui anymore.

Greetings
Stephan

 

--

Scout Release Engineer, Senior Software Architect

BSI Business Systems Integration AG

Täfernstrasse 16a, CH-5405 Baden

T +41 56 484 19 47

M + 41 78 728 25 05

www.bsi-software.com

 

Neue Adresse ab 1.12.2015: Täfernweg 1, CH-5405 Baden

On 22 Oct 2015, at 15:45, David M Williams wrote:

For the record, the aggregation build is now running "clean", with only
LDT and BIRT (still) disabled and a MAT feature disabled, since it depends
on BIRT.
I know BIRT being disabled will effect EPP packages for M3, so I hope it
can be fixed soon.

In addition, there are three other files with disabled features or
repositories -- I assume disabled by the project's themselves, at least I
don't recall doing it.

objectteams.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build

For all cases, please let us know why disabled (no longer participating?)
and when you expect to have "fixed".

As always, feel free to ask if questions or issues.

From: Greg Watson g.watson@xxxxxxxxxxxx
To: Cross project issues cross-project-issues-dev@xxxxxxxxxxx,
Date: 10/21/2015 10:40 AM
Subject: Re: [cross-project-issues-dev] Next turn of the crank ...
runtime compatibility bundle
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

I thought I’d fixed PTP already, but I’ll check again.

Greg

On Oct 21, 2015, at 9:52 AM, David M Williams <david_williams@xxxxxxxxxx>
wrote:

Since no response from Birt, I have disabled BIRT from the aggregation,
for now (which required me to also disable MAT chart feature, for now,
since depends on BIRT) so that we can see who else might still depend on
compatibility bundle.

According to my local builds, I think PTP does?

If so, please correct soon, please ... I'd like to know if there's any
more, after that is fixed?

Thanks!

From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross-project-issues-dev@xxxxxxxxxxx,
Date: 10/20/2015 03:02 PM
Subject: Re: [cross-project-issues-dev] ... runtime compatibility
bundle ... and LDT ... and Neon M3
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

OK, ready to try again? Since the LDT contribution has not changed, I have
disabled it from the aggregation build, so that we can see who else still
refers to the defunct compatibility runtime bundle.

According to my local builds, BIRT will be the next project to fail ...
now that DTP has been fixed (thanks Konstantin, and others).
[Correction

Please correct any failures as soon as possible. That is, don't wait until
your +N day. You can always contribute your final content later, but build
"breaks" should be corrected right away.

Same goes for you, LDT team, though I know your "break" isn't obvious, and
realize you have some "redesign" work to do to figure out how to deliver
"just your code" (and not all dependencies too).

Thanks all,

From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross-project-issues-dev@xxxxxxxxxxx,
Date: 09/30/2015 11:04 AM
Subject: Re: [cross-project-issues-dev] DTP for Neon stream ...
runtime.compatibility ... and LDT? ... and Neon M2
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

OK, I give up.

It appears some projects are not going to be able to react to the removal
of runtime.compatibility bundle, for M2, so I have re-enabled the LDT
contribution. (Bug 478009 and Bug 478330).
This will allow the aggregation build, at least, to complete, so that
others can make progress.

This won't help projects who have a direct dependancy on, say, DTP (which
in turn as a dependency on runtime compatibility bundle) since they depend
on it, but do not provide it.
For those people, the only work around I know of is to "include" only that
bundle from our M1 repository, or something similar.
Less that ideal, but I'd like to push forward and see if we can get out
some form of M2 that can be used to create a cleaner M3!

Let me know if suggestions or alternative approaches. (And, FYI, it does
not appear that extending the deadline a few days will help with the
runtime compatibility issue, but, if anyone has been blocked due to this
issue, and needs a few days to work around the problem, I think it
reasonable to consider an extension of a few days ... if you make such a
request, please be specific ... I'd hate to extend it to Monday instead of
Friday (let's say) and then that still not be enough time.)

Thanks,

From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross-project-issues-dev@xxxxxxxxxxx,
Date: 09/28/2015 08:47 PM
Subject: Re: [cross-project-issues-dev] DTP for Neon stream ...
runtime.compatibility ... and LDT? ... and Neon M2
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

I hope everyone remembers that Neon M2 is this Friday ... and that means
your Neon M2 contributions must be done by Wednesday.

AND .. it seems, some have not yet reacted to the platform removing
org.eclipse. runtime.compatibility bundle (Bug 394739).

AND .. some have been "getting it automatically" from the current Sim.
Release contributions, because Lua Development Tools (LDT) duplicates it
(and many others) in their repository (Bug 478009).

Since LDT has not updated their repo yet for Neon, I fear some may have of
a false sense that "everything is ok".

Put more bluntly, we all know, some projects do not build against the
latest version of their pre-reqs! And, we all know that some projects
won't react until "the build fails".

Therefore ... I am about to make the build fail for others, by removing
LDT's massive contribution.

If someone has a better suggestion, that would be good to hear, but I hope
I am doing everyone a favor, by making the problem more apparent in the
aggregation build.

(And, greatest thanks to those of you who HAVE reacted to this change
already ... thanks to all your release engineers!)

Thank to you all,

From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues cross-project-issues-dev@xxxxxxxxxxx,
Date: 09/21/2015 08:09 PM
Subject: Re: [cross-project-issues-dev] DTP for Neon stream ... and
LDT?
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

A question regarding the aggregation build. I thought it was
designed to catch issues like this, but I don’t see any failures on

Hudson.

I was wondering that too. :) So ...

I looked in the log, at
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/111/consoleFull

and could see

  • mirroring artifact osgi.bundle,org.eclipse.core.runtime.compatibility,3.2.300.v20150423-0821

and then searching backwards in log, for "Mirroring artifacts from",
could see that the LDT project is (also) contributing that bundle, via
their repository at
.../download.eclipse.org/ldt/releases/stable/1.3

I hope that is a temporary condition, since (in this case) do not think
the Platform would like others
"extending the life" of something they are trying to end. But ... I am not
sure. I think the next step
is to hear from the LDT project. I have opened bug 478009 for this issue.

I did also use b3 aggregator editor to search for others who might be
contributing that bundle, and it appears there are no others.
(And, appears that LDT contributes much more potentially problematic
bundles, than just that one, since they duplicate a great deal
of other's projects, for their "Eclipse product").


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top