Bug 188659 - Maintainer timeout: Update java/eclipse to 4.3.2, request maintainership
Maintainer timeout: Update java/eclipse to 4.3.2, request maintainership
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: John Marino
:
: 180243 188904 (view as bug list)
Depends on:
Blocks: 191798
  Show dependency treegraph
 
Reported: 2014-04-15 14:30 UTC by Jimmy Kelley
Modified: 2014-07-11 05:44 UTC (History)
4 users (show)

See Also:


Attachments
Updated port using distfiles (177.19 KB, text/plain)
2014-06-19 20:42 UTC, Jonathan Chen
no flags Details
latest shar of updated port (29.29 KB, application/gzip)
2014-06-20 13:08 UTC, Jimmy Kelley
no flags Details
Poudriere failure log (708.53 KB, application/octet-stream)
2014-06-20 21:11 UTC, John Marino
no flags Details
port shar updated for stage-qa issues (177.78 KB, application/x-shar)
2014-06-23 12:54 UTC, Jimmy Kelley
no flags Details
fix bad patch (177.78 KB, application/x-shar)
2014-06-26 00:12 UTC, Jimmy Kelley
no flags Details
fix bad patch take 2 (177.78 KB, application/x-shar)
2014-06-26 02:11 UTC, Jimmy Kelley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jimmy Kelley 2014-04-15 14:30:00 UTC
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
Comment 1 Edwin Groothuis freebsd_committer 2014-04-15 18:20:40 UTC
Class Changed
From-To: maintainer-update->change-request

Fix category (submitter is not maintainer) (via the GNATS Auto Assign 
Tool)
Comment 2 Edwin Groothuis freebsd_committer 2014-04-15 18:20:42 UTC
Responsible Changed
From-To: freebsd-ports-bugs->eclipse

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 3 Baptiste Daroussin freebsd_committer 2014-04-29 07:28:10 UTC
Responsible Changed
From-To: eclipse->bapt

I'll take it.
Comment 4 baptiste.daroussin 2014-04-29 07:32:02 UTC
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
Comment 5 Baptiste Daroussin freebsd_committer 2014-04-29 08:27:18 UTC
Responsible Changed
From-To: bapt->freebsd-ports-bugs

Give a chance to any committer to get into it
Comment 6 Jonathan Chen 2014-06-06 07:00:28 UTC
*** Bug 188904 has been marked as a duplicate of this bug. ***
Comment 7 John Marino freebsd_committer 2014-06-19 11:05:51 UTC
*** Bug 180243 has been marked as a duplicate of this bug. ***
Comment 8 John Marino freebsd_committer 2014-06-19 11:09:07 UTC
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?
Comment 9 Jonathan Chen 2014-06-19 20:42:52 UTC
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.
Comment 10 John Marino freebsd_committer 2014-06-19 20:54:42 UTC
okay, does ljboiler still agree to be the maintainer?

Is this shar ready to go?
Comment 11 Jimmy Kelley 2014-06-20 02:29:27 UTC
(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.
Comment 12 Jimmy Kelley 2014-06-20 13:08:05 UTC
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.
Comment 13 John Marino freebsd_committer 2014-06-20 13:12:07 UTC
okay, so now is it ready to go to the best of your knowledge?  :)
Comment 14 Jimmy Kelley 2014-06-20 13:24:38 UTC
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...
Comment 15 John Marino freebsd_committer 2014-06-20 13:27:10 UTC
okay, cool.  I can test it in poudriere.  Assuming it passes cleanly, I'll commit it soon afterwards.
Comment 16 John Marino freebsd_committer 2014-06-20 18:35:27 UTC
(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.
Comment 17 John Marino freebsd_committer 2014-06-20 18:40:19 UTC
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?
Comment 18 Jimmy Kelley 2014-06-20 19:52:13 UTC
(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 19 John Marino freebsd_committer 2014-06-20 19:58:15 UTC
Comment on attachment 143939 [details]
Updated port using distfiles

Yep, Jonathan's was 177K, no problem
Comment 20 Jimmy Kelley 2014-06-20 20:10:20 UTC
(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.
Comment 21 John Marino freebsd_committer 2014-06-20 20:16:04 UTC
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...
Comment 22 John Marino freebsd_committer 2014-06-20 21:11:57 UTC
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?
Comment 23 Jimmy Kelley 2014-06-20 21:24:14 UTC
(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.
Comment 24 John Marino freebsd_committer 2014-06-20 21:25:58 UTC
scroll far, far back.  signal 9 is a symptom.  There are 8 errors before all that [INFO] stuff.
Comment 25 John Marino freebsd_committer 2014-06-20 21:27:32 UTC
to be clear, this is not a disk space or memory issue. I have plenty of both.
Comment 26 Jimmy Kelley 2014-06-20 21:41:20 UTC
Are you referring to this:
                ^^^^^^^^^^^^
Resource leak: 'jarredPlugin' is never closed
8 problems (8 warnings)
[INFO]

at around line 237251 of 237892 [99%] ?
Comment 27 John Marino freebsd_committer 2014-06-20 21:43:53 UTC
yep.  I didn't look any further, I zipped up the log and mailed it when I saw that.
Comment 28 Jimmy Kelley 2014-06-20 21:49:22 UTC
Just warnings.  Several sections have those, with counts way above 8.
Comment 29 John Marino freebsd_committer 2014-06-20 21:54:37 UTC
I'll try again with poudriere testport instead of poudriere bulk
Comment 30 John Marino freebsd_committer 2014-06-20 22:18:35 UTC
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.
Comment 31 John Marino freebsd_committer 2014-06-20 22:52:29 UTC
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
Comment 32 Jimmy Kelley 2014-06-23 12:54:34 UTC
Created attachment 144062 [details]
port shar updated for stage-qa issues
Comment 33 John Marino freebsd_committer 2014-06-23 21:44:12 UTC
Thanks.  I don't have access to the poudriere computer for 2 more days.  I'll check this latest version when I get home.
Comment 34 John Marino freebsd_committer 2014-06-25 22:26:13 UTC
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.
Comment 35 John Marino freebsd_committer 2014-06-25 23:54:30 UTC
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)
Comment 36 John Marino freebsd_committer 2014-06-25 23:58:07 UTC
it seems that hunk was missing the "space" character to start the first line.  I'm guessing the patch was manually constructed.
Comment 37 Jimmy Kelley 2014-06-26 00:12:55 UTC
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.
Comment 38 Jimmy Kelley 2014-06-26 00:13:33 UTC
(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.
Comment 39 John Marino freebsd_committer 2014-06-26 00:15:50 UTC
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.
Comment 40 John Marino freebsd_committer 2014-06-26 00:18:13 UTC
btw, the "fix bad patch" patch is still bad.

You have "-s (LFLAGS)" instead of "-s $(LFLAGS)"
Comment 41 Jimmy Kelley 2014-06-26 02:11:08 UTC
Created attachment 144135 [details]
fix bad patch take 2
Comment 42 John Marino freebsd_committer 2014-06-26 06:27:06 UTC
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.
Comment 43 John Marino freebsd_committer 2014-06-26 07:21:59 UTC
I confirmed that it happily builds without "USES=desktop-file-utils" so I removed it.
Comment 44 commit-hook freebsd_committer 2014-06-26 08:48:25 UTC
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
Comment 45 John Marino freebsd_committer 2014-06-26 09:04:30 UTC
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?
Comment 46 commit-hook freebsd_committer 2014-06-26 09:13:28 UTC
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
Comment 47 commit-hook freebsd_committer 2014-06-26 09:22:30 UTC
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
Comment 48 John Marino freebsd_committer 2014-06-26 09:30:00 UTC
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.
Comment 49 John Marino freebsd_committer 2014-06-26 09:50:29 UTC
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.
Comment 50 John Marino freebsd_committer 2014-06-27 21:54:19 UTC
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.
Comment 51 Jimmy Kelley 2014-06-28 14:45:07 UTC
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.
Comment 52 John Marino freebsd_committer 2014-06-28 14:56:21 UTC
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?
Comment 53 commit-hook freebsd_committer 2014-06-28 22:48:23 UTC
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/
Comment 54 Jimmy Kelley 2014-06-29 12:04:01 UTC
(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.
Comment 55 js 2014-06-30 22:50:57 UTC
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.
Comment 56 Jimmy Kelley 2014-07-04 21:13:45 UTC
(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.
Comment 57 John Marino freebsd_committer 2014-07-10 15:56:48 UTC
Is there any news about the plugins in general?

This PR is still open due to the 8 plugins that used the extra Makefile.
Comment 58 Jimmy Kelley 2014-07-10 23:40:47 UTC
(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.
Comment 59 John Marino freebsd_committer 2014-07-11 05:44:17 UTC
Okay, thanks.  I'm moving plugin discussion over to that PR.