After studying in more detail how the org.eclipse.core.runtime /
org.eclipse.equinox.common bundles deal with the split package
situation, I believe that our split package declaration must be
fixed in MANIFEST.MF or there is risk that an "import-package" client
would be wired by OSGi against the wrong bundle.
Also reduced the minimum execution environment of the native bundle
to J2SE-1.5 such that it is more widely usable across a broader range
of possible aadopters.
Change-Id: I6dfc0c67987203810a3fd75d49a5f26bb7ee30c1
Signed-off-by: Martin Oberhuber <martin.oberhuber@windriver.com>
Reviewed-on: https://git.eclipse.org/r/27581
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
Native more accurately reflects what we've put there. They're native
utilities that can be reused by other Eclipse bundles to access
native services.
Also fixed up the cdt 4.4 target which had fixed version numbers for
some of the dependencies and used RSE out of the Luna repo instead
of their latest milestones.
Change-Id: I259aa9e92212409378679a8c61bf2fffd05c67a2
Reviewed-on: https://git.eclipse.org/r/27304
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
This commit creates a new feature "org.eclipse.cdt.spawner"
which is included by the cdt.platform feature and only holds the
CDT native code fragments along with a new bundle named
"org.eclipse.cdt.core.spawner" as their new fragment host.
This new feature and bundle provide access to the CDT PTY, Spawner,
Windows Registry Accesss and Tasklist capabilities without having to
depend on the full cdt.core bundle.
Nothing changes for existing consumers of the cdt.platform feature, or
cdt.sdk feature (the new feature and bundle are installed and pulled
in automatically). Consumers who only installed the org.eclipse.cdt
bundle in the past will now also need the new spawner bundle.
Change-Id: I3943b35948d1bba4771f715c5e700570aa2ae125
Signed-off-by: Martin Oberhuber <martin.oberhuber@windriver.com>
Reviewed-on: https://git.eclipse.org/r/27225
Tested-by: Hudson CI
Reviewed-by: Anton Leherbauer <anton.leherbauer@windriver.com>
Tested-by: Anton Leherbauer <anton.leherbauer@windriver.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
Addresses review comments from https://git.eclipse.org/r/#/c/10648.
Fixes the junit problems by making sure that the dummy PDOM acquires its
write lock before calling exercising the tag index.
Original commit message:
This new extension point allows contributors to put their own
information into the PDOM and to later retrieve it for their own
purposes.
There are many details in the bug. The idea is that contributors
provide an implementation of IBindingTagger, which is given a chance to
examine IBindings when they are created. The ITagWriter interface
allows the contributor to create a new tag which can then have data
written to it.
The ITagService interface (accessible from CCorePlugin.getTagService()
provides a way for the contributor to later get an instance of
ITagReader to retrieve tags from bindings.
ITags are copied to the PDOM when the associated binding is persisteed.
Contributors use a unique id (based on their plugin id), so that
multiple contributors are able to independently tag a given binding.
In-memory tags are not cached. I've done some timing tests using my
sample implementation and found no measurable difference. The full log
lines look like:
!MESSAGE Indexed 'simple-01' (2 sources, 184 headers) in <see below>
sec: 21,550 declarations; 35,394 references; 0 unresolved inclusions; 1
syntax errors; 0 unresolved names (0.00%)
I did 5 tests using the current master (no tagging-related code), the
times were:
18.86 sec
9.17 sec
5.91 sec
4.79 sec
4.83 sec
And then I ran the same sequence of tests using the code in this
commit:
18.73 sec
9.39 sec
6.50 sec
4.78 sec
5.27 sec
If performance does become a problem, then caching could be introduced
with a new implementation of ITaggableService. The two problems are
finding a key other than the identity of the IBinding (since IBindings
are re-created often) and properly evicting stale entries when the
binding is no longer valid.
The process of copying tags from an in-memory IBinding to a PDOMBinding,
is a synchronization. This means that tags that are no longer
applicable, will be removed from the persistent store.
While developing this I found that PDOMBindings are not deleted from the
Database (only the names that reference them are deleted), so there is
no provision for deleting all tags at once.
New database locks are not needed. By the time the persistent tags are
accessed, higher levels of code have already taken a read or write lock
as appropriate.
There are new unit tests covering the changes to the PDOM.
Change-Id: I6ae1afc949082f7f4484b3faa1550670be43312f
Reviewed-on: https://git.eclipse.org/r/10659
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
This new extension point allows contributors to put their own
information into the PDOM and to later retrieve it for their own
purposes.
There are many details in the bug. The idea is that contributors
provide an implementation of IBindingTagger, which is given a chance to
examine IBindings when they are created. The ITagWriter interface
allows the contributor to create a new tag which can then have data
written to it.
The ITagService interface (accessible from CCorePlugin.getTagService()
provides a way for the contributor to later get an instance of
ITagReader to retrieve tags from bindings.
ITags are copied to the PDOM when the associated binding is persisteed.
Contributors use a unique id (based on their plugin id), so that
multiple contributors are able to independently tag a given binding.
In-memory tags are not cached. I've done some timing tests using my
sample implementation and found no measurable difference. The full log
lines look like:
!MESSAGE Indexed 'simple-01' (2 sources, 184 headers) in <see below>
sec: 21,550 declarations; 35,394 references; 0 unresolved inclusions; 1
syntax errors; 0 unresolved names (0.00%)
I did 5 tests using the current master (no tagging-related code), the
times were:
18.86 sec
9.17 sec
5.91 sec
4.79 sec
4.83 sec
And then I ran the same sequence of tests using the code in this
commit:
18.73 sec
9.39 sec
6.50 sec
4.78 sec
5.27 sec
If performance does become a problem, then caching could be introduced
with a new implementation of ITaggableService. The two problems are
finding a key other than the identity of the IBinding (since IBindings
are re-created often) and properly evicting stale entries when the
binding is no longer valid.
The process of copying tags from an in-memory IBinding to a PDOMBinding,
is a synchronization. This means that tags that are no longer
applicable, will be removed from the persistent store.
While developing this I found that PDOMBindings are not deleted from the
Database (only the names that reference them are deleted), so there is
no provision for deleting all tags at once.
New database locks are not needed. By the time the persistent tags are
accessed, higher levels of code have already taken a read or write lock
as appropriate.
There are new unit tests covering the changes to the PDOM.
Change-Id: I8da1bf5eeba7e1fc2ca7ec308ed8e212629986a4
Reviewed-on: https://git.eclipse.org/r/10407
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
- Reworked IFileSystem utility so that now it is noimplement/noextend. Clients should now extend from concrete class FileSystemUtility instead to better insulate them from future API changes.
- Reworked the resulting concurrency fixes - indexing and scanner discovery now synchronize on the project root as a scheduling rule. Original HEAD behaviour was to synch on the project's .settings folder for indexing, but that deadlocked with scanner discovery.
- Fixed remote indexing. Changes on HEAD that deprecated CodeReader broke the ability for remote translation units to provide the path to load the file content from. Added API to ITranslationUnit for this purpose.
