Marketplace

[tomasbjerre]

Would be fantastic if a marketplace, that can be very much inspired by https://marketplace.atlassian.com/ can be developed. Where reviews and rating can be done.

I started working on it here:

http://www.jenkins-plugins.com/ And code is here: https://github.com/tomasbjerre/jenkins-plugins/

I dont mind forking the project to this organization, if you see any value in it.

I also have some domains registered for such a marketplace: www.jenkinsplugins.com www.jenkins-plugins.com www.jenkinsmarket.com www.jenkinsmarketplace.com

[bsideup]

FYI I own "juci.es" domain, just in case :)

[bsideup]

@tomasbjerre It might sound very opinionated, but, if you don't mind, I would prefer to implement it in a pure JS, with some modern tools like ReactJS + ES6 + Webpack. If they are new for you, I can kickstart barebone project, so you can quickly start with it.

update-center.json generated by Jucies will have some additional meta information (i.e. labels), and it should be fairly easy to render it. Also, we can attach Disqus widget to allow users to comment.

Will it work for you?

[tomasbjerre]

Ok. My idea was to render static pages for start page, categories and a page per plugin. Because I think that will make it easier for Google to find and index. And then use whatever modern JS stuff for the other features.

Disqus sounds good!

[scherler]

https://groups.google.com/d/msg/jenkinsci-dev/lL1etDkbwvg/PbGvsSCeDAAJ

I created a micro site based on http://updates.jenkins-ci.org/current/update-center.json you can find the source in https://github.com/scherler/jenkins-plugin-site and a demo in http://plugin-site.stax.net/ (it is still under development).

It is a simple rendering of the plugin list as taken from updates.jenkins-ci.org/current/update-center.json to make the information of plugins searchable and filterable.

It is based on a node server that processes the jsonp creates a in.memory "poor-mans" database (if you want to go so far to call it db) and then serves as REST backend e.g. http://plugin-site.stax.net/plugins or http://plugin-site.stax.net/labels. The front end is based on react.js and redux.

That would be easy adoptable to pull from different market places. I actually think even having the current plugins in a market place would allow as well features like rating, favorites, custom grouping, etc. Instead of using above jsonp source I would rather use a REST/CORS server that provides thus data.

[tomasbjerre]

Beautiful stuff =)

[bsideup]

@scherler your site looks great! If we can make it backend-less, it will be a great fit for Jucies!

[scherler]

@bsideup define backend less, as in dropping node.js as server?

[bsideup]

@scherler yes, make it static site which reads update-sites.json directly. How do you think, is it possible?

[scherler]

the problem is perfomance, we are speaking 1195 plugins and counting everyday. The first load is way too long, I tried before. The node stuff just slice and dices as search backend. IMHO something needs to go in the middle as buffer.

[tomasbjerre]

Or during build, read update-sites.json and produce other static json-files to put on the filesystem. In runtime, load from them when needed?

Also I think its important that Google can index at least some of the page. I'm not sure, but heavy usage of javascript is not good for search engine optimization right? Perhaps also produce some very simple static pages during build.

[scherler]

@tomasbjerre yeah was thinking to implement something like https://github.com/scherler/react-header-modal as standalone page linked from the search results, instead of for now link directly to the wiki page. That would make each plugin indexable by search engines.

Coming back to the data source can you provide a link to the update-sites.json from juice? How is it generated and who exposes it?

[bsideup]

It's http://jucies.github.io/update-center.json

Generated by https://github.com/jucies/releases/blob/master/build.gradle every 5 minutes on Travis https://travis-ci.org/jucies/releases published as GitHub page: https://github.com/jucies/jucies.github.io

The whole process is clear, open sourced, automated, and has no backend.

[scherler]

jeje, I actually found https://github.com/jucies/releases/blob/master/build.gradle#L124 ;) yeah I see so I need to look into changing the implementation to include the search functionality in the front end and pre- checkout/fetch the http://jucies.github.io/update-center.json.

I am just trying to use http://jucies.github.io/update-center.json instead the official, but run into the issue that you are producing line breaks (pretty-print) the gson.toJson(site). The original file gives 3 line where line 2 is the response object "site", the others are decorators for the jsonp call. Could you imitate that behaviour? I am not familiar with GsonBuilder but I think dropping https://github.com/jucies/releases/blob/master/build.gradle#L154 would do the trick.

[scherler]

Are you planning to include the official plugins in the u-c.json?

[bsideup]

@scherler it's pretty printed for a reason: diffs https://github.com/jucies/jucies.github.io/commit/67e0f204989b3262fbf363d7a5167ea0c854b2fc

You can easily use it just by dropping first and last lines btw.

I don't plan to include official plugins. Their lifecycle and infra doesn't corelate with Jucies. However, there is a bunch of official plugins included in Jucies by their authors who decided to simplify their life :)

But, for the marketplace, we could re-index both Jucies and official UC timely in the same maner

[scherler]

Yeah, will do something like if lines > 3 then strip decorates and use remaining.

I may create a branch to show you how current u-c.j would look like.

[bsideup]

@scherler you can use generic rule "skip 1 and last line" because both official UC and Jucies are using such notation - this is how it works in Jenkins.

[scherler]

jupp that is what I ended up with ;)

https://github.com/scherler/jenkins-plugin-site/tree/juice

...but I think you are not using 100% same syntax I got some errors.

[bsideup]

@scherler awesome! It must be exactly the same syntax. What did you get?

[scherler]

@bsideup will have lunch and tell you ;)

[scherler]

e.g. the following is missing requiredCore

{
  "excerpt": "",
  "url": "https://jitpack.io/com/github/jucies/jucies-plugin/0.1.1/jucies-plugin-0.1.1.hpi",
  "releaseTimestamp": "2016-04-18T18:23:56.00Z",
  "buildDate": "Apr 18, 2016",
  "version": "0.1.1",
  "title": "Jucies update center plugin",
  "wiki": "https://github.com/jucies/releases",
  "name": "jucies",
  "group": "org.jenkins-ci.plugins",
  "dependencies": [],
  "developers": [
    {
      "developerId": "bsideup",
      "email": "bsideup@gmail.com",
      "name": "Sergei Egorov"
    }
  ]
}

Where the setup should be like:

const Record = Immutable.Record({
  id: null,
  name: null,
  title: '',
  buildDate: null,
  releaseTimestamp: null,
  version: null,
  wiki: '',
  excerpt: '',
  iconDom: null,
  requiredCore: null,
  developers: [],
  labels: [],
  dependencies: []
});

the id is generated and ATM ===name and generated

[bsideup]

@scherler ah, I see. Currently, I'm using http://github.com/yandex-qatools/juseppe to generate all these fields, but it looks a bit outdated - i.e. it will use Hudson-Version for "requiredCore", but Gradle JPI plugin will generate Jenkins-Version instead. I'll research some options, i.e. switch to the native UC backend from Jenkins