[opendaylight-dev] Concerning YangIDE release, do we have a definite (or even tentative) production update site URL?


Michael Vorburger
 

+yangide_dev list

https://bugs.opendaylight.org/show_bug.cgi?id=5869 tracks this particular story.

Latest status is in the list email from Thanh I've linked in that bug; they are working on this, still ongoing. From what I understand, the problem here with yangide is not the build (we do have one of course), but the automated CI publication of the resulting p2 repo on Nexus. Thanh can explain this much better than me, but basically it seems it's non trivial to push a built ZIP from Jenkins to Nexus to HTTP serve it, and to do this properly with cleaning up the content of the previous build.

So in the mean time, for fun and personal cloudy learning, I have put together https://github.com/vorburger/Docker/tree/master/yangide-jenkins, and have now thrown that Docker image onto http://209.132.179.72 (that's the IP of a VM on Red Hat's public OpenStack instance we can use for such stuff). You for now therefore have a temporary p2 site of yangide available on http://209.132.179.72/job/yangide/lastSuccessfulBuild/artifact/product/update-site/target/repository/ in CI.

Personally I will, until https://bugs.opendaylight.org/show_bug.cgi?id=5869 is resolved and we have yangide's p2 properly continuously integrated on https://nexus.opendaylight.org, for https://github.com/vorburger/opendaylight-eclipse-setup now be letting it pull from this new yangide p2 site (see https://github.com/vorburger/opendaylight-eclipse-setup/commit/bf67b1fc8f760ca89777e3b924b6f7eec1759a71).


Tx,
M.
--
Michael Vorburger <vorburger@...> | IRC: vorburger @freenode | G/Hangout: michael.vorburger | Skype: mike_vorburger | ~ = http://vorburger.ch

On Wed, Jun 1, 2016 at 11:25 PM, David M. Karr <davidmichaelkarr@...> wrote:
On 06/01/2016 02:14 PM, Luis Gomez wrote:
What I mean is that if the final release artifact can be built by ODL Jenkins, the same job could deploy it to Nexus.

Yes.  It might not be the "same job", but we intend to have the ODL Jenkins build process eventually deploy the artifact to a public update site, likely provided by the Nexus server.



On Jun 1, 2016, at 2:04 PM, David M. Karr <davidmichaelkarr@...> wrote:

On 06/01/2016 02:00 PM, Luis Gomez wrote:
Hi David,

One question: what you plan to release is something that you build in ODL? If so you can have a job that automatically publishes the artifacts in Nexus opendaylight.release [1]. If your release is not built in ODL (like few other projects) I believe you can handoff the artifacts to LF people who will manually upload them to a Nexus URL. Can LF people confirm this?
I'm not sure exactly what you mean by "build in ODL".  It requires some ODL-built Maven artifacts, but it obviously doesn't get deployed to Karaf like the majority of ODL components.

Also, deploying an Eclipse plugin release requires unzipping the final artifact to the destination.  You can't just copy it.  There's also some question about whether we should deploy it to a structure that allows people to install older versions instead of the latest version (once we have older versions that exist).

I believe Andy and Thanh (and Michael Vorburger) have been looking at how this can be provided.
BR/Luis

[1] https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/

On Jun 1, 2016, at 10:55 AM, David M. Karr <davidmichaelkarr@...> wrote:

Concerning our discussions about provisioning a public update site for the YangIDE project, is there a definite (or tentative) URL for this yet?  It doesn't have to exist yet, I just need to know what it is or will be.
_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


Thanh Ha <thanh.ha@...>
 

Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

As for the SNAPSHOT p2repo part as Michael mentioned there are still work that needs to be done on that front to complete. My WIP Gerrit patch gets us most of the way there but as mentioned in our other discussion thread we still need to figure out how the job will determine the version number of the SNAPSHOTS to push as it's currently hardcoded in the job. At this moment if we merged the job that would mean someone has to update the job every time yangide version bumps their project which isn't ideal. I'm hoping to get the automation in so that the job itself can figure out what the version to push is.

Regards,
Thanh

On 2 June 2016 at 09:52, Michael Vorburger <vorburger@...> wrote:
+yangide_dev list

https://bugs.opendaylight.org/show_bug.cgi?id=5869 tracks this particular story.

Latest status is in the list email from Thanh I've linked in that bug; they are working on this, still ongoing. From what I understand, the problem here with yangide is not the build (we do have one of course), but the automated CI publication of the resulting p2 repo on Nexus. Thanh can explain this much better than me, but basically it seems it's non trivial to push a built ZIP from Jenkins to Nexus to HTTP serve it, and to do this properly with cleaning up the content of the previous build.

So in the mean time, for fun and personal cloudy learning, I have put together https://github.com/vorburger/Docker/tree/master/yangide-jenkins, and have now thrown that Docker image onto http://209.132.179.72 (that's the IP of a VM on Red Hat's public OpenStack instance we can use for such stuff). You for now therefore have a temporary p2 site of yangide available on http://209.132.179.72/job/yangide/lastSuccessfulBuild/artifact/product/update-site/target/repository/ in CI.

Personally I will, until https://bugs.opendaylight.org/show_bug.cgi?id=5869 is resolved and we have yangide's p2 properly continuously integrated on https://nexus.opendaylight.org, for https://github.com/vorburger/opendaylight-eclipse-setup now be letting it pull from this new yangide p2 site (see https://github.com/vorburger/opendaylight-eclipse-setup/commit/bf67b1fc8f760ca89777e3b924b6f7eec1759a71).


Tx,
M.
--
Michael Vorburger <vorburger@...> | IRC: vorburger @freenode | G/Hangout: michael.vorburger | Skype: mike_vorburger | ~ = http://vorburger.ch

On Wed, Jun 1, 2016 at 11:25 PM, David M. Karr <davidmichaelkarr@...> wrote:
On 06/01/2016 02:14 PM, Luis Gomez wrote:
What I mean is that if the final release artifact can be built by ODL Jenkins, the same job could deploy it to Nexus.

Yes.  It might not be the "same job", but we intend to have the ODL Jenkins build process eventually deploy the artifact to a public update site, likely provided by the Nexus server.



On Jun 1, 2016, at 2:04 PM, David M. Karr <davidmichaelkarr@...> wrote:

On 06/01/2016 02:00 PM, Luis Gomez wrote:
Hi David,

One question: what you plan to release is something that you build in ODL? If so you can have a job that automatically publishes the artifacts in Nexus opendaylight.release [1]. If your release is not built in ODL (like few other projects) I believe you can handoff the artifacts to LF people who will manually upload them to a Nexus URL. Can LF people confirm this?
I'm not sure exactly what you mean by "build in ODL".  It requires some ODL-built Maven artifacts, but it obviously doesn't get deployed to Karaf like the majority of ODL components.

Also, deploying an Eclipse plugin release requires unzipping the final artifact to the destination.  You can't just copy it.  There's also some question about whether we should deploy it to a structure that allows people to install older versions instead of the latest version (once we have older versions that exist).

I believe Andy and Thanh (and Michael Vorburger) have been looking at how this can be provided.
BR/Luis

[1] https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/

On Jun 1, 2016, at 10:55 AM, David M. Karr <davidmichaelkarr@...> wrote:

Concerning our discussions about provisioning a public update site for the YangIDE project, is there a definite (or tentative) URL for this yet?  It doesn't have to exist yet, I just need to know what it is or will be.
_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev



David Karr
 

Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

As for the SNAPSHOT p2repo part as Michael mentioned there are still work that needs to be done on that front to complete. My WIP Gerrit patch gets us most of the way there but as mentioned in our other discussion thread we still need to figure out how the job will determine the version number of the SNAPSHOTS to push as it's currently hardcoded in the job. At this moment if we merged the job that would mean someone has to update the job every time yangide version bumps their project which isn't ideal. I'm hoping to get the automation in so that the job itself can figure out what the version to push is.

As you say, it would definitely be better to determine the version automatically from the source artifacts.

Regards,
Thanh

On 2 June 2016 at 09:52, Michael Vorburger <vorburger@...> wrote:
+yangide_dev list

https://bugs.opendaylight.org/show_bug.cgi?id=5869 tracks this particular story.

Latest status is in the list email from Thanh I've linked in that bug; they are working on this, still ongoing. From what I understand, the problem here with yangide is not the build (we do have one of course), but the automated CI publication of the resulting p2 repo on Nexus. Thanh can explain this much better than me, but basically it seems it's non trivial to push a built ZIP from Jenkins to Nexus to HTTP serve it, and to do this properly with cleaning up the content of the previous build.

So in the mean time, for fun and personal cloudy learning, I have put together https://github.com/vorburger/Docker/tree/master/yangide-jenkins, and have now thrown that Docker image onto http://209.132.179.72 (that's the IP of a VM on Red Hat's public OpenStack instance we can use for such stuff). You for now therefore have a temporary p2 site of yangide available on http://209.132.179.72/job/yangide/lastSuccessfulBuild/artifact/product/update-site/target/repository/ in CI.

Personally I will, until https://bugs.opendaylight.org/show_bug.cgi?id=5869 is resolved and we have yangide's p2 properly continuously integrated on https://nexus.opendaylight.org, for https://github.com/vorburger/opendaylight-eclipse-setup now be letting it pull from this new yangide p2 site (see https://github.com/vorburger/opendaylight-eclipse-setup/commit/bf67b1fc8f760ca89777e3b924b6f7eec1759a71).


Tx,
M.
--
Michael Vorburger <vorburger@...> | IRC: vorburger @freenode | G/Hangout: michael.vorburger | Skype: mike_vorburger | ~ = http://vorburger.ch

On Wed, Jun 1, 2016 at 11:25 PM, David M. Karr <davidmichaelkarr@...> wrote:
On 06/01/2016 02:14 PM, Luis Gomez wrote:
What I mean is that if the final release artifact can be built by ODL Jenkins, the same job could deploy it to Nexus.

Yes.  It might not be the "same job", but we intend to have the ODL Jenkins build process eventually deploy the artifact to a public update site, likely provided by the Nexus server.



On Jun 1, 2016, at 2:04 PM, David M. Karr <davidmichaelkarr@...> wrote:

On 06/01/2016 02:00 PM, Luis Gomez wrote:
Hi David,

One question: what you plan to release is something that you build in ODL? If so you can have a job that automatically publishes the artifacts in Nexus opendaylight.release [1]. If your release is not built in ODL (like few other projects) I believe you can handoff the artifacts to LF people who will manually upload them to a Nexus URL. Can LF people confirm this?
I'm not sure exactly what you mean by "build in ODL".  It requires some ODL-built Maven artifacts, but it obviously doesn't get deployed to Karaf like the majority of ODL components.

Also, deploying an Eclipse plugin release requires unzipping the final artifact to the destination.  You can't just copy it.  There's also some question about whether we should deploy it to a structure that allows people to install older versions instead of the latest version (once we have older versions that exist).

I believe Andy and Thanh (and Michael Vorburger) have been looking at how this can be provided.
BR/Luis

[1] https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/

On Jun 1, 2016, at 10:55 AM, David M. Karr <davidmichaelkarr@...> wrote:

Concerning our discussions about provisioning a public update site for the YangIDE project, is there a definite (or tentative) URL for this yet?  It doesn't have to exist yet, I just need to know what it is or will be.
_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev




Thanh Ha <thanh.ha@...>
 

On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

Regards,
Thanh


David Karr
 

On 06/03/2016 11:10 AM, Thanh Ha wrote:
On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

What we definitely want to prevent is a directory containing all of the release artifacts for all of the released versions, all mixed together.  I could live with a directory that contains the version folders, with the newest one on top.  The former is what I saw when I tested this a few weeks ago.

Regards,
Thanh



Thanh Ha <thanh.ha@...>
 

On 3 June 2016 at 14:15, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:10 AM, Thanh Ha wrote:
On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

What we definitely want to prevent is a directory containing all of the release artifacts for all of the released versions, all mixed together.  I could live with a directory that contains the version folders, with the newest one on top.  The former is what I saw when I tested this a few weeks ago.

The releases will go into directories as follows:

yangide/release/1.0.0
yangide/release/1.0.1
yangide/release/2.0.0

The composite metadata located at yangide/release will contain the metadata for all of those repos so when someone points an update site to yangide/release they can choose which versions they want to install. As I've stated before I find it odd that yangide does not want to provide their users a downgrade path but at this point I'm willing to concede this as I feel our discussions around this area has been unproductive and we really need to move on from discussing this over and over as boron development continues and there are more productive things we could be working on.

I will modify the build scripts this weekend to only allow the user to install only the latest yangide release build at the release url.

Regards,
Thanh


David Karr
 

On 06/03/2016 11:35 AM, Thanh Ha wrote:
On 3 June 2016 at 14:15, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:10 AM, Thanh Ha wrote:
On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

What we definitely want to prevent is a directory containing all of the release artifacts for all of the released versions, all mixed together.  I could live with a directory that contains the version folders, with the newest one on top.  The former is what I saw when I tested this a few weeks ago.

The releases will go into directories as follows:

yangide/release/1.0.0
yangide/release/1.0.1
yangide/release/2.0.0

The composite metadata located at yangide/release will contain the metadata for all of those repos so when someone points an update site to yangide/release they can choose which versions they want to install. As I've stated before I find it odd that yangide does not want to provide their users a downgrade path but at this point I'm willing to concede this as I feel our discussions around this area has been unproductive and we really need to move on from discussing this over and over as boron development continues and there are more productive things we could be working on.

I will modify the build scripts this weekend to only allow the user to install only the latest yangide release build at the release url.

Your response makes me think I'm still not getting the important point across.  I will be more explicit.

I'm not wild about allowing users to install older versions, but I really don't care that much.  That isn't the problem I'm referring to.

When a user selects the update site from a list, they should get a top-level "folder" named "YANG IDE".  Within that folder, there are presently four separate components, with the following names:

* m2e connector for YANG
* m2e connector for YANG Developer Resources
* YANG IDE
* YANG IDE Developer Resources

These components, although under the "YANG IDE" umbrella, are all separately versioned, and presently all have the same version (ideally).

When I first tried the update site that you provided, where you had both the "1.1.1" and "1.1.2" versions installed and available, there was still the "YANG IDE" container, but underneath that were EIGHT components, each of those four component names, with two different versions, all in the same folder.  If the user selected the top-level "YANG IDE" checkbox, it would have tried to install all EIGHT components, installing two different versions at the same time.  I certainly hope this would fail, but I don't know if it would tell the user what the real problem is.

Again, I don't care if the user has the choice of selecting an older version, but I definitely do not want to force them to individually select all the sub-components that they need, making sure that they select only the ones from the version they want.


Regards,
Thanh



Thanh Ha <thanh.ha@...>
 

On 3 June 2016 at 15:26, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:35 AM, Thanh Ha wrote:
On 3 June 2016 at 14:15, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:10 AM, Thanh Ha wrote:
On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

What we definitely want to prevent is a directory containing all of the release artifacts for all of the released versions, all mixed together.  I could live with a directory that contains the version folders, with the newest one on top.  The former is what I saw when I tested this a few weeks ago.

The releases will go into directories as follows:

yangide/release/1.0.0
yangide/release/1.0.1
yangide/release/2.0.0

The composite metadata located at yangide/release will contain the metadata for all of those repos so when someone points an update site to yangide/release they can choose which versions they want to install. As I've stated before I find it odd that yangide does not want to provide their users a downgrade path but at this point I'm willing to concede this as I feel our discussions around this area has been unproductive and we really need to move on from discussing this over and over as boron development continues and there are more productive things we could be working on.

I will modify the build scripts this weekend to only allow the user to install only the latest yangide release build at the release url.

Your response makes me think I'm still not getting the important point across.  I will be more explicit.

I'm not wild about allowing users to install older versions, but I really don't care that much.  That isn't the problem I'm referring to.

When a user selects the update site from a list, they should get a top-level "folder" named "YANG IDE".  Within that folder, there are presently four separate components, with the following names:

* m2e connector for YANG
* m2e connector for YANG Developer Resources
* YANG IDE
* YANG IDE Developer Resources

These components, although under the "YANG IDE" umbrella, are all separately versioned, and presently all have the same version (ideally).

When I first tried the update site that you provided, where you had both the "1.1.1" and "1.1.2" versions installed and available, there was still the "YANG IDE" container, but underneath that were EIGHT components, each of those four component names, with two different versions, all in the same folder.  If the user selected the top-level "YANG IDE" checkbox, it would have tried to install all EIGHT components, installing two different versions at the same time.  I certainly hope this would fail, but I don't know if it would tell the user what the real problem is.

Again, I don't care if the user has the choice of selecting an older version, but I definitely do not want to force them to individually select all the sub-components that they need, making sure that they select only the ones from the version they want.

I apologize I misunderstood what you were asking for. I believe the thing that controls that is your category.xml definition here:


which currently identifies 4 features which is why the user has 4 options to install when installing yangide. If you would like to cut this down to make it more simple for your users one option I believe is to make a single super feature that installs all YANG IDE features in a single feature and modify this file to contain only a single feature to be installed.

This is outside of my domain of knowledge though so I suspect your question is better directed at the p2 developers over at Eclipse.

Hope this helps,
Thanh



David Karr
 

On 06/03/2016 12:47 PM, Thanh Ha wrote:
On 3 June 2016 at 15:26, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:35 AM, Thanh Ha wrote:
On 3 June 2016 at 14:15, David M. Karr <davidmichaelkarr@...> wrote:
On 06/03/2016 11:10 AM, Thanh Ha wrote:
On 3 June 2016 at 12:39, David M. Karr <davidmichaelkarr@...> wrote:
Thanks for the update.

On 06/03/2016 09:25 AM, Thanh Ha wrote:
Hi David,

The work for "released" YangIDE was done long ago and only changed slightly due to Michael and your request to also allow SNAPSHOTs to be pushed. Thus the URL for released artifacts will be located at:


It is currently created with test artifacts that we created for your testing previously and is a p2composite repo containing several releases. When YangIDE does an official release we will delete the release directory to clear the test artifacts and from then on only publish official release artifacts. This work is complete today and is ready to go anytime. It requires helpdesk to kick the job that publishes the artifacts since we will push the yangide p2 repos once the TSC approves of the ODL simultaneous release for publishing.

Just so we're clear on expectations, I note that when I view this location in a browser, it has two different versions (1.1.1 and 1.1.2), but the XML files only refer to the 1.1.1 version. When I attempt to install a plugin at that location, it only sees the 1.1.1 version.

Will the final state be similar to this, being a subdir with a version number, and the two XML files referring to that version as the only child?  When we release a newer version in the future, would we add an additional versioned subdir and have the XML files refer to that as the only child, or will they refer to both versions?  If the latter, I'd like to be certain I understand the user experience when they select the main update site.

It's been awhile since I last checked but I think we were testing to see what happens if a repo path contained 2 releases but composite metadata only listed one of them. The actual script that generates the composite files will list all directories so when we start pushing releases there it will contain the full list of release directories. So people pointing to the release repo will see all released artifacts.

What we definitely want to prevent is a directory containing all of the release artifacts for all of the released versions, all mixed together.  I could live with a directory that contains the version folders, with the newest one on top.  The former is what I saw when I tested this a few weeks ago.

The releases will go into directories as follows:

yangide/release/1.0.0
yangide/release/1.0.1
yangide/release/2.0.0

The composite metadata located at yangide/release will contain the metadata for all of those repos so when someone points an update site to yangide/release they can choose which versions they want to install. As I've stated before I find it odd that yangide does not want to provide their users a downgrade path but at this point I'm willing to concede this as I feel our discussions around this area has been unproductive and we really need to move on from discussing this over and over as boron development continues and there are more productive things we could be working on.

I will modify the build scripts this weekend to only allow the user to install only the latest yangide release build at the release url.

Your response makes me think I'm still not getting the important point across.  I will be more explicit.

I'm not wild about allowing users to install older versions, but I really don't care that much.  That isn't the problem I'm referring to.

When a user selects the update site from a list, they should get a top-level "folder" named "YANG IDE".  Within that folder, there are presently four separate components, with the following names:

* m2e connector for YANG
* m2e connector for YANG Developer Resources
* YANG IDE
* YANG IDE Developer Resources

These components, although under the "YANG IDE" umbrella, are all separately versioned, and presently all have the same version (ideally).

When I first tried the update site that you provided, where you had both the "1.1.1" and "1.1.2" versions installed and available, there was still the "YANG IDE" container, but underneath that were EIGHT components, each of those four component names, with two different versions, all in the same folder.  If the user selected the top-level "YANG IDE" checkbox, it would have tried to install all EIGHT components, installing two different versions at the same time.  I certainly hope this would fail, but I don't know if it would tell the user what the real problem is.

Again, I don't care if the user has the choice of selecting an older version, but I definitely do not want to force them to individually select all the sub-components that they need, making sure that they select only the ones from the version they want.

I apologize I misunderstood what you were asking for. I believe the thing that controls that is your category.xml definition here:


which currently identifies 4 features which is why the user has 4 options to install when installing yangide. If you would like to cut this down to make it more simple for your users one option I believe is to make a single super feature that installs all YANG IDE features in a single feature and modify this file to contain only a single feature to be installed.

This is outside of my domain of knowledge though so I suspect your question is better directed at the p2 developers over at Eclipse.

Yeah, me too.  Hopefully Michael understands some of this.  I tried going through the docs on this before, but found them to be a bunch of twisty passages.  I'll have to try harder.


Hope this helps,
Thanh