Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Am 05.05.2016 um 22:59 schrieb Mykola Nikishov: > Markus Koschany writes: > >> The new build system Tycho is completely different and is now Maven >> based. It must be packaged first. Several modules must be updated as >> well. > > Strictly speaking, Eclipse Tycho is just a set of Maven plug-ins and > (just a wild guess) not that hard to package. > > The much bigger problem is p2 repositories that Tycho uses to download > dependencies from. These dependencies are OSGi bundles and should be > packaged first, right? You will have to package all build-dependencies as separate Debian packages if they are not already available. Downloading dependencies at build time from untrusted repositories is not allowed in Debian. Markus signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Hi! On 04/29/2016 07:55 PM, Markus Koschany wrote: > > No worries. Valid questions won't offend me but I couldn't resist to do > some straight talking here. Ok, good. > If you aren't scared yet, read on... > No, not at all > Luca Vercelli worked on Tycho before but he just wanted to get the > package into Debian and didn't really want to maintain it. You could > search for "debian java list tycho" to find some correspondence on our > mailing list. > > e.g. > > https://lists.debian.org/debian-java/2016/01/msg00015.html > > > He also uploaded an unfinished package of Tycho to mentors.debian.net. > It is not perfect but a first start. > > https://mentors.debian.net/package/tycho > > If we want to get Eclipse 4.x into Stretch, Tycho should be the first > goal. After that we should focus on updating src:eclipse and after that > all other plugins/modules but those are rather optional depending on how > many people intend to help. > > My advise is to copy Fedora's approach in packaging Eclipse and Tycho or > at least to learn from them. > > http://pkgs.fedoraproject.org/cgit/rpms/tycho.git/ > http://pkgs.fedoraproject.org/cgit/rpms/eclipse.git/ > https://fedoraproject.org/wiki/Eclipse > > We should find a way to make packaging Eclipse plugins and the base IDE > much simpler in the long run. Thanks for all the info, that is a very good starting point. I have only been related to native library packaging and haven't done Java packaging yet but the documentation I found so far seems great. So this might take me a while to get on track. > If you have questions, or would like to request reviews and sponsorship, > please feel free to ask on debian-j...@list.debian.org or on IRC at > irc.debian.org, #debian-java. I will, thank you. Greetings Peter signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Am 29.04.2016 um 18:47 schrieb Peter Spiess-Knafl: > Hi Markus! > > On 04/29/2016 04:34 PM, Markus Koschany wrote: >> >> Hi, >> >> the answer is pretty simple. Someone needs to do the work because >> Eclipse won't package itself. > > I did not mean to offend anybody, just wanted to know if its just lack > of time or if there are other already known problems for not packaging it. No worries. Valid questions won't offend me but I couldn't resist to do some straight talking here. >> A lot of time has passed between the >> current version in Debian and the most recent version. The new build >> system Tycho is completely different and is now Maven based. It must be >> packaged first. Several modules must be updated as well. And most >> importantly Eclipse must be maintained for the future. It's not about >> getting a new version into Debian and then you can stop working on it >> and everything will be fine. That's a constant process of repeating tasks. >> > > Of course, its not solely packaging and than you are fine but currently > that would be the first required action I guess. First of all, thanks for your interest in Eclipse. You're right that packaging a newer release is the first step. However you're not the first one who tried it and many people underestimate the importance or difference between packaging something and maintaining it. Maintaining is a recurring activity and by packaging something you automatically opt-in for keeping a package in good shape, not forever, but at least for the foreseeable future. Otherwise you would simply shift the responsibility to another team member and that's not fair in my opinion. We are not looking for the fire-and-forget maintainer but for someone who responds to bug reports, fixes bugs in his packages, forwards patches upstream etc. Then it is completely fine if you only want to maintain one or two packages and you are here at the right place. >> In my opinion it should be obvious that Eclipse needs help. So an RFH >> bug won't change much. > > Maybe not, but it will certainly not do any harm and maybe draw > attention to more developers, maintainers or people who might want to help. Granted, it won't hurt and I wouldn't object if somebody filed one. In my opinion RFH bug reports are often not very useful. People who really care about a package get involved with the packaging anyway, or they send patches, contact us on IRC or the mailing list. Those guys are promising because they show autonomy. RFH bugs often attract people who have never done any packaging work before. I definitely would want that those people get more involved with Debian but they should show at least some will to overcome obstacles. People who need too much hand-holding will quickly give up when they face something unexpected or complicated and Eclipse is one of the most complex pieces of Java software in the universe. If you aren't scared yet, read on... >> Eclipse requires at least one dedicated >> maintainer but the more the merrier. So if you want to help us >> to_maintain_ the packages, be more than welcome. I would help you to get >> the packages into Debian. >> > > That is good to know. So currently nobody is working on it? I saw you > made some commits on an experimental branch regarding 4.5.1. > > I will take a deeper look and try to check which steps are required to > make an upgrade possible. > > You already mentioned packaging the new build-system (tycho). That seems > a logical step to start with. > > If any of the current maintainers could provide additional information > to whats required, I would appreciate it very much. Luca Vercelli worked on Tycho before but he just wanted to get the package into Debian and didn't really want to maintain it. You could search for "debian java list tycho" to find some correspondence on our mailing list. e.g. https://lists.debian.org/debian-java/2016/01/msg00015.html He also uploaded an unfinished package of Tycho to mentors.debian.net. It is not perfect but a first start. https://mentors.debian.net/package/tycho If we want to get Eclipse 4.x into Stretch, Tycho should be the first goal. After that we should focus on updating src:eclipse and after that all other plugins/modules but those are rather optional depending on how many people intend to help. My advise is to copy Fedora's approach in packaging Eclipse and Tycho or at least to learn from them. http://pkgs.fedoraproject.org/cgit/rpms/tycho.git/ http://pkgs.fedoraproject.org/cgit/rpms/eclipse.git/ https://fedoraproject.org/wiki/Eclipse We should find a way to make packaging Eclipse plugins and the base IDE much simpler in the long run. If you have questions, or would like to request reviews and sponsorship, please feel free to ask on debian-j...@list.debian.org or on IRC at irc.debian.org, #debian-java. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Hi Markus! On 04/29/2016 04:34 PM, Markus Koschany wrote: > > Hi, > > the answer is pretty simple. Someone needs to do the work because > Eclipse won't package itself. I did not mean to offend anybody, just wanted to know if its just lack of time or if there are other already known problems for not packaging it. > A lot of time has passed between the > current version in Debian and the most recent version. The new build > system Tycho is completely different and is now Maven based. It must be > packaged first. Several modules must be updated as well. And most > importantly Eclipse must be maintained for the future. It's not about > getting a new version into Debian and then you can stop working on it > and everything will be fine. That's a constant process of repeating tasks. > Of course, its not solely packaging and than you are fine but currently that would be the first required action I guess. > In my opinion it should be obvious that Eclipse needs help. So an RFH > bug won't change much. Maybe not, but it will certainly not do any harm and maybe draw attention to more developers, maintainers or people who might want to help. > Eclipse requires at least one dedicated > maintainer but the more the merrier. So if you want to help us > to_maintain_ the packages, be more than welcome. I would help you to get > the packages into Debian. > That is good to know. So currently nobody is working on it? I saw you made some commits on an experimental branch regarding 4.5.1. I will take a deeper look and try to check which steps are required to make an upgrade possible. You already mentioned packaging the new build-system (tycho). That seems a logical step to start with. If any of the current maintainers could provide additional information to whats required, I would appreciate it very much. > Regards, > > Markus > Thanks for your reply. Greetings Peter signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Am 29.04.2016 um 16:12 schrieb Peter Spiess-Knafl: > Hi! > > I would also like to know what is exactly the problem that prevents > upgrading to a more recent version of Eclipse? > > I think it would be really worth putting effort into getting the latest > version (or at least a more recent version form 4.x) of eclipse into the > next release of Debian. > > I could not find an RFH bug for Eclipse but I think one should be filed, > because the current version, even in unstable, is almost four years old. > > Greetings > Peter Hi, the answer is pretty simple. Someone needs to do the work because Eclipse won't package itself. A lot of time has passed between the current version in Debian and the most recent version. The new build system Tycho is completely different and is now Maven based. It must be packaged first. Several modules must be updated as well. And most importantly Eclipse must be maintained for the future. It's not about getting a new version into Debian and then you can stop working on it and everything will be fine. That's a constant process of repeating tasks. In my opinion it should be obvious that Eclipse needs help. So an RFH bug won't change much. Eclipse requires at least one dedicated maintainer but the more the merrier. So if you want to help us to_maintain_ the packages, be more than welcome. I would help you to get the packages into Debian. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Hi! I would also like to know what is exactly the problem that prevents upgrading to a more recent version of Eclipse? I think it would be really worth putting effort into getting the latest version (or at least a more recent version form 4.x) of eclipse into the next release of Debian. I could not find an RFH bug for Eclipse but I think one should be filed, because the current version, even in unstable, is almost four years old. Greetings Peter
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
On 07/06/2014 12:28 AM, Adrien Grellier wrote: > Hi, > > In my laboratory, we are using Debian as the official Linux distribution and > Eclipse as the official EDI. So I would like to know if there is any hope to > have the 4.* series in Debian before the freeze ? Or will we stay with the > 3.* series ? > > The freeze start on september, so there is only 2 month to make it… > > Thanks for your work, > > Regards, Hello Adrien, It's nice to hear that your laboratory is using to Debian, and I wish I could state otherwise, however, I think it's very unlikely that we will have Eclipse 4.x packages ready for the jessie release. That said, I would be happy to be proven wrong. I haven't looked at the challenges of packaging Eclipse 4 directly, but suspect that it's a large undertaking. It's primarily a question of having sufficient volunteer developers to go around. I didn't want your question to go without an answer. Regards, tony signature.asc Description: OpenPGP digital signature
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Hi, In my laboratory, we are using Debian as the official Linux distribution and Eclipse as the official EDI. So I would like to know if there is any hope to have the 4.* series in Debian before the freeze ? Or will we stay with the 3.* series ? The freeze start on september, so there is only 2 month to make it… Thanks for your work, Regards, Adrien signature.asc Description: This is a digitally signed message part.
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
I also need Eclipse 4.2 to debug Caleydo, which doesn't support 3.8... Sincerely, ciel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Package: eclipse Version: 3.8.0~rc4-1 Severity: wishlist Dear Maintainer, With the Juno simultaneous release of Eclipse, the 3.x series has been deprecated in favor of 4.x. According to the press release entitled "Eclipse Juno Release Train Has Arrived": "Eclipse 4.2 in now the mainstream platform for the Eclipse community. The existing Eclipse 3.x code stream is being put into maintenance mode. Eclipse 4.2 includes a compatibility layer that allows existing Eclipse plugins and RCP applications to work on the new platform." http://www.eclipse.org/org/press-release/20120627_junorelease.php Eclipse 3.8 is not considered the main release of Eclipse Juno but is only intended for backwards compatibility. Please move the wheezy release from 3.8 to 4.2. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages eclipse depends on: ii eclipse-jdt 3.8.0~rc4-1 ii eclipse-pde 3.8.0~rc4-1 eclipse recommends no packages. eclipse suggests no packages. Versions of packages eclipse-platform depends on: ii ant1.8.2-4 ii ant-optional 1.8.2-4 ii default-jre [java6-runtime]1:1.6-47 ii eclipse-platform-data 3.8.0~rc4-1 ii eclipse-rcp3.8.0~rc4-1 ii gcj-4.7-jre [java5-runtime]4.7.1-1 ii gconf-service 3.2.5-1 ii java-common0.47 ii libc6 2.13-33 ii libcommons-codec-java 1.6-1 ii libcommons-httpclient-java 3.1-10 ii libcommons-logging-java1.1.1-9 ii libgconf-2-4 3.2.5-1 ii libglib2.0-0 2.32.3-1 ii libjetty8-java 8.1.3-4 ii libjsch-java 0.1.42-2 ii liblucene2-java2.9.4+ds1-4 ii libservlet3.0-java 7.0.28-1 ii multiarch-support 2.13-33 ii openjdk-6-jre [java6-runtime] 6b24-1.11.3-2 ii openjdk-7-jre [java6-runtime] 7~u3-2.1.1-1 ii sat4j 2.3.1-1 Versions of packages eclipse-platform recommends: ii eclipse-pde 3.8.0~rc4-1 Versions of packages eclipse-platform suggests: ii eclipse-jdt 3.8.0~rc4-1 Versions of packages eclipse-pde depends on: ii default-jre [java6-runtime]1:1.6-47 ii eclipse-jdt3.8.0~rc4-1 ii eclipse-platform 3.8.0~rc4-1 ii gcj-4.7-jre [java5-runtime]4.7.1-1 ii libasm3-java 3.3.2-1 ii openjdk-6-jre [java6-runtime] 6b24-1.11.3-2 ii openjdk-7-jre [java6-runtime] 7~u3-2.1.1-1 eclipse-pde suggests no packages. Versions of packages eclipse-jdt depends on: ii default-jre [java6-runtime]1:1.6-47 ii eclipse-platform 3.8.0~rc4-1 ii gcj-4.7-jre [java5-runtime]4.7.1-1 ii junit 3.8.2-8 ii junit4 4.10-3 ii libhamcrest-java 1.2-2 ii openjdk-6-jre [java6-runtime] 6b24-1.11.3-2 ii openjdk-7-jre [java6-runtime] 7~u3-2.1.1-1 Versions of packages eclipse-jdt recommends: ii default-jdk 1:1.6-47 eclipse-jdt suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org