[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-papyrus.dev] Oomph model for Papyrus
|
I'm not really sure why it failed, but I think it was the settings that I was using. When I gave up on making my own
changes and tried exactly as in your video it worked. I'm not sure if it was a coincidence or if the settings really
were causing problems.
I was trying to change things like the location of the bundle pool, using absolute paths for installation, workspace,
git checkout, and a few others.
One error that was unrelated to the settings (I think) was a "Too many files open" exception after running for awhile.
Restarting the installer and trying again got past that problem. I think this might be a bug in Oomph, but I'm not able
to reproduce it anymore so it is tough to say.
Another thing that I just remembered -- after installing (using a Java6 VM), it refused to load because the IDE requires
Java7. I can see that requirement in the generated eclipse.ini file -- could it have come from the papyrus.setup model?
I was able to get past the problem by switching to a Java7 VM. However, AFAIK, Papyrus is still supposed to work on Java6.
-Andrew
On 14-07-11 08:47 AM, Christian W. Damus wrote:
> 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
>
>
> On Jul 10, 2014, at 10:36 PM, Andrew Eidsness <eclipse@xxxxxxxxxx <mailto:eclipse@xxxxxxxxxx>> wrote:
>
>> 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> <http://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> <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>
>>>> [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> <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> [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> <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> <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 <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
>
