Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Oomph model for Papyrus

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] 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> 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] 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:
    • Eclipse (of course)
    • EMF Ecore Tools for editing Ecore models
    • UML2 for editing UML models
    • 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
    • Mylyn for working with Git, Bugzilla, Gerrit, and Hudson builds
    • m2e for working with Maven POMs etc.
    • SWTBot for recording automated UI test cases
    • 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
    • features and plug-ins required by Papyrus
    • 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:
    • Open bugs in bugzilla
    • Open enhancement requests in bugzilla
    • Resolved items in bugzilla
    • Bugzilla items that are flagged for review (the review? flag)
    • All open Gerrit reviews
    • 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:
    • the Papyrus code formatter profile
    • the Papyrus copyright header and possibly other templates
    • J2SE 1.6 compliance for compilation

 

You can see a short(ish) video of this Oomph model in action, here:

 

 

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:  

 

 

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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 


Back to the top