Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Preparing Papyrus-RT for the Eclipse Marketplace
That's a very good point indeed. We could be breaking some people's clients, and now that we have 446 downloads of the RCP, we can no longer assume that our changes would have only a limited effect.

As far as I'm concerned, we should release it as 1.0.1. Any objections?

A question:  the changes that I've made to several version ranges on our dependencies where from [3.0.0,4.0.0) to [3.0.0,5.0.0). Am I increasing the range too much? Would it be preferable to increase them to [3.0.0,4.1.0) or [3.0.0,4.0.1)?

--
Ernesto


On Fri, Oct 6, 2017 at 8:49 AM Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
If it helps, I agree with your assessment.

Changing the version range of a dependency potentially changes the class space of users of the bundle, and the possible wirings in the OSGi framework.  So that really does seem to need a new version number.

Cheers,

Christian

On Oct 5, 2017, 12:24 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
I've ran into a number of issues regarding this preparation for the Marketplace.

The story is this: in order to publish the changes required on the feature.xml files we need to build, but the build fails because one dependency (the Papyrus JUnit framework) is available only in a nightly update site so only its latest version is available and this requires some bundles that have been backported from Photon into the Papyrus streams/3.0-maintenance branch but these had not been published. After some discussions in the Papyrus dev mailing list, they have published a Papyrus 3.2 milestone with the updated, backported bundles. So as part of Gerrit 106163 I've updated our TPs to use that new 3.2 milestone update site to obtain the Papyrus SDK. The problem is that several of our plugins have dependencies with version ranges [3.0.0,4.0.0) on plugins which have been backported. So in that same Gerrit I've increased the version range in the relevant MANIFEST.MF files to [3.0.0,5.0.0).  Now, one issue is that we had previously discussed that we didn't need to bump the version number to 1.0.1, but I was reading the guidelines at [1] and they state:

"The service segment number must be incremented whenever there have been changes to a plug-in between releases that are not visible in its API. For example, a bug has been fixed in the code, the plug-in manifest has changed, documentation has changed, compiler settings have changed."

So it looks like we would have to increase the version number. Any thoughts on this?

I'm also running into other build issues. Apparently the new Papyrus 3.2 build is not compatible with the Papyrus Interoperability RSA feature that we need in our RSA-RTE import feature. 



On Wed, Oct 4, 2017 at 12:28 PM Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Great, I'll do that. Good to know I won't have to do one of those big version-changing gerrits ;) We should really have a script for that.

--
Ernesto




On Wed, Oct 4, 2017 at 12:25 PM Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
The “1.0a” is just a marketing version name so, no, just the publication URL as you suggested and I suppose also hyperlink text on the Papyrus-RT web pages and wikis, etc.

Cheers,

Christian

On Oct 4, 2017, 12:23 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
Good point. But to publish it as 1.0a do we need to change the versions in all bundles and pom files, or would it be enough to simply make the build job publish in http://download.eclipse.org/papyrus-rt/updates/releases/oxygen/1.0.0a/?

--
Ernesto


On Wed, Oct 4, 2017 at 12:17 PM Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,

Sounds good.  But, the new build will have new qualifiers for the feature versions, so probably it should be published as a Papyrus-RT 1.0a (yay a-builds) as a separate child repository of the composite, not replacing the previous bits.  For complete and accurate release history and reproducibility for dependents.

Cheers,

Christian

On Oct 4, 2017, 12:12 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
Hello all. This is a quick note to inform everyone that we are preparing to add Papyrus-RT to the Eclipse Marketplace.

Our plan is to provide listings for both the RCP and the update site, but in order to do this, we need to do a some small maintenance to our 1.0 release because an installation using the update site fails to resolve some dependencies. In particular, the features that fail to be installed are the C++ feature, the RSA-RTE importer feature and Codegen. The dependencies that fail are the following:

C++: org.eclipse.papyrus.designer.languages.cpp.library 0.7.0
Codegen: org.eclipse.papyrus.designer.languages.common.base [1.0.4,2.0.0)
RSA-RTE Importer: org.eclipse.papyrus.interoperability.rsa [1.4.0,2.0.0)

The first two are from Papyrus Designer, and they are available from http://download.eclipse.org/modeling/mdt/papyrus/components/designer/neon/1.0.4_papyrus-designer-neon_494/ 

The last is available from the Papyrus Interoperability component available from 

So we need to make some small adjustments to a couple of features, more precisely to their meta-data.  We need to add the URLs above as "discovery" URLs to the corresponding feature.xml. I have already done that with Gerrit 106163. Unfortunately the build fails because the TPs fails to resolve a transitive dependency of the Papyrus JUnit feature. I've been discussing this in the Papyrus Developers mailing list (see thread https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg04137.html)

So once the build issue is resolved, we will publish a "new" release. It will still be 1.0.0 but with a slightly different qualifier. After discussing with Christian, it seems that we do not need to bump the version to 1.0.1 since we are only modifying some meta-data. I will announce here when the new build is available, and when the Marketplace listing is up.

Incidentally, if you don't install the C++, Codegen and RSA Importer features, you are unable to create models! But that's a different issue. I'll open a bug for that. 

--
Ernesto Posse
Zeligsoft



--
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
--
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
--
Ernesto Posse
Zeligsoft
--
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
--
Ernesto Posse
Zeligsoft

Back to the top