Sorry about that. Cut and paste error, I didn't notice. Should be
fixed now.
As to the separate milestones... yea it can lead to confusion. We
try to generate a Milestone for EclipseLink once a month and when
referring to the SimRel Train contribution can lead to confusion. I
try to follow the nomenclature of "Kepler M4" vs "EclipseLink M5",
so my comments usually say something akin to "Contribution of
EclipseLink M5 for Kepler M4" Though sometimes it is just
"EclipseLink contribution for Kepler M#" and the aggregation file
specifies the appropriate EclipseLink milestone repo.
If you can think of a better methodology let me know.
Eric
On 20/12/2012 3:53 PM, David M Williams wrote:
Ok, thanks Eric, for
letting us know. Neil's
told me you kind of have "your own" milestones, and then take
the closest one to our Simultaneous Milestones ... no harm in
that, just
means we have to communicate carefully.
Normally "having two versions"
wouldn't hurt anything, unless you know there's some API change
or something
that makes them incompatible, so I'll assume we are ok, unless
someone
reports an actual problem (and, getting kind of late, even for
that :)
You are right, there's no harm
doing
the update so "in case" we need to respin, it would pick up your
corrected version, however I still get
Unable to load repository p2:http://download.eclipse.org/rt/eclipselink/milestone-updates/
2.5.0.v20121120-ec51fcc_M5
so if we did respin right now,
we'd
be broken.
I think the first problem is
there is
a space (blank) in both your URL and version that should not be
there.
But, even if I fix that, then I
get:
Cannot complete the install
because
one or more required items could not be found.
Missing requirement: EclipseLink
JPA
2.5.0.v20121120-ec51fcc
(org.eclipse.persistence.jpa.feature.group
2.5.0.v20121120-ec51fcc)
requires 'org.eclipse.persistence.oracle
[2.5.0.v20121120-ec51fcc]' but
it could not be found
InstallableUnit(org.eclipse.persistence.oracle
[2.5.0.v20121120-ec51fcc,2.5.0.v20121120-ec51fcc])
is required by:
ValidationSet(main)
Contribution(EclipseLink)
MappedRepository(http://download.eclipse.org/rt/eclipselink/milestone-updates/2.5.0.v20121120-ec51fcc_M5)
Feature(org.eclipse.persistence.sdk.feature.group
2.5.0.v20121120-ec51fcc)
InstallableUnit(org.eclipse.persistence.jpa.feature.group
2.5.0.v20121120-ec51fcc)
The b3 aggregator editor can be
your
friend :)
From:
Eric Gwin
<eric.gwin@xxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
12/20/2012 02:06 PM
Subject:
Re:
[cross-project-issues-dev]
Status and outlook for Kepler M4 +3
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
David,
No. EclipseLink's M4 was 2.5.0.v20121016-ab08992,
it is what was included in the aggregation files. However, Dali
is including
EclipseLink directly, and they are using M5
(2.5.0.v20121120-ec51fcc).
So currently both versions are in the aggregation.
When I released our M5 I thought I had updated the aggregation
files to
reflect the new Milestone. However somehow it never did occur. I
probably
forgot to push my local change, and later issues caused me to
re-clone
so the change was lost.
In any case, the only issue I'm aware of is the multiple
versions of most
of our bundles. I'm unaware of any other repercussion. I just
thought that
if the aggregation was going to be redone, than syncing things
up would
be in everyone's best interest. Your call however.
-Eric
On 20/12/2012 12:24 PM, David M Williams wrote:
I'm a bit confused, but in any
case
would need more justification to do a rebuild, this late. What
impact to
users is there? Can they get your "correct M4" from your own
repo? Is there a work around? Does it effect EPP packages?
When I look for Eclipse link in .../releases/staging, I do see
the same
thing as in .../releases/kepler;
EclipseLink Target Components 2.5.0.v20121016-ab08992
So, I think you are saying that's your M3 level? But your note,
and your
commit to get mention M5: "update Kepler contrib to EclipseLink
M5".
We are still on M4, if that's a point of confusion. But in any
case, can
you make an argument why this would be "blocking".
FYI, we've not "strict on dates" just for sake of being strict
(though, that is a good reason :) ... but the process of doing a
rebuild
is itself risky ... others might have changed something,
intentional or
not ... so introduces uncertainty and a lot of re-work for many.
So, if your users can get what they need from your project's
repo, I'd
prefer to go that route.
Thanks,
From: Eric
Gwin <eric.gwin@xxxxxxxxxx>
To: Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 12/20/2012
11:34 AM
Subject: Re:
[cross-project-issues-dev] Status and outlook for Kepler M4 +3
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
David,
I was certain that I'd already updated EclipseLink, but that
was not the
case. I double checked this morning on a whim due to this
thread, and discovered
the issue. You are using our M5, but our build was still set
to M4. That
would leave two sets of jars in the aggregation. I've just
submitted the
new build file.
I apologize for the mix-up.
-Eric
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|