Re: [cross-project-issues-dev] Has Java 5 Platform support been discontinued?
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 does it say The platform requires Java 6. Regards Ed Willink On 03/09/2013 17:19, John Arthorne wrote: I can't think of any way to be clearer than I already have. The platform requires Java 6, and it has required Java 6 for several years. Next time I do a plan update I will try to make that even clearer. John From: Ed Willink e...@willink.me.uk To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 09/03/2013 10:47 AM Subject: Re: [cross-project-issues-dev] Has Java5Platform supportbeendiscontinued? Sent by: cross-project-issues-dev-boun...@eclipse.org -- Hi I'm sorry John but you are dodging the issue. There is far too much this is what we do, and very little of this is what we require. /Most of the Eclipse SDK is pure Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java 5, etc)./ /In general, the 4.3 release of the Eclipse Project is developed on a mix of Java SE 6 and Java SE 7 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs. Most functionality is available for Java SE 6 level development everywhere, and extended development capabilities are made available on the VMs that support them./ Yes there have been a few bundles that needed 1.6 for some time, but it seems like the critical parts of the platform have been 1.5. The list on _http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#appendix_ still shows very little that needs 1.6, so I see no statement that the platform needs 1.6. I delivered my Indigo, Juno and Kepler releases as Java 5 minimum requirement. Clearly the platform and many projects were highly Java 5 tolerant. There should perhaps be a separate overall statement at the top that 1.6 is the minimum requirement (although some bundles may be more tolerant). Or org.eclipse.core.* needs to change to 1.6 Regards Ed Willink On 03/09/2013 14:57, John Arthorne wrote: I seem to have a knack for definitive statements lately so I'll take a try at this. The last Eclipse Platform release to officially support Java 5 was 3.6/Helios. We have not run our tests against Java 5 for several years and can make no claim that it works. 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). Oracle Java end of life was in 2009 (in fact Oracle Java 6 is also past end of life now). Some individual bundles may still support older runtimes but at this point they are the exception rather than the norm. The list of bundle EE levels is updated with each plan revision, but as long as they are within the scope of the current list of reference platforms they are not generally announced individually. John From: Ed Willink _e...@willink.me.uk_ mailto:e...@willink.me.uk To: Cross project issues _cross-project-issues-dev@eclipse.org_ mailto:cross-project-issues-dev@eclipse.org, Date: 09/03/2013 09:24 AM Subject: Re: [cross-project-issues-dev] Has Java 5Platform support beendiscontinued? Sent by: _cross-project-issues-dev-bounces@eclipse.org_ mailto:cross-project-issues-dev-boun...@eclipse.org
Re: [cross-project-issues-dev] bugzilla down?
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 problem (a DDoS) and our site seems to be happy once again. Denis On 07/03/2013 12:07 PM, Roland Grunberg wrote: I am experiencing very slow response times / hangs accessing http://bugs.eclipse.org/ Is it me or is bugzilla down? Jan I seem to be experiencing the same. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] RC3 and Final Daze ...
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 make certain we have no issue running against 1.6.0, and slip that version from Orbit into our release p2 repo. If that fails I'm going to have to update our jar with appropriate files, and again regen our release p2 repo. I hope to have this fixed in the next day or so. Eric On 2013-06-06, at 10:58 AM, Wayne Beaton wa...@eclipse.org wrote: Thanks for looking. I looked a little harder and--based on file dates--it's probably coming from EclipseLink. Wayne On 06/06/2013 04:31 AM, sven.rottst...@sungard.com wrote: I’ve validated the P2 repository of Stardust at /home/data/httpd/download.eclipse.org/milestones/kepler/1.0.0-RC3-SNAPSHOT/plugins which was picked up by the simrel aggregator build but we’ve no javax.resource_1.5.0.v200906010428.jar included. Should I also check the Require-Bundle section of the MANIFEST.MF files? Von: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Wayne Beaton Gesendet: Mittwoch, 5. Juni 2013 21:36 An: cross-project-issues-dev@eclipse.org Betreff: Re: [cross-project-issues-dev] RC3 and Final Daze ... I've broken David's missing abouts file into project responsibilities. In some cases, a Kepler project is consuming a non-Kepler project's code. Please connect with the source project's team to address the issue. Note that the full list of files is in the link provided by David http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt Please address this ASAP. David, can you please plan to re-run the script on Friday? EclipseLink or Stardust? Missing about.html in file: javax.resource_1.5.0.v200906010428.jar ECF Missing about.html in file: org.eclipse.ecf.* GMF Runtime Missing about.html in file: org.eclipse.gmf.runtime.* Gyrex Missing about.html in file: org.eclipse.gyrex.* Missing about.html in file: org.eclipse.gemini.jpa_1.1.0.RELEASE.jar Web Tools Missing about.html in file: org.eclipse.jpt.doc.user_3.2.0.v201305240436.jar Koneki Missing about.html in file: org.eclipse.koneki.* Missing about.html in file: com.cforcoding.jmd_0.8.1.201305031130.jar Mylyn Missing about.html in file: org.eclipse.mylyn.reviews.edit.source_2.0.0.I20130529-1332.jar Riena Missing about.html in file: org.eclipse.riena.* Missing about.html in file: org.eclipse.nebula.widgets.grid_1.0.0.HEAD.jar TCF Missing about.html in file: org.eclipse.tcf.te.tcf.launch.cdt_1.1.0.201305210728.jar Xtext Missing about.html in file: org.eclipse.xtend.* Missing about.html in file: org.eclipse.xtext.* m2e-wpt Missing about.html in file: org.sonatype.m2e.mavenarchiver_0.15.0.201207090125-signed-201209140800.jar BIRT Missing about.html in file: uk.co.spudsoft.birt.emitters.excel.source_4.3.0.v201306041519.jar Missing about.html in file: uk.co.spudsoft.birt.emitters.excel_4.3.0.v201306041519.jar Thanks, Wayne On 06/05/2013 02:58 PM, David M Williams wrote: Here we are, nearly at the end of RC3 (remember, staging repo builds close at 5 PM Eastern, unless someone notifies us here they need an extra hour or two). I am a little disappointed there is still so much work for some projects to do to meet minimum requirements to be released, http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt http://build.eclipse.org/simrel/kepler/reporeports/reports/verifydiroutput/unsigned.txt But, I guess every year there are some projects that like to save it to the very end. The main purpose of this note is to educate everyone on some of the mechanics over the next few weeks what we call the Final daze. For those of you that have been through it before ... it's all the same ... just dates have changed ... but it wouldn't hurt for Project Leads and release engineers to re-read. For those of you new to Simultaneous Release, I hope you find it a helpful reference on how to make things go smoother, in a more coordinated way. http://wiki.eclipse.org/Kepler/Final_Daze After reading it, and the documents it links to, please ask here on cross-project list if there are questions, issues, or suggestions. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org
Re: [cross-project-issues-dev] Permission issues on build.eclipse.org
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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Build.eclipse.org Down
Thanks very much. I started a build, and it failed: /opt/users/hudsonbuild/workspace/eclipselink-nightly-master/autobuild.xml:430: java.io.FileNotFoundException: /shared/rt/eclipselink/handoff-file-build-master-v20130222-547208e.dat (Permission denied) Looks like Hudson may need some 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 still cannot get to Hudson. Thanks much. Eric On 21/02/2013 4:29 PM, Denis Roy wrote: /shared is in the process of being restored. Unfortunately, it is absolutely huge, so it is taking a while 224GB done out of 894GB, restoring at about 40 MB/sec. Denis On 02/21/2013 04:26 PM, Alexander Nyßen wrote: Denis, when trying to run my promotion script (in order to prepare the GEF 3.8.2 release), I run into the problem that file permissions do not seem to be properly restored on /shared, i.e. I am for instance not allowed to access /shared/jobs/gef-maintenance. Cheers Alexander Am 21.02.2013 um 22:21 schrieb Alexander Nyßen alexander.nys...@itemis.de mailto:alexander.nys...@itemis.de: I still can't access hudson.eclipse.org http://hudson.eclipse.org/... Cheers Alexander Am 21.02.2013 um 20:17 schrieb Denis Roy denis@eclipse.org mailto:denis@eclipse.org: build.eclipse.org http://build.eclipse.org/ is back online, and /shared is being restored. Apologies for the long delay. Denis On 02/21/2013 01:50 PM, Dennis Hübner wrote: Am 21.02.2013 um 17:45 schrieb Denis Roy: FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece that has been taking a beating 24/7. Quality iron right there, folks. Sounds like binford 3000 hard drive. hr hr hr hr. :) Regards, Dennis Hübner Xtext Commiter / Build Engineer ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Corrupt Simrel repo???
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 checkout: soa-bpel.b3aggrcon Please commit your changes or stash them before you can switch branches. This is from a freshly cloned repo. I don't know if the issue is mine (can't see how), or a corrupt git repo, or something to do with the soa-bpel file. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Corrupt Simrel repo???
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, 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 checkout: soa-bpel.b3aggrcon Please commit your changes or stash them before you can switch branches. This is from a freshly cloned repo. I don't know if the issue is mine (can't see how), or a corrupt git repo, or something to do with the soa-bpel file. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Corrupt Simrel repo???
Hi, I understand that the message is usually a standard Git protection to keep me from inadvertently overwriting edited files. However, my point is I haven't edited the file. Ever. It comes edited when the repo is cloned. Therefore, I surmise that the file is, in fact, corrupt in the repo, and everyone using that repo is having to deal with the consequences. It would be nice if it were fixed. Eric On 2013-01-18, at 4:54 PM, Ed Willink e...@willink.me.uk wrote: Hi This is standard GIT protection for edited files. As the message says you must either preserve of lose the changed files. To lose it/them just replace all files shown in the Staging View by HEAD. Then you're good to go. Regards Ed Willink On 18/01/2013 21:45, Benjamin Cabé wrote: FWIW I have the very same issue, so sth is probably wrong in the git repo itself indeed... Benjamin 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 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 checkout: soa-bpel.b3aggrcon Please commit your changes or stash them before you can switch branches. This is from a freshly cloned repo. I don't know if the issue is mine (can't see how), or a corrupt git repo, or something to do with the soa-bpel file. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6039 - Release Date: 01/17/13 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Corrupt Simrel repo???
David, Perhaps EGit helps out so you didn't see the issue. I typically work directly from the Git command-line or use GUI tools, like TortoiseGit, or SourceTree. All three reported the issue. None of the other Git repos I use have ever gotten into that state. At least one of them is fairly active and receives regular cross-platform commits. The two platforms I'm using that had the issue were Windows and Mac OSx. Although I do have a linux box available I didn't check it. Thanks for looking into it. I wasn't intending to sound snarky. I'd originally believed it to be a windows issue - not playing well with Git. However, when the Mac command-line tools also reported the same results I became a bit more worried. Though not finding any other reports of the issue was also odd. I just thought I bring it to folks attention, and see if there was something obvious I was missing. I'll clone again in the morning and see if I still see the issue. Thanks again. Eric On 2013-01-18, at 9:16 PM, David M Williams david_willi...@us.ibm.com wrote: Do people who always have to deal with the consequences use Windows? Linux? Mac? Do they use EGit or command line? I ask, since I do not see the problem you describe, using Linux and EGit. But, I did look closely at the file, and see that it had mixed line endings (some windows CRLF and some linux LF). This, in turn, makes me wonder if participants have read http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_repo and http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_workspace_content_types In short, use autocrlf=false and define your content types and/or associate the file types with text editors. autocrlf=false should prevent a change from occurring on checkout, and having correct content types defined make it easy to fix using Convert Line Delimiters To ... . If you're the CLI only type, you'd have to use dos2unix to fix. I have corrected the delimiters (so it is now no longer a test case) ... but, having the repo configured correctly will help avoid it in future and make it possible for you, participants, to fix files in the future, if it happens again. Maybe we should add a reminder test case file, with deliberate mixed line endings that'd say if you see this file as changed, 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:01/18/2013 07:09 PM Subject:Re: [cross-project-issues-dev] Corrupt Simrel repo??? Sent by:cross-project-issues-dev-boun...@eclipse.org Hi, I understand that the message is usually a standard Git protection to keep me from inadvertently overwriting edited files. However, my point is I haven't edited the file. Ever. It comes edited when the repo is cloned. Therefore, I surmise that the file is, in fact, corrupt in the repo, and everyone using that repo is having to deal with the consequences. It would be nice if it were fixed. Eric On 2013-01-18, at 4:54 PM, Ed Willink e...@willink.me.uk wrote: Hi This is standard GIT protection for edited files. As the message says you must either preserve of lose the changed files. To lose it/them just replace all files shown in the Staging View by HEAD. Then you're good to go. Regards Ed Willink On 18/01/2013 21:45, Benjamin Cabé wrote: FWIW I have the very same issue, so sth is probably wrong in the git repo itself indeed... Benjamin 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 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 checkout: soa-bpel.b3aggrcon Please commit your changes or stash them before you can switch branches. This is from a freshly cloned repo. I don't know if the issue is mine (can't see how), or a corrupt git repo, or something to do with the soa-bpel file. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3
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 Components2.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.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 by: cross-project-issues-dev-boun...@eclipse.org -- 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminder Kepler M3 deadlines are next week
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 jwt.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build And a number of additional ones that contain disabled repos for features ... some of which may be waiting on the above contributions? amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build emf-emf.b3aggrcon - org.eclipse.simrel.build mylyn.b3aggrcon - org.eclipse.simrel.build (2 matches) tcf.b3aggrcon - org.eclipse.simrel.build (2 matches) tm.b3aggrcon - org.eclipse.simrel.build webtools.b3aggrcon - org.eclipse.simrel.build Let me know if I can help. And I'll give an early reminder that the next cycle (M4) will be a little shorter for some (most) projects since we shift to the one week window then, From http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule Elapsed Weeks End Date Span from +0 for RC0 for EPP avail M1 Friday, August 24, 2012 08/10 to 08/24 6 8 (from previous release GA) M2 Friday, October 0509/21 to 10/05 6 6 (from M1) M3 Friday, November 16 11/02 to 11/16 6 6 (from M2) M4 Friday, December 21 12/14 to 12/21 6 5 (from M3) (shift from 2 week window to 1 week window) Thanks! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler initial daze
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 up (I propose). First, transition to Git. [1] I have been exploring and experimenting with moving the aggregation files and build to Git and am feeling confident enough to say we'll do it in about a week. So, at some point, let's say Friday, 8/3, will be the official cut off time for CVS changes. After that, I suspect there will be a little down time while I actually do the move, and get things working again before it'd make sense to make official changes to your Git files. So, anything not building by Friday will just be disabled. 1) Awesome. I'm looking forward to Git. As mentioned EclipseLink should be good-to-go Second, change in aggregation build project name. [1] As we rethink this stuff, as we move to Git, and a new release, it makes sense to change the name of the projects to a persistent name, that won't change from release to release, and instead we'll just make persistent branches of those projects. The name currently proposed for new project will be org.eclipse.simrel.builds which will initially be a copy of org.eclipse.juno.builds (done after Friday 8/3). 2) Makes sense, I have no qualms about the name of the project. I assume the git repo would actually be called org.eclipse.simrel.builds.git right? Third, right after we migrate to Git, and get the build running again with those Git repos, we will branch master of org.eclipse.simrel.builds to Juno_maintenance. From that point on, master will be for Kepler and Juno_maintenance for Juno SR1. I expect this all to happen before Kepler M1 +0 which is 8/10 [2] (And Juno SR1 aggregation starts shortly after that. [3] ) 3) Ok Fourth, we need the maintenance branch to be able to build at any time ... so, everyone needs to get and keep that up to date, if anything breaks from what ever your final release was (which, should be unlikely). But ... 4) Again, okay. But I think we need to talk due to WTP's pickup of EclipseLink (soon), I'm not certain how it is decided what to include, and duplicates can easily ensue if we get out-of-sync. Fifth, due to some discussions in some bug somewhere [4], it was decided that as we start a new release, ALL projects will start off disabled in the aggregation build. The project team will need to re-enable when they are ready and committed to Kepler, which should be for M1 for those participating in Juno. That would be by 8/22 at the latest. Anyone in Juno, but not in Kepler M1 will be assumed to not be participating in Kepler or having some troubles. Projects new to Kepler (still) have until M4 (at the latest) to join the train (but, can join earlier, if they'd like!). 5) EclipseLink will be in Kepler, but we've just completed a migration to Git, and we've decided we won't be ready to contribute a new build for Kepler M1. Instead we were planning on leaving the Juno contrib in place, until M2. Is this decision going to result in extra admin steps? Is there any way EclipseLink could be left active, as I will also be away on vacation during M1, so won't be available to activate it? ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Aggregation failure...
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). -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Aggregation failure...
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 release repo (from the last milestone - they are identical repos, but in different locations). -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] publishing from Hudson???
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 have access to the download site. However, I am running into a similar issue, though reversed... my user (that runs the script) doesn't seem to have access to the Hudson workspace. I'd rather not have Hudson copy the bits to build then have a separate process copy them again from build to download, so I'm posting here to find out what other teams are doing. Thanks. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Contributed new build of EclipseLink (pre-RC4)
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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Orbit and Maven question...
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 never answered you main question, so will now confirm, yes, that's
pretty much it. The first three segments are meant to match exactly the
original 3rd party jar/bundle, but the qualifier is not literally
date/time built but rather date/time of last CVS change, just to be
explicit.
HTH
From: David M Williams/Raleigh/IBM@IBMUS
To: Cross project issuescross-project-issues-dev@eclipse.org,
Date: 01/03/2012 03:07 PM
Subject:Re: [cross-project-issues-dev] Orbit and Maven question...
Sent by:cross-project-issues-dev-boun...@eclipse.org
Yes, I am still lead, and no, no eclipse-maven coordination about
versioning that I am aware of.
There is some ongoing discussion of maven-orbit issues in bug 364469 [1]
and elsewhere, but first I've heard of versioning issues.
The problem of OSGi and Maven treating 3 part versions opposite of each
other sounds like a whopper.
You might already know the answer, but a broader question might be if OSGi
and Maven have tried to coordinate anything about versioning, which could
be asked on OSGi mailing list,
osgi-...@mail.osgi.org .
As an aside, Orbit specific questions can be asked on
orbit-...@eclipse.org.
As another aside, the info pages produced by the Eclipse Foundation should
always be accurate in terms of leads, etc., see
http://www.eclipse.org/projects/listofprojects.php
or for orbit specifically,
http://www.eclipse.org/projects/project.php?id=tools.orbit
Thanks, sounds like some important issues between communities and nice to
know someone is working on them. I'm sure many in Eclipse will be
interested in your progress or outcome.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=364469
From:Eric Gwineric.g...@oracle.com
To: David M Williams/Raleigh/IBM@IBMUS, Cross project issues
cross-project-issues-dev@eclipse.org,
Date:01/03/2012 02:15 PM
Subject: [cross-project-issues-dev] Orbit and Maven question...
Sent by: cross-project-issues-dev-boun...@eclipse.org
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 followed by the build date:
javax.foo.jar (version 1.0.3) -javax.foo_1.0.3.date/time built.jar
My understanding is that this is the case, and that it is followed to
easily track the jar that is wrapped (1.0.3), and maintain the ability to
fix wrapping bugs (by changing the qualifier:1.0.3.x).
The reason I'm asking is that our team publishes a maven repository for our
artifacts, and has for years. A few years ago we added our run-time
dependencies (which come from orbit).
At the time there was no coordinated effort to support Maven at Eclipse,
and we were fairly new to Maven as well. Since Orbit could release many
updated versions of the same bundle:
javax.foo:1.0.3.x
javax.foo:1.0.3.y
javax.foo:1.0.3.z
We had a problem.
Maven standards recognize only a three-part version and qualifier, but
there are special rules, so in order to maintain the immutability of a
version (javax.foo:1.0.3.x) we had to publish Orbit bundles using the
qualifier as well. However, opposite of OSGi standards, with Maven a
three-part version alone (1.0.3) is always higher than three-part version
and qualifier (1.0.3-x) {That meant that 1.0.3 would always supersede
1.0.3-anything}. In an attempt to eliminate confusion between versions,
we normalized using the four-part Orbit version (1.0.3.x), so we could
publish updated Orbit bundles. A side-effect in Maven is that indexing
won't work.
I'm wondering if you are aware of any standards Eclipse has adopted for
Orbit bundles with the Mavenization projects. We've been asked to migrate
to the Eclipse Maven repository, and I want to be sure I don't duplicate
effort, and curious at the solution they reached.
-Eric
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
[cross-project-issues-dev] Orbit and Maven question...
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 followed by the build date:
javax.foo.jar (version 1.0.3) - javax.foo_1.0.3.date/time built.jar
My understanding is that this is the case, and that it is followed to easily
track the jar that is wrapped (1.0.3), and maintain the ability to fix wrapping
bugs (by changing the qualifier:1.0.3.x).
The reason I'm asking is that our team publishes a maven repository for our
artifacts, and has for years. A few years ago we added our run-time
dependencies (which come from orbit).
At the time there was no coordinated effort to support Maven at Eclipse, and we
were fairly new to Maven as well. Since Orbit could release many updated
versions of the same bundle:
javax.foo:1.0.3.x
javax.foo:1.0.3.y
javax.foo:1.0.3.z
We had a problem.
Maven standards recognize only a three-part version and qualifier, but there are special rules,
so in order to maintain the immutability of a version (javax.foo:1.0.3.x) we had to
publish Orbit bundles using the qualifier as well. However, opposite of OSGi standards, with
Maven a three-part version alone (1.0.3) is always higher than three-part version and qualifier
(1.0.3-x) {That meant that 1.0.3 would always supersede 1.0.3-anything}. In an attempt
to eliminate confusion between versions, we normalized using the four-part Orbit version
(1.0.3.x), so we could publish updated Orbit bundles. A side-effect in Maven is that indexing
won't work.
I'm wondering if you are aware of any standards Eclipse has adopted for Orbit
bundles with the Mavenization projects. We've been asked to migrate to the
Eclipse Maven repository, and I want to be sure I don't duplicate effort, and
curious at the solution they reached.
-Eric
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Empty EclipseLink p2 repository for Juno
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 (which may actually only be Jubula). I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=364542 to track this issue. - Zeb ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] For Maven users: Questions about versions and Eclipse
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 bundle-version, and can be dealt with separately. On 08/11/2011 11:07 AM, Joakim Erdfelt wrote: The important thing to your question is how the various plugins for the maven projects finally place the dependencies into a means that satisfies the OSGi framework you are using. Yes it was. Part of my concern was that P2 and/or Equinox seems to link the bundle's filename with the internal bundle-name and bundle-version, if Maven did the same with the version parameter the resulting bundle wouldn't work in Equinox/P2, and that led to the question of how other teams got around the issue (which seems not to be an issue). Thanks. -Eric ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
