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
- 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
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?
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.
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@xxxxxxxxxxxTo 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
|