Project.xml enhancements

[wrzep]

Hello,

Below you can find my proposal affecting project.xml design.

After I started implementing project info edit view, I realized that using the current project.xml design is sometimes quite annoying ;-) That's why I'd like to introduce some changes.

What we've got now is the Project class representing the project.xml file in the CMS. There are fields that are mapped as lists since it's possible for them to occur more than one time in the project.xml file, but it seems to me it isn't really necessary. For instance, we allow multiple issue trackers, multiple repository locations to be assigned to one project. Example:

<project>
...
<issue-tracker type="jira">http://jira.jboss.com/MySuperbProject</issue-tracker>
<issue-tracker type="bugzilla">http://bugzilla.somewhere.com/MyEvenMoreSuperbProject</issue-tracker>
...
</project>

This is mapped as the following method

protected List<IssueTracker> getIssueTrackers()

in the Project class.

I can imagine that some projects, sometimes might have more than one issue tracker. On the other hand, such a definition makes this property really difficult to use, cause:

1. We don't know which issue tracker is the project main one.
Let's say we want to have a link to the project issue tracker in the navigation. We don't know which one to choose.

2. It makes using Project bean more complicated. If every project had one issue tracker, the method would return just one IssueTracker bean. Easy to use, for example, in JSF ("#{project.issueTracker.link}") - you don't need to iterate. The same for the Java code.

That's why I'd vote for making it less general, but easier-to-use. With the current implementation I had to write a lot of useless lines of code dealing with lists.

Detailed proposal follows.

<project>
...

<issue-tracker type="jira">http://jira.jboss.com/MySuperbProject</issue-tracker> <!-- one occurence, don't allow many -->

<!-- was: multiple occurences of
<repository type="SVN | ANONSVN | CVS | ANONCVS">url</repository> (even mixed CVS with ANONSVN!) -->

<repo-type>SVN</repo-type>
<anon-repo>http://anonsvn.jboss.com/MySuperbProjectRepo</anon-repo>
<commiter-repo>http://svn.jboss.com/MySuperbProjectRepo</commiter-repo>

<repo-monitor type="fisheye">fisheye url</repo-monitor> <!-- one occurence, don't allow many -->

<!-- was: multiple occurences of
<support-services type="support | training">http://jboss.com/GetSupportForThisProject</support-service> -->

<support>http://jboss.com/GetSupportForThisProject</support>
<training>http://jboss.com/training</training>

...
</project>

This would simplify access to those attributes and make a lot of coding easier as we would get methods like:

Repository getAnonRepo();
Repository getCommiterRepo();
RepoMonitor getRepoMonitor();
Training getTrainig();

instead of:

List<Repository> getRepositories();
List<RepoMonitor> getRepoMonitors();
protected List<SupportService> getSupportServices();

I'm aware of the fact that those are just details, but they seem to me as quite important details as they affect all projects and much of code ;-)

Comments are welcome :)

Cheers

[unibrew]

Hi

I was discussing this with Pawel earlier and we decided to make it team-wide discussion as it affects all of us using this in future.
The drawback of those changes is generation of more specialized JavaBeans and class attributes. Code will be less abstract and this means all uses of those classes might be more affected by changes in project.xml.
Limitations in the amount of repos or issue trackers etc. is not an issue in my opinion. I always considered this as too optimistic but that's what you requested ;-).
Positive value of this change is obviously easier development when using those beans.

I hope, we'll get some more input in this discussion ;-)

Cheers,
Rysiek

[adamw]

I suppose that one issue tracker per project, one public/anonymous repository, one support and training site per project is very reasonable. It goes along with the simplification for users we're doing in Labs 2 :)

--
Adam

[unibrew]

FYI ... Done :-)

Cheers,
Rysiek

[dsicore]

Sorry to prop up a dead horse here... but... :)

I think users should be able to specify IRC servers and channels on which live discussions take place.

Other things to consider: forums vs newsgroups vs mailing lists.

Traditionally, in Labs, users just made "freezone" links or outbound links, but I think Labs should internalize these--at least the IRC servers and channels--to directly encourage the use of those techniques.

<montyPythonVoice>And now for something completely different...</montyPythonVoice>

[szimano]

Well... IRC is used by people over 30, so that's not a problem - they'll soon be blind and not able to use computers due to being too old.

Tomek

[dsicore]

*sigh* It's hard having vision.