Courier was unable to deliver the parcel, ID00641460
by FedEx SmartPost
Dear Customer,
Your parcel has arrived at September 20. Courier was unable to deliver the parcel to you.
You can review complete details of your order in the find attached.
Yours faithfully,
Isaac Hickey,
FedEx Station Manager.
10 years, 10 months
Please create 4.3.0.CR2 version in Jira
by Pavol Srna
$subj
Thanks!
--
Pavol Srna
JBoss QA Engineer, JBDS
Phone: +420 532 294 352, +420 774 519 396
Red Hat Czech
Purkynova 99, 612 00 Brno, Czech Republic
10 years, 10 months
TARGET_PLATFORM_VERSION value in parent/pom.xml for jbosstools-4.3.x branch
by Denis Golovin
While having troubles with master build I realized parent/pom.xml property
TARGET_PLATFORM_VERSION has wrong value. As I remember the idea was to keep
building the code base with TP based on Mars.0 release and running tests
with TP based on latest Mars release.
Currently TARGET_PLATFORM_VERSION=4.50.0.CR1-SNAPSHOT which is far ahead
from Mars.0 based TP.
According to the commit history (see below) closest released target
platform based on Mars.0 is 4.3.0.Beta2:
....
* 57fb37d - JBIDE-20143 generate SHA-256 checksum instead of SHA-1 since
that's what CSP/GG uses (10 weeks ago) <nickboldt>
** ae5f7d5 - (tag: refs/tags/4.50.0.Beta2) TP release 4.50.0.Beta2 (10
weeks ago) <Mickael Istria>*
* 5462b74 - Revert "JBIDE-20216 'The general rule is to use the latest
stable or release train ...(2 months ago) <nickboldt>
* b4adf55 - JBIDE-20216 'The general rule is to use the latest stable or
release train ...(2 months ago) <nickboldt>
* e997da3 - JBIDE-20216 add wikitext asciidoc editor; exclude creole and
commonmark plugins (for now) (3 months ago) <nickboldt>
* 04569fa - LOCUS-37: Include assertj 2.1.0 in TP (3 months ago) <Mickael
Istria>
* 4e7f019 - Update easymport (3 months ago) <Mickael Istria>
* 295f16a - include m2e 1.6.1 (not part of Mars R release) (3 months ago)
<nickboldt>
* 3a13c1f - JBIDE-19981: JSDT importer from upstream (3 months ago)
<Mickael Istria>
** 6955ca7 - Mars release (3 months ago) <Mickael Istria>*
...
Shouldn't parent/pom.xm have TARGET_PLATFORM_VERSION=4.50.0.Beta2 instead
what it has now?
With 4.50.Beta2 we can be at least sure about being able to install on
Mars.0 without manual testing.
WDYT?
Denis
--
CONFIDENTIALITY NOTICE: This email and files attached to it are
confidential. If you are not the intended recipient you are hereby notified
that using, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this email in error please notify the sender and delete this email.
10 years, 10 months
Possible Respin of Mars.1 (because of Buildship)
by Nick Boldt
FYI.
Since we don't include Buildship, this probably won't affect us much.
But it DOES mean that some users of Mars.1 EPP bundles (who also use
Buildship) might hit the problem mentioned below, unless they upgrade
to Mars.1a.
Nick
---------- Forwarded message ----------
From: Doug Schaefer <dschaefer(a)qnx.com>
Date: Wed, Sep 23, 2015 at 9:55 AM
Subject: [eclipse.org-planning-council] FW: Respin of Mars 1 for Buildship
To: Eclipse Planning Council <eclipse.org-planning-council(a)eclipse.org>
For your consideration.
I’ve commented on the cross-projects list with my thinking here. Since
we don’t seem to have a way to ensure we get maintenance releases of
the projects to users of the EPP packages, we have to do what’s right
for the users of those packages and fix these problems how we can. And
unfortunately, right now, that requires a respin.
Doug.
From: <tools-pmc-bounces(a)eclipse.org> on behalf of Etienne Studer
<etienne(a)gradle.com>
Reply-To: Tools PMC mailing list <tools-pmc(a)eclipse.org>
Date: Wednesday, September 23, 2015 at 7:28 AM
To: Tools PMC mailing list <tools-pmc(a)eclipse.org>
Subject: [tools-pmc] [Request] Respin of Mars 1
Hello
I’d like to ask the Tools PMC to do a re-spin of Mars 1 due to a
critical bug in Buildship 1.0.3, the Buildship version that is
currently in Mars 1 RC4 and its EPP packages (Java / Committer / RCP).
The bug has been fixed in Buildship 1.0.5.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478151
Some details below:
What is the bug?
Buildship calls Bundle#start() to eagerly activate its UI plugin. This
is a problem since it causes the OSGi framework to persistently mark
that bundle for eager activation upon restart. Once Eclipse is
restarted, the bundle that was persistently activated will be
activated very early in the startup process which will likely cause it
to touch preferences 'too early' which results in no workspace prompt
and the default workspace being used.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054.
How does the bug become apparent?
Once a Gradle task has been launched from the Tasks View, the user
will not be prompted for the workspace anymore the next time he starts
Eclipse, but instead the very default Eclipse workspace is used.
Who is affected?
The bug affects those users (and only those users) that run a Gradle
task through Buildship from within Eclipse.
When was the bug identified and investigated?
We were able to confirm that this is a Buildship bug yesterday. We
also found the cause and a fix yesterday. All Buildship versions <
1.0.5 contain the bug.
When was this bug introduced?
The bug is there since June 6th, as we have found out in retrospect (yesterday).
Why was this bug not found earlier?
Most likely, because the relation between Buildship and how the bug
manifests itself in Eclipse is not obvious to the user observing the
issue.
Is there a fix available?
Yes, the fix is available in Buildship 1.0.5, available as of last
night. It has been confirmed by three Gradle forum users that the
issue has been resolved in Buildship 1.0.5 .
I believe that it is critical for the introduction of Buildship into
the Eclipse SimRel and the Eclipse distributions that we get this fix
in for Mars 1. Otherwise, it will be a bad start for Buildship,
especially considering that the bug was known before the release and a
fix would have been available. Also, users might associate the bug
with a general Eclipse problem, which could cause unfair frustrations
about the Eclipse IDE.
Thanks for considering it.
Regards, Etienne
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council(a)eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation. To be permanently removed from this list,
you must contact emo(a)eclipse.org to request removal.
--
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.
http://nick.divbyzero.com
10 years, 10 months
OpenShift branch targeting JBoss Tools 4.3.1
by Fred Bricon
Hi,
we have a bunch of stuff to do in OpenShift tooling, for the 4.3.1 release
and, given the jbosstools-4.3.x branch is closed for business for the next
2 weeks, the 4.3.1 work will happen in branch jbosstools-4.3.1x. Once
4.3.0.Final is released, the 4.3.1.x branch will be merged into 4.3.x[1].
Hopefully it should be a fast forward merge by then.
So currently we have the following branches:
jbosstools-4.3.x: jbosstools-openshift 3.0.0-SNAPSHOT (4.3.0.CR1-SNAPSHOT
parent)
jbosstools-4.3.1.x: jbosstools-openshift 3.1.0-SNAPSHOT (4.3.0.CR1-SNAPSHOT
parent)
master: jbosstools-openshift 3.2.0-SNAPSHOT (4.3.0.CR1-SNAPSHOT parent)
Appropriate parent versions will have to be changed ASAP.
For each fix pushed to the jbosstools-4.3.1.x, the matching JIRA can be
updated to 'Resolved'
Maybe not a perfect workflow but it's the least bad we could think of :-)
If other JBT components have similar requirements, feel free to implement a
similar pattern.
Fred
[1] https://issues.jboss.org/browse/JBIDE-20766
10 years, 10 months
Working on 4.3.1/4.4.0
by Alexey Kazakov
Hi,
Just a reminder that the jbosstools-4.3.x branch is still frozen and
will remain frozen until we release JBT 4.3.0.Final (should happen in
two weeks or later if we have to postpone it).
If you have something you want to fix for the future versions then please:
*a. If your change is something that should be fixed only for JBT 4.4*,
for example some big changes or Eclipse Neon related fixed/updates then:
a.1. Create a PR for master. Apply it. Resolve the issue for JBT
4.4.0.Alpha1. (don't forget to update the version of your component if
you have not done it yet).
*b. If you have something that should be fixed in both JBT 4.4 (Eclipse
Neon) and JBT 4.3.1* (maintenance release for Eclipse Mars) then:
b.1. Fix it in master. See a.1.
b.2.1. Create a PR for jbosstools-4.3.x and wait for that branch to be
open for 4.3.1 development. You should keep your JIRA open until both PR
are merged.
or if you really need some open branch to continue working on 4.3.1
issues (for example the OpenShift team needs it) then you have the
following option:
b.2.2. Create a new jbosstools-4.3.1.x branch from jbosstools-4.3.x,
work with that to fix all needed issues (create a PR, apply after
someone's review, resolve the jira, all usual stuff). And create a JIRA
for JBT 4.3.1 which says the 4.3.1.x branch should be merged to 4.3.x.
When the main 4.3.x branch is open, then you will be able to merge the
branches and continue working on the main 4.3.x branch directly.
I hope it makes sense.
Thanks.
10 years, 10 months
ACTION REQUIRED: Update parent pom to 4.4.0.Alpha1 in master
by Alexey Kazakov
Hi,
It's time to prepare the master branch for JBT 4.4 / JBDS 10 development.
1. Please update the parent pom in your component from
4.3.0.CR1-SNAPSHOT to 4.4.0.Alpha1-SNAPSHOT:
jbosstools-*/pom.xml:
<parent>
<groupId>org.jboss.tools</groupId>
<artifactId>parent</artifactId>
<version>*4.4.0.Alpha1-SNAPSHOT*</version>
</parent>
Please update the parent pom now.
2. Bump the version of your component. For example if the current
version of your component is 4.3.0 then update it to 4.4.0 or 4.3.100
(if you don't add any new functionality):
mvn org.eclipse.tycho:tycho-versions-plugin:set-version
-DnewVersion=4.4.0.SNAPSHOT
You should update the component version when you pushing any changes to
master that you don't have in JBT 4.3.0
I didn't create JIRAs for these updates, so, please, don't ignore this
email :)
Thanks.
10 years, 10 months
