Home » Eclipse Projects » Oomph » Targlet configuration
| Targlet configuration [message #1426099] |
Thu, 18 September 2014 04:43  |
Eclipse User |
|
|
|
Hello,
I'm confused with the using of Targlets.
Currently, we are using .target files to specify our target platform dependencies. The thread Oomphing paradigm already discusses some of the features and what it is intended for.
What I'm still missing is a more detailed explanation, how to use Targlets and what they do. What are the main differences to .target definitions?
Looking at the oomph.setup, I see, that the location of Requirements seems to be resolved by the Source Locator element. How does this work? Our plugins are stored in a SVN repository. Can we use this feature anyway?
Many thanks and best regards,
Joachim
|
|
|
| Re: Targlet configuration [message #1426119 is a reply to message #1426099] |
Thu, 18 September 2014 05:18  |
| Eclipse User |
|
|
|
Joachim,
Comments below.
On 18/09/2014 10:44 AM, Joachim Engelhardt wrote:
> Hello,
>
> I'm confused with the using of Targlets.
> Currently, we are using .target files to specify our target platform
> dependencies.
Yes, that's what most people do, given there are no viable alternatives.
> The thread https://www.eclipse.org/forums/index.php/m/1405533/ already
> discusses some of the features and what it is intended for.
> What I'm still missing is a more detailed explanation, how to use
> Targlets and what they do.
In the end, it's must the same (simple) concept. You have to specify
which installable unit are required in the target platform/workspace as
well as the p2 update sites and/or source folders in which to locate them.
> What are the main differences to .target definitions?
Targlets unify the provisioning of the workspace and the provisioning of
the target platform. So, for example, if you have your projects in a
git clone, you can specify a git clone task to clone that, along with a
targlet task that points at the clone's location, specifies the root
feature(s) in your clone that you want in the workspace, specifies the
p2 update sites where to resolve your bundle and feature dependencies
(for the things not resolved within the clone itself), and let that
resolve. At this point the process is effectively the same as what you
get with a *.target, except with Targlets your source folders are viewed
as if they were p2 repositories, so p2 can find a resolution based on
sources. When the resolution is completed, any resolved installable
unit that originated as source is imported into the workspace and all
others are dumped into the target platform.
Of course you'll often want to specify addition root features in the
targlet, e.g., you'll probably want the platform SDK, JDT and the PDE
even if your projects don't require them to compile, because you'll
likely want to launch a self-hosted instance that includes these things.
Another advantage of targlets is that they can share the same bundle
pool as the one used to install the IDE(s) and the same one used for the
target platforms of all workspaces of all your IDEs, so you can avoid
downloading artifacts you already have on disk. PDE's *.targets on the
other hand keep a per-workspace pool, so you're often downloading the
same things again and again. And, quite frankly, the *.target editor is
a disaster; just opening one of those files involves a long long long
wait...
And finally, another advantage of targlets is that the required
installable units are truly requirements, i.e., they specify an ID and,
most importantly a version range so you can ensure that resolution find
solutions within the range that's acceptable, without hard coding one
specific version as the case with a *.target, i.e., there you can either
specify some Omni version of a specific version, but not a range.
>
> Looking at the oomph.setup, I see, that the location of Requirements
> seems to be resolved by the Source Locator element. How does this
> work? Our plugins are stored in a SVN repository. Can we use this
> feature anyway?
Support for SVN is something targeted for a commercial version, so yes,
you can use that feature, but no, not with the free open source version.
That being said, you can still use a *.psf file to import projects into
your workspace, and then use the workspace itself as a source locator,
to resolve all the dependencies of all the projects in the workspace.
In other words, you only miss out on the cool ability to resolve
projects into the workspace directly from the source code repository...
>
> Many thanks and best regards,
> Joachim
|
|
| | | | |
| Re: Targlet configuration [message #1428994 is a reply to message #1428940] |
Mon, 22 September 2014 12:52 |
| Eclipse User |
|
|
|
Joachim,
I see. It's an interesting use case that's not been considered. Please
open a bugzilla request.
I see that launchers generally specify the following
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl}
-consoleLog
So I imagine one use case would be that one could request more than one
architecture or perhaps all architectures be resolved in the target
platform... In any case, we'll need to consider this and investigate.
On 22/09/2014 5:15 PM, Joachim Engelhardt wrote:
> Ed Merks wrote on Mon, 22 September 2014 14:33
>> I think the targlet will use the architecture of the IDE, i.e., PDE's
>> default behavior. I guess it's possible for that to be different
>> from the architecture you're using for your TP. Is that the case
>> you're concerned about?
>
>
> Yes!
> Our team members develop with different IDE versions (x64/x32), so we
> standarized the platform using the defined architecture inside the
> target platform definition, so all dependencies and product builds
> uses the same target architecture.
> I tried to enable the Include All Platforms property of the targlet.
> Thus, the plugins for the 32bit architecture could be resolved by the
> product definition file. But running the product does still not work.
> I think, because the wrong target architecture is used when building
> the workspace plugins.
It shouldn't actually matter what it's compiled against... The
fragments shouldn't be directly visible. But it certainly would matter
whether you're compiling against a 32 bit JRE verses a 64 bit JRE.
|
|
| |
| Re: Targlet configuration [message #1430279 is a reply to message #1430265] |
Wed, 24 September 2014 03:52 |
| Eclipse User |
|
|
|
Joachim,
Open a bugzilla enhancement request with motivation how you use this. I
know there's an enhancement request for the JRE task to allow arguments
to be specified for that as well. In general the JRE task needs quite a
bit more love and attention, particularly with helping users find the
JDKs on their machines. This would be helpful not only for specifying
JRE tasks, but also an Eclipse Ini task for specifying the -vm argument
(which is a perenial source of problem on the newcomers forum). I.e.,
if you don't specify one, and you install a new JDK, you might suddenly
find Eclipse won't start because the JRE on the path is suddenly a
different one...
On 24/09/2014 9:37 AM, Joachim Engelhardt wrote:
> Ed Merks wrote on Mon, 22 September 2014 16:52
>> I see. It's an interesting use case that's not been considered.
>> Please open a bugzilla request.
>
>
> I opened the request
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=444806 and it was
> immediately resolved (many thanks to Eike Stepper).
> So setting the target platform architecture is now possible.
>
> Another field we use in the *.target file is Program arguments. This
> allows the developer to launch the product configuration from within
> the product configuration editor without edit the run configuration
> manually. In our case, we need to set the argument -launch as program
> argument. Is there currently a way to give those arguments to the
> targlet configuration?
>
> We also configure the specific Java Runtime Environment, but this use
> case is not as strong as the arguments, because we all work with the
> same JRE.
>
> I think, if the targlet configuration is such similar to the *.target
> configuration, there might also exist an additional model element
> Environment where we can configure the settings which are provided by
> the *.target file within this section.
|
|
|
Goto Forum:
Current Time: Wed Jul 30 17:52:14 EDT 2025
Powered by FUDForum. Page generated in 0.05211 seconds |
Home