VSCode allows developers to define custom tasks in .vscode/tasks.json. How to inherit VSCode's tasks.json?
tsconfig or tslint could be inherited using extends "keyword". However I have not found such option in tasks.json schema.
My use case: I have a common library that is shared across projects. The library also define various common gulp tasks. Each project inherits gulpfile, tsconfig, tslint from the common library. The only problem is with .vscode/tasks.json especially with custom problem matchers.
If the task inheritance is not yet possible, how to reuse custom problem matchers?
Related
Is there a generic way to prevent a given set of files from being parsed by IntelliSense modules while it still shows up elsewhere?
For instance, I have a third-party library that provides an AppModel class I can customise. Such class is defined in several places:
The library bundles a template to copy from.
The library includes a usage example.
The library implements the class in a helper tool.
The library defines the class for its test harness.
I implement the class in my app.
My implementation is the only one that gets loaded when the app runs and the only one I care about when I navigate my code or use Go to Symbol yet I need to pick among the 5 definitions every time.
For languages where there isn't a specific setting, the only way to go appears to be files.exclude. But that directive basically makes the file or directory completely disappear from the program. It won't even show up in the Explorer pane. That feature seems designed for source control metadata and similar stuff and I don't think it's entirely convenient for third-party libraries.
Any idea?
I don't really understand what the point of having a package is. Every Class is kept in a different file, so what's the point of using different packages in a single project?
An Eclipse project has nothing to do with Java. It is a feature of Eclipse to organize and configure your different projects.
A Java package is a language feature of Java. You can use them to structure your project and control visibility between different classes. This becomes necessary even in relatively small projects, which already might have a few hundred classes. I suggest you look for a basic tutorial on what a Java package is and what it can do. To give you a headstart, here is what the official documentation has to say about the purpose of bundling related classes in a package:
You should bundle these classes and the interface in a package for several reasons, including the following:
You and other programmers can easily determine that these types are related.
You and other programmers know where to find types that can provide graphics-related functions.
The names of your types won't conflict with the type names in other packages because the package creates a new namespace.
You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package.
Packages are useful for many things. For example, you could store a set of files that do a given task TASK in a package named task.
Packages are a way for developers to find easily and quickly a file, knowing what the role of the file is.
Whenever your project starts growing, packages are essential.
See this lesson for basic understanding of packages utility.
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.
I would like to create a custom context for templates in eclipse.
How I can do it?
It's an extension point provided by the platform, "org.eclipse.ui.editors.templates. You can check the org.eclipse.jdt.ui plugin.xml for an example of how the existing contexts are defined. If you want to show those templates during content assist, you'll also need to contribute an extension to org.eclipse.jdt.ui.javaCompletionProposalComputer to actually use your context rather than the ones that JDT itself defines. The JDT computer for templates only loads the templates from JDT's contexts.
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
Vim-emulation library (vrapper.core)
Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
vrapper.core - Eclipse-independent code for Vrapper
vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
There are 3 plug-ins
two OSGified libraries vrapper.core, surround.core
vrapper.eclipse
surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project
*.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?