Hi, Ernesto,
I think the Papyrus setup model actually configures that preference to “ignore”. 😕 I can do the something similar in this setup. There are a couple of different tasks in Oomph that have to do with API Baselines, but I haven’t investigated them, yet (there is no documentation for them). One thing I would like to avoid is forcing a download of a whole additional Eclipse installation on people. But one of these tasks appears to create an API baseline from a target, and if it can materialize a baseline from the same shared bundle pool as it does everything else, and if that baseline can include only the Papyrus-RT bundles, then that would be great. I’ll check it out.
Yes, the handling of generated code and the missing empty classpath container folders are not new and unaffected by this setup model. There are no setup tasks for generation of code, and I would much rather see a project builder that does the generation than to attempt to extend the setup framework for that. It really needs to be included in the incremental build in the same way as Xtend. I forgot that I had fixed errors in the Xtext plug-ins by associating a Java 8 run-time with the JavaSE-1.7 EE, because at that time I still had some C++ Codegen plug-ins from Papyrus Extras that on the Neon branch were using Java 8 APIs and language features without having updated their BREEs. But, again, not a setup problem (that was missed in the original port to Neon).
For now, the setup model isn’t installing the codegen bundles in the development environment because (I think) originally I didn’t know that the Papyrus-RT feature actually doesn’t contain them (cf. the discussion about the “All” Hudson build and repository). But then, it seemed that only the tooling would actually be needed for development because it’s all that’s needed for editing the source models. If that’s not true, then I can easily enough add the codegen bundles to the workbench installation. Just let me know.
There are three places where you have to select “Neon” to get a proper Neon setup: - the version of the Eclipse Product on which you’re basing your installation (I always recommend the Eclipse for Committers product)
- the stream of each of the Papyrus-RT project that you import from the setup model
- the value of the “eclipse.target.platform” variable, which if you selected the Neon streams of the imported projects, should default to Neon anyways
Is it possible that you missed one of those? In the mean-time, I’ll try with a new installation, too.
The default name for the git clone should be something like “papyrus-rt-neon” for a Neon stream checkout. I’ll try a from-scratch setup with a new clone and everything to test this.
Christian
On 7 April, 2016 at 15:22:53, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I just tested the latest patch to the developer
Oomph setup. Works great!
There are a couple of kinks though:
3. Errors in the Xtext plugins: the execution environment has
to be updated to Java 1.8; also there is a complain about missing
'src', 'src-gen' and 'xtend-gen' folders. Right now these are empty
so they won't be on git. I'll push a gerrit for this.
What should be done about #1? In the past I've changed
'Preferences->Plug-in Development->API Baselines->Missing
API baseline' from "Error" to "Warning", but I get the feeling this
is very hackiish. Shouldn't we add the target platform to the API
baseline? Or something else?
Also, Christian, I noticed that the latest setup model
mentions the update site where successful builds from tooling are
being published, but not the one for codegen. Does it matter?
Other notes:
- When installing, I selected the neon branch, but it cloned
into a 'mars' folder and checked out the mars branch.
- In the Git Repositories View the cloned repo is shown as if
it was called with the checked out branch (mars). I think it would
be better to give it the same name as the repo, specially since one
may clone other repos (I used Oomph earlier to setup PapyrusRT by
first setting up Papyrus and as a result I got two repositories
named 'master' in the Git Repositories View)
The website exists at https://www.eclipse.org/papyrus-rt/ but it's not
connected to gerrit. So far it's been Simon maintaining it, and I
don't recall where it is stored. I'll look it up.
No,
I don’t suppose we would care much about the history of the setup
model, but we would get it for free, because the Eclipse website is
maintained in git.
BTW, I don’t see a repository for the
Papyrus-RT website in gerrit. Does the website exist, or is
it just not (yet) connected to gerrit?
I think the argument for putting the setup
model in the web repository is very good. But I'm assuming we don't
care much about the model's history, is that right?
Hi,
As a latecomer to the project, I have to ask
why hyphens in project names are bad. Many, if not most,
Eclipse Projects use feature IDs that are the same as their lead
plug-in IDs, and so append a “-feature” on the name of the feature
project to make it distinct in the workspace from the bundle
project of the same name. This avoids the redundant suffix
“.feature” in the actual feature ID, which the results in a p2 IU
name with “.feature.feature.group”.
Anyways,
I can certainly postpone any requests to the Oomph team for
cataloguing our setup model until we have settled the issue at
hand. Developers can always add the setup to their User
Projects from their git checkout.
But, now that you mention it, this
reminds me of a problem that we have in Papyrus that would perhaps
best be avoided here while we have the chance. The problem is
that the setup model actually includes information for all
development streams of the project, which means that it doesn’t
make much sense for it to be hosted within the same Git repository
as the source code that is branched for those various development
streams. In Papyrus we are now maintaining the setup model on
the master branch only, which means that if you’re working on
(e.g.) Mars branch, then you have to switch back-and-forth to the
master branch to work on the setup model. Very
cumbersome.
So, I would rather maintain this setup model
for Papyrus-RT in the web repository. The extra
benefit of this is that then the Oomph Catalogue can reference it
on the Papyrus-RT website, which by-passes the Git repository
viewer. That would make our Webmasters very happy (the web
server takes quite a hit whenever Oomph requests resources from the
git viewer).
I have not looked at the
latest patch set yet, I just wanted to give a quick comment, since
I saw that you wanted to get the model added to the Oomph catalogue
(which I think will be great).
As part of https://git.eclipse.org/r/#/c/69746/ Celine
proposed to rename the project in which this setup-file is placed.
Celine's argument was that it needed to follow naming rules which
disallows '-' to be included in the project name. I made the
comment that any change to the project name, will impact the
installation instructions, including any users that already have
followed these instructions and now have a reference to the setup
file via a plain git resource link as given by the instructions
at https://wiki.eclipse.org/Papyrus-RT/User_Guide/Eclipse_Installer
Since I do know that the
Oomph catalogue uses exactly the same approach using a plain git
resource link, we will "bump into" yet another issue if we later
decide to change the name of the project containing these
setup-files, then with both the product setup files as well as the
new project setup files.
So I would really like
to settle the name of this project. I do know that Celine reverted
the name of the project in later patch sets of that Gerrit change,
but I guess Celine still thinks that the project should align its
names. As I indicated in that Gerrit change, I think that Charles
should give his view on any name change, since it will impact the
installation guide (which Charles has mainly worked with) and the
aspect on the impact on any existing users that now has references
to a file in this project in the Git repo.
Simplest would of course
be if we just accepted that this project keep its name which does
not follow the naming conventions. But I don't know what kind of
impact that will have.... Celine, please give your view regarding
this.
To
follow this up, I have just pushed a new Gerrit patch for a new
Oomph setup model for Papyrus-RT development:
I
would greatly appreciate a review of this patch so that we can
merge it and request this new setup model’s addition to the Oomph
catalogue to get the development team on track for Neon
development.
In
the meanwhile, if you’d like to get a head start on Neon, you can
fetch this patch and use the setup model from your local
filesystem.
Hello
everyone,
The Neon build has been merged on the master branch.
But the papyrus-rt.setup file has not been updated accordingly yet
and should be soon available. Allowing an easy update of your
IDE.
Therefore, it is recommended to push your work on the new mars
branch "origin/mars" waiting for this update in a couple of
days.
Regards
Céline
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|