PR 180243 has been idle/unanswered for over 4 months. Request maintainership of the port with an update to version 4.3.2. This will bring the Eclipse port to the latest official release version; it is also the version that supports a patch from the Eclipse download sites to enable building projects for Java 8 runtime environments. Fix: Shar file for updated port is available at http://webpages.charter.net/ljboiler/eclipseKeplerSR2.shar.gz
Class Changed From-To: maintainer-update->change-request Fix category (submitter is not maintainer) (via the GNATS Auto Assign Tool)
Responsible Changed From-To: freebsd-ports-bugs->eclipse Over to maintainer (via the GNATS Auto Assign Tool)
Responsible Changed From-To: eclipse->bapt I'll take it.
2 notes here: it is forbidden to fetch the distfiles from git as we really need to be able be able to validate against a checksum without network access. It would be better to get a patch against the current port. regards, Bapt
Responsible Changed From-To: bapt->freebsd-ports-bugs Give a chance to any committer to get into it
*** Bug 188904 has been marked as a duplicate of this bug. ***
*** Bug 180243 has been marked as a duplicate of this bug. ***
Didn't this topic about how to work around github come up on ports@ recently? Also, I don't think a shar is appropriate for a ports update. When is a new diff going to be attached here?
Created attachment 143939 [details] Updated port using distfiles I've updated the original shar file to: * use a snapshot of the git-repo * build offline * maintainer is still the OP The OP has totally rewritten and cleaned up the port, the only file that is the same is pkg-descr. The patch file is 3.5 times the shar file - it is easier to remove the old port and extract.
okay, does ljboiler still agree to be the maintainer? Is this shar ready to go?
(In reply to John Marino from comment #10) > okay, does ljboiler still agree to be the maintainer? > > Is this shar ready to go? No problem with being the maintainer. This is no longer building successfully on a 9.2-x86 VM that I have, so I'm looking into that. Just a note: I tried running this through RedPorts, but it appears that this port requires a whole lot more work space than RedPorts allows: "no space left on device" error, and decke told me that it might be because the build is running out of tmpfs space. /usr/ports/java/eclipse, after a "make package" takes just over 16Gb.
Created attachment 143957 [details] latest shar of updated port This now builds for me after fetching without needing to get to the internet (had to remove the step that assembled an update repository), and I also corrected a problem where it was hard-coded to build the x86_64 (amd64) configuration rather than being patched for whatever platform this was being built on.
okay, so now is it ready to go to the best of your knowledge? :)
Indeed, I think it is. P.S. A big thank-you to Jonathan Chen for putting together those distfiles. I have copied those over to my own place on GoogleDrive (the current shar is fetching things from there). Now, on to getting ready for Eclipse 4.4, which supposedly is coming soon...
okay, cool. I can test it in poudriere. Assuming it passes cleanly, I'll commit it soon afterwards.
(In reply to ljboiler from comment #12) > Created attachment 143957 [details] > latest shar of updated port Ah, you really need to stop gzipping these files. It's a huge PITA and it prevents us from view them in the browser too.
also, what should we do about eclipse-devel? delete it? What's the benefit of having two eclipses assuming -devel is even newer than the main eclipse?
(In reply to John Marino from comment #16) > (In reply to ljboiler from comment #12) > > Created attachment 143957 [details] > > latest shar of updated port > > Ah, you really need to stop gzipping these files. It's a huge PITA and it > prevents us from view them in the browser too. Sorry. The old GNATS system couldn't handle anything that big, but I take it that Bugzilla can? I'll remember that.
Comment on attachment 143939 [details] Updated port using distfiles Yep, Jonathan's was 177K, no problem
(In reply to John Marino from comment #17) > also, what should we do about eclipse-devel? delete it? What's the benefit > of having two eclipses assuming -devel is even newer than the main eclipse? It was used just like any other of the -devel ports: to track any up-and-coming release, allowing people to play with the milestone and RC versions that were available. In the past, eclipse-devel would even be used for a brand new Eclipse release until it was decided that it was ready for prime time and would replace the existing eclipse port. I believe that was being planned for the current eclipse-devel port , and then the freebsd-eclipse "team" evaporated. I had been working on getting the Eclipse 4.4 code ready to go into that eclipse-devel spot, but set it aside a couple of months ago, waiting to see if/when the main eclipse port would be accepted. I would say that once the eclipse 4.3.2 port is in, the current eclipse-devel 4.2.0 port could be deleted, and I'll work on following the old tradition with a new eclipse-devel port as soon as I can.
In my experience, -devel have inconsistent results. They are bitrotted and lead to confusion just as often as they offer the shiny new version. In the case of eclipse with lots of plugins, that just leads to even more complexity. Does this plugin work with regular but not -devel or vice-versa? If I had a vote, I'd vote for a single eclipse port. The maintainer of it should work on new versions behind the scenes and be the sole judge of when it's ready for prime-time (and only use releases for stability) I see it like stating you have two quarterbacks. You really have none. :) It's probably better to concentrate on one good eclipse port. That's my opinion. I really don't like -devel ports...
Created attachment 143974 [details] Poudriere failure log Bad news, guys. This failed to build in poudriere 3.0.16 on FreeBSD 10/amd64. I've attached the log. Any ideas?
(In reply to John Marino from comment #22) > Created attachment 143974 [details] > Poudriere failure log > > Bad news, guys. This failed to build in poudriere 3.0.16 on FreeBSD > 10/amd64. I've attached the log. > > Any ideas? Well, if I understand "Signal 9", that's telling me that poudriere decided for some reason to kill off the build. I haven't played with poudriere to know why it would want to do that (time limit / memory limit / disk space limit ?). The build was nearly done, down to the part of assembling everything together into a installable eclipse tarball, and that's where it gets to eating up disk space pretty quick.
scroll far, far back. signal 9 is a symptom. There are 8 errors before all that [INFO] stuff.
to be clear, this is not a disk space or memory issue. I have plenty of both.
Are you referring to this: ^^^^^^^^^^^^ Resource leak: 'jarredPlugin' is never closed 8 problems (8 warnings) [INFO] at around line 237251 of 237892 [99%] ?
yep. I didn't look any further, I zipped up the log and mailed it when I saw that.
Just warnings. Several sections have those, with counts way above 8.
I'll try again with poudriere testport instead of poudriere bulk
another signal 9 with testport. I'm going to check the poudriere default settings to see if it's limiting tmpfs or something. I'm worried about the builders. This is one port that needs binary packages built.
I changed poudriere to only use tmpfs on the wrkdir partition and this time it finished (lending credence to hypthosis that the build ran out of memory) But it didn't pass the QA checks: =========================================================================== ====> Running Q/A tests (stage-qa) Error: 'lib/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile. profile/.data/.settings/org.eclipse.equinox.p2.artifact.repository.prefs' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile. profile/.data/.settings/org.eclipse.equinox.p2.metadata.repository.prefs' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/configuration/org.eclipse.osgi/bundles/112/data/cache.timestamps' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/configuration/org.eclipse.osgi/bundles/112/data/timestamps1438412847' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/configuration/org.eclipse.osgi/bundles/103/data/-546387271/artifacts.xml' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/configuration/org.eclipse.osgi/bundles/123/data/108308412/content.xml' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Error: 'lib/eclipse/configuration/org.eclipse.osgi/bundles/123/data/108308412/artifacts.xml' is referring to /wrkdirs/usr/ports/java/eclipse/work/stage Warning: 'lib/eclipse/plugins/org.eclipse.equinox.launcher.gtk.freebsd.x86_64_1.1.200.v20140620-2227/eclipse_1508.so' is not stripped consider using ${STRIP_CMD} Warning: 'lib/eclipse/eclipse' is not stripped consider using ${STRIP_CMD} Warning: you may not need USES=desktop-file-utils *** Error code 1
Created attachment 144062 [details] port shar updated for stage-qa issues
Thanks. I don't have access to the poudriere computer for 2 more days. I'll check this latest version when I get home.
Can you explain the requirement for gpatch on FreeBSD 8 and 9? Is it a carryover? In any case, I need to change this for DragonFly. This OSREL is FreeBSD specific.
make_freebsd.mak fails to patch. And I think it's got a bug too: > $(DLL): $(DLL_OBJS) $(COMMON_OBJS) >- $(CC) $(LFLAGS) -o $(DLL) $(DLL_OBJS) $(COMMON_OBJS) $(LIBS) >+ $(CC) $-s (LFLAGS) -o $(DLL) $(DLL_OBJS) $(COMMON_OBJS) $(LIBS) I think that's supposed to be "-s $(LFLAGS)", not "$-s (LFLAGS)". I don't know why it's not patching yet though. (1 hunk failed out of 3)
it seems that hunk was missing the "space" character to start the first line. I'm guessing the patch was manually constructed.
Created attachment 144134 [details] fix bad patch Not entirely hand generated, but a cut-n-paste from one machine to another, and then hand-edited to fix the tabs that disappear when doing that. I won't be trying that again.
(In reply to John Marino from comment #34) > Can you explain the requirement for gpatch on FreeBSD 8 and 9? Is it a > carryover? In any case, I need to change this for DragonFly. This OSREL is > FreeBSD specific. The base system patch command can't deal correctly with a file path that has a space in it on the older FreeBSD versions, but gpatch can. This appears to have been fixed FreeBSD 10, and I was trying to keep dependencies (build or otherwise) to a minimum.
regarding the bad patch, I already regenerated that hunk and pasted it back in. It's building now (it got paste patch target) but now I'm going to bed and hope it's complete correctly in the morning.
btw, the "fix bad patch" patch is still bad. You have "-s (LFLAGS)" instead of "-s $(LFLAGS)"
Created attachment 144135 [details] fix bad patch take 2
at this point submitting new shars is counterproductive. It would wipe out my local modifications, not to mention it's more cumbersome to remove and extract. In any case, my fix worked so I didn't need the last two submissions. The only note I get during QA is: "Warning: you may not need USES=desktop-file-utils" I'll check that out. Otherwise it's ready to go.
I confirmed that it happily builds without "USES=desktop-file-utils" so I removed it.
A commit references this bug: Author: marino Date: Thu Jun 26 08:48:12 UTC 2014 New revision: 359322 URL: http://svnweb.freebsd.org/changeset/ports/359322 Log: java/eclipse: Update version 3.7.1 => 4.3.2 and assign maintainer At long last, eclipse has been updated to the latest release and is now under the stewardship of Jimmy Kelly. This version supports OpenJDK8 runtime environments. A special thanks to Jonathan Chen for getting the ball rolling after the PR stalled. PR: 188659 Submitted by: Jimmy Kelly Distfiles by: Jonathan Chen Verified by: F10/amd64 poudriere Changes: head/java/eclipse/Makefile head/java/eclipse/Makefile.plugins head/java/eclipse/distinfo head/java/eclipse/files/eclipse-build-config-upstream.patch head/java/eclipse/files/eclipse-build-upstream.patch head/java/eclipse/files/freebsd-support.patch head/java/eclipse/files/patch-aggregator head/java/eclipse/files/patch-dependencyManifests head/java/eclipse/files/patch-eclipse-build head/java/eclipse/files/patch-freebsd_natives head/java/eclipse/files/patch-generatedScripts head/java/eclipse/files/patch-submodules head/java/eclipse/scripts/ head/java/eclipse/scripts/pre-patch
Okay, the only thing left to do is decide about java/eclipse-devel. At a minimum, we need to mark it "IGNORE" and say use the newer "java/eclipse" instead right? I think it would be better to remove eclipse-devel completely and only concentrate on maintaining one version of eclipse well, instead of two versions badly as has been the case historically. So again, is there a compelling case to maintain competing eclipse ports?
A commit references this bug: Author: marino Date: Thu Jun 26 09:13:00 UTC 2014 New revision: 359325 URL: http://svnweb.freebsd.org/changeset/ports/359325 Log: java/eclipse: Remove troublesome comment completely Freshports won't update the entry due to choking on the MAVEN_OPTS comment. Truthfully the comment is more trouble than it's worth. First, it's MVN_OPTS, not MAVEN_OPTS. Secondly, "+=" is a no-op, so the definition should be there anyway. Thirdly, MVN_OPTS is undefined. Just remove the whole mess. PR: 188659 Changes: head/java/eclipse/Makefile
A commit references this bug: Author: marino Date: Thu Jun 26 09:22:12 UTC 2014 New revision: 359326 URL: http://svnweb.freebsd.org/changeset/ports/359326 Log: java/eclipse: Put back Makefile.plugins to unbreak index At least one port is still using Makefile.plugins. Put in a placeholder to unbreak the index. PR: 188659 Changes: head/java/eclipse/Makefile.plugins
okay, that commit broke the index because the Makefile.plugins file was removed. A quick grep reveals the following ports are trying to use that file: devel/scala-ide devel/subversive java/eclipse-webtools java/eclipse-datatools java/eclipse-emf java/eclipse-windowbuilder java/eclipse-gef java/eclipse-pydev I added a temporary Makefile.plugins to intentionally break all those ports. We need a permanent solution. By the way, if plugins are using "eclipse" and not "eclipse-devel", that's another argument for dropping eclipse-devel. Anyway, please get back quickly on what to do about these plugins. Thanks.
i just noticed that openjdk 1.7 exactly is being specified. Eclipse can't be built with openjdk 1.8? also, I noticed <pre>/<post> is being used. I am testing if <options> can be used instead. so far, so good. If it passes, I'll commit that change.
you guys were silent after the commit broke 8 ports (and the index). I think everyone expected a pretty quick response. Portmgr (antoine) at first marked all 8 ports broken and marked them for removal in 30 days, but then went back and restored to file (Makefile.plugins) http://www.freshports.org/commit.php?category=java&port=eclipse&files=yes&message_id=201406272136.s5RLaXhA022351@svn.freebsd.org When you break the index and on top of that 8 ports, please try to be proactive in the resolution as it reflects on me as well. FYI, breaking the index is a really big deal. It would be nice to have Antoine's solution reviewed and also make a decision about what to do about eclipse-devel. Portmgr will probably do something about that as well if there's no plan on the table.
The Makefile.plugins added by antoine should be fine for now; I have not tested ANY of the plugins, but my guess is that most of them will be too old to work with this new version of Eclipse. As for eclipse-devel, just delete it.
eclipse-devel: okay, great, I'll put that in work These 8 plugins: It would be fantastic if you could check each one out and note whether it should be updated, removed, or if it's okay how it is as a follow-on. We might as well do this right. I guess you can open a new bug report for that, and either assign it to me or tell me and I'll pick it up. openjdk 1.7: Did you determine if openjdk 1.8 can be used to build eclipse?
A commit references this bug: Author: marino Date: Sat Jun 28 22:47:34 UTC 2014 New revision: 359724 URL: http://svnweb.freebsd.org/changeset/ports/359724 Log: Remove java/eclipse-devel as java/eclipse is newer Given the amount of work required to maintain a single version of eclipse, it was thought prudent to focus maintenance efforts on a single port, especially since the plugins are designed for java/eclipse, not the development version. Discussed in PR. PR: 188659 Changes: head/MOVED head/java/Makefile head/java/eclipse-devel/
(In reply to John Marino from comment #52) > eclipse-devel: okay, great, I'll put that in work > > These 8 plugins: It would be fantastic if you could check each one out and > note whether it should be updated, removed, or if it's okay how it is as a > follow-on. We might as well do this right. > > I guess you can open a new bug report for that, and either assign it to me > or tell me and I'll pick it up. > > openjdk 1.7: Did you determine if openjdk 1.8 can be used to build eclipse? openjdk1.8 cannot be used to build this. Looking at the plugins.
Unfortunately, plugins installed via Help->Install New Software are not working. The install goes smoothly, but upon Eclipse restart, none of the functionality is there. In Help->About Eclipse, the plugins show under Installed Software and Installation History, but not under Features or Plugins. I've seen something similar in older versions when installing plugins as non-root. So, I logged in as root, totally uninstalled Eclipse, rm -rf /usr/local/lib/eclipse, re-installed, and ran Eclipse as root. Installed plugins, restarted Eclipse and the results are the same - plugin functionality is non-existent.
(In reply to js from comment #55) > Unfortunately, plugins installed via Help->Install New Software are not > working. The install goes smoothly, but upon Eclipse restart, none of the > functionality is there. > > In Help->About Eclipse, the plugins show under Installed Software and > Installation History, but not under Features or Plugins. I've seen > something similar in older versions when installing plugins as non-root. > So, I logged in as root, totally uninstalled Eclipse, rm -rf > /usr/local/lib/eclipse, re-installed, and ran Eclipse as root. Installed > plugins, restarted Eclipse and the results are the same - plugin > functionality is non-existent. This appears to be a bug in the latest openjdk7. Try running eclipse with openjdk6.
Is there any news about the plugins in general? This PR is still open due to the 8 plugins that used the extra Makefile.
(In reply to John Marino from comment #57) > Is there any news about the plugins in general? > > This PR is still open due to the 8 plugins that used the extra Makefile. That Makefile.plugins is fine as it is. I submitted PR 191798 to update those 8 plugins to the versions needed for eclipse 4.3.2, which points to a required PR 191766. This PR can be closed I think.
Okay, thanks. I'm moving plugin discussion over to that PR.