Regarding CDT Arduino bringing in PDE, and JDT (which you're right, is crazy) :

It looks like org.eclipse.cdt.arduino.ui -> org.eclipse.remote.ui -> org.eclipse.ui.trace , and org.eclipse.ui.trace is something packaged as part of the Eclipse PDE UI, which then brings in the JDT. The requirement for org.eclipse.ui.trace is only so that the org.eclipse.ui.trace.traceComponents extension point may be used (http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fextension-points%2Forg_eclipse_ui_trace_traceComponents.html) . I think making the dependency optional could resolve this and I would even argue that it's an upstream bug.

On the other hand this can also be considered a Fedora packaging bug. org.eclipse.ui.trace ships upstream in the SDK but not in the platform product so there's some justification for placing it in PDE. However it has no dependency on other PDE components, so maybe placing it in platform would make more sense from a user download -size perspective.

Mat, thoughts ?



Regarding the missing arduino functionality, this also appears to be a packaging bug :

eclipse-cdt-arduino requires google-gson and apache-commons-compress but they aren't symlinked into the dropins folder during %install. eclipse-cdt doesn't build using %mvn_install so this would beed to be done manually.

!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-03 11:37:21.646
!MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle com.google.gson 2.2.4.
!SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-03 11:37:21.646
!MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle org.apache.commons.compress 1.6.0.

(In reply to Roland Grunberg from comment #1)
> Regarding CDT Arduino bringing in PDE, and JDT (which you're right, is
> crazy) :
> 
> It looks like org.eclipse.cdt.arduino.ui -> org.eclipse.remote.ui ->
> org.eclipse.ui.trace , and org.eclipse.ui.trace is something packaged as
> part of the Eclipse PDE UI, which then brings in the JDT. The requirement
> for org.eclipse.ui.trace is only so that the
> org.eclipse.ui.trace.traceComponents extension point may be used
> (http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.pde.doc.
> user%2Freference%2Fextension-points%2Forg_eclipse_ui_trace_traceComponents.
> html) . I think making the dependency optional could resolve this and I
> would even argue that it's an upstream bug.
> 
> On the other hand this can also be considered a Fedora packaging bug.
> org.eclipse.ui.trace ships upstream in the SDK but not in the platform
> product so there's some justification for placing it in PDE. However it has
> no dependency on other PDE components, so maybe placing it in platform would
> make more sense from a user download -size perspective.
> 
> Mat, thoughts ?
> 

You're probably right that this dep should be optional.

I was looking for what the idiomatic usage of this extension point is and interestingly, if you look at org.eclipse.jdt.debug or org.eclipse.jdt.launching which also make use of it, you'll find no deps on org.eclipse.ui.trace in their manifests.

Dennis, could you try out the following builds to see if they resolve the issue on f23 :

This should solve the broken arduino issue :
http://koji.fedoraproject.org/koji/taskinfo?taskID=12855033
You'll need eclipse-cdt-8.8.0-6.fc23.x86_64.rpm, and eclipse-cdt-arduino-8.8.0-6.fc23.x86_64.rpm and possibly more depending on how many cdt bundles you have that would need to update as well.

This should solve the unnecessary dependence on eclipse-pde, eclipse-jdt :
http://koji.fedoraproject.org/koji/buildinfo?buildID=724986
You'll need just eclipse-remote-2.0.1-2.fc23.noarch.rpm

I'll probably end up backporting this even to f22.

eclipse-remote-2.0.1-2.fc23 eclipse-cdt-8.8.0-6.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b836b8a61b

OK, tried those but we're only half way there.

I only needed cdt, cdt-arduino, and -remote as it turned out. This
time jdt and pde were not pulled in.

But cdt-arduino still doesn't show up in preferences or the installation
details list.

google-gson and apache-commons-compress are installed but did not
get symlinked into the dropins directory as you mentioned they should.

Where precisely should those links point? I can at least try to set
them up manually and see if that's truly the only remaining problem.

The links are part of the rpm (http://koji.fedoraproject.org/koji/rpminfo?rpmID=7325960) so they should be at those locations on the system. 
'rpm -qf /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/com.google.gson_2.2.4.jar /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/org.apache.commons.compress_1.6.0.jar' should return eclipse-cdt-arduino-8.8.0-6.fc23.noarch.

eclipse-cdt-8.8.0-6.fc23, eclipse-remote-2.0.1-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b836b8a61b

(In reply to Roland Grunberg from comment #6)
> The links are part of the rpm
> (http://koji.fedoraproject.org/koji/rpminfo?rpmID=7325960) so they should be
> at those locations on the system. 
> 'rpm -qf
> /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/com.google.gson_2.2.4.
> jar
> /usr/lib64/eclipse/dropins/cdt-arduino/eclipse/plugins/org.apache.commons.
> compress_1.6.0.jar' should return eclipse-cdt-arduino-8.8.0-6.fc23.noarch.

Ah. They're correct then. I was looking directly in the dropins directory.

Still, eclipse doesn't see the plugin. And it gets stranger...

I have a laptop (Lenovo thinkpad T61) where I've been trying all this,
and a guest VM which I run on it. The host and the guest are both running
F23 up to data as of today. Just to be thorough, on each system I erased
all eclipse packages, then installed just the three new ones I need from the
set you pushed out, letting yum pull in the necessary requirements. So both
systems have the following set of eclipse packages: 

eclipse-avr-2.3.4-10.fc23.noarch
eclipse-cdt-8.8.0-6.fc23.x86_64
eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
eclipse-ecf-core-3.12.0-1.fc23.x86_64
eclipse-emf-core-2.11.1-1.fc23.x86_64
eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
eclipse-filesystem-1.0-5.fc23.x86_64
eclipse-launchbar-1.0.1-0.1.git3c10977.fc23.noarch
eclipse-platform-4.5.1-7.fc23.x86_64
eclipse-remote-2.0.1-2.fc23.noarch
eclipse-rse-3.7.0-5.git97bd591.fc23.noarch
eclipse-swt-4.5.1-7.fc23.x86_64
eclipse-tm-terminal-4.0.0-3.fc23.noarch

(I added the eclipse-avr package later. Its presence or absence
seems irrelevant.)

I have also moved ~/workspace and ~/.eclipse out of the way to
force eclipse into thinking it's getting a fresh start.

Running eclipse on the VM system under Window=>preferences=>C/C++ I
see the Arduino entry between Appearance and Autotools; on the host
system it's not there. Likewise it can be seen under Help=>Installation
Details on the VM, but not on the host.

Is there somewhere else that eclipse squirrels away hidden state
that might be messing this up? Just for grins I logged into another
uid which has never before used eclipse and got the same result: no
arduino plugin menu entry.

Does eclipse keep any other startup logs I can fish through? I did find
what are supposed to be error logs under Help=>Installation Details
in the Configuration tab. On the VM there are a couple of lines for
each start showing the Arduino plugin being started. In the host log
the string "arduino" is not to be found.

I'm at a loss.

Do you see other plugin contributions to the UI, like the C/C++ perspective, C/C++ preference page entry ? If not, this might indicate a deeper issue with the Eclipse installation itself, and not the just CDT.

The main location Eclipse modifies are in $HOME/.eclipse and the actual workspace location, so clearing/moving those should have worked. Also it's not recommended to run Eclipse as root. While I don't think you have I thought I'd mention it just in case, and an 'rpm -qV eclipse-platform' might reveal if it has been. Running as root in the past meant Eclipse would write to the shared location /usr/lib*/eclipse which pretty much destroyed the setup.

You could try creating a file called '.options' containing :

org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true

Then run : 'eclipse -debug -consolelog >log' from the same directory as the created .options file (generally in $HOME)

You can then cancel the workspace prompt, or just close it immediately and attach the contents of the log. If you see any messages about 'Unable to satisfy dependency', those would be relevant.

Created attachment 1122294 [details]
Log file from eclipse -consoleLog -debug

(In reply to Roland Grunberg from comment #9)
> Do you see other plugin contributions to the UI, like the C/C++ perspective,
> C/C++ preference page entry ? If not, this might indicate a deeper issue
> with the Eclipse installation itself, and not the just CDT.
> 

Nope, everything else shows up as it should. It's just the arduino plugin
that's a problem as far as I can see.

> The main location Eclipse modifies are in $HOME/.eclipse and the actual
> workspace location, so clearing/moving those should have worked. Also it's
> not recommended to run Eclipse as root. While I don't think you have I
> thought I'd mention it just in case, and an 'rpm -qV eclipse-platform' might
> reveal if it has been. Running as root in the past meant Eclipse would write
> to the shared location /usr/lib*/eclipse which pretty much destroyed the
> setup.
> 

'rpm -qV eclipse-platform' produces no output and return code zero. You're
right that root has never used eclipse.

> You could try creating a file called '.options' containing :
> 
> org.eclipse.equinox.p2.core/debug=true
> org.eclipse.equinox.p2.core/reconciler=true
> 
> Then run : 'eclipse -debug -consolelog >log' from the same directory as the
> created .options file (generally in $HOME)
> 
> You can then cancel the workspace prompt, or just close it immediately and
> attach the contents of the log. If you see any messages about 'Unable to
> satisfy dependency', those would be relevant.

Aha. I had discovered -consoleLog and -debug over the weekend, but the
output was very sparse and unhelpful. No mention of cdt-arduino at all
until I removed .eclipse and workspace, then this complaint showed up:

 61 !ENTRY org.eclipse.equinox.p2.publisher.eclipse 4 0 2016-02-08 16:53:12.070
 62 !MESSAGE Unable to acquire PluginConverter service during generation for: /usr/lib64/eclipse/dropins/cdt-arduino.

But the same complaint was issued for everything in dropins.

Now with your .options file the output is similarly sparse but at
least cdt-arduino is mentioned. Removing .eclipse and workspace first
produces much more information, log file attached.

This time there are a whole lot of "unable to satisfy dependency"
messages including:

!ENTRY org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.082
   1097 !MESSAGE Problems resolving provisioning plan.
   1098 !SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.082
   1099 !MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle com.google.gson 2.2.4.
   1100 !SUBENTRY 1 org.eclipse.equinox.p2.director 2 0 2016-02-08 14:40:46.084
   1101 !MESSAGE Unable to satisfy dependency from org.eclipse.cdt.arduino.core 1.0.0.201510090737 to bundle org.apache.commons.compress 1.6.0.

'rpm -qv' for google-gson and apache-commons-compress produces no output
and return code zero. I'm tempted to reinstall those packages and see
what happens...but that might just destroy evidence if there's some more
obscure bug my setup happens to have exposed. It may be better to follow
this through to the end.

What next?

Sorry for the delay, but this is quite strange to see.

The thing that stood out even more than the arduino.core failure are the org.eclipse.platform.ide failures :
!MESSAGE Unable to satisfy dependency from org.eclipse.platform.ide 4.5.1.v20160106-1000 to a.jre.javase [1.6.0].

As far as I know this happens with a corrupted Eclipse but if 'rpm -qV eclipse-platform' is quiet then this can't be the case. Is your '/etc/eclipse.ini' the same for both your host and VM ? Could you also try the following : 'find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u'. This might take some time but I'm interested to see if the result contains anything of the form 'file $FILEPATH is not owned by any package'.

I'm able to reproduce the error by doing some things that Fedora Eclipse has explicitly prevented for a while.

eclipse-cdt-8.8.0-6.fc23, eclipse-remote-2.0.1-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Roland Grunberg from comment #11)
> Sorry for the delay, but this is quite strange to see.
> 
> The thing that stood out even more than the arduino.core failure are the
> org.eclipse.platform.ide failures :
> !MESSAGE Unable to satisfy dependency from org.eclipse.platform.ide
> 4.5.1.v20160106-1000 to a.jre.javase [1.6.0].
> 
> As far as I know this happens with a corrupted Eclipse but if 'rpm -qV
> eclipse-platform' is quiet then this can't be the case. Is your
> '/etc/eclipse.ini' the same for both your host and VM ? Could you also try
> the following : 'find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u'. This
> might take some time but I'm interested to see if the result contains
> anything of the form 'file $FILEPATH is not owned by any package'.
> 
> I'm able to reproduce the error by doing some things that Fedora Eclipse has
> explicitly prevented for a while.

/etc/eclipse.ini is the same on the VM and the host.

The search for orphaned files on the VM turns up nothing:

   [root@raid-lvm-scratch Desktop]# find /usr/lib*/eclipse/ | xargs rpm -qf | sort -u
   eclipse-cdt-8.8.0-6.fc23.x86_64
   eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
   eclipse-ecf-core-3.12.0-1.fc23.x86_64
   eclipse-emf-core-2.11.1-1.fc23.x86_64
   eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
   eclipse-filesystem-1.0-5.fc23.x86_64
   eclipse-platform-4.5.1-7.fc23.x86_64
   eclipse-swt-4.5.1-7.fc23.x86_64

On the host I get this:

eclipse-cdt-8.8.0-6.fc23.x86_64
eclipse-cdt-arduino-8.8.0-6.fc23.x86_64
eclipse-ecf-core-3.12.0-1.fc23.x86_64
eclipse-emf-core-2.11.1-1.fc23.x86_64
eclipse-equinox-osgi-4.5.1-7.fc23.x86_64
eclipse-filesystem-1.0-5.fc23.x86_64
eclipse-platform-4.5.1-7.fc23.x86_64
eclipse-swt-4.5.1-7.fc23.x86_64
file /usr/lib64/eclipse/dropins/cdt-arduino/features is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/epl-v10.html is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/feature.properties is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/feature.xml is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737 is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/license.html is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/META-INF is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/features/org.eclipse.cdt.arduino_8.8.0.201510090737/META-INF/MANIFEST.MF is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins/org.eclipse.cdt.arduino.core_1.0.0.201510090737.jar is not owned by any package
file /usr/lib64/eclipse/dropins/cdt-arduino/plugins/org.eclipse.cdt.arduino.ui_1.0.0.201510090737.jar is not owned by any package


Interesting. Those orphaned features and plugins directories are from
the earlier and older eclipse-cdt-arduino which was installed from the repos
way back when. 

Here's what I think must have happened...recall I earlier mentioned moving some
of those directories around to see if the original package had just dropped them
in the wrong place. No joy, so later I moved them back where they belonged and
removed eclipse-cdt-arduino. But I must have moved those directories back to the
wrong place--they should have been under the cdt-arduino/eclipse directory. yum and
rpm will both complain if files they need to remove are already missing, but I
must have missed that. Afterward, of course, rpm will confirm the package is not
installed so I was happy. But those subdirectories got incorrectly left in place.

And that, it seems, was all it took to create the problem once the original package was fixed.

I think this definitively solves my original problem. 

However, you noted some log messages you said appeared wrong in comment #11.
That same example you gave plus numerous others still occur on both my host
and VM. I will attach both logs.

If this is really a separate issue and you want to pursue it, I'm happy to
experiment for you. Possibly one of us should open a separate bug report?

Thanks, Roland!

--Dennis

Created attachment 1135108 [details]
Attachment for comment #13

Log from the host system.

Created attachment 1135109 [details]
Another attachment for Comment #13

Log from the VM system.