[Question] What is the -application command line parameter for the new Sloeber project wizard

[madhephaestus]

This is not a bug but a request for information.

how you would kick off the new project wizard for a normal C++ project:

eclipse -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import /path/to/the/source/directory

what is the correct -application parameter for the new Sloeber project wizard?

[jantje]

I'm sorry but I do not understand your question.
I guess you have better eclipse knowledge than I do ;-)

[madhephaestus]

@jantje for instance here is how you would kick off the new project wizard for a normal C++ project:

eclipse -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import /path/to/the/source/directory

what is the correct -application parameter for the new Sloeber project wizard?

[jantje]

I tried to run the command
E:\test\eclipse>eclipse -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import E:\test\source

but I get an error with the following error log
1609973628157.log

I'm still not sure what this is supposed to do 😕

[madhephaestus]

that one needs this plugin: https://gnu-mcu-eclipse.github.io/advanced/headless-builds/

[jantje]

Reading the doc it looks to me this won't work yet with sloeber. I mean there is currently no import but the work I'm currently doing #1268 will require one.
Can you elaborate on your use case so I can see whether I can fit that in the work I'm currently doing?

The use case I currently see for import in #1268 is:
Step 1: Store your arduino code and a sloeber.cfg (created by sloeber but also possible to make manually) in version control and share your code inclusive compile commands in a OS independent way.
Step 2: add "auto install of the platform" in case the imported workspace does not have the platform.
Step 3: add the libraries used (will require support for multiple versions of the library)
Step 4: install the library versions needed at import time

I'm currently progressing through the foundation of step 1.

[madhephaestus]

AWESOME!

for step one, that would be all the decisions the user makes when creating a new project?

What you are describing sounds a LOT like how platformio defines their projects. Maybe look at their stack to see if there is anything you could use? Even better would be the ability to use the same config files the platformio.ini

If you had step one, and a command line argument to call to load it, that would be all i need. I have my own installers and set up sctipts to keep my Arduino and Sloeber in sync with libraries and toolchains.
https://github.com/WPIRoboticsEngineering/ESP32ArduinoEclipseInstaller/blob/master/linux-eclipse-esp32.sh

My Use Case: I have a robotics IDE that manages all of my source projects for a given robots CAD, Code, Firmware (Arduino), robot definitions. From my IDE i can call command line arguments for Eclipse to import a project. I use this to push my groovy code into eclipse. I hand create the .project and .classpath files to make an appropriate Eclipse project, then call eclipse with the path to the project root. In eclipse, the project import wizard is initiated. To my surprize a whole new eclipse was not started, but instead the commands are passed into the running eclipse, and the wizard to import the project is started in my already running eclipse.

[jantje]

for step one, that would be all the decisions the user makes when creating a new project?

Not really. It is the stuf in project properties->arduino. There is no need to know the project started of from the blink example.
As I want sloeber.cfg to be platform agnostic it currently does not contain the upload/serial monitor port and the upload command. I am considering a "ui filter" to select what should be in sloeber.cfg but for now I opted to hard code to not include these.
Sloeber.cfg also contains the build options you can find in project properties->arduino-> and that for all selected version configurations (It's hard to explain but I think it will be easy to understand when you see it working)

If you had step one, and a command line argument to call to load it, that would be all i need.

👍
I'm currently working on multiple configurations. Which is a hard part (keeping sloeber configs in sync with CDT configs without the proper events 😓 ). If you do not need multiple configs I could do the import first.

I have my own installers and set up sctipts to keep my Arduino and Sloeber in sync with libraries and toolchains.

That is an impressive script. I'm surprised you dumped sloeber and your configuration inside a github release. Do you realize this causes lots of overhead (like the download folder)
That sound like a good solution when reading directly from version control (which you do in your script). IMHO for managed libraries and boards a line in a config file is easier to manage. One doesn't exclude the other though.
Looking at the script is seems like you install using arduino CLI (though your sloeber zip contains stuff as well). I advice strongly against using arduino ide/cli installed stuff in Sloeber, Sloeber may miss information leading to sloeber making wrong decisions.

I hand create the .project and .classpath files to make an appropriate Eclipse project,

The need for these files is why I want to go the sloeber.cfg route. The import should create these files and all should be well.
IMHOP sloeber does not need classpath files.

To my surprize a whole new eclipse was not started, but instead the commands are passed into the running eclipse,

There is no human who understands the way of the lord eclipse 😕
The more I learn about open source the more I see the benefit of commercial software. But most of the commercial software is way out of my financial reach. 😢

[madhephaestus]

I did notice that Sloeber did not know it had the new toolchain when looking in the toolchain installer, but it did know it was there when creating a project, so it can be used to develop with. Can you give me some tips to "complete" the transfer?

Also I would like some tip on how to read the current toolchain info from the sloeber config files? If i wanted to generate a config file, i would like to use the most recent toolchain info.

Going the other way didnt work at all im afraid. I would love to sync the sloeber packages into my arduino install, but Arduino never recognized them.

As for my use case, a little more detail:

1. I have an arduino sketch, its an ino in a folder of the same name
2. i want to write a config file into that folder to give Sloeber all the metadata (toolchain and whatnot)
3. i want to call eclipse from the command line pointing it at that folder
4. Sloeber import the project, or at least start the project import wizard prepopulated with the correct folder, ideally prefilling the toolchain info from the config file
5. Start developing in Sloeber the same file that still works in Arduino, on the disk in the same place.

Here is how i do that process for Groovy projects:

https://github.com/CommonWealthRobotics/BowlerStudio/blob/development/src/main/java/com/neuronrobotics/bowlerstudio/scripting/EclipseExternalEditor.java#L142

[jantje]

I did notice that Sloeber did not know it had the new toolchain when looking in the toolchain installer, but it did know it was there when creating a project, so it can be used to develop with

Well ... it depends. The whole toolchain selection is a complex issue. I guess you are not well versed in the arduino framework dirty details so I will spare you them. To keep it nice and simple: "to be sure it works use the sloeber boardsmanager"
When sloeber starts the first time following page is shown. http://eclipse.baeyens.it/product/V4_0.php There it states "Do not use Arduino IDE installed platforms. It will not work."

Can you give me some tips to "complete" the transfer?

I'm not sure which transfer you are referring to. If you are referring from arduino installed platforms to Sloeber installed platforms. Step 2 mentioned above would mean: you only need to add the info to the sloeber.cfg
As I'm not there yet: in the sloeber perspective go to preferences and install the versions of the platforms you need. Basically like in Arduino IDE.
As you seem to be well versed in scripting and eclipse maybe looking at how the junit tests do installs/project creation may be interesting https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.tests/src/io/sloeber/core/RegressionTest.java#L54
Also: Normally Sloeber creates the arduinoPlugin folder in the eclipse install folder. You can put it somewhere else using the SLOEBER_HOME environment variable. Don't open 2 eclipses using the same SLOEBER_HOME folder and expect everything to work fine. This is not a tested/supported setup.
And lastly: the arduinoPlugin folder contains a download folder. Before downloading slàoeber check availability there. If you want to keep network traffic low you can keep that folder's content.

Going the other way didnt work at all im afraid. I would love to sync the sloeber packages into my arduino install, but Arduino never recognized them.

It won't work properly, never. Basically the IDE needs the json files and the installed platforms (packages folder) to pick and run the correct toolchain.
Also Sloeber allows you to install/use multiple versions from the same platform at the same time and arduino IDE does not.

As for my use case, a little more detail:

1. sounds ok
   2)That should be sloeber.cfg
   3)I guess you mean the parent of the folder as workspace?
   4)The tell Eclipse to do something is still hocus pocus for me. I still need to look into this. The second part I would call project creation and not import. The line is thin I know ;-).
   5)To keep stuff in arduino IDE ans Sloeber I propose to open the parent folder of the sketches as workspace. You can create a new project (using the folder name) and select default ino (or better "no file" when using the nightly) , Sloeber will not overwrite the existing [foldername].ino file.
   The generated slober.ino.cpp is safeguared with #ifdef IN_ECLIPSE and does not cause problems.

[jantje]

This is what the Sloeber.cfg currently looks like

Config.Release.board.BOARD.ID=espea32
Config.Release.board.BOARD.MENU.FlashFreq=80
Config.Release.board.BOARD.MENU.UploadSpeed=921600
Config.Release.board.BOARD.TXT=${SLOEBER_HOME}/arduinoPlugin/packages/esp32/hardware/esp32/1.0.4/boards.txt
Config.Release.compile.sloeber.extra.all=
Config.Release.compile.sloeber.extra.archive=
Config.Release.compile.sloeber.extra.assembly=
Config.Release.compile.sloeber.extra.c.compile=
Config.Release.compile.sloeber.extra.compile=
Config.Release.compile.sloeber.extra.cpp.compile=
Config.Release.compile.sloeber.extra.link=
Config.Release.compile.sloeber.size.switch=false
Config.Release.compile.sloeber.warning_level=true
Config.Release.other.IS_VERSION_CONTROLLED=true

[jantje]

I have added a file-> new->other->arduino->convert to arduino project
This is a convert not a new project
And only one test case

[wimjongman]

To my surprize a whole new eclipse was not started, but instead the commands are passed into the running eclipse, and the wizard to import the project is started in my already running eclipse.

This does not work as you describe here. In fact, a new eclipse is started in "headless" mode (no GUI).

The -application is the id to a java class [1] that is defined in the Applications extension point.

The reason that it looks like it works in your current application is that the workspace refreshes automatically. You don't need to run the application, you can just drop the project into the workspace and it will become visible (providing you have the correct .project as you describe).

The -application you point to is a way to compile a project headless (without an Eclipse GUI starting) e.g. for use on a build server.

[1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/build/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/core/HeadlessBuilder.java

[jantje]

The reason that it looks like it works in your current application is that the workspace refreshes automatically.

That was what I was thinking to. But that does mean the workspace is opened twice. This is not possible when using the gui only.So I must assume a headless eclipse can open a already open workspace.

[wimjongman]

The "application" is the first java class that gets loaded after the normal boot.

The concept of a locked workspace is from the "normal" GUI application (called IDEApplication [1] (around line 222))

Other applications don't give diddly-squat about a lock. It is just a file that is checked. A workspace cannot be "opened". That is also just an IDEApplication concept. The WS it is just a directory, not the cave of Ali Baba. ;)

[1] https://github.com/eclipse/eclipse.platform.ui/blob/master/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/IDEApplication.java

[jantje]

@wimjongman
thanks for these insights

[jantje]

Version 4.4 is out that supports the sloeber.cfg I talked about earlier. I made a video how to make this work in the gui https://www.youtube.com/watch?v=bqdw1L_8Gjs&t
Is your question answered?
Can this issue be closed?