[dhladky]

I am currently working on the generated project matrix. Right now there are two sources of data for it. The one is centralized, the other group is sort of decentralized.

- most of the data come from Magnolia repository. The projects described here have a special paragraph, that allows navigation (project navigation paragraph). E.g. if you look here http://www.hibernate.org, you can see a menu with items Overview, Downloads..... This is the paragraph I am talking about.

- for projects, that are not in Magnolia CMS there are two options at this moment:

1. we add a single page with the project navigation (so Magnolia can find the paragraph and render the project information from it). The project manager can enter or modify the his links there.
2. you publish a property file of specified structure on your page and send its URL to us, so we can tell Magnolia to parse it. At this moment its structure is the same as the structure of the data from the project navigation paragraph. It  will be described here  http://www.jboss.org/help/awestructguide/projectpropertyfilestruction.htm. The process what to how to get your page into the project matrix (unless you are already in Magnolia) will be described here: http://www.jboss.org/help/awestructguide. I repeat "it will be". I am half-way through writing them so at this time they are not yet published. When they are out, I will mention it here so you can add your suggestions.

As for the property file as the medium, I chose it, because its structure is trivial (and it has direct J2SE support). I have no doubt people able to publish JSON or specially formated XML will be able to publish a property file so I hope it will not be a problem. The only thing necessary for the rendering is a couple of field name + field value pairs and IMO the property file is the best format for such thing (no extra characters).

[dhladky]

I promised to let you know, when the links are active. It is now. Probably the next Wednesday the generated project matrix will be deployed on server and the community will have the possibility to check, whether their projects are displayed properly.

[aslak]

David, you want 1 property file pr project/subproject ?

Depending on how you define a subproject, Arquillian has rougly 30. We might not display all as subprojects in the project matrix, but..

is there a 'mother' properties file where we can give you information about which subproject properties files exists?

[maxandersen]

Same goes in parts for JBoss Tools - could we see/check this on staging before it goes live ?

[dhladky]

Asiak, thank you for your question. Yes, one property file per a project or subproject.  However there is no need and I actually do not think it is desirable if all subproject of a project have the property file and are published on the project matrix page. If there is too much content on a page, no one will want to search there.

As for the Arquillian, there is no need to use any property file at all. It is already in the project matrix, because it has content in Magnolia (http://www.jboss.org/arquillian.html) and the data about thisproject goes from its project navigation paragraph. The property files were meant for those, who do not want to be in Magnolia at all but need to be in the project matrix.

If you have the sub-project in Arquillian, that really should be in the project matrix (it has a big impact on community), it is possible to add the information about him to Magnolia or set up his project property file somewhere. In the hand written project matrix there was just one link to Arquillian and so it is in the new generated one.

[dhladky]

Hi Max, the situation of JBoss Tools is very similar to Arquillian. In the old project matrix it was represented as a single project and so it is in the new one (it is in Magnolia CMS too, so no property file needed).

It will not be possible to check the project matrix on staging, because it reads data from the server and I spent a week updating project navigation paragraphs of production server in order to make them to have all necessary information from the old project matrix (and fixing the links, if they were obsolete. A lot of the project from the old project matrix migrated from SVN to GIT and it was not changed in their project navigation paragraphs).

However when the new version of the project matrix paragraph is deployed in production, I will publish a page that uses it, so people in the community can investigate, if their projects are represented there and everything is OK. After they do so, the original hand written project matrix will be replaced by this one.

[aslak]

Arquillian in Magnolia is just temp and Magnolia not the master for this data.

The hand written project matrix only contain one Arquillian because it's hand written and written about 2 years ago. A lot has changed since then

[dhladky]

I never said Arquillian shall stay as the single project in the matrix. Just that if you add all the 30 projects (and the same  Hibernate and JBoss AS will do), the page will be completely unreadable. So, please, think about the projects, that you would like to add under Arquillian. I do not want to specify the limit, but please, make their number reasonable. Less is sometimes more. 

If you know user credentials to https://www.jboss.org/author/arquillian.html, you can add subpages of the Arquillian sub-projects to Magnolia. The only important paragraph, that must be on their pages is the project navigation. If you do that, they will be inserted into the matrix automatically. Or you can prepare and publish the property files as described in the guide and let me know.

It is sad I can not show you the page before we deploy it to production server. It requires restart of the server and so it will not be done earlier than the next Wednesday. I do hope it will not be postponed again.

[aslak]

Of course, the plan wasn't to add all 30. But we do have a few 'Top Level' projects that probably should have their own line in the matrix.

Having a single entry point for the integration between a project and jboss.org would make it a lot simpler to maintain. Now we have to give you x number of links and maintain those linkes over time.

An extra property in the mother properties file alla:

  subProjects=URL, URL, URL

would make this a lot easier. If it exists, you read it and fetch the content of the URL's..

[dhladky]

This is an interesting idea. It will not be easy, because the project properties are parsed separately but I think it may be worthwhile to implement this feature.

[dhladky]

An extra property in the mother properties file alla:

  subProjects=URL, URL, URL

The feature added. It will be possible to use this field in master project property file. After some considerations this field is ignored in subproject property files, so I do not need to solve cyclic referrals and some other problems.

[aslak]

excellent, thank you!

[aslak]

Will jboss.org expose it's accumulated project knowlegde as a API for others to consume?

e.g. arquillian.org could then consume the jboss.org API to correctly link to other projects in docs/guides etc

[dhladky]

I am not sure what you mean by "accumulated project knowledge". I can imagine using rest for sharing some data for example, actually there are systems, that read data from Magnolia already,  however you would need to specify what exactly do you need.

[aslak]

By Accumulated project knowledge I mean:

All projects, individually, give JBoss.org information about them selves. Now JBoss.org knows 'everything' about project X, Y, Z. But Project X does not have information about Project Y.

So instead of Project X asking Project Y for their project information or project properties URL, Point To Point. JBoss.org could provide a API with what it knows. Project X can now ask JBoss.org for the information about Project Y and function like a Hub.

Example:

JBoss.org is given ProjectX's URL: http://project.org/api/project.json

Which could return:

{
  name: ProjectX
  doc {
    guides: URL,
    reference: URL
  },
  sub_projects: [
    {
      name: ProjectX Sub A 
    },
    {
      name: ProjectX Sub B
    }
  ] 
}

Same goes for ProjectZ,Y etc

Now when Project X wants to know what JBoss.org knows, it could call JBoss.org's project URL: http://api.jboss.org/project/

[
  {
    name: ProjectX
    ...
  },
  {
    name: ProjectZ
    ...
  },
  {
    name: ProjectY
    ...
  }
]

JBoss.org would then return a list of all known projects, optionally with a http://api.jboss.org/project/ProjectX as a 'filter' if you only want one specific project.

{
  name: ProjectX
  ...
}

Ideally the structure used by the Project to feed jboss.org with information would be the same structure JBoss.org returns in it's APIs (only wrapped as a list notation since we're talking about multiple entries)