On 12/20/2012 10:20 PM, David M Williams wrote:
Most of you know, that we normally keep 3 milestones in our common
repository, as a composite.
This works as long as no one removes a feature or a feature is
mistakenly "down versioned".
The easiest fix at this point, for common repo is just to
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 n
Most of you know, that we normally keep 3 milestones in our common
repository, as a composite.
This works as long as no one removes a feature or a feature is mistakenly
"down versioned".
But, I have detected a problem with doing that this time. See
Bug 397033 - Acceleo has conflicting depende
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
th
Eric Gwin wrote on 12/20/2012 02:04:11 PM:
>
> 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 aggre
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 ha
Thanks, now the model validates, but I get a message (when running
locally) related to the Eclipselink contribution:
Unable to load repository p2:
http://download.eclipse.org/rt/eclipselink/milestone-updates/
2.5.0.v20121120-ec51fcc_M5
Judging from the last couple of letters ("M5") perhaps the
Le 20/12/2012 18:44, David M Williams a écrit :
This commit, did "break" aggregation. The reason is you removed the
feature from your file, but its still "listed" in the "SOA
Development" Category. When ever features are added or removed, I
recommend using the b3 aggregator editor. It often eff
This commit, did "break" aggregation. The reason is you removed the
feature from your file, but its still "listed" in the "SOA Development"
Category. When ever features are added or removed, I recommend using the
b3 aggregator editor. It often effects not only your file, but the
simrel.b3aggr f
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 th
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 s
Cool. Does this mean we are ready for Kepler M4?
Done.
However, I made a Git merge. I just hope I did not break anything.
:|
Vincent.
Le 20/12/2012 15:05, Vincent Zurczak a écrit :
Hi,
Thanks Vincent!bob
Hi,
I will handle the soa.bpel warning before this evening.
Cheers,
Vincent.
Le 19/12/2012 22:51, David M Williams a écrit :
It is almost 5 PM
(Eastern) and not heard
Done.
However, I made a Git merge. I just hope I did not break anything.
:|
Vincent.
Le 20/12/2012 15:05, Vincent Zurczak a écrit :
Hi,
I will handle the soa.bpel warning before this
Hi,
I will handle the soa.bpel warning before this evening.
Cheers,
Vincent.
Le 19/12/2012 22:51, David M Williams a écrit :
It is almost 5 PM
(Eastern) and not heard
anyone ask for "wait" .
15 matches
Mail list logo
