Home » Eclipse Projects » Oomph » Oomphing paradigm
| Oomphing paradigm [message #1404962] |
Wed, 06 August 2014 08:41  |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hey there,
I am going through a transformation how I use Eclipse.
In the past, my workspace was important to me. It had to contain all
plugins I need, correctly ordered in WorkingSets. Depending on what I
worked on, I would close/open projects and load a .target file, which
would compile the stuff and all would run nicely. Loosing this setup,
was a horrific thought.
When I heard about Oomph, I wasn't sure what is was about, but now it
dawns to me, that it changes how one uses Eclipse and the workspace. In
fact, the workspace becomes some sort of volatile container to compile
stuff and make sure Eclipse can be used at it's full potential, but
loosing is it not an issue anymore. In fact, one could argue multiple
workspaces are still needed. "Can we drop the switch Workspace feature
please!"
The central view for me now is the 'GIT Repositories' view and not the
Explorer anymore. In fact, I open files from this view more and more
often, without importing the project at all. The main driver for this
was the switch to tycho. I run maven builds from the root project, and
if it builds, I can run the end product from the IDE, but more important
is commit it to the build server, and I am pretty sure the build will
succeed.
What a productivity improvement (already)!
but to be honest, I haven't started to use Oomph yet, but I know
exactly, how I wish to use it.
- Setup working sets with projects from git as independent bits
- Set the corresponding .target. (With Xtext, I have an issue with this,
as the IDE installed xtext plugins need to match the version in the target).
- Set IDE preferences.
Productivity will boost even more with Oomph I expect.
One more remark, somehow it feels Eclipse should grow closer to git
repo's. Example: When opening a Java file directly from the git repo,
it's not compiled and various IDE functions don't work. Of course this
is the current state, but I keep thinking, why can't the git repo be a
fully functional workspace, which is powered by Oomph to get all
configured correctly?
Cheers Christophe
|
|
|
| Re: Oomphing paradigm [message #1405156 is a reply to message #1404962] |
Wed, 06 August 2014 18:13  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
On 06/08/2014 10:41 AM, Christophe Bouhier wrote:
> Hey there,
>
> I am going through a transformation how I use Eclipse.
> In the past, my workspace was important to me. It had to contain all
> plugins I need, correctly ordered in WorkingSets. Depending on what I
> worked on, I would close/open projects and load a .target file, which
> would compile the stuff and all would run nicely. Loosing this setup,
> was a horrific thought.
:-P
>
> When I heard about Oomph, I wasn't sure what is was about, but now it
> dawns to me, that it changes how one uses Eclipse and the workspace.
Yes.
> In fact, the workspace becomes some sort of volatile container to
> compile stuff and make sure Eclipse can be used at it's full
> potential, but loosing is it not an issue anymore.
No, if you describe what's needed well, you can recover it in minutes.
> In fact, one could argue multiple workspaces are still needed. "Can we
> drop the switch Workspace feature please!"
Actually, it's still potentially useful to have an IDE with lots of
things installed that can also work with various workspaces, but with
Oomph it's also easy just to have on IDE per workspace, which isn't as
wasteful as it sounds, because they all share the same bundles from a
single bundle pool.
>
> The central view for me now is the 'GIT Repositories' view and not the
> Explorer anymore. In fact, I open files from this view more and more
> often, without importing the project at all. The main driver for this
> was the switch to tycho. I run maven builds from the root project, and
> if it builds, I can run the end product from the IDE, but more
> important is commit it to the build server, and I am pretty sure the
> build will succeed.
I see.
>
> What a productivity improvement (already)!
>
> but to be honest, I haven't started to use Oomph yet, but I know
> exactly, how I wish to use it.
> - Setup working sets with projects from git as independent bits
Working sets can be defined to be dynamic using predicates to describe
what should and shouldn't be in that working set.
> - Set the corresponding .target.
Sorry, but .target files suck big time. Yes you can use Oomph to
activate one, but Targlets are a dramatic improvement over what you can
do with "pure PDE", giving you much better control over what ends up in
your target platform and in your workspace.
> (With Xtext, I have an issue with this, as the IDE installed xtext
> plugins need to match the version in the target).
I need that for Xcore as well, you can look at its setup. I created one
for Xtext has well, though it still needs some fine tuning. One of the
very nice things about Targlets is that it unifies the provisioning of
the target platform with that of the workspace. For example, you say
you want Xtext in the TP, so in the Targlet Task you specify which IU
and which p2 update site to get it from. If you also specify to git
clone Xtext and specify that the targlet look at that repo, you'll end
up not only with Xext in your TP, but you'll end up with Xtext source
bundles in workspace (which you can close, because the binaries are also
in the TP)...
> - Set IDE preferences.
Yes, you can record preferences and have the "played back" into each IDE
you ever start...
>
> Productivity will boost even more with Oomph I expect.
Yes.
>
> One more remark, somehow it feels Eclipse should grow closer to git
> repo's.
That's what we're trying to to with Targlet tasks; unify the
provisioning of the TP and the workspace, where the split just depends
on whether you specify a source locator or not. If source is available,
it's put in the workspace, if a binary is available, it's put in the TP
(and if both are available, they show up in both places).
> Example: When opening a Java file directly from the git repo, it's not
> compiled and various IDE functions don't work. Of course this is the
> current state, but I keep thinking, why can't the git repo be a fully
> functional workspace, which is powered by Oomph to get all configured
> correctly?
Just point your targlet at it, and it will put them in the workspace,
and make sure that everything it depends on is also added to the TP
(which might require you to specify in which p2 repo to find them).
Of course ideally, all the projects would specify a *.setup, and then
you'd just choose from the installer (or add project to workspace
wizard) which one(s) you want...
>
> Cheers Christophe
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Oomphing paradigm [message #1405172 is a reply to message #1405156] |
Wed, 06 August 2014 19:07 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Thanks for clarifying on Oomph.
The concept of Targlets is interresting, and I do very much agree
with you on the shortcomings (I am holding back now!) of .target files.
But, as I use tycho, I need the .target file.
The .target editor is so horrible, that I started to query about
possibilities to break up a .target in pieces, on the tycho mailing
list, and I was pointed to this tool today:
https://github.com/mbarbero/fr.obeo.releng.targetplatform
It's really awesome, especially the include feature and the fact that
the .target is generated from this DSL.
An 'end' target for me looks like this now:
target "oss2_xtext231_cdo42SR2"
include "modules/oss2_kepler.tpd"
include "modules/oss2_emf.tpd"
include "modules/oss2_xtext_231.tpd"
include "modules/oss2_cdo_42SR2.tpd"
include "modules/oss2_mwe_111.tpd"
include "modules/oss2_nebula.tpd"
include "modules/oss2_xpand_110.tpd"
include "modules/oss2_gef_390.tpd"
include "modules/oss2_orbit.tpd"
include "modules/oss2_peaberry.tpd"
and an example of a plugin is like this:
target "emf" with allEnvironments
// EMF, the latest release.
// http://www.eclipse.org/modeling/emf/downloads/?project=emf
location "http://download.eclipse.org/modeling/emf/emf/updates/releases/" {
org.eclipse.emf.oda.sdk.feature.group 1.2.0.v20140203-1126
org.eclipse.emf.feature.group 2.9.2.v20140203-1126
org.eclipse.emf.gwt.ecore.feature.group 2.9.0.v20140203-1126
org.eclipse.emf.codegen.feature.group 2.9.0.v20140203-1126
org.eclipse.emf.converter.feature.group 2.9.1.v20140203-1126
org.eclipse.emf.gwt.ecore.edit.feature.group 2.8.0.v20140203-1126
org.eclipse.emf.rap.edit.ui.feature.group 2.9.0.v20140203-1126
org.eclipse.emf.gwt.edit.feature.group 2.8.0.v20140203-1126
org.eclipse.emf.codegen.ecore.feature.group 2.9.1.v20140203-1126
org.eclipse.emf.mapping.ecore.feature.group 2.7.0.v20140203-1126
org.eclipse.emf.codegen.ecore.ui.feature.group 2.9.1.v20140203-1126
etc..
On 06-08-14 20:13, Ed Merks wrote:
> Christophe,
>
> Comments below.
>
> On 06/08/2014 10:41 AM, Christophe Bouhier wrote:
>> Hey there,
>>
>> I am going through a transformation how I use Eclipse.
>> In the past, my workspace was important to me. It had to contain all
>> plugins I need, correctly ordered in WorkingSets. Depending on what I
>> worked on, I would close/open projects and load a .target file, which
>> would compile the stuff and all would run nicely. Loosing this setup,
>> was a horrific thought.
> :-P
>>
>> When I heard about Oomph, I wasn't sure what is was about, but now it
>> dawns to me, that it changes how one uses Eclipse and the workspace.
> Yes.
>> In fact, the workspace becomes some sort of volatile container to
>> compile stuff and make sure Eclipse can be used at it's full
>> potential, but loosing is it not an issue anymore.
> No, if you describe what's needed well, you can recover it in minutes.
>> In fact, one could argue multiple workspaces are still needed. "Can we
>> drop the switch Workspace feature please!"
> Actually, it's still potentially useful to have an IDE with lots of
> things installed that can also work with various workspaces, but with
> Oomph it's also easy just to have on IDE per workspace, which isn't as
> wasteful as it sounds, because they all share the same bundles from a
> single bundle pool.
>>
>> The central view for me now is the 'GIT Repositories' view and not the
>> Explorer anymore. In fact, I open files from this view more and more
>> often, without importing the project at all. The main driver for this
>> was the switch to tycho. I run maven builds from the root project, and
>> if it builds, I can run the end product from the IDE, but more
>> important is commit it to the build server, and I am pretty sure the
>> build will succeed.
> I see.
>>
>> What a productivity improvement (already)!
>>
>> but to be honest, I haven't started to use Oomph yet, but I know
>> exactly, how I wish to use it.
>> - Setup working sets with projects from git as independent bits
> Working sets can be defined to be dynamic using predicates to describe
> what should and shouldn't be in that working set.
>> - Set the corresponding .target.
> Sorry, but .target files suck big time. Yes you can use Oomph to
> activate one, but Targlets are a dramatic improvement over what you can
> do with "pure PDE", giving you much better control over what ends up in
> your target platform and in your workspace.
>> (With Xtext, I have an issue with this, as the IDE installed xtext
>> plugins need to match the version in the target).
> I need that for Xcore as well, you can look at its setup. I created one
> for Xtext has well, though it still needs some fine tuning. One of the
> very nice things about Targlets is that it unifies the provisioning of
> the target platform with that of the workspace. For example, you say
> you want Xtext in the TP, so in the Targlet Task you specify which IU
> and which p2 update site to get it from. If you also specify to git
> clone Xtext and specify that the targlet look at that repo, you'll end
> up not only with Xext in your TP, but you'll end up with Xtext source
> bundles in workspace (which you can close, because the binaries are also
> in the TP)...
>> - Set IDE preferences.
> Yes, you can record preferences and have the "played back" into each IDE
> you ever start...
>>
>> Productivity will boost even more with Oomph I expect.
> Yes.
>>
>> One more remark, somehow it feels Eclipse should grow closer to git
>> repo's.
> That's what we're trying to to with Targlet tasks; unify the
> provisioning of the TP and the workspace, where the split just depends
> on whether you specify a source locator or not. If source is available,
> it's put in the workspace, if a binary is available, it's put in the TP
> (and if both are available, they show up in both places).
>> Example: When opening a Java file directly from the git repo, it's not
>> compiled and various IDE functions don't work. Of course this is the
>> current state, but I keep thinking, why can't the git repo be a fully
>> functional workspace, which is powered by Oomph to get all configured
>> correctly?
> Just point your targlet at it, and it will put them in the workspace,
> and make sure that everything it depends on is also added to the TP
> (which might require you to specify in which p2 repo to find them).
>
> Of course ideally, all the projects would specify a *.setup, and then
> you'd just choose from the installer (or add project to workspace
> wizard) which one(s) you want...
>>
>> Cheers Christophe
>
|
|
|
| Re: Oomphing paradigm [message #1405340 is a reply to message #1405172] |
Thu, 07 August 2014 06:04 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
On 06/08/2014 9:07 PM, Christophe Bouhier wrote:
> Thanks for clarifying on Oomph.
> The concept of Targlets is interresting, and I do very much agree
> with you on the shortcomings (I am holding back now!) of .target files.
It's really quite terrible....
> But, as I use tycho, I need the .target file.
We use Tycho as well and we love the ability to use Tycho to build Oomph
locally (in less that 2 minutes). In fact it's essential to our local
development because I can't test the installer unless I have a p2 update
site for Oomph itself that includes all my latest local development
changes. So we couldn't live without Tycho in our development process...
>
> The .target editor is so horrible, that I started to query about
> possibilities to break up a .target in pieces, on the tycho mailing
> list, and I was pointed to this tool today:
Yes, it's effectively unusable. Who would design an editor that by the
very process of editing, destroys your active TP?
>
> https://github.com/mbarbero/fr.obeo.releng.targetplatform
>
> It's really awesome, especially the include feature and the fact that
> the .target is generated from this DSL.
Oomph can generate a .target from from a Targlet container, and in fact
we use that for Oomph to speed up the build, because of course Tycho can
use the .target to make the build fast. Not only does it support
..target generation, but it can also update the pom.xmls to make sure
the version of the pom.xml stays in synch with the versions in your
feature.xml and MANIFEST.MF.
As such, a .target file isn't something you ever need to edit, you can
simply induce one if you need one (which is generally only for Tycho,
which of course could be extended to read a targlet container definition
because it has the same information in it as a .target file).
>
>
> An 'end' target for me looks like this now:
>
> target "oss2_xtext231_cdo42SR2"
>
> include "modules/oss2_kepler.tpd"
> include "modules/oss2_emf.tpd"
> include "modules/oss2_xtext_231.tpd"
> include "modules/oss2_cdo_42SR2.tpd"
> include "modules/oss2_mwe_111.tpd"
> include "modules/oss2_nebula.tpd"
> include "modules/oss2_xpand_110.tpd"
> include "modules/oss2_gef_390.tpd"
> include "modules/oss2_orbit.tpd"
> include "modules/oss2_peaberry.tpd"
>
>
> and an example of a plugin is like this:
>
> target "emf" with allEnvironments
>
> // EMF, the latest release.
> // http://www.eclipse.org/modeling/emf/downloads/?project=emf
> location
> "http://download.eclipse.org/modeling/emf/emf/updates/releases/" {
> org.eclipse.emf.oda.sdk.feature.group 1.2.0.v20140203-1126
> org.eclipse.emf.feature.group 2.9.2.v20140203-1126
> org.eclipse.emf.gwt.ecore.feature.group 2.9.0.v20140203-1126
> org.eclipse.emf.codegen.feature.group 2.9.0.v20140203-1126
> org.eclipse.emf.converter.feature.group 2.9.1.v20140203-1126
> org.eclipse.emf.gwt.ecore.edit.feature.group 2.8.0.v20140203-1126
> org.eclipse.emf.rap.edit.ui.feature.group 2.9.0.v20140203-1126
> org.eclipse.emf.gwt.edit.feature.group 2.8.0.v20140203-1126
> org.eclipse.emf.codegen.ecore.feature.group 2.9.1.v20140203-1126
> org.eclipse.emf.mapping.ecore.feature.group 2.7.0.v20140203-1126
> org.eclipse.emf.codegen.ecore.ui.feature.group 2.9.1.v20140203-1126
> etc..
If you look at the targlet definition in EMF, it's much nicer than this
(and is more modular so I can separate out GWT and RAP is if they were
separate projects). At no point would you ever be entering such
version numbers, nor such a large set of feature, because only root
features need to be specified.
>
>
>
>
> On 06-08-14 20:13, Ed Merks wrote:
>> Christophe,
>>
>> Comments below.
>>
>> On 06/08/2014 10:41 AM, Christophe Bouhier wrote:
>>> Hey there,
>>>
>>> I am going through a transformation how I use Eclipse.
>>> In the past, my workspace was important to me. It had to contain all
>>> plugins I need, correctly ordered in WorkingSets. Depending on what I
>>> worked on, I would close/open projects and load a .target file, which
>>> would compile the stuff and all would run nicely. Loosing this setup,
>>> was a horrific thought.
>> :-P
>>>
>>> When I heard about Oomph, I wasn't sure what is was about, but now it
>>> dawns to me, that it changes how one uses Eclipse and the workspace.
>> Yes.
>>> In fact, the workspace becomes some sort of volatile container to
>>> compile stuff and make sure Eclipse can be used at it's full
>>> potential, but loosing is it not an issue anymore.
>> No, if you describe what's needed well, you can recover it in minutes.
>>> In fact, one could argue multiple workspaces are still needed. "Can we
>>> drop the switch Workspace feature please!"
>> Actually, it's still potentially useful to have an IDE with lots of
>> things installed that can also work with various workspaces, but with
>> Oomph it's also easy just to have on IDE per workspace, which isn't as
>> wasteful as it sounds, because they all share the same bundles from a
>> single bundle pool.
>>>
>>> The central view for me now is the 'GIT Repositories' view and not the
>>> Explorer anymore. In fact, I open files from this view more and more
>>> often, without importing the project at all. The main driver for this
>>> was the switch to tycho. I run maven builds from the root project, and
>>> if it builds, I can run the end product from the IDE, but more
>>> important is commit it to the build server, and I am pretty sure the
>>> build will succeed.
>> I see.
>>>
>>> What a productivity improvement (already)!
>>>
>>> but to be honest, I haven't started to use Oomph yet, but I know
>>> exactly, how I wish to use it.
>>> - Setup working sets with projects from git as independent bits
>> Working sets can be defined to be dynamic using predicates to describe
>> what should and shouldn't be in that working set.
>>> - Set the corresponding .target.
>> Sorry, but .target files suck big time. Yes you can use Oomph to
>> activate one, but Targlets are a dramatic improvement over what you can
>> do with "pure PDE", giving you much better control over what ends up in
>> your target platform and in your workspace.
>>> (With Xtext, I have an issue with this, as the IDE installed xtext
>>> plugins need to match the version in the target).
>> I need that for Xcore as well, you can look at its setup. I created one
>> for Xtext has well, though it still needs some fine tuning. One of the
>> very nice things about Targlets is that it unifies the provisioning of
>> the target platform with that of the workspace. For example, you say
>> you want Xtext in the TP, so in the Targlet Task you specify which IU
>> and which p2 update site to get it from. If you also specify to git
>> clone Xtext and specify that the targlet look at that repo, you'll end
>> up not only with Xext in your TP, but you'll end up with Xtext source
>> bundles in workspace (which you can close, because the binaries are also
>> in the TP)...
>>> - Set IDE preferences.
>> Yes, you can record preferences and have the "played back" into each IDE
>> you ever start...
>>>
>>> Productivity will boost even more with Oomph I expect.
>> Yes.
>>>
>>> One more remark, somehow it feels Eclipse should grow closer to git
>>> repo's.
>> That's what we're trying to to with Targlet tasks; unify the
>> provisioning of the TP and the workspace, where the split just depends
>> on whether you specify a source locator or not. If source is available,
>> it's put in the workspace, if a binary is available, it's put in the TP
>> (and if both are available, they show up in both places).
>>> Example: When opening a Java file directly from the git repo, it's not
>>> compiled and various IDE functions don't work. Of course this is the
>>> current state, but I keep thinking, why can't the git repo be a fully
>>> functional workspace, which is powered by Oomph to get all configured
>>> correctly?
>> Just point your targlet at it, and it will put them in the workspace,
>> and make sure that everything it depends on is also added to the TP
>> (which might require you to specify in which p2 repo to find them).
>>
>> Of course ideally, all the projects would specify a *.setup, and then
>> you'd just choose from the installer (or add project to workspace
>> wizard) which one(s) you want...
>>>
>>> Cheers Christophe
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Oomphing paradigm [message #1405387 is a reply to message #1405340] |
Thu, 07 August 2014 08:25 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 07-08-14 08:04, Ed Merks wrote:
Ed, I really need to give Oomph a go hearing all these capabilities.
One clarification on version numbers etc...
In the DSL I use now, I can state 'lazy' for a version, which will
effectively put '0.0.0' in the corresponding IU in the .target file.
Also the fact if the 'slicer' or 'planner' is used, will yield different
results.
How does Oomph deal with this? If versions are not specified in a
Targlet, how do you control which version is populated in the TP, will
be the same as the one resolved by tycho ? Can it be controlled
that the dependencies worked against in the IDE (TP) are the same as
tycho would resolve with the generated .target?
Also, what do you mean with root features, when looking at the emf P2, I
don't see such 'root' hierarchy? For managing a Targlet, I would still
need to pick, EMF, EMF RAP, EMF GWT etc.. right?
Thank You,
Christophe
> Christophe,
>
> Comments below.
>
> On 06/08/2014 9:07 PM, Christophe Bouhier wrote:
>> Thanks for clarifying on Oomph.
>> The concept of Targlets is interresting, and I do very much agree
>> with you on the shortcomings (I am holding back now!) of .target files.
> It's really quite terrible....
>> But, as I use tycho, I need the .target file.
> We use Tycho as well and we love the ability to use Tycho to build Oomph
> locally (in less that 2 minutes). In fact it's essential to our local
> development because I can't test the installer unless I have a p2 update
> site for Oomph itself that includes all my latest local development
> changes. So we couldn't live without Tycho in our development process...
>>
>> The .target editor is so horrible, that I started to query about
>> possibilities to break up a .target in pieces, on the tycho mailing
>> list, and I was pointed to this tool today:
> Yes, it's effectively unusable. Who would design an editor that by the
> very process of editing, destroys your active TP?
>>
>> https://github.com/mbarbero/fr.obeo.releng.targetplatform
>>
>> It's really awesome, especially the include feature and the fact that
>> the .target is generated from this DSL.
> Oomph can generate a .target from from a Targlet container, and in fact
> we use that for Oomph to speed up the build, because of course Tycho can
> use the .target to make the build fast. Not only does it support
> .target generation, but it can also update the pom.xmls to make sure
> the version of the pom.xml stays in synch with the versions in your
> feature.xml and MANIFEST.MF.
>
> As such, a .target file isn't something you ever need to edit, you can
> simply induce one if you need one (which is generally only for Tycho,
> which of course could be extended to read a targlet container definition
> because it has the same information in it as a .target file).
>>
>>
>> An 'end' target for me looks like this now:
>>
>> target "oss2_xtext231_cdo42SR2"
>>
>> include "modules/oss2_kepler.tpd"
>> include "modules/oss2_emf.tpd"
>> include "modules/oss2_xtext_231.tpd"
>> include "modules/oss2_cdo_42SR2.tpd"
>> include "modules/oss2_mwe_111.tpd"
>> include "modules/oss2_nebula.tpd"
>> include "modules/oss2_xpand_110.tpd"
>> include "modules/oss2_gef_390.tpd"
>> include "modules/oss2_orbit.tpd"
>> include "modules/oss2_peaberry.tpd"
>>
>>
>> and an example of a plugin is like this:
>>
>> target "emf" with allEnvironments
>>
>> // EMF, the latest release.
>> // http://www.eclipse.org/modeling/emf/downloads/?project=emf
>> location
>> "http://download.eclipse.org/modeling/emf/emf/updates/releases/" {
>> org.eclipse.emf.oda.sdk.feature.group 1.2.0.v20140203-1126
>> org.eclipse.emf.feature.group 2.9.2.v20140203-1126
>> org.eclipse.emf.gwt.ecore.feature.group 2.9.0.v20140203-1126
>> org.eclipse.emf.codegen.feature.group 2.9.0.v20140203-1126
>> org.eclipse.emf.converter.feature.group 2.9.1.v20140203-1126
>> org.eclipse.emf.gwt.ecore.edit.feature.group 2.8.0.v20140203-1126
>> org.eclipse.emf.rap.edit.ui.feature.group 2.9.0.v20140203-1126
>> org.eclipse.emf.gwt.edit.feature.group 2.8.0.v20140203-1126
>> org.eclipse.emf.codegen.ecore.feature.group 2.9.1.v20140203-1126
>> org.eclipse.emf.mapping.ecore.feature.group 2.7.0.v20140203-1126
>> org.eclipse.emf.codegen.ecore.ui.feature.group 2.9.1.v20140203-1126
>> etc..
> If you look at the targlet definition in EMF, it's much nicer than this
> (and is more modular so I can separate out GWT and RAP is if they were
> separate projects). At no point would you ever be entering such
> version numbers, nor such a large set of feature, because only root
> features need to be specified.
>>
>>
>>
>>
>> On 06-08-14 20:13, Ed Merks wrote:
>>> Christophe,
>>>
>>> Comments below.
>>>
>>> On 06/08/2014 10:41 AM, Christophe Bouhier wrote:
>>>> Hey there,
>>>>
>>>> I am going through a transformation how I use Eclipse.
>>>> In the past, my workspace was important to me. It had to contain all
>>>> plugins I need, correctly ordered in WorkingSets. Depending on what I
>>>> worked on, I would close/open projects and load a .target file, which
>>>> would compile the stuff and all would run nicely. Loosing this setup,
>>>> was a horrific thought.
>>> :-P
>>>>
>>>> When I heard about Oomph, I wasn't sure what is was about, but now it
>>>> dawns to me, that it changes how one uses Eclipse and the workspace.
>>> Yes.
>>>> In fact, the workspace becomes some sort of volatile container to
>>>> compile stuff and make sure Eclipse can be used at it's full
>>>> potential, but loosing is it not an issue anymore.
>>> No, if you describe what's needed well, you can recover it in minutes.
>>>> In fact, one could argue multiple workspaces are still needed. "Can we
>>>> drop the switch Workspace feature please!"
>>> Actually, it's still potentially useful to have an IDE with lots of
>>> things installed that can also work with various workspaces, but with
>>> Oomph it's also easy just to have on IDE per workspace, which isn't as
>>> wasteful as it sounds, because they all share the same bundles from a
>>> single bundle pool.
>>>>
>>>> The central view for me now is the 'GIT Repositories' view and not the
>>>> Explorer anymore. In fact, I open files from this view more and more
>>>> often, without importing the project at all. The main driver for this
>>>> was the switch to tycho. I run maven builds from the root project, and
>>>> if it builds, I can run the end product from the IDE, but more
>>>> important is commit it to the build server, and I am pretty sure the
>>>> build will succeed.
>>> I see.
>>>>
>>>> What a productivity improvement (already)!
>>>>
>>>> but to be honest, I haven't started to use Oomph yet, but I know
>>>> exactly, how I wish to use it.
>>>> - Setup working sets with projects from git as independent bits
>>> Working sets can be defined to be dynamic using predicates to describe
>>> what should and shouldn't be in that working set.
>>>> - Set the corresponding .target.
>>> Sorry, but .target files suck big time. Yes you can use Oomph to
>>> activate one, but Targlets are a dramatic improvement over what you can
>>> do with "pure PDE", giving you much better control over what ends up in
>>> your target platform and in your workspace.
>>>> (With Xtext, I have an issue with this, as the IDE installed xtext
>>>> plugins need to match the version in the target).
>>> I need that for Xcore as well, you can look at its setup. I created one
>>> for Xtext has well, though it still needs some fine tuning. One of the
>>> very nice things about Targlets is that it unifies the provisioning of
>>> the target platform with that of the workspace. For example, you say
>>> you want Xtext in the TP, so in the Targlet Task you specify which IU
>>> and which p2 update site to get it from. If you also specify to git
>>> clone Xtext and specify that the targlet look at that repo, you'll end
>>> up not only with Xext in your TP, but you'll end up with Xtext source
>>> bundles in workspace (which you can close, because the binaries are also
>>> in the TP)...
>>>> - Set IDE preferences.
>>> Yes, you can record preferences and have the "played back" into each IDE
>>> you ever start...
>>>>
>>>> Productivity will boost even more with Oomph I expect.
>>> Yes.
>>>>
>>>> One more remark, somehow it feels Eclipse should grow closer to git
>>>> repo's.
>>> That's what we're trying to to with Targlet tasks; unify the
>>> provisioning of the TP and the workspace, where the split just depends
>>> on whether you specify a source locator or not. If source is available,
>>> it's put in the workspace, if a binary is available, it's put in the TP
>>> (and if both are available, they show up in both places).
>>>> Example: When opening a Java file directly from the git repo, it's not
>>>> compiled and various IDE functions don't work. Of course this is the
>>>> current state, but I keep thinking, why can't the git repo be a fully
>>>> functional workspace, which is powered by Oomph to get all configured
>>>> correctly?
>>> Just point your targlet at it, and it will put them in the workspace,
>>> and make sure that everything it depends on is also added to the TP
>>> (which might require you to specify in which p2 repo to find them).
>>>
>>> Of course ideally, all the projects would specify a *.setup, and then
>>> you'd just choose from the installer (or add project to workspace
>>> wizard) which one(s) you want...
>>>>
>>>> Cheers Christophe
>>>
>>
>
|
|
|
| Re: Oomphing paradigm [message #1405533 is a reply to message #1405387] |
Thu, 07 August 2014 15:04 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Christophe,
Comments below.
On 07/08/2014 10:25 AM, Christophe Bouhier wrote:
> On 07-08-14 08:04, Ed Merks wrote:
> Ed, I really need to give Oomph a go hearing all these capabilities.
> One clarification on version numbers etc...
>
> In the DSL I use now, I can state 'lazy' for a version, which will
> effectively put '0.0.0' in the corresponding IU in the .target file.
> Also the fact if the 'slicer' or 'planner' is used, will yield
> different results.
I see.
>
> How does Oomph deal with this? If versions are not specified in a
> Targlet, how do you control which version is populated in the TP, will
> be the same as the one resolved by tycho ?
Since I don't know what Tycho does, I can't answer that. In Oomph, all
the things you list in the targlet (and in the p2 task for that matter),
are treated as requirements of a synthetic root IU, so I think p2 will
generally try to find the newest version of such things.
> Can it be controlled
> that the dependencies worked against in the IDE (TP) are the same as
> tycho would resolve with the generated .target?
Without Tycho knowledge of it's underlying mechanisms, I can't comment
informatively.
>
> Also, what do you mean with root features, when looking at the emf P2,
> I don't see such 'root' hierarchy?
If a feature includes another feature, you don't need to list the
included ones.
> For managing a Targlet, I would still need to pick, EMF, EMF RAP, EMF
> GWT etc.. right?
Yes, you pick the ones you want from the choices available.
>
> Thank You,
> Christophe
>
>
>
>> Christophe,
>>
>> Comments below.
>>
>> On 06/08/2014 9:07 PM, Christophe Bouhier wrote:
>>> Thanks for clarifying on Oomph.
>>> The concept of Targlets is interresting, and I do very much agree
>>> with you on the shortcomings (I am holding back now!) of .target files.
>> It's really quite terrible....
>>> But, as I use tycho, I need the .target file.
>> We use Tycho as well and we love the ability to use Tycho to build Oomph
>> locally (in less that 2 minutes). In fact it's essential to our local
>> development because I can't test the installer unless I have a p2 update
>> site for Oomph itself that includes all my latest local development
>> changes. So we couldn't live without Tycho in our development
>> process...
>>>
>>> The .target editor is so horrible, that I started to query about
>>> possibilities to break up a .target in pieces, on the tycho mailing
>>> list, and I was pointed to this tool today:
>> Yes, it's effectively unusable. Who would design an editor that by the
>> very process of editing, destroys your active TP?
>>>
>>> https://github.com/mbarbero/fr.obeo.releng.targetplatform
>>>
>>> It's really awesome, especially the include feature and the fact that
>>> the .target is generated from this DSL.
>> Oomph can generate a .target from from a Targlet container, and in fact
>> we use that for Oomph to speed up the build, because of course Tycho can
>> use the .target to make the build fast. Not only does it support
>> .target generation, but it can also update the pom.xmls to make sure
>> the version of the pom.xml stays in synch with the versions in your
>> feature.xml and MANIFEST.MF.
>>
>> As such, a .target file isn't something you ever need to edit, you can
>> simply induce one if you need one (which is generally only for Tycho,
>> which of course could be extended to read a targlet container definition
>> because it has the same information in it as a .target file).
>>>
>>>
>>> An 'end' target for me looks like this now:
>>>
>>> target "oss2_xtext231_cdo42SR2"
>>>
>>> include "modules/oss2_kepler.tpd"
>>> include "modules/oss2_emf.tpd"
>>> include "modules/oss2_xtext_231.tpd"
>>> include "modules/oss2_cdo_42SR2.tpd"
>>> include "modules/oss2_mwe_111.tpd"
>>> include "modules/oss2_nebula.tpd"
>>> include "modules/oss2_xpand_110.tpd"
>>> include "modules/oss2_gef_390.tpd"
>>> include "modules/oss2_orbit.tpd"
>>> include "modules/oss2_peaberry.tpd"
>>>
>>>
>>> and an example of a plugin is like this:
>>>
>>> target "emf" with allEnvironments
>>>
>>> // EMF, the latest release.
>>> // http://www.eclipse.org/modeling/emf/downloads/?project=emf
>>> location
>>> "http://download.eclipse.org/modeling/emf/emf/updates/releases/" {
>>> org.eclipse.emf.oda.sdk.feature.group 1.2.0.v20140203-1126
>>> org.eclipse.emf.feature.group 2.9.2.v20140203-1126
>>> org.eclipse.emf.gwt.ecore.feature.group 2.9.0.v20140203-1126
>>> org.eclipse.emf.codegen.feature.group 2.9.0.v20140203-1126
>>> org.eclipse.emf.converter.feature.group 2.9.1.v20140203-1126
>>> org.eclipse.emf.gwt.ecore.edit.feature.group 2.8.0.v20140203-1126
>>> org.eclipse.emf.rap.edit.ui.feature.group 2.9.0.v20140203-1126
>>> org.eclipse.emf.gwt.edit.feature.group 2.8.0.v20140203-1126
>>> org.eclipse.emf.codegen.ecore.feature.group 2.9.1.v20140203-1126
>>> org.eclipse.emf.mapping.ecore.feature.group 2.7.0.v20140203-1126
>>> org.eclipse.emf.codegen.ecore.ui.feature.group 2.9.1.v20140203-1126
>>> etc..
>> If you look at the targlet definition in EMF, it's much nicer than this
>> (and is more modular so I can separate out GWT and RAP is if they were
>> separate projects). At no point would you ever be entering such
>> version numbers, nor such a large set of feature, because only root
>> features need to be specified.
>>>
>>>
>>>
>>>
>>> On 06-08-14 20:13, Ed Merks wrote:
>>>> Christophe,
>>>>
>>>> Comments below.
>>>>
>>>> On 06/08/2014 10:41 AM, Christophe Bouhier wrote:
>>>>> Hey there,
>>>>>
>>>>> I am going through a transformation how I use Eclipse.
>>>>> In the past, my workspace was important to me. It had to contain all
>>>>> plugins I need, correctly ordered in WorkingSets. Depending on what I
>>>>> worked on, I would close/open projects and load a .target file, which
>>>>> would compile the stuff and all would run nicely. Loosing this setup,
>>>>> was a horrific thought.
>>>> :-P
>>>>>
>>>>> When I heard about Oomph, I wasn't sure what is was about, but now it
>>>>> dawns to me, that it changes how one uses Eclipse and the workspace.
>>>> Yes.
>>>>> In fact, the workspace becomes some sort of volatile container to
>>>>> compile stuff and make sure Eclipse can be used at it's full
>>>>> potential, but loosing is it not an issue anymore.
>>>> No, if you describe what's needed well, you can recover it in minutes.
>>>>> In fact, one could argue multiple workspaces are still needed.
>>>>> "Can we
>>>>> drop the switch Workspace feature please!"
>>>> Actually, it's still potentially useful to have an IDE with lots of
>>>> things installed that can also work with various workspaces, but with
>>>> Oomph it's also easy just to have on IDE per workspace, which isn't as
>>>> wasteful as it sounds, because they all share the same bundles from a
>>>> single bundle pool.
>>>>>
>>>>> The central view for me now is the 'GIT Repositories' view and not
>>>>> the
>>>>> Explorer anymore. In fact, I open files from this view more and more
>>>>> often, without importing the project at all. The main driver for this
>>>>> was the switch to tycho. I run maven builds from the root project,
>>>>> and
>>>>> if it builds, I can run the end product from the IDE, but more
>>>>> important is commit it to the build server, and I am pretty sure the
>>>>> build will succeed.
>>>> I see.
>>>>>
>>>>> What a productivity improvement (already)!
>>>>>
>>>>> but to be honest, I haven't started to use Oomph yet, but I know
>>>>> exactly, how I wish to use it.
>>>>> - Setup working sets with projects from git as independent bits
>>>> Working sets can be defined to be dynamic using predicates to describe
>>>> what should and shouldn't be in that working set.
>>>>> - Set the corresponding .target.
>>>> Sorry, but .target files suck big time. Yes you can use Oomph to
>>>> activate one, but Targlets are a dramatic improvement over what you
>>>> can
>>>> do with "pure PDE", giving you much better control over what ends
>>>> up in
>>>> your target platform and in your workspace.
>>>>> (With Xtext, I have an issue with this, as the IDE installed xtext
>>>>> plugins need to match the version in the target).
>>>> I need that for Xcore as well, you can look at its setup. I
>>>> created one
>>>> for Xtext has well, though it still needs some fine tuning. One of the
>>>> very nice things about Targlets is that it unifies the provisioning of
>>>> the target platform with that of the workspace. For example, you say
>>>> you want Xtext in the TP, so in the Targlet Task you specify which IU
>>>> and which p2 update site to get it from. If you also specify to git
>>>> clone Xtext and specify that the targlet look at that repo, you'll end
>>>> up not only with Xext in your TP, but you'll end up with Xtext source
>>>> bundles in workspace (which you can close, because the binaries are
>>>> also
>>>> in the TP)...
>>>>> - Set IDE preferences.
>>>> Yes, you can record preferences and have the "played back" into
>>>> each IDE
>>>> you ever start...
>>>>>
>>>>> Productivity will boost even more with Oomph I expect.
>>>> Yes.
>>>>>
>>>>> One more remark, somehow it feels Eclipse should grow closer to git
>>>>> repo's.
>>>> That's what we're trying to to with Targlet tasks; unify the
>>>> provisioning of the TP and the workspace, where the split just depends
>>>> on whether you specify a source locator or not. If source is
>>>> available,
>>>> it's put in the workspace, if a binary is available, it's put in
>>>> the TP
>>>> (and if both are available, they show up in both places).
>>>>> Example: When opening a Java file directly from the git repo, it's
>>>>> not
>>>>> compiled and various IDE functions don't work. Of course this is the
>>>>> current state, but I keep thinking, why can't the git repo be a fully
>>>>> functional workspace, which is powered by Oomph to get all configured
>>>>> correctly?
>>>> Just point your targlet at it, and it will put them in the workspace,
>>>> and make sure that everything it depends on is also added to the TP
>>>> (which might require you to specify in which p2 repo to find them).
>>>>
>>>> Of course ideally, all the projects would specify a *.setup, and then
>>>> you'd just choose from the installer (or add project to workspace
>>>> wizard) which one(s) you want...
>>>>>
>>>>> Cheers Christophe
>>>>
>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 17:50:35 GMT 2024
Powered by FUDForum. Page generated in 0.03432 seconds |
] 
Search
Help
Register
Login
Home
