Hi, Ernesto,
Sure, not everyone on the team is familiar yet with Oomph, but we are all developers of a complex Eclipse-based modeling tool. We understand models and we understand setting up an Eclipse environment, so any of us is as well equipped as I am to figure out Oomph. Besides, now we’ve built up enough examples in the setup that it should be easy for everyone to maintain! And, of course, I’m always happy to answer questions to help Oomph newcomers. That doesn’t interrupt my work (or yours or anyone’s) as much as running the setup and finding that the workspace has gone haywire. 😀 I would much prefer that everybody become familiar with maintaining the setup by actually doing it themselves when they restructure the repository, instead of delegating the work. That’s better for everyone. And after all, we expect every contribution to build (Gerrit enforces this), so we already have to ensure that the build system is maintained together with the sources, so why not the setup?
cWOn 30 May, 2016 at 16:05:34, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hi Christian.
+1 on people updating the setup model whenever new bundles are
added. I think a few of us are using it, and I expect future
developers will use it too. It's getting far too complicated to
install a developer environment by hand, so the setup model is
becoming a necessity.
Of course, the issue is that not everyone is familiar with
Oomph setup models. In which case, I would propose that, if any
committer adds (or deletes) a new bundle and is not familiar with
the setup models, then inform me and I'll make the updates.
@Remi: do you intend to remove o.e.prt.umlrt.core.cpp?
Oh, I see.
Indeed, this gerrit was not ready to be merged. There are two
problems:
- the org.eclipse.papyrusrt.umlrt.core.cpp bundle is
superseded by the new org.eclipse.papyrusrt.umlrt.cpp bundle,
but the former was not deleted from git. The old bundle
project has the compilation error; you can just close it to get a
clean workspace
- the org.eclipse.papyrusrt.umlrt.core.cpp.tests bundle is
still present and is in the “core” component in git, not in the new
“cpp” component. It should be renamed
as org.eclipse.papyrusrt.umlrt.cpp.tests
Also, I would appreciate it if, when committers add new components
to the repository, they could also update the Oomph setup model to
add sub-projects for those new components so that (a) when
developers run the setup they get all of the right projects in
their workspaces presented in a coherent way and (b) I don’t have
to follow up everybody’s work to do it.
Unless, of
course, I’m the only one using the setup model, in which case I’ll
just ignore any new components. For now, I have created an
update for the setup model:
but I won’t
merge it until the problems above are fixed, because otherwise
people will run the setup, get problems, and blame the setup.
Thanks,
Christian
On 30 May, 2016 at 15:28:35, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Thanks I see the updates to the setup
now.
As for the missing method, the were added by
commit f9a153c99874bde712a93baf3d0c3e00622eccf2,
gerrit 73928 which was merged.
Hi, Ernesto,
The RSA Import bundle was merged by Camille today and I
updated the setup model to provide a new sub-project with the
required dependencies. See the mailing list discussion from
earlier today (eastern time).
I have no compilation errors in the CppDefaultLanguage
class. In my workspace, the IDefaultLanguage interface has no
getSystemClasses method. And my git workspace (fetched today)
has neither of those first two projects. AFAIK, Rémi’s Gerrit
patch hasn’t been merged, yet.
I'm getting some errors after recent merges. I
noticed three new projects:
o.e.prt.umlrt.common.rts.library
o.e.prt.umlrt.cpp
o.e.prt.umlrt.migration.rsa
After importing them most errors go away, except
two:
1) The MANIFEST of o.e.prt.umlrt.migration.rsa shows an
unresolved dependency on org.eclipse.papyrus.migration.rsa;bundle-version="1.2.0",.
I'm guessing this is missing from the target platform?
2) In o.e.prt.umlrt.core.cpp class CppDefaultLanguage gets
this:
The type CppDefaultLanguage must implement the inherited abstract
method IDefaultLanguage.getSystemClasses(ResourceSet)
Is this known? @Remi: I'm guessing this is your work?
--
Ernesto Posse
Zeligsoft
_______________________________________________
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
_______________________________________________
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
|