[Oomph] Create an Oomph setup model for OCL

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 430983 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 24, 2014 06:03 EDT | | Modified | May 28, 2015 05:37 EDT | | Reporter | Felix Dorner |

Description

This bug shall discuss the initial creation of an Oomph setup model for Eclipse OCL. In a sentence, Oomph performs automated setup of workspace/target platform/preferences. For more info: http://wiki.eclipse.org/Eclipse_Oomph_Installer

[eclipse-ocl-bot]

By Felix Dorner on Mar 24, 2014 06:07

After some experiments and after discussion on the EMF newsgroup, it seems to be necessary to change the version constraint for lpg.runtime.java in the org.eclipse.ocl feature to use "0.0.0". With the current setting "2.0.17.qualifier", the p2 director won't find the bundle. I also tried "2.0.17" and that doesn't work either. This has also been discussed on the EMF newsgroup under the thread "[Oomph] Targlet resolve fails for feature with mixed plugin locations"

[eclipse-ocl-bot]

By Ed Merks on Mar 24, 2014 10:50

Note that if you want to work around the problem, you could write a task that changes the feature.xml, i.e, a Text Modify task with a pattern match to change the hard-coded value to an omni version. You could look at the Platform.setup for an example

[eclipse-ocl-bot]

By Ed Willink on Mar 24, 2014 15:26

(In reply to Felix Dorner from comment #1)

"2.0.17.qualifier", the p2 director won't find the bundle.

The usage of 2.0.17.qualifier seems to be inconsistent in many ways.

So long as 2.0.17 is all that is in Orbit, we should be able to change to 0.0.0.

If Orbit advances, then we may need to find a way to ensure that 2.0.17 is all that is available for Hudson to distribute.

Do you want this to be changed?

[eclipse-ocl-bot]

By Felix Dorner on Mar 25, 2014 04:07

(In reply to Ed Willink from comment #3)

Do you want this to be changed?

Yes, please use 0.0.0. I can then attach a .setup file.

[eclipse-ocl-bot]

By Felix Dorner on Mar 25, 2014 09:35

Created attachment 241222 Initial Oomph setup model for ocl

So here's my try. Some notes:

• I didn't replicate all the working sets from the psf files, not sure if all are needed, we can add them later.

• To setup formatter preferences I used the recorder. I imported and applied the OCL formatter preferences.xml file from the ocl.releng project. Should this do the trick? It seems to work, but I formatted some projects and got lots of changes. But maybe code in repo has already messed up formatting?

• I didn't want to add the org.eclipse.sdk feature to the targlet, but without it, there are compiler errors about SWT. (If I remove the feature, I get org.eclipse.swt, but not the win32 fragment)

• I also had to add emf.validation to the targlet. I think it's because it is specified as an 'optional' dependency on one of the ocl plugins.

• I preconfigured some mylin queries, some for bugzilla and some for gerrit.

ocl.setup

[eclipse-ocl-bot]

By Felix Dorner on Mar 25, 2014 09:44

Oh, and there was another thing: The mylin commit template from the OCL wiki is multi-line, but I don't know how to add a multi-line preference value. The only way I can think of is to hack the file by hand.

[eclipse-ocl-bot]

By Ed Willink on Mar 25, 2014 09:49

I don't use Mylyn so I've no idea what you are referring to.

[eclipse-ocl-bot]

By Felix Dorner on Mar 25, 2014 10:01

(In reply to Ed Willink from comment #7)

I don't use Mylyn so I've no idea what you are referring to.

https://wiki.eclipse.org/OCL/Dev/Setup#Mylyn_EGit.2FGerrit_integration

[eclipse-ocl-bot]

By Ed Willink on Mar 25, 2014 10:24

You can see from the GIT history that I do

[${task.key}]

manually. I find commits that have used the GIT template very unhelpful; the GIT overview just shows a repreated and sometimes unhelpful title.

If a simpler template helps you then we can easily change.

Similarly the code templates await a refresh to accommodate more realistic line lengths; I sometimes get annoyed when some sensibly formatted code gets trashed.

So again don't struggle to much to maintain the current state of the art.

Just maybe if you provide a cleaner setup I might be persuaded that Mylyn/Gerrit are not designed to increase my numbers of bad days.

A 0.0.0 LPG dependency sems to have built ok on https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/lastSuccessfulBuild/ so I've pushed it to master.

[eclipse-ocl-bot]

By Ed Merks on Mar 25, 2014 11:08

With regard to the comment

• I didn't want to add the org.eclipse.sdk feature to the targlet, but without it, there are compiler errors about SWT. (If I remove the feature, I get org.eclipse.swt, but not the win32 fragment)

Note that the way fragments are handled you are generally best off to include a feature that includes the fragments because otherwise you have to specify fragments directly, and that's bad because there are so many platform specific variants.

Also consider that not only do you want a target platform that makes the source code happy, you want a target platform that you can use to launch Eclipse itself to test UI integration and so on. So if you have IDE-based editors you most likely do want the SDK...

[eclipse-ocl-bot]

By Eike Stepper on Mar 25, 2014 20:25

Created attachment 241245 Project-specific properties for the commit templates

I use project-specific properties for the commit templates, as shown in the attached screenshot. Then I always use our org.eclipse.emf.cdo.releng.projectcopy feature when I need new projects, which is like a one-time copy+adjust+import wizard. Later we want to add documentation on how to use our org.eclipse.emf.cdo.releng.projectconfig model to define and enforce project-specific property templates.

screenshot1.png

[eclipse-ocl-bot]

By Felix Dorner on Mar 31, 2014 12:49

(In reply to Ed Willink from comment #9)

You can see from the GIT history that I do

[${task.key}]

manually. I find commits that have used the GIT template very unhelpful; the GIT overview just shows a repreated and sometimes unhelpful title.

This should work fine.

Similarly the code templates await a refresh to accommodate more realistic line lengths; I sometimes get annoyed when some sensibly formatted code gets trashed.

There's an option "Format on save" which I usually disable directly. Instead, I'm used to format the sections of code that I write with the format command.

So again don't struggle to much to maintain the current state of the art.

It's just that the wiki page seemed like a good "template" for the oomph model. If you want, remove the trash from the page and I'll update the model.

Just maybe if you provide a cleaner setup I might be persuaded that Mylyn/Gerrit are not designed to increase my numbers of bad days.

I have no real experience with gerrit. If you're fine with merging stuff from github, we can remove gerrit and just leave mylin+bugzilla.

What else do you want cleaned?

A 0.0.0 LPG dependency sems to have built ok on https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/ lastSuccessfulBuild/ so I've pushed it to master.

Nice, thanks.

[eclipse-ocl-bot]

By Ed Willink on Apr 10, 2014 05:44

Where are we on this Bug?

I tried to use the original attachment, but not knowing what to do, I was not sure what I created where. Certainly nothing useable as a development environment.

It was far from clear to me what were limitations in the original attachment and what were Oomph bugs; e.g. I could not be anonymous.

[eclipse-ocl-bot]

By Felix Dorner on Apr 10, 2014 06:18

(In reply to Ed Willink from comment #13)

I tried to use the original attachment, but not knowing what to do, I was not sure what I created where. Certainly nothing useable as a development environment.

The intended result is to end up with a running workspace that contains the OCL sources. (Plus the mylin/gerrit stuff, but let's go step by step)

How was your result different from that?

It was far from clear to me what were limitations in the original attachment and what were Oomph bugs; e.g. I could not be anonymous.

We could add a second model OCL (Anonymous), for users that just want a development environment and don't plan (yet) to commit something back or use the mylin bugzilla connector. But maybe another problem was the clone url? I use the gerrit repo location, and afaiu you need an account/ssh keys setup for this. We could could use the github or eclipse.org location to avoid that, but users would need to setup gerrit themselves later.

[eclipse-ocl-bot]

By Ed Willink on Apr 10, 2014 06:54

(In reply to Felix Dorner from comment #14)

How was your result different from that?

I expected that the GIT repo browser would show me an OCL (and EMF) repo clone, probably with all active projhects checked out into nice working sets. Workspace and Git Repo browser were empty.

(Anonymous)

I presume that the goal is to be as friendly as possible, so I would expect that a default (read-only) working environment would work with as much Next,Next,Next etc as possible. I think it is an Oomph bug that prohibits blank entries for anonymous. Changing from read-only experimenter to read-write contributor could be an Oomph re-install/tune-up option.

My attempt took a long time, and while Oomph said to be patient, there was no comforting cloning in progress message to reassure me. I just know from the very long delay that it probably was cloning. However I have yet to find out where/if a clone was created. IIRC correctly Oomph switched user on me to be the Windows administrator so maybe everything ended up in a useless place.

Scanning the setup file, I was uncomfortable with what appeared to be configured on a per-workspace rather than per-project basis. I don't know whether this is your or Oomph's work-in-progress. Eclipse has major limitations in supporting configuration of preferences for project groups. So until project groups are supported, IMHO Oomph may help in enforcing consistent settings for project groups and Oomph must not change default Eclipse workspace settings.

[eclipse-ocl-bot]

By Eike Stepper on Apr 10, 2014 08:27

(In reply to Ed Willink from comment #13)

It was far from clear to me what were limitations in the original attachment and what were Oomph bugs; e.g. I could not be anonymous.

You can already use the (virtual) user ID "anonymous".

[eclipse-ocl-bot]

By Ed Willink on Apr 10, 2014 08:42

(In reply to Eike Stepper from comment #16)

(In reply to Ed Willink from comment #13)

It was far from clear to me what were limitations in the original attachment and what were Oomph bugs; e.g. I could not be anonymous.

You can already use the (virtual) user ID "anonymous".

Yes, but it's not the no-typing default.

[eclipse-ocl-bot]

By Felix Dorner on Apr 10, 2014 09:18

(In reply to Ed Willink from comment #15)

Scanning the setup file, I was uncomfortable with what appeared to be configured on a per-workspace rather than per-project basis.

Why not just commit project-specific preferences? Then you could of course remove them from the setup model. Eike mentioned he always creates projects from a template and so makes sure that his preferences are in sync. Agreed that this could be easier, but in the end projects are created only once, so It's not really a huge deal. Is it that process that bothers you?

[eclipse-ocl-bot]

By Ed Willink on Apr 10, 2014 09:31

(In reply to Felix Dorner from comment #18)

Eike mentioned he always creates projects from a template

Good idea, don't know how to do it. I have a Bug open on not being able to copy a plugin project, adjust with Notepad, then import.

I'm hoping that Oomph is going to make my life better as well as casual developers, so a multi-project co-ordination would be good. ?? A ProjectBuilder that automatically synchronizes slave project settings with a master/branding project ??

[eclipse-ocl-bot]

By Eike Stepper on Apr 11, 2014 00:41

You can already use the (virtual) user ID "anonymous".

Yes, but it's not the no-typing default.

Hi Ed, yesterday we've realized that it's even worse: with ssh:// you can't seem to log in anonymously (which makes sense to me). For the new Oomph we're currently working on a new story for variable resolution that includes rule handling.

The GitCloneTask seems to be one with the most complex requirements and we plan to change it in several ways to satisfy the needs of project authors and users as much as possible. It'll take one or two more weeks to stabilize these new designs.

Meanwhile you should be able to use a redirection task in your Preferences model to adjust the remoteURI in the GitCloneTask to an http:// URI. Sorry for the temporary inconvenience.

[eclipse-ocl-bot]

By Ed Willink on Jul 29, 2014 13:44

Christian Damus has debugged a variety of issues while getting a Papyrus Oomph working. See news://news.eclipse.org:119/lr8hia$f14$1@news.eclipse.org

OCL should be much simpler than Papyrus, so I suggest simplifying what he did.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 03, 2015 07:13

Hi Folks,

I've committed a new org.eclipse.ocl.oomph project (in the 'releng' git repo folder) with an ocl.setup file. It properly imports the OCL projects in the workspace organised in some working sets. After changing the preference of the lack of API Baseline (to ignore it), there some compiler errors in the following projects,:

a)

• "org.eclipse.ocl.examples.consumers.tests",
• "org.eclipse.ocl.examples.xtext2lpg",

Which are not properly updated given EdW recent names refactoring (Pivot promotion).

b)

• "org.eclipse.ocl.xtext.*" grammars.\ The IDE is installed from mars repository (M4), hence the "old" pivot meta-model. Xtext grammars are importing the meta-models via its nsURI, therefore Xtext grammars emit an error given the new Pivot meta-model URI. Not a real problem: after M5 a fresh oomph based setup will not have those grammar errors. On the other hand, I'm wondering why not using others URIs formats instead (for instance, platform:/resource ). I presume that EdW can say something about it.

Apart from that, some other comments:

• LPG. For the time being, it's in the target platform. If you wanted it in the workspace, I think we could use the "Project sets import" task to import the ProjectSet you had created to import lpg from the Orbit's CVS repository. I don't know if there is another way to do that.
• I've included some of the Felix contributions, e.g. Mylyn queries.
• I've added another mylyn tasks to manage the hudson builds. I hadn't used that Mylyn tool for Hudson, but it seems quite useful/impressive, specially for allowing to see the test cases results in the JUnit view.
• I also want to setup the API base line, for which I noticed there is an specific task. However, I'm not sure how to use it since I've not seen any hint in the documentation or examples before. Should I just use the "location" to reference a kind of Target Platform file with the API base line? I'll be playing around it.
• Also to do, for the Releng subproject: import the release train stuff.

EdM, Eike (and whoever else has worked on this) congratulations for this tooling, I really like it :).\ EdW, have a look if you can use the setup. When configuring variables during the installation process, I suggest the following one for the "Git clone location rule":

"Located in a folder named '-' within the root Git-container folder" (or the /), so that:

1. Every time you do a new setup, the git repos are not cloned again.
2. You have separate git-repos when working with the main development stream, and the maintenance one.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Jan 03, 2015 08:50

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #22)

I've committed a new org.eclipse.ocl.oomph project (in the 'releng' git repo folder) with an ocl.setup file.

Thanks.

It properly imports the OCL projects in the workspace organised in some working sets.

How? nothing in project/context menus/no action in setup.

ocl.setup has 4 validation errors.

there some compiler errors in the following projects,:

a)

• "org.eclipse.ocl.examples.consumers.tests",
• "org.eclipse.ocl.examples.xtext2lpg",

Oops. Fixed.

b)

• "org.eclipse.ocl.xtext.*" grammars. The IDE is installed from mars repository (M4)

Is there no option to use GIT/a nightly repo?

Where are the options?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 03, 2015 09:53

Hi Ed,

I don't see any error in the model. Please, download all the "setup" features from the oomph repository[1].

It also contains some documentation in the Help center, which can help you to use the ocl.setup file. In essence:

• Download the oomph installer[2] and execute it. This oomph installer will be now, the tool to install other/new tools.
• Follow the wizard, ensuring that you select the OCL/Development and/or OCL/Releng projects (in the wizard's Project Page, after adding the ocl.setup in the same Projects page).

(In reply to Ed Willink from comment #23)

Is there no option to use GIT/a nightly repo?

Where are the options?

The tool installs a new IDE. I see reasonable, for any developer (we or anyone else interested), installing components from the default mars official repository, in essence, the last released milestone. If you wanted, additional repositories might be used, to install components from nightly repositories.

Actually, in the model, if you look at the first "Eclipse Installation"/P2 "Director Task (Developer IDE)", you can see how I added the platform interim repository to install the more recent JDT which fixes Bug 455557. I tend to remove that repository entry after M5.

You can try to add the OCL nightly repo, to verify that the more recent components are installed, and those errors disappear. Once the first IDE is created/installed, you can do changes to the original ocl.setup file and do "Help->Perform setup tasks...", which will configure the changes for you (including installing new components in the IDE).

Cheers,\ Adolfo.

[1] http://download.eclipse.org/oomph/updates/latest\ [2] https://wiki.eclipse.org/Eclipse_Oomph_Installer

[eclipse-ocl-bot]

By Ed Willink on Jan 03, 2015 10:12

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #24)

I don't see any error in the model. Please, download all the "setup" features from the oomph repository[1].

But that forces Maven on me. Ehat is the necessary install?\

• Download the oomph installer[2] and execute it. This oomph installer will be now, the tool to install other/new tools.

I don't understand. I'm an Eclipse user, why does it need a separate tool for working installations?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 04, 2015 05:58

Hi,

I'm suggesting to use the oomph installer, as a main tool to start setting up fresh IDEs/workspaces etc., which is what I've been exercising. Any other new use case is as new for me as it's for you.

That said, I've done more investigations for you. Just try the following, which will get you to the Projects wizard page I mentioned before:

• File -> Import... -> Oomph -> Projects into Workspace

With respect to the the Oomph setup features. You complained about model errors, and I don't have them, so I simply told you the features I installed. If you are clever enough to know that you don't need the Maven-related feature, I'm pretty sure you can manage to get the necessary install. That said, I can only discuss about errors as long as we are playing with the same IDE configuration.

Suggestion: If you don't want to change your dev IDE to experiment around what Oomph can offers you, I suggest installing a new IDE. Use Oomph installer for that :D

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 04, 2015 06:45

EdM, Eike

I've got an issue with the ocl.setup. In principle, we need to have some emf projects (in essence, org.eclipse.emf.examples.library) in the workspace (for some testing and documentation).

In principle, adding a second GIT clone task for clonning EMF repo and importing the required EMF projects was not a trouble. However, that worked for me because the selected stream when installing, let's say the "Developement" project, was "master", and that branch name existed in both repositories. This doesn't occur when I want to setup the maintenance stream, because the corresponding branch names are different.

Could you give me a hint or point me out and example to see how to address this specific scenario ?

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Eike Stepper on Jan 04, 2015 07:11

You can add the second GitClone task to your project's list of tasks and set its checkoutBranch attribute to "${emf.branch}". Then you can define different VariableTasks in the streams of this project to specify the stream-spcific checkoutBranch values.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 05, 2015 07:14

Hi Eike/EdM,

Thanks a lot. I've added the support to the requirement given your hints (I've pushed a new asbh/430983 branch)

Regarding the API Base Line, I've not got what I wanted to do. My idea was using a target platform file (.target), which is already used by our buckminster based build, in order to set the API Base Line of the new IDE. I tried location and remoteURI attributes with no luck: oomph "successfully" performs the task, but no API Base Line is set.

Could target platform files be used for this task ?. How should that API Base Line task be used ?

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Eike Stepper on Jan 05, 2015 08:55

You must provide the URL to archive that contains the baseline artifacts. The CDO setup file contains an example. The archive must contain a top-level folder that contains the "plugins" folder. This top-level folder will become visible in your filesystem after the installation.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 05, 2015 13:27

Hi Eike,

Thanks. I've finally set up the API base line :)

EdW, for the time being, I've created a zip file with the Luna OCL binaries in the org.eclipse.ocl.oomph project. When target definitions are supported, I'll use the .target file we had defined for buckminster. I plan to move it from the releng project to the oomph one (updating the corresponding bucky scripts).

Other comments:

• I've included some contributions to also clone the simrel repo, import the simrel project and adding it to the OCL-Releng working set.
• Regarding the Code Formatter preference. That was the typical preference I easily forget to set. In any case, I'm inclined to not to include it as workspace preference. Each Eclipse project might have their own policy/rules. Therefore, this should be a per (OCL) project preference.

The other task I have got pending, is sending a gerrit push to oomph project so that the OCL setup can be available in the general Eclipse.org project catalog in the future.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 06, 2015 10:15

After some WorkingSet tuning suggested by EdW, I've done some last bits and merged asbh/430983 on master.

The contribution to the Eclipse.org catalag just waiting for Gerrit review[1]

Cheers,\ Adolfo.

[1] https://git.eclipse.org/r/#/c/39043/

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 09, 2015 07:37

OCL setup available in the Eclipse.org catalog.

I'll wait till post-M5 to close the bug:

1. I want to remove the P2 repo entry referring the platform interim repository.
2. I want to check that Xtext grammars errors disappear with a fresh installation after M5.

EdW, with respect to 2, since we need OCL components to develop OCL, it might make sense to install OCL components in the IDE from nighty and/or interim repositories. Please let me know what's your preference. In principle all remaining components will be installed from the last released milestone (e.g. http://download.eclipse.org/releases/mars).

[eclipse-ocl-bot]

By Ed Willink on Jan 09, 2015 08:40

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #33)

2. I want to check that Xtext grammars errors disappear with a fresh installation after M5.

Unfortunately the Xtext index is aggressive in discovering model candidates. IMHO this wastes a lot of time and results in some very wrong behaviors. I thought that the current problems were just for me from UML-aligned candidates in the build plugin. Fundamentally this requires an understnading of the undocumented Xtet indexer so that its options can be exploited to avoid this nonsense.

EdW, with respect to 2, since we need OCL components to develop OCL, it might make sense to install OCL components in the IDE from nighty and/or interim repositories.

I think milestones should be fine-enough grain by default. Nothing will be perfect. Users can always update from interim/nightly.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 25, 2015 07:04

(In reply to comment #33)\

I'll wait till post-M5 to close the bug:

1. I want to remove the P2 repo entry referring the platform interim repository.
2. I want to check that Xtext grammars errors disappear with a fresh installation after M5.

I've additionally introduced a last change to the Oomph file:

• Including MARTE feature in the TP to make the consumers.tests be free of compilation errors.

I've also created an entry in the wiki, anticipating possible changes between releases transition:

https://wiki.eclipse.org/OCL/Dev/Releng/ReleasesTransition#Oomph_project_configuration

Resolved as fixed