He didn't. He said that the platform doesn't support java5:
Since Platform 3.8 it has certainly been impossible to run the complete platform
using Java 5 due to Jetty dependency on Java 6 (and possibly other bundles).
On 03/09/2013 12:34 PM, Ed Willink wrote:
Hi
I must be very dense. Where
Denis,
It may be unrelated, but slow response times appear to be occurring again. Am
attempting to ssh to build.eclipse.org, and login response is slow and terminal
periodically freezes. sometimes for up to a minute.
Eric
On 03/07/2013 1:16 PM, Denis Roy wrote:
Our ISP has located the
Wayne,
Sorry about the delay. It is coming from EclipseLink. After investigating, it
seems the jar used to be just a compile dependency, so didn't contain the
needful because it was never shipped. That changed recently, and updating to
the Orbit version fell through the cracks. I'm going to
Is this resolved? all our builds are failing.
Eric
On 24/04/2013 5:34 AM, Eike Stepper wrote:
Hi Laurent,
I think the drive is full: https://bugs.eclipse.org/bugs/show_bug.cgi?id=406391
Cheers
/Eike
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
permissions updates.
-Eric
On 22/02/2013 8:55 AM, Denis Roy wrote:
Restore is complete, and Matt is kicking Hudson as I type this.
Thanks,
Denis
On 02/22/2013 08:54 AM, Eric Gwin wrote:
Any news? A cursory look at build.eclipse.org shows what appears to be a
completed restore (/shared), but I
David,
For a while now I've been having trouble switching my simrel branch. I thought
it was just my system, but tried from another system recently. Any attempt to
switch to the Juno_maintenance branch is giving me:
error: Your local changes to the following files would be overwritten by
Ok. got past it again by unstaging the file. and was able to checkout the
Juno branch, but it should still probably be looked into.
-Eric
On 18/01/2013 2:14 PM, Eric Gwin wrote:
David,
For a while now I've been having trouble switching my simrel branch. I thought
it was just my system
Eric Gwineric.g...@oracle.com a écrit :
Ok. got past it again by unstaging the file. and was able to checkout the
Juno branch, but it should still probably be looked into.
-Eric
On 18/01/2013 2:14 PM, Eric Gwin wrote:
David,
For a while now I've been having trouble switching my
, you need to set
autocrlf=false? :) At least, I'm assuming that was (one of) the problems
... like I said, I've not actually seen the issue.
HTH
From:Eric Gwin eric.g...@oracle.com
To:Cross project issues cross-project-issues-dev@eclipse.org,
Date
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
can get what they need from your project's repo, I'd prefer
to go that route.
Thanks,
From: Eric Gwin eric.g...@oracle.com
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date: 12/20/2012 11:34 AM
Subject: Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
Sent
All,
EclipseLink just pushed its M3 contrib (EclipseLink 2.5.0 M4).
-Eric
On 08/11/2012 7:57 PM, David M Williams wrote:
Still several previous contributions that have not been re-enabled
emf-query2.b3aggrcon - org.eclipse.simrel.build
gyrex.b3aggrcon - org.eclipse.simrel.build
David,
I've updated EclipseLink's aggregation build file to our release repo (from the
last milestone - they are identical repos, but in different locations).
-Eric
Comments on your points are inline:
On 31/07/2012 8:44 PM, David M Williams wrote:
Here's an outline of what is quickly coming
Looks like the identical repo isn't good enough. I'm investigating the
aggregation failure.
On 01/08/2012 11:46 AM, Eric Gwin wrote:
David,
I've updated EclipseLink's aggregation build file to our release repo (from the
last milestone - they are identical repos, but in different locations
I think It is resolved... small path issue fixed.
On 01/08/2012 11:56 AM, Eric Gwin wrote:
Looks like the identical repo isn't good enough. I'm investigating the
aggregation failure.
On 01/08/2012 11:46 AM, Eric Gwin wrote:
David,
I've updated EclipseLink's aggregation build file to our
All,
I'm moving our build processes over to Hudson, and am running into an issue
getting access to the built artifacts. We used to generate on build and had a
separate process that would grab the bits and publish them to download.
I was hoping to follow a similar model since Hudson doesn't
Hi All,
Since RC3 was announced complete, and Dali requested it, I have submitted a new
build of EclipseLink to the Repo before RC4. At this point it looks like it
will also be our RC4+1 contribution, but Monday will tell...
-Eric
___
Thanks.
On 03/01/2012 4:31 PM, David M Williams wrote:
because I'd like confirmation that Orbit bundles follow a versioning
standard where the bundle uses the version of the original jar
followed by the build date:
javax.foo.jar (version 1.0.3) -javax.foo_1.0.3.date/time built.jar
I see I
David,
You are listed as the lead for Orbit, but the project pages don't appear to
have been updated for a while.
I'm wondering if you are still the lead, because I'd like confirmation that
Orbit bundles follow a versioning standard where the bundle uses the version of
the original jar
Looks like the metadata failed to generate. reverted to previous.
-Eric
On 23/11/2011 3:55 AM, Zeb Ford-Reitz wrote:
As of the most recent commit to the Juno aggregator, the referenced update site
for EclipseLink is empty. This breaks Juno projects that have a dependency on
EclipseLink
Thank you for your reply.
As I understand it you are saying that the naming in the repository is separate
from the naming of the object once it is served back out for the purposes of
another project. If so, then the Maven versioning information is completely
separate from the OSGi
21 matches
Mail list logo
