Hi, Ernesto,
Yes, the idea behind the ‘releases’ TP would be as the basis for bug fixes, but we haven’t yet got maintenance development streams because we haven’t yet reached a 1.0 release and much of our new development requires new APIs in Papyrus, so the latest Papyrus release isn’t so useful. Likewise the ‘milestones’ TP, which would be useful for third parties building extensions to Papyrus who only need to synchronize occasionally with new development. Again, not a description of Papyrus-RT. The EMF Compare and EGit dependencies are pretty clearly in the main Papyrus-RT project’s targlet, so unless you’re not importing any stream of the top ‘Papyrus-RT’ project node, I have no explanation for why you should be getting these compilation errors. It should not be necessary to set your PDE Target from the target definition used by the build.
The Oomph Installer is targeted at developers contributing to Eclipse projects. I think that for end users of the Papyrus family of tools, an RCP package, the Modeling Components installer provided by Amalgam, Eclipse Marketplace, or some combination of all of these would be a better experience. Perhaps the Oomph setups were helpful to bootstrap an installation procedure before these other mechanisms were in place for Papyrus-RT, but I would like to see them deprecated.
On 15 July, 2016 at 12:30:07, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hi, Ernesto,
See some replies in-line, below.
cW
On 15 July, 2016 at 11:38:44, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Ok, I see.
So it is up to the developer to set the TP whenever a
dependency has been added?
In general then, what should be done, 1) by someone
adding a new dependency, 2) by a developer using the Oomph
setup?
From what I understand, for 1), the developer adding a
new dependency is responsible for
1. updating MANIFEST and POM files as
required
2. adding it to the relevant .tpd(s) (releases, nightly
and/or milestones); to all of them or only some?
3. creating/generating the .target(s) from the
.tpd(s)
4. committing all (including the .target(s)) to the
repository
5. adding them to the three .setup models (user, tester
and developer)
6. committing the updated .setup
models
Is this correct?
Yes, although
- I don’t understand why we have three target platforms. At
the rate at which Papyrus and Papyrus-RT are co-evolving, we will
not have any use for the “milestones” and “releases” TPs in the
foreseeable future. As you’ve noticed, some bits of
Papyrus-RT are already relying on new APIs added to Papyrus since
the last release, and there isn’t a new Papyrus Milestone,
yet. I don’t think anyone can plausibly use any TP but the
“nightly”; they won’t be developing on a realistic target
Right. I don't know either (I didn't create them). I'm not
sure about the motivation. I suppose you don't need the releases TP
for deployment? Perhaps the idea is to provide a TP for bug fixes
after a release?
- likewise, I don't know why we have more than one setup
model. For non-developers, the best deployment vehicle is the
Papyrus-RT RCP package. But, I suppose until we have that, if
any new external dependency is introduced (such as requiring EMF
Compare), then yes, it is helpful to any consumers of these setups
to add that new dependency to them
But if we don't have the user Oomph setup, end-users won't be
able to install it using the Eclipse Installer, no? Don't we want
that?
As for 2), the rest should:
1. perform the setup tasks
2. setting the TP
I don’t understand the second item. Why would you set a
TP when the setup already configured your PDE target?
I thought it would be, but I only got rid of the errors in my
workspace after selecting
oeprt.targetplatform.neon.papyrusnightly.tpd, then
right-click->Set as Target Platform.
Perhaps what I had before was another TP?
Philip suggested I do that in case it was a caching
issue.
Anything else?
One potential problem is that other developers may not
know which TP to set. For example, what happened to me: the
'releases' TP did not work, but the 'nightly' did. How should other
developers know which is the "correct" TP?
Again, why? The setup provisions the PDE Target. I
suppose if you don’t use the setup tooling for some reason, you
might then set the TP as your PDE Target, but as I said before that
can only ever be the ‘nightly’ one. The other two are
useless.
Well, I still got the errors after performing the setup tasks,
so the setup may not have set the right TP?
Hi,
Oomph doesn’t use the *.target files to provision the
PDE Target; it builds its modular target independently of any of
that.
We had briefly discussed, early on, the notion of
teaching Oomph to generate the targets from the TPDs so that we
could unify our workspace and build target definitions. But,
this doesn’t work, because the Modular Target mechanism in Oomph is
bigger than Papyrus-RT: any other projects that a developer
imports from other setups also will contribute to the modular
target, and PDE can only have one active target, so you can’t mix
Oomph’s modular target with *.target files.
The only way I could see would be to develop an Oomph
extension that synthesizes a dynamic Targlet from a *.TPD during
the setup execution. This would be cool.
On 14 July, 2016 at 12:47:16, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I only tried re-creating the .target(s)
but that didn't work. Re-setting the targets the the
'papyrusrelease' TP seems to work for the *.compare.* plugins, but
it breaks the *.migration.* plugins. Resetting to the
'papyrusnightly' TP seems to work.
Still, I wonder if we could make Oomph create the
.target(s) and set the default TP.
Hi Ernesto,
The resolution of the dependencies worked for me so that
there are now compile errors on the compare projects. Did you
re-set the target manually to test if it isn't just a caching
issue?
Thanks and best wishes,
Philip
_______________________________________________
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
_______________________________________________
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
|