| That's right, Andrew.
Once we're satisfied with the setup model, we need to send a bugzilla to the Oomph team to have it included in their catalogue.
Thanks for your feed-back! If I may ask, why did it take a few tries? Is there some ergonomic improvement that could be made in the setup model?
cW
This is great Christian, thanks! It took me a few tries, but now that it has worked I'm very happy with the result. I certainly would have liked to have had Oomph to set everything up for me earlier. I wonder if there is a place to store the papyrus.setup file other than the repository that is about to be cloned by the setup model that is described in the file that is in the repository that is about to be cloned by the setup model that is described in the file that is in the repository that is about to be cloned by ... :-) I guess that is why you mentioned getting this added to the official Oomph product catalog? -Andrew On 14-07-09 10:41 AM, Christian W. Damus wrote: Great! Thanks again, Benoit.
There was a question about Oomph model reuse on the forum [1] and the answer suggests that the design doesn't support
the kind of use case you're looking at, where (if I understand you right) you would have a model of your own flavour of
Papyrus setup that inherits/reuses the public Papyrus setup model and adds content such as git repositories, project
import tasks, and mylyn queries.
However, composition of models is supported in two ways: by nesting projects and by importing multiple projects into
your Oomph installation. The former is demonstrated amply by the Papyrus setup model I've been working on: for
example, the "extra component" projects inherit some configuration of generalized project-import and working-set tasks
from the "Extras" project and git repository configuration, p2, mylyn queries, etc. from the "Papyrus" project. You can
also just define your internal-Papyrus project on the side and import it into your Oomph install in addition to the
Eclipse.org <http://Eclipse.org> Papyrus setup.
*But* there is one other indirect composition mechanism available, which is the "logical container project". Your
internal-Papyrus setup model can reference any project known in your local Oomph catalogue (including locally-added
projects that aren't in the central catalogue) as the logical container project. This is the project that your project
will be added to as a child when you drag and drop your setup model onto the Oomph Installer wizard. As I understand
it, this will effectively make your project a sub-project of the logical container, so it will inherit all of that
container's configuration. You can "try this at home" already with the Papyrus setup model in git. I'll be interested
to hear back how well it works for you. :-)
I am fairly certain that you can also share an Oomph catalogue with your team, which might then provide your internal
Papyrus setup out-of-the-box, but I think it involves system properties in the config.ini of the Oomph Installer to
configure some redirection of the catalogue URL that the installer loads when it starts up. I don't have a clear
understanding of the details ... best to ask on the forum about that.
I am also fairly certain that Oomph Installer can only configure one Eclipse instance at a time, because the procedure
involves a bootstrapping step to create the instance and then a follow-up to launch that instance and have it complete
the setup itself. There is only a single variable in the setup model that locates the installation. You will need to
have two setup models and run two separate installs with the two different models. But don't worry about
download/install performance; Oomph caches all of the bundles that it downloads in a bundle pool for all installs to
share. Once you have installed a few different EPPs, the p2 tasks run pretty quickly.
HTH,
Christian
[1] https://www.eclipse.org/forums/index.php/t/781760/
On Jul 9, 2014, at 6:44 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx <mailto:Benoit.MAGGI@xxxxxx>> wrote:
Hi Christian,
Good work, it works fine on my machine.
The split of the main sub projects seems good to me.
Do you know if there is a way to “extend” the papyrus setup ?
For example, we may want to add an internal remote for git and configuration to our Jenkins.
Another question, is there a way to setup 2 eclipses with one setup configuration ?
Regards,
Benoit
*De :* mdt-papyrus.dev-bounces@xxxxxxxxxxx <mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx>
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] *De la part de* Christian W. Damus
*Envoyé :* mardi 8 juillet 2014 21:15
*À :* Papyrus Project list
*Objet :* Re: [mdt-papyrus.dev] Oomph model for Papyrus
Hi, Benoit,
I've pushed some improvements to the Papyrus Oomph model. See replies in-line, below, and a new (much shorter)
screencast at http://youtu.be/M6ZnL2mO88Q
Thanks,
Christian
On Jul 7, 2014, at 10:23 AM, MAGGI Benoit Intérimaire <Benoit.MAGGI@xxxxxx <mailto:Benoit.MAGGI@xxxxxx>> wrote:
Hi Christian,
I just tried Oomph with your model and managed to get an environment working.
I looks pretty cool and seems to offer a lot of opportunities but I ran into some issues :
1) I got an exception with “Eclipse Modeling Tool” as main Product
ð see OomphPapyrusFailedModelingCore.txt
[cwd] For some reason, I thought the Oomph tooling was only compatible with EcoreTools 1.x and was incompatible with
the 2.0 version. I think that's bogus, so I've removed the version constraint on the EcoreTools feature in the
Papyrus Oomph model's p2 task. I can now successfully build an Oomph install based on the Modeling EPP.
2) While following your video (except cloning the git repo) I got an OutOfBoundException
ð see Oomph Installer_OutOfBoundException
[cwd] I think I saw this a few times, too, but am not now able to reproduce it (perhaps because there's been a new
Oomph build?). In any case, it's an Oomph bug and it doesn't seem to interfere with the installation process; it's
only in the wizard.
3) I tried to install only an extra-plugin (Moka) but I got a workspace with compilation problems
ð probably because we don’t have any papyrus product entry
[cwd] The model is now restructured so that the common descriptions of Mylyn queries, the git repository, and PDE
target are in the top-level "Papyrus" Oomph project. These were in the "Main" sub-project, so it was necessary to
import at least Papyrus/Main in addition to the Papyrus/Extras/* component that you wanted to work on. Now, this is
no longer the case. The only importable projects are the leaf-level sub-projects (which is less confusing anyways)
and you can pick and choose as you like. There are still a few dependencies between them for individual projects (for
example, as shown in the latest screencast, one of the test plug-ins in the UML component needs one of the test
plug-ins in the Views component). This should be quite manageable for developers: you can always import additional
projects from the workspace or just import the component that has it from the Oomph model, or else close a project
that's missing its dependencies if you don't care about it.
Also, the need for the Oomph feature patch implementing nested variable expansion (which the Oomph committers don't
want to support) is now removed by simply repeating all of the variable definitions in every stream of every
sub-project. It's not pretty, but it works.
I've also removed some configuration that was interfering with the way Oomph likes to manage git clone locations on
the local filesystem.
I also have some remarks :
- My first installation (without cloning the git repository) took 20/30 min (+15 min for “build all”)
ð For a new guy hopping to contribute, it will take at least one hour to get the environment working.
[cwd] Well, an Eclipse workbench, git repository, and workspace can be quite large and complex things and take a
while to get set up. At least Oomph makes it a hands-off process that requires almost no thought. There is a
definite limit to how quickly even Oomph can pull things together.
- Is it possible to have an official Papyrus product on the wizard first page ?
[cwd] If the Papyrus project creates an EPP, it could be added to central Oomph catalogue. I don't think such an EPP
exists, yet.
- I would prefer to split the Main project in sub projects : infra, uml, sysml…
[cwd] I've broken the Main suib-project down further into what I hope are useful groupings. At this point, I'm happy
to leave further tweaking to others. (I, for one, generally work with all of the Papyrus sources in my workspace
because I want to take care not to break API dependencies).
My main concern is for the thirds issue because it will be a normal use case : contributing to an extra without
coding in Papyrus main.
[cwd] Yep. That should be cleared up, now.
Regards,
Benoit
*De :* mdt-papyrus.dev-bounces@xxxxxxxxxxx
<mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx> [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] *De la part de* Christian W.
Damus
*Envoyé :* lundi 7 juillet 2014 04:24
*À :* Papyrus Project list
*Objet :* [mdt-papyrus.dev] Oomph model for Papyrus
Hi, Team,
I have developed an initial Oomph model for Papyrus that provides a complete Eclipse IDE for working on the Papyrus
sources. This model defines several projects:
* Main - the main Papyrus sources. You should always import this Oomph project
* Extras/* - the extra components sources. Import any of these Oomph projects only if you need to work on those
extra components
* Developer - the development-time code generation tools and debugging aids
that each have two different streams:
* maintenance (Luna/1.0.x) - for SR1 development, until we branch it and master is taken over for Mars
* master (Mars/1.1) - a sketch of what the Mars stream would look like once we have branched Luna maintenance and
Papyrus’s dependencies have started publishing milestone builds towards Mars release
For now, the Luna maintenance stream is the default choice because that is the only active stream in the Papyrus
repository (it actually is master) and the Mars stream isn’t actually functional because it guesses at what p2
repositories of project dependencies will be that don’t yet exist. Be sure, if you import both the main and extras
Oomph projects, that you import the same stream of each.
So, when using this Oomph model to import Papyrus, you can only reasonably choose the Luna maintenance stream (which
is the default selection).
Both of these streams are configured to perform the following setup tasks:
* install various tools in the host workbench required for development of the Papyrus code, including:
o Eclipse (of course)
o EMF Ecore Tools for editing Ecore models
o UML2 for editing UML models
o Papyrus for editing our developer documentation models but also because the QVTo editor requires it for
resolving Papyrus metamodels in the customization model generation transforms: QVTo doesn’t resolve
these dependencies in the PDE target (as it should) but instead in the installed IDE
o Mylyn for working with Git, Bugzilla, Gerrit, and Hudson builds
o m2e for working with Maven POMs etc.
o SWTBot for recording automated UI test cases
o Oomph for running setup tasks
* clone the Papyrus git repository into the location of your choice if it has not already been cloned
* define a complete PDE target for all of the Papyrus codebase, including both main and “extra” plug-ins
o features and plug-ins required by Papyrus
o the latest Papyrus nightly build from the appropriate stream (so that you don’t have to have all of the
Papyrus source projects open in your workspace)
* import all of the currently active Papyrus main plug-in projects into the workspace from the git repository (and
the extra components if you also imported any of those Oomph sub-projects)
* Mylyn queries for:
o Open bugs in bugzilla
o Open enhancement requests in bugzilla
o Resolved items in bugzilla
o Bugzilla items that are flagged for review (the review? flag)
o All open Gerrit reviews
o Hudson builds:
+ Papyrus trunk nightly
+ Papyrus trunk nightly tests
+ Papyrus trunk extras nightly
+ Papyrus trunk extras nightly tests
* working sets to organize all of the Papyrus main sources (and the extra components if you imported any of those
Oomph sub-projects)
* workspace-wide preferences, including:
o the Papyrus code formatter profile
o the Papyrus copyright header and possibly other templates
o J2SE 1.6 compliance for compilation
You can see a short(ish) video of this Oomph model in action, here:
http://youtu.be/hgKjzr2pXzI
and you can try it out for yourself by running the Oomph installer on the setup model in the new
org.eclipse.papyrus.oomph project in Git master:
releng/org.eclipse.papyrus.oomph/setups/papyrus.setup
If you have any feed-back or suggestions of content to change or add in this model, please comment on the bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=438981
When we deem this model sufficiently ready for the community at large to start using it to provision their workbenches
for contributing to Papyrus, then I'll work with the Oomph team to add it to the official project catalogue.
Thanks,
Christian
<OomphPapyrusFailedModelingCore.txt><Oomph
Installer_OutOfBoundException.png>_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx <mailto:mdt-papyrus.dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx <mailto:mdt-papyrus.dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
