You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/11/05 21:49:28 UTC
Common XML Project descriptor ( Re: Subtle barriers to entry )
Nicola Ken Barozzi wrote:
>>Personally I prefer to have two files: one describes the project, and it
>>stays basically fixed; the other is more dynamic and changes frequently.
>>
>>_projectinfo.xml_
>>
>>- goals
>>- credits
>>- license
>>- resource URLs (site, mailing lists + archives, VCS stuff)
>>- description
>>- short description
>>- what it does
>>
>>_status.xml_
>>
>>- committers
>>- todos
>>- changes
>>- votings ?
Martin van den Bemt wrote:
> The general impression that that is too much info for a generic approach.
> Unless your goal is to redefine the project pages ;)
> I was more thinking in line of a "quick" view page, with all the projects
> with the most basic info (description, lists, cvs repo, latest version,
> project page link)
> So people can go to eg http://www.apache.org/projects-info.html and get all
> "quick" info over there..
> This way you don't have to go through the process of every project changing
> their sites again..
Well, _projectinfo.xml_ is basically what you would need for it, with
some aggregtation, while the second file is more about project
management - decision making process.
Let me try a second stab at _projectinfo.xml_ alone then.
_projectinfo.xml_
<?xml version="1.0"?>
<project id="myproject">
<site url="http://mysite.org/"
hostname="mysite.org"
remotedir="/home/groups/m/my/myproject/htdocs"/>
<vcs type="subversion"
root="http://myvcs/"
url="http://myvcs/cgi-bin/viewcvs.cgi/"/>
<bugtrack url="http://myproject.org/mybugziulla/"/>
<mailing-lists>
<mailing-list
mail="project-dev@project.org"
subscribe="project-dev-subscribe@project.org"
unsubscribe="project-dev-unsubscribe@project.org"
user="developer">
<archives>
<archive name="one" url="http://etc1"/>
<archive name="two" url="http://etc2"/>
</archives>
</mailing-list>
</mailing-lists>
<description abstract="My project is about this.">
This is about my project in detail.
</description>
<what>
<goal>It will do this.</goal>
<goal>It will do that.</goal>
</what>
<why>
This project started because...
</why>
<vendor>Apache Software Foundation - apache.org</vendor>
<licence legal="./legal">
This software is released under the
Apache Public License 1.1.
</licence>
<credits>
<credit>This software includes software developed by...</credit>
</credits>
</project>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 6 Nov 2002 11:58, Daniel Rall wrote:
>
>>Nicola Ken Barozzi <ni...@apache.org> writes:
>>
>>>Peter Donald wrote:
>>>
>>>>Secondly make it so each project can have multiple vcs entrys (ie
>>>>Avalon and it's 6 or 7, turbine with the same).
>>>
>>>Hmmm... this descriptor should have a 1-1 relationship with a single
>>>VCS entry, as it defines what in CVS is a "module", as in the Gump
>>>descriptor.
>>
>>Then it's not really a project descriptor, now is it? We already have
>>plenty of projects at the ASF which have multiple CVS repositories --
>>look at httpd. Even the new infrastructure project will have several
>>(so it's a growing trend).
>
>
> We also have projects that propose one VCS (commons@apache) where codebases
> have subdirectorys (like serf/, httpunit/ etc). Other projects share mailing
> list for multiple codebases. Which sort to starts to get back to that icky
> state of flux that the alexandria (then gump) descriptors went through.
The truth is that I think you are rught, we will never come to a solid
relationship with these entities, and history is here to warn us.
> What happens when a particular "resource" is used across multiple codebases?
> Possible resources being;
>
> * mailing lists
> * VCS
> * issue trackers
> * developers
> * schedulers/task trackers
>
> If it was a normalized database model it would be simple because there would
> just be relationships between the entities. But because XML is a hierarchial
> data store then it no work.
As you know, Gump resolves this by defining common entities separately
and "linking" them, like CVS repository info, that can be defined in one
place and "linked" in all project descriptors.
> Maybe it would be a good idea to start from a fully normalized database model
> and then work towards exporters that denormalize for particular purposes. The
> information could then be shared between different users and they could
> formulate it as they desire.
Conceptually it's basically the same as with what Gump does, but I'm
interested in pursuing alternative paths if they are better.
What do you see in the Gump-like information-sharing system that needs
to be redone or that cannot be done?
> Does this sound like a good idea?
Sure clears up the picture :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Peter Donald <pe...@apache.org>.
On Wed, 6 Nov 2002 11:58, Daniel Rall wrote:
> Nicola Ken Barozzi <ni...@apache.org> writes:
> > Peter Donald wrote:
> > > Hi,
> > > Firstly rename bugtrack to issuetracker as many projects use the
> > > issue tracker to store enhancement requests.
> >
> > Hmmm, how about:
> >
> > <tracker type="bugs" url="http://..."/>
> > <tracker type="enhancements" url="http://..."/>
>
> Naw, just about every tracker is used as a generic issue -- or even
> project-wide -- tracker whether it was originally intended for that or
> not. Leave off the type attribute (or at least make it optional).
+1
> > > Secondly make it so each project can have multiple vcs entrys (ie
> > > Avalon and it's 6 or 7, turbine with the same).
> >
> > Hmmm... this descriptor should have a 1-1 relationship with a single
> > VCS entry, as it defines what in CVS is a "module", as in the Gump
> > descriptor.
>
> Then it's not really a project descriptor, now is it? We already have
> plenty of projects at the ASF which have multiple CVS repositories --
> look at httpd. Even the new infrastructure project will have several
> (so it's a growing trend).
We also have projects that propose one VCS (commons@apache) where codebases
have subdirectorys (like serf/, httpunit/ etc). Other projects share mailing
list for multiple codebases. Which sort to starts to get back to that icky
state of flux that the alexandria (then gump) descriptors went through.
What happens when a particular "resource" is used across multiple codebases?
Possible resources being;
* mailing lists
* VCS
* issue trackers
* developers
* schedulers/task trackers
If it was a normalized database model it would be simple because there would
just be relationships between the entities. But because XML is a hierarchial
data store then it no work.
Maybe it would be a good idea to start from a fully normalized database model
and then work towards exporters that denormalize for particular purposes. The
information could then be shared between different users and they could
formulate it as they desire.
Does this sound like a good idea?
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Daniel Rall wrote:
> Nicola Ken Barozzi <ni...@apache.org> writes:
>
>
>>Peter Donald wrote:
>>
>>>Hi,
>>>Firstly rename bugtrack to issuetracker as many projects use the
>>>issue tracker to store enhancement requests.
>>
>>Hmmm, how about:
>>
>> <tracker type="bugs" url="http://..."/>
>> <tracker type="enhancements" url="http://..."/>
>
>
> Naw, just about every tracker is used as a generic issue -- or even
> project-wide -- tracker whether it was originally intended for that or
> not. Leave off the type attribute (or at least make it optional).
+1 for optional
>>>Secondly make it so each project can have multiple vcs entrys (ie
>>>Avalon and it's 6 or 7, turbine with the same).
>>
>>Hmmm... this descriptor should have a 1-1 relationship with a single
>>VCS entry, as it defines what in CVS is a "module", as in the Gump
>>descriptor.
>
> Then it's not really a project descriptor, now is it? We already have
> plenty of projects at the ASF which have multiple CVS repositories --
> look at httpd. Even the new infrastructure project will have several
> (so it's a growing trend).
Then where will this descriptor be stored, in what repository?
I've looked at these repos (I assume it's the httpd-* ones), and each
has a STATUS file, so IMV they are each a project....
Hmmm... any idea on how this should be resolved?
> I'm glad we're having this discussion (in a productive manner, no less
> ;).
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Nicola Ken Barozzi <ni...@apache.org> writes:
> Peter Donald wrote:
> > Hi,
> > Firstly rename bugtrack to issuetracker as many projects use the
> > issue tracker to store enhancement requests.
>
> Hmmm, how about:
>
> <tracker type="bugs" url="http://..."/>
> <tracker type="enhancements" url="http://..."/>
Naw, just about every tracker is used as a generic issue -- or even
project-wide -- tracker whether it was originally intended for that or
not. Leave off the type attribute (or at least make it optional).
> > Secondly make it so each project can have multiple vcs entrys (ie
> > Avalon and it's 6 or 7, turbine with the same).
>
> Hmmm... this descriptor should have a 1-1 relationship with a single
> VCS entry, as it defines what in CVS is a "module", as in the Gump
> descriptor.
Then it's not really a project descriptor, now is it? We already have
plenty of projects at the ASF which have multiple CVS repositories --
look at httpd. Even the new infrastructure project will have several
(so it's a growing trend).
I'm glad we're having this discussion (in a productive manner, no less
;).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> Hi,
>
> Firstly rename bugtrack to issuetracker as many projects use the issue tracker
> to store enhancement requests.
Hmmm, how about:
<tracker type="bugs" url="http://..."/>
<tracker type="enhancements" url="http://..."/>
> Secondly make it so each project can have
> multiple vcs entrys (ie Avalon and it's 6 or 7, turbine with the same).
Hmmm... this descriptor should have a 1-1 relationship with a single VCS
entry, as it defines what in CVS is a "module", as in the Gump descriptor.
> I would also add a few more features. The two most improtant of which would
> be;
>
> * a link to an rss feed (if project has one)
Ok. It's planned that we make status.xml todos and changes avaliable as
rss feeds; probably adding all the remaining community activities to
status.xml would make it ok.
- announcements
- votes
- other?
> * a link to either
> - downloads xml descriptor/page, or
> - a set of downloads/releases
right
> In the future it would be great if we linked to task/scheduling software but
> there is nothing in opensource land that I can see. And most of the good ones
> (ie Jira) are heavily linked into issuetracking and/or vcs.
With the <tracker> element it should be included already.
Good tips, thanks for the feedback! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Peter Donald <pe...@apache.org>.
Hi,
Firstly rename bugtrack to issuetracker as many projects use the issue tracker
to store enhancement requests. Secondly make it so each project can have
multiple vcs entrys (ie Avalon and it's 6 or 7, turbine with the same).
I would also add a few more features. The two most improtant of which would
be;
* a link to an rss feed (if project has one)
* a link to either
- downloads xml descriptor/page, or
- a set of downloads/releases
In the future it would be great if we linked to task/scheduling software but
there is nothing in opensource land that I can see. And most of the good ones
(ie Jira) are heavily linked into issuetracking and/or vcs.
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> On Tue, 2002-11-05 at 16:45, Nicola Ken Barozzi wrote:
>
>>Costin Manolache wrote:
>>
[...]
>>>Sounds good. What about the root element :-) ?
>>
>>It has been asked by many to change the root element to <project>, and
>>the <project> to <subproject> (or similar), but it should be made to
>>work with both semantics, for backward compat.
>
>
> I love XML. Maybe some namespace should be used ? ( ant also uses
> <project>, as we all know :-)
<projects> ? ;-)
^^^^
As long as we define the Doctype, which will be done once we have a
stable DTD, we can do it.
The problem is in Ant though, since it doesn't/can't have one.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Costin Manolache <co...@covalent.net>.
On Tue, 2002-11-05 at 16:45, Nicola Ken Barozzi wrote:
>
> Costin Manolache wrote:
> > On Tue, 2002-11-05 at 16:03, Nicola Ken Barozzi wrote:
> >
> >
> >>Costin Manolache wrote:
> >>
> >>>Can someone summarize what's wrong with the gump descriptor used by
> >>>all jakarta and xml projects ?
> >>>
> >>>I understand we may need to add more stuff ( maybe using some ns: ),
> >>>but I don't quite understand why we need to change existing definitions.
> >>
> >>
> >>If you look at the proposed DTD, apart from the root element, there is
> >>basically nothing that the Gump descriptor cannot cope with.
> >>It's the route we've taken with Forrest, and my proposal takes from that.
> >
> >
> > Sounds good. What about the root element :-) ?
>
> It has been asked by many to change the root element to <project>, and
> the <project> to <subproject> (or similar), but it should be made to
> work with both semantics, for backward compat.
I love XML. Maybe some namespace should be used ? ( ant also uses
<project>, as we all know :-)
> Ok, I think I have had enough to get started.
> I'll go with this pseudo-DTD, and once it's defined as a formal DTD and
> the new summary pages get published, our Maven friends can add the info
> to the Gump plugin.
Since I don't think ant to change its dtd from <project> and namespace
support is not in any released version - it may be nice to add at least
a namespace if you really need to use the same word.
Some editors might get confused.
Costin
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> On Tue, 2002-11-05 at 16:03, Nicola Ken Barozzi wrote:
>
>
>>Costin Manolache wrote:
>>
>>>Can someone summarize what's wrong with the gump descriptor used by
>>>all jakarta and xml projects ?
>>>
>>>I understand we may need to add more stuff ( maybe using some ns: ),
>>>but I don't quite understand why we need to change existing definitions.
>>
>>
>>If you look at the proposed DTD, apart from the root element, there is
>>basically nothing that the Gump descriptor cannot cope with.
>>It's the route we've taken with Forrest, and my proposal takes from that.
>
>
> Sounds good. What about the root element :-) ?
It has been asked by many to change the root element to <project>, and
the <project> to <subproject> (or similar), but it should be made to
work with both semantics, for backward compat.
> As long as it just add more info to the existing projects.xml files -
> I'm happy. The other question is if gump can ignore the extra info -
> but I assume it can, at least from the xsl that I understand so far.
It can. As I said, the trick is not to use href="" attributes in the
extra elements, since Gump expands/resolves them during the runs.
BTW, after adding these tags, I looked into the alexandria legacy
descriptors, and found most of them! Seems like history repeating... ;-)
Ok, I think I have had enough to get started.
I'll go with this pseudo-DTD, and once it's defined as a formal DTD and
the new summary pages get published, our Maven friends can add the info
to the Gump plugin.
Moving this work to Alexandria-Gump...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Costin Manolache <cm...@yahoo.com>.
On Tue, 2002-11-05 at 16:03, Nicola Ken Barozzi wrote:
> Costin Manolache wrote:
> > Can someone summarize what's wrong with the gump descriptor used by
> > all jakarta and xml projects ?
> >
> > I understand we may need to add more stuff ( maybe using some ns: ),
> > but I don't quite understand why we need to change existing definitions.
>
>
> If you look at the proposed DTD, apart from the root element, there is
> basically nothing that the Gump descriptor cannot cope with.
> It's the route we've taken with Forrest, and my proposal takes from that.
Sounds good. What about the root element :-) ?
As long as it just add more info to the existing projects.xml files -
I'm happy. The other question is if gump can ignore the extra info -
but I assume it can, at least from the xsl that I understand so far.
Costin
RE: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Martin van den Bemt <ma...@isallineed.org>.
>But when I saw that Maven guys volunteered to make a plugin that outputs
>the descriptor, I proposed the DTD which is plainly from the Forrest
>extensions to Gump.
I'm not a committer, just contributor ;) I was just willing to make the
plugin, since the idea is good..
>Probably it means that it's just easier for Maven to add the elements in
>the Gump plugin?
That would be the simplest solution indeed and probably logical, if the gump
descriptor is that close already to the wishes...
Mvgr,
martin
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Can someone summarize what's wrong with the gump descriptor used by
> all jakarta and xml projects ?
>
> I understand we may need to add more stuff ( maybe using some ns: ),
> but I don't quite understand why we need to change existing definitions.
If you look at the proposed DTD, apart from the root element, there is
basically nothing that the Gump descriptor cannot cope with.
It's the route we've taken with Forrest, and my proposal takes from that.
These are Gump project descriptors that already embed the proposed elements:
http://cvs.apache.org/viewcvs/xml-forrest/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
http://cvs.apache.org/viewcvs/jakarta-poi/module.xml?rev=HEAD&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-centipede/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
Also note that I've not included href attributes, as they are expanded
by default by Gump.
Since Maven has it's own descriptor, I initially thought it was better
not to start another Gump VS Maven format debate that I've already gone
through more than once on the Alexandria list and elswhere (if you want
the details see the archives).
But when I saw that Maven guys volunteered to make a plugin that outputs
the descriptor, I proposed the DTD which is plainly from the Forrest
extensions to Gump.
Probably it means that it's just easier for Maven to add the elements in
the Gump plugin?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Costin Manolache <co...@covalent.net>.
Can someone summarize what's wrong with the gump descriptor used by
all jakarta and xml projects ?
I understand we may need to add more stuff ( maybe using some ns: ),
but I don't quite understand why we need to change existing definitions.
Costin
On Tue, 2002-11-05 at 14:08, John Keyes wrote:
> <snip/>
> > > If the answer to above is yes : cool and from a maven perspective the above
> > > is what can be offered, based on the maven project.xml, and I can write a
> > > maven plugin to generate that xml.
> > > If you had something different in mind, please explain ;)
> >
> > What you propose is simply a subset of what I envision.
> >
> > With the above descriptor, we can create both a centralized page with
> > the summaries for all projects *and* project summary pages.
>
> It sounds like it would make sense if maven was modified
> to import a projectinfo document and therefore it could
> generate the project page using it. This would support
> the vision of it being tool agnostic.
>
> -John K
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by John Keyes <jk...@icarus.apache.org>.
<snip/>
> > If the answer to above is yes : cool and from a maven perspective the above
> > is what can be offered, based on the maven project.xml, and I can write a
> > maven plugin to generate that xml.
> > If you had something different in mind, please explain ;)
>
> What you propose is simply a subset of what I envision.
>
> With the above descriptor, we can create both a centralized page with
> the summaries for all projects *and* project summary pages.
It sounds like it would make sense if maven was modified
to import a projectinfo document and therefore it could
generate the project page using it. This would support
the vision of it being tool agnostic.
-John K
Re: Common XML Project descriptor ( Re: Subtle barriers to entry
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Martin van den Bemt wrote:
> See inline ;)
>
>
>>_projectinfo.xml_
>>
>>
>><?xml version="1.0"?>
>>
>><project id="myproject">
>>
>> <site url="http://mysite.org/"
>> hostname="mysite.org"
>> remotedir="/home/groups/m/my/myproject/htdocs"/>
>>
>> <vcs type="subversion"
>> root="http://myvcs/"
>> url="http://myvcs/cgi-bin/viewcvs.cgi/"/>
>>
>> <bugtrack url="http://myproject.org/mybugziulla/"/>
>>
>> <mailing-lists>
>> <mailing-list
>> mail="project-dev@project.org"
>> subscribe="project-dev-subscribe@project.org"
>> unsubscribe="project-dev-unsubscribe@project.org"
>> user="developer">
>>
>> <archives>
>> <archive name="one" url="http://etc1"/>
>> <archive name="two" url="http://etc2"/>
>> </archives>
>>
>> </mailing-list>
>>
>> </mailing-lists>
>>
>> <description abstract="My project is about this.">
>> This is about my project in detail.
>> </description>
>>
>> <what>
>> <goal>It will do this.</goal>
>> <goal>It will do that.</goal>
>> </what>
>
>
> </project>
> -- end here --
>
>
>> <why>
>> This project started because...
>> </why>
>
>
> Nice for the project page itself.
Hmmm...
>> <vendor>Apache Software Foundation - apache.org</vendor>
>>
>> <licence legal="./legal">
>> This software is released under the
>> Apache Public License 1.1.
>> </licence>
>
>
> Also vendor + license seems a bit obvious, or am I missing something (I
> assume incubator projects will adopt APL immidiately).
I intend to make this descriptor of more general use than in Apache only.
>> <credits>
>> <credit>This software includes software developed by...</credit>
>> </credits>
>
>
> Also nice for the project page, not for a quick overview.
>
> Maybe it is a communication problem, so let me know if my assumption is
> wrong :
>
> We are talking about generating a centralized page (= not on the project
> webpage) with the project information specified above, so that people that
> want a quick look what's out there or want to quickly find where mailinglist
> of project X is, can go to ?
Yes.
> If the answer to above is yes : cool and from a maven perspective the above
> is what can be offered, based on the maven project.xml, and I can write a
> maven plugin to generate that xml.
> If you had something different in mind, please explain ;)
What you propose is simply a subset of what I envision.
With the above descriptor, we can create both a centralized page with
the summaries for all projects *and* project summary pages.
Actually, I also started with the status.xml format also, to be able for
all to see what's going on easily in every project, in a *centralized*
way, regardless to which build-documentation system is used.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: Common XML Project descriptor ( Re: Subtle barriers to entry )
Posted by Martin van den Bemt <ma...@isallineed.org>.
See inline ;)
> _projectinfo.xml_
>
>
> <?xml version="1.0"?>
>
> <project id="myproject">
>
> <site url="http://mysite.org/"
> hostname="mysite.org"
> remotedir="/home/groups/m/my/myproject/htdocs"/>
>
> <vcs type="subversion"
> root="http://myvcs/"
> url="http://myvcs/cgi-bin/viewcvs.cgi/"/>
>
> <bugtrack url="http://myproject.org/mybugziulla/"/>
>
> <mailing-lists>
> <mailing-list
> mail="project-dev@project.org"
> subscribe="project-dev-subscribe@project.org"
> unsubscribe="project-dev-unsubscribe@project.org"
> user="developer">
>
> <archives>
> <archive name="one" url="http://etc1"/>
> <archive name="two" url="http://etc2"/>
> </archives>
>
> </mailing-list>
>
> </mailing-lists>
>
> <description abstract="My project is about this.">
> This is about my project in detail.
> </description>
>
> <what>
> <goal>It will do this.</goal>
> <goal>It will do that.</goal>
> </what>
</project>
-- end here --
>
> <why>
> This project started because...
> </why>
Nice for the project page itself.
>
> <vendor>Apache Software Foundation - apache.org</vendor>
>
> <licence legal="./legal">
> This software is released under the
> Apache Public License 1.1.
> </licence>
Also vendor + license seems a bit obvious, or am I missing something (I
assume incubator projects will adopt APL immidiately).
> <credits>
> <credit>This software includes software developed by...</credit>
> </credits>
Also nice for the project page, not for a quick overview.
Maybe it is a communication problem, so let me know if my assumption is
wrong :
We are talking about generating a centralized page (= not on the project
webpage) with the project information specified above, so that people that
want a quick look what's out there or want to quickly find where mailinglist
of project X is, can go to ?
If the answer to above is yes : cool and from a maven perspective the above
is what can be offered, based on the maven project.xml, and I can write a
maven plugin to generate that xml.
If you had something different in mind, please explain ;)
Mvgr,
Martin