|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1816163 is a reply to message #1816154] |
Tue, 22 October 2019 21:12   |
|
Thanks Eike, but using the target file without extension did not do the trick.
<setupTask
xsi:type="pde:TargetPlatformTask"
name="target-platform-latest"/>
I attached the setup file, in case you can have a look at it to see my error.
>Out of curiosity, what was wrong with the Targlet Task?
Nothing, I just wanted to start with something we already have. At a later point I plan to generate the target file via Oomph based on the Targlet.
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1816230 is a reply to message #1816163] |
Thu, 24 October 2019 13:49   |
|
It seems you have no task to import the projects (in particular the one that contains the .target file) from the Git clone into the workspace. So PDE can't find the target definition. The Modular Target (Targlet) task would have done that for you. You can also use a task like this:
<?xml version="1.0" encoding="UTF-8"?>
<projects:ProjectsImportTask
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:predicates="http://www.eclipse.org/oomph/predicates/1.0"
xmlns:projects="http://www.eclipse.org/oomph/setup/projects/1.0"
xsi:schemaLocation="http://www.eclipse.org/oomph/predicates/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/Predicates.ecore http://www.eclipse.org/oomph/setup/projects/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/Projects.ecore">
<sourceLocator
rootFolder="${git.clone.dartboard.location}"
locateNestedProjects="true">
<predicate
xsi:type="predicates:NotPredicate">
<operand
xsi:type="predicates:NamePredicate"
pattern="dartboard"/>
</predicate>
</sourceLocator>
</projects:ProjectsImportTask>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1816515 is a reply to message #1816509] |
Wed, 30 October 2019 11:26   |
Eclipse User |
|
|
|
I would not use a target platform task if at all avoidable (and it's always avoidable). There are only downsides at development time:
https://wiki.eclipse.org/Oomph_Targlets
It's bloated (copies yet another copy of everything into the workspace metadata), it's slow (downloads everything you already have downloaded before), it's redundant (duplicates information already in your bundle/feature requirements), it's not resilient (destroys your current target platform if there is a network failure or a resolution failure,) it's not composeable (so your project cannot work with any other project), and of course the target editor is not a joy to use (believing it's necessary to resolve and download everything while editing). I cringe every time I accidentally open it to view the generated .target file...
|
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854358 is a reply to message #1816536] |
Mon, 15 August 2022 22:40   |
Eclipse User |
|
|
|
Hi. I have a question closely related to this one. The Target Platform Definition DSL feature from https://github.com/eclipse-cbi/targetplatform-dsl can generate a .target from a textual definition of the target platform (a .tpd file). It's a very neat feature which we use in our projects. I was wondering if is it possible to invoke the TPD generator from an Oomph setup model to generate and set the target platform? It would seem that it may be doable with the "Launch" task, but somehow it feels like a bit of an overkill.
I understand Ed's comments regarding the preferability of Targlet tasks, but unfortunately my team doesn't want to use Oomph, but they are Ok with using the TPD DSL, which means that if I want to use Oomph to setup my development environment, I have to manage and keep in sync two different target definitions (the .tpd file and the targlet in the Oomph model).
In fact it would be very neat to go further and be able to generate a .tpd from a targlet task and vice-versa (as some prefer editing text over models). Has anyone considered this?
|
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854362 is a reply to message #1854358] |
Tue, 16 August 2022 06:29   |
Eclipse User |
|
|
|
All things are possible with implementation effort, but I'd not be so happy to build actual project dependencies on the TDP project to complicate our builds (and our contribution to SimRel). There's perhaps a way to support what you suggest without hard dependencies on the TDP projects, at least in terms of generating the concrete syntax. Note that it is possible to drag a *.target and drop it onto a Targlet task to create a targlet that matches that *.target, so I suppose indirectly you can also create the targlet from the *.tdp...
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854374 is a reply to message #1854361] |
Tue, 16 August 2022 15:23   |
Eclipse User |
|
|
|
Well, I think it's mostly a case of senior developers set in their ways, not wanting to spend time learning a new tool and thinking that it's just adding more complexity to the development. And as they have seniority over me, there's not a lot I can do, although once in a while I try to sell the idea of using Oomph. Maybe one day they will actually give it a try if they have the time, but I'm not counting on it happening in the short term.
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854375 is a reply to message #1854362] |
Tue, 16 August 2022 15:24   |
Eclipse User |
|
|
|
Thanks!
I can see a number of options:
1) Invoke the TPD generator from an Oomph task (my original thought)
2) Generate a .tpd file from a targlet using a custom generator (say in Xtend) to avoid adding dependencies on the TPD project, and invoking it from some task in the Oomph model
3) Dragging an existing .target to a targlet task.
I was not aware about option 3, which is the easiest in the sort term, so I will give that a try.
But I might be interested in exploring options 1 and 2 a little bit. In both cases I would need to invoke some generator through some API. My question there is what would be the right way to invoke some external procedure, to call some Java API from an Oomph model? I can imagine a way by using a Launch task, or a "Project Build" task, but they feel a bit hackish. Is there a better way?
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854378 is a reply to message #1854375] |
Tue, 16 August 2022 16:30   |
Eclipse User |
|
|
|
A launch task already exists, so that's a possibility. I don't know if TDP provides a builder that automatically builds, but if they did, it would already be automatic I guess. :-P
Another thought that came to mind is if there is a command that could be invoked, perhaps with parameters. But I've not looked at all the APIs involved for such a thing...
|
|
|
Re: Using Oomph to activate a regular target platform (not a Target [message #1854460 is a reply to message #1854361] |
Fri, 19 August 2022 09:52   |
Eclipse User |
|
|
|
Eike Stepper wrote on Tue, 16 August 2022 08:28Why does your team not want to use Oomph?
This question triggers me to hijack the topic to mention some issues I have encountered while using Oomph targlets, and which make me at least consider prefering TPD-based target platforms:
* When provisioning an IDE for several projects based on targlets, Oomph composes their targlets by creating one big targlet. This works at runtime but sort-of "breaks" the workflow where you want Oomph to generate your .target file. I described the issue here.
* I had some issues with platform-specific bits in the targlet-based generated .target file and its use in Tycho builds.
If my memory is correct, I needed the targlet to include platform-specific bits so that it resolves correctly on my Windows machine. But I did not want them in the generated .target file because Tycho somehow adds them at build time (?). With the platform-specific bits in the .target file, the Tycho build on a Linux machine complained about mac and windows stuff.
I settled the issue by manually running a script on the generated .target file to remove platform-specific bits.
[Updated on: Fri, 19 August 2022 10:05] by Moderator Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.05763 seconds