| Hi Juergen.
Are these extensions based on the 1.0 RCP or on some more recent nightly build? And by "extensions" do you mean plugins that modify the Papyrus-RT source code, or only add new plugins (that do not modify the source code)? If they are based on the 1.0 RCP and are only additions, you shouldn't be blocked: you can always make plugins that extend a stable version (e.g. the 1.0 RCP), independently of the status of the nightly builds. On the other hand, if your extensions are actually modifying Papyrus-RT code, then yes, this would be a bigger problem and you could not use the existing maven/tycho.
The build issue only affects Papyrus-RT developers and developers of extensions of Papyrus-RT (as in extensions that modify the -RT sources) and which either try to setup their development environment using the Oomph setup model, and those who try to use maven/tycho for building the product, which is what you would do if you are modifying the Papyrus-RT sources.
In any case, I'm working on getting the build up again, but it is time-consuming. I'm making progress, but I don't know when it will be done.
-- Ernesto Posse Zeligsoft (2009) Ltd.
Charles,
thank you very much for looking into this.
We have several significant extensions of Papyrus-RT (e.g.,
dedicated action language
with full smart editor support, a gateway/observer service/capsule,
and an MQTT
extension for IoT applications) in the pipeline that are difficult
to make public at the
moment due to the broken build.
Juergen
This is in relation to
It appears that a back port from Photon to the
Papyrus 3.0 maintenance stream has dependencies on Photon
(4.0) bundles… and the use of a unit test component has
results in problems for Papyrus-RT (go read bug 531432 for more information).
The result is that it is no longer possible to
build Papyrus-RT, which means that we cannot provide fixes. This
has the side effect (reported by one user thus far) that it is
no longer possible to install the Papyrus-RT development
environment by following the instructions in the wiki. This
means that currently, Papyrus-RT cannot be used as a base for
further customization, as indicated by an affected external user
(who may not be a user for long…).
This is an example of a “very bad thing” that
could easily be called a lack of “industrialness” in Papyrus
and our approach. I am hopeful that it is not worse and not a
manifestation of siloed thinking by our teams.
I do understand that, this particular problem has
been going on for some time and that it has been discussed
already. This should make finding a solution.
We now have a risk identified, let's work at
establishing governance for this risk and implement compliance
checks.
This needs to be addressed in the context of the
joint PMC-Arch efforts on delivery governance and quality.
We were lucky in that this does not seem to have
affected many users. We may not be as lucky next time…
If the Papyrus IC (and Papyrus product line) wants
to be taken seriously, it can never happen again!
I would like to invite anyone interested in
the Papyrus IC product line Delivery Governance, including the Quality Framework &
Testing to contact either the Architecture Committee lead (Rémi
Schnekenburger) or myself (for the Product Management
Committee).
Regards / cordialement,
Charles Rivet
Senior Product Manager / directeur principal de produits
- Zeligsoft
Chairman, Papyrus IC Product Management Committee /
président du comité de gestion de produits du consortium
industriel de Papyrus
charles@xxxxxxxxxxxxx
_______________________________________________
papyrus-ic mailing list
papyrus-ic@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-ic
_______________________________________________ papyrus-ic mailing list papyrus-ic@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-ic
|
