ssi-schaefer / lcdsl Goto Github PK

Problem is that the scoping uses the index. this works fine except for when a project has been cleaned (unfortunately).

I have some startLevels defined in my product:

<configurations>
      <plugin id="org.eclipse.core.runtime" autoStart="true" startLevel="1" />
      <plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="1" />
      <plugin id="org.eclipse.equinox.event" autoStart="true" startLevel="2" />
      <plugin id="my.plugin" autoStart="true" startLevel="3" />
   </configurations>

But they seem not to have any impact. The important point is for the plugin from workspace:
<setEntry value="my.plugin@default:default"/>
So that I need to define at least the my.plugin startlevel in the lc to run my project properly.

Also the org.eclipse.equinox.ds does not get any starting level:
<setEntry value="org.eclipse.equinox.ds*[version]@default:default"/>

And org.eclipse.core.runtime gets another start level:
<setEntry value="org.eclipse.core.runtime*3.20.100.v20210111-0815@0:true"/>

The lc looks like this:

explicit eclipse configuration MyProduct {
	product my.product;
	content-provider "${workspace_loc:my.product}/product.product";
	//plugin my.plugin startlevel 3 autostart;
}

Hello Launch Configuration DSL team,

The Xtext team would like to update the Xtext community website listing all the cool projects people are building around Xtext/Xtend.

See also the corresponding GitHub issue and Bugzilla ticket.

If you are interested that the Launch Configuration DSL project is listed there, please provide the following information as a comment to this issue:

<tr>
	<td><a href="project_link">project_name</a></td>
	<td>project_description_max_2_sentences</td>
	<td>license</td>
	<td>category</td>
	<td>author(s)</td>
</tr>

We will then update the Xtext community website and get it online as soon as possible.

Thanks!
Tamás

I'm working on a RCP application with a product and a single feature.
When I generate a launch configuration from the product, everything works, and I can start the application.
I would expect to be able to create a working launch configuration from the following LC file as well:

eclipse configuration LcLaunch {
    workspace "${workspace_loc}/../runtime-MyWorkspace";
    product foo.bar.product;
    feature foo.bar.feature;
}

Instead, I get an NPE in my error log:

Caused by: java.lang.NullPointerException
	at com.wamas.ide.launching.generator.DependencyResolver.getPluginModels(DependencyResolver.java:256)
	at com.wamas.ide.launching.generator.DependencyResolver.findDependencies(DependencyResolver.java:128)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generateDependenciesEclipseRap(StandaloneLaunchConfigGenerator.java:346)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generateEclipse(StandaloneLaunchConfigGenerator.java:340)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generate(StandaloneLaunchConfigGenerator.java:173)
	at com.wamas.ide.launching.ui.handlers.AbstractLaunchConfigGeneratorHandler.execute(AbstractLaunchConfigGeneratorHandler.java:37)
	at com.wamas.ide.launching.ui.handlers.AbstractLaunchConfigGeneratorHandler.execute(AbstractLaunchConfigGeneratorHandler.java:1)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:291)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:92)
	at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
	... 36 more

If I try this it with a content-provider with the pull path of my product as a parameter, I also get an NPE with a different stack-trace

eclipse configuration LcLaunch {
    workspace "${workspace_loc}/../runtime-MyWorkspace";
    product foo.bar.product;
    
    content-provider 'C:\\foo\\bar\\Foo.product';
}

Caused by: java.lang.NullPointerException
	at com.wamas.ide.launching.generator.DependencyResolver.getPluginModels(DependencyResolver.java:256)
	at com.wamas.ide.launching.generator.DependencyResolver.lambda$3(DependencyResolver.java:208)
	at org.eclipse.xtext.xbase.lib.internal.FunctionDelegate.apply(FunctionDelegate.java:42)
	at com.google.common.collect.Iterators$7.transform(Iterators.java:750)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)
	at com.google.common.collect.Iterators$6.computeNext(Iterators.java:616)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140)
	at com.google.common.collect.TransformedIterator.hasNext(TransformedIterator.java:42)
	at com.google.common.collect.MultitransformedIterator.hasNext(MultitransformedIterator.java:50)
	at com.google.common.collect.MultitransformedIterator.hasNext(MultitransformedIterator.java:50)
	at com.google.common.collect.Iterators.addAll(Iterators.java:366)
	at com.google.common.collect.Iterables.addAll(Iterables.java:332)
	at com.wamas.ide.launching.generator.DependencyResolver.findBundlesInProduct(DependencyResolver.java:213)
	at com.wamas.ide.launching.generator.DependencyResolver.findDependencies(DependencyResolver.java:107)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generateDependenciesEclipseRap(StandaloneLaunchConfigGenerator.java:346)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generateEclipse(StandaloneLaunchConfigGenerator.java:340)
	at com.wamas.ide.launching.generator.StandaloneLaunchConfigGenerator.generate(StandaloneLaunchConfigGenerator.java:173)
	at com.wamas.ide.launching.ui.handlers.AbstractLaunchConfigGeneratorHandler.execute(AbstractLaunchConfigGeneratorHandler.java:37)
	at com.wamas.ide.launching.ui.handlers.AbstractLaunchConfigGeneratorHandler.execute(AbstractLaunchConfigGeneratorHandler.java:1)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:291)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:92)
	at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
	... 36 more

Also, I do not understand why the DSL forces me to add features/plug-ins or a content-provider at all, when the product should contain everything that's necessary to generate a launch configuration.

I'm using Oxygen and the latest LCDSL.

The project is currently in an inconsistent state and does not compile, if the JDK is setup correctly. It uses methods from Java 11 (List.of(...)), but compiles with 1.8 and has BREE 1.8. Would you prefer fixing the code to be 1.8 compatible again, or rather upgrade BREE and jdt settings to 11 (what I would very much prefer)?

Hi,

I tried to use lcdsl for our RCP application but I encountered an issue.

I this config launch.lc:

eclipse configuration Coder_Studio {
    product io.toro.coder.branding.io.toro.coder.product;
    
    feature io.toro.coder.feature;
    feature io.toro.coder.gloop.feature;
    feature io.toro.coder.flux.feature;
}

Once the corresponding launch configuration is generated I check it and the select product is invalid.

If I do it manually it would be:

The plugin.xml in io.toro.coder.branding looks like this:

<plugin>
    <extension
            id="io.toro.coder.product"
            point="org.eclipse.core.runtime.products">
        <product
                description="Coder Studio"
                application="org.eclipse.ui.ide.workbench"
                name="TORO Coder Studio">
        <!-- ... -->
        </product>
    </extension>
</plugin>

Am I doing something wrong or is it an issue on lcdsl side?

Additionally to the launch configuration type, a sub-categorization by project would be helpful.

In the LCDSCL the block

Test {
    class my.TestClass;
}

does not accept all JUnit5 test classes.

E.g. in JUnit5 test class/method can be non-public, but package visible only. Please consider this example:

class TestClass {
    class Base {
        @Test
        void testMethod1() {}
        @Test
        void testMethod2() {}
    }
    @Nested
    class Variant1 extends Base {
        // configuration only, no test method
    }
    @Nested
    class Variant2 extends Base {
        // configuration only, no test method
    }
}

Using CTRL+SHIFT+F in eclipse results in "complete content of file is moved to first line of file".

So instead of

java configuration XXX : BaseJavaLog4jLaunch {
memory max = 1280M;
main-class com.test.something.Main;
project com.test.something;
argument "42";
vm-argument "-Dtarget.home=${target_home}" ;
}

I get

java configuration XXX : BaseJavaLog4jLaunch { memory max = 1280M; main-class om.test.something.Main; project com.test.something; argument "42"; vm-argument -Dtarget.home=${target_home}" ; }

I'd like to jump to the referenced product / feature / plugin when Ctrl-clicking / pressing F3 on a reference.

Example (| = cursor position):

plugin com.example.m|y.plugin;

Pressing F3 should open plugin.xml in com.example.my.plugin.

For junit-plugin configurations, the documentation of container says "If the container points to a plugin project, the plugin will be added to the dependency list as well". This partly works, the plugin is added to the dependencies. But that plugin's transitive dependencies are not added automatically. It seems like the container plugin is not part of the automatic dependency resolution.

Example: Assuming we have two plugin projects, org.example.demo.test which depends on org.example.demo. In the following configuration org.example.demo.test is added as dependency because the container points to that plugin project. Launching it will fail because org.example.demo is missing though.

junit-plugin configuration Demo {
    test {
        runner junit5;
        container '/org.example.demo.test';
    }
    application org.eclipse.pde.junit.runtime.coretestapplication;
    plugin slf4j.simple;
}

Only if we add the container plugin redundantly in the dependencies, then org.example.demo is added automatically as expected.

junit-plugin configuration Demo {
    test {
        runner junit5;
        container '/org.example.demo.test';
    }
    application org.eclipse.pde.junit.runtime.coretestapplication;
    plugin slf4j.simple;
    plugin org.example.demo.test;
}

Is there a way to launch plug-in tests?

I usually would create the launch configuration by right-clicking the project and choosing "Run --> JUnit Plug-in Test".

In order to simplify trial and usage of those plugins, it would be great to produce and publish a p2-repo.

I'd like to add the same plugin twice, with different versions.
This is possible in regular launch configs.

LcDsl gives an error Duplicate PluginWithVersion 'org.antlr.runtime'

Example:

plugin org.antlr.runtime 3.2.0.v201101311130;
plugin org.antlr.runtime 4.3.0.v201502022030;

We do make a difference between out JUnit plugin tests vs our pure unit tests.
The plugin test take significant more startup time, so we want to run the pure unit test much more often.

Could LCDSL also support this?

I have the following configuration:

abstract swtbot configuration Base-UI-Test {
	product MyProduct;
	content-provider "${workspace_loc:MyProduct}/target/classes/product.product";
}
swtbot configuration My-Plugin-UI-Test : Base-UI-Test {
	plugin MyPlugin;
	workspace "${workspace_loc:/MyPlugin}/target/swt-workspace";
	
	test {
		runner junit4;
		container '/MyPlugin';
	}
}

and with variables I would like to be able to do something like this:

abstract swtbot configuration Base-UI-Test {
	product MyProduct;
	content-provider "${workspace_loc:MyProduct}/target/classes/product.product";
	
	workspace "${workspace_loc:/$testPlugin}/target/swt-workspace";
	
	test {
		runner junit4;
		container '/$testPlugin';
	}
}
swtbot configuration My-Plugin-UI-Test : Base-UI-Test {
	plugin MyPlugin;
	var testPlugin="MyPlugin";
}

I'm not sure what all is possible within the editor for pre validating the code.

Maybe it would even be possible in Non-String arguments for:
plugin $testPlugin;

An ArrayIndexOutOfBoundsException is thrown when saving a configuration that declares a non-existing content provider.

Copy the following snippet into a .lc file and press save.

eclipse configuration ConfigA {
    product org.eclipse.sdk.ide;
    content-provider "Foo";
}

stacktrace.txt

The validation looks for test related annotations on public test methods only. However, JUnit 5 no longer requires public test methods, therefore the validation wrongly fails on JUnit 5 test classes that leave away the public keyword.

See https://github.com/ssi-schaefer/lcdsl/blob/master/com.wamas.ide.launching/src/com/wamas/ide/launching/validation/LcDslValidator.xtend#L425 and https://github.com/ssi-schaefer/lcdsl/blob/master/com.wamas.ide.launching/src/com/wamas/ide/launching/validation/LcDslValidator.xtend#L427

Using the Eclipse variable ${folder_prompt} (which should open a dialog and prompt the user to choose a folder) in working-dir crashes the Eclipse IDE on Windows. As soon as you enter the variable in the editor, even before saving the file, Eclipse gets unresponsive and the process has to be killed. One time I noticed that the file chooser dialog popped up for a split second after entering the variable. My guess is that the variable is evaluated immediately after typing instead of when running the launch configuration. There's nothing logged about the crash in the Eclipse log. The variable works as expected in e.g. vm-arguments.

To make the language extensible, it should be possible to define schemas (without changing LcDsl) to define new launch configuration types.

The language should provide the value types (string, int, plugin, feature, path, ...), and the schema should define which keys are using which value types, as well as how they transform into the launch configuration attributes later on.

Currently, I have to know at which position I have to enter the launch config ID, as the auto-complete does not propose anything at this point.
It would be easier to use if auto-complete provides an default ID, so I can get to a valid launch config by hitting Ctrl-Space lots of times.

Scenario: Developers are checking in launch configuration into a code repository so that the entire team uses the same settings.

Now as a developer i want to customize an existing configuration to adopt some settings (xmx, plug-ins). Currently i have to derive from the existing configuration and choose a new unique name. This is annoying in the case that the configuration is referenced in a shared launch group. I would now also need to change the launch group.

Would be nice to have a feature that allows me to overwrite settings of an existing configuration. It should be validated that there can only be a single configuration that overwrites an existing configuration.

Perhaps via the right‑click menu, a selection for bringing up the XML file for the launch configuration in the Eclipse editor.
For this, I could see a Open and Open With similar to that if you right‑click a file in the Project Explorer.

It's sometimes nice to be able to edit those files outright as oppose to needing to work through the Launch Configuration Editor GUI window.

Additionally with this, a separate context‑menu selection for opening the location of the launch configuration in the file navigator (Windows Explorer (win), Finder (macOS), etc.) would be really nice to have as well.
Open File Location

As this plugins are a lot about UI, it would be nice to show images or animated gifs presenting the features in README.md

When updating our internal IDE (based on Eclipse 2022-03) to ship with eaa541d, our internal CI builds (using TEA tasks) hang somewhere around "loading target platform" when about to set up the workspace for building the IDE.

Some stack dump is available in ldcsl-202205201343-hang-stackdump.txt

This is a regression since 413d2aa.

Before I start trying to reproduce in a local workspace: @szarnekow @jukzi Any idea so far?

Set the focus initially to the tree when opening the view

In the latest code some classes out of a newer version of org.eclipse.debug.ui.launchview are used. But there is no repository providing this plugin. Any idea where to get it?

If a subclass requires a plugin that is explicitly ignored in a superclass, then the plugin will be added to the launch configuration without its dependencies.

I don't know if you are familiar with the Eclipse working sets, but it's a great way to organize your projects in an Eclipse workspace in the Project Explorer view.

It would cool to be able to toggle a filter for the launch configurations by selected project. Or to be able to toggle organizing them by working set or project instead of type.

Must be implemented based on Oxygen

When copying a whole project including launch configurations, both the original and the copy should work. This is only possible if they get different names. A keyword (like 'auto-qualify' or so) could be implemented to prefix the launch configuration name automatically with the project name. This would allow to have both without any modifications. This is more or less the same requirement sources as "project self;"

In the Junit Runner application, there is a setting to run the built-in Eclipse JUnit runner. It hides behind a drop-down setting of [No Application] - Headless Mode. It would be nice to include this setting or even make this the default. I am unsure how else I can use the DSL without this at the moment - the validation fails as the editor does not know about this.

The default application name is org.eclipse.pde.junit.runtime.application for headless, and something with UI for running with widgets. It would be great if you could add this, as headless tests are very common.

Hi,

due to a discussion in portfolio-performance/portfolio#1156, I am checking out a generic way to create reliable launch configurations. I really like the approach of this project.

My Product file does not reside in the workspace (as the git projects are checked out somewhere else. I would hope to use project_loc, however, my Eclipse Installation (2019-03) --> on macOS I get a spinning wheel mouse pointer and have to abort Eclipse.

Is project_loc supported?

eclipse configuration PP {
    workspace "${workspace_loc}/../runtime-MyWorkspace";
    product name.abuchen.portfolio.bootstrap.product;
    
    content-provider "${project_loc}/../portfolio-product/name.abuchen.portfolio.product";
    
    ignore javax.servlet;
    ignore name.abuchen.portfolio.tests;
    ignore name.abuchen.portfolio.ui.tests;
    ignore org.jsr-305;
    
    argument "-consoleLog";
    argument "-Dorg.eclipse.e4.core.di.debug=true";
}

BTW, the resolution includes more plugins than defined in the product file - for example all test plugins. Is there a way to reduce it to the features/plugins defined in the product file only?

It would be nice to have a quickfix that adds all required dependencies to a launch config.

This could work

• For a complete launch config (main use case)
• For one entry (product / feature / plugin) to only add the dependencies required for this one

In any case, we should add transitive dependencies, too.

Referring to http://marketplace.eclipse.org/comment/5727#comment-5727

We often have the problem, that a project will be copied (or branched) with it's launch configurations.
This new projects get's a new project name.
After the copy and renaming of the project the launch configurations they will not longer work, because they contain the old project name.

It would be nice to have a place holder for the project which will be filled with the current project.
Especially for launch configurations located in the project it would be helpful.

Related to #79, if a junit-plugin container points to a plugin project, it is added to the list of dependencies. If there are no explicit plugin dependencies defined though, we get the error missing required attribute: [plugins, contentProviderProduct, features]. This seems to restrictive to me, it should be ok to omit explicit dependencies in that case.

For example, this should be a valid configuration, but it is currently considered invalid because org.example.demo.test is only listed as container but not redundantly as plugin dependency.

junit-plugin configuration Demo {
    test {
        runner junit5;
        container '/org.example.demo.test';
    }
    application org.eclipse.pde.junit.runtime.coretestapplication;
}

The project self mechanism seems to find the outermost eclipse project (which is wrong), even when working an a workspace with flat project setup.

Content assist is not working properly in a lot of cases, for instance the launch configuration type is no longer proposed once a single 'modifier' is present.

Have a stored launch config (.launch, not .lc) in your workspace that is unknown to all the plugins in the current IDE. In that case the launch view is completely unusable because of NPE during creation of the tree. The view needs to filter out all launches where the container cannot be calculated.

java.lang.NullPointerException
	at org.eclipse.debug.ui.launchview.internal.model.LaunchViewModel.lambda$9(LaunchViewModel.java:68)
	at java.base/java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2754)
	at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
	at org.eclipse.debug.ui.launchview.internal.model.LaunchViewModel.getModel(LaunchViewModel.java:67)
	at org.eclipse.debug.ui.launchview.internal.view.LaunchViewImpl.lambda$7(LaunchViewImpl.java:271)

In our case this happens because we declare own launch config types and have serialized launches for these types in our example and test models. And of course those runtime-only launch types are unknown to the IDE.

Copy the following snippet into a new .lc file:

eclipse configuration ConfigA {
    product org.eclipse.sdk.ide;
    plugin org.eclipse.core.runtime;
  }

  eclipse configuration CustomConfigA:ConfigA {
  }

Now rename CustomConfigA to ConfigA and press save.

eclipse configuration ConfigA:ConfigA { 
}

This results in a StackOverflow exception when trying to validate the configuration. See the attached file for more details.

stacktrace.txt