At least we have an agreement on adding a <type> element. That's a good first step! :-)
Hmm... If I understand correctly what you are saying about deliverables, there should be one project.xml for each deliverable. That means that all of these project.xml (for each deliverable) could/should actually live in the same directory location (as they are operating on the same sources for most of them). project-jar.xml project-javadoc.xml project-src.xml Is that what you mean? But then, isn't this the same as saying <project> <deliverable>jar</deliverable> <deliverable>jar</deliverable> <deliverable>jar</deliverable> </project> or <solution> <deliverable>project-jar.xml</deliverable> <deliverable>project-javadoc.xml</deliverable> <deliverable>project-src.xml</deliverable> </solution> if you prefer. That said I find this a bit heavy to write as all project-*.xml will share 99% of their content. So in practice you'll need: project-common.xml (extending some higher level project-common.xml) project-jar.xml (extending project-common.xml) project-javadoc.xml "" project-src.xml "" I definitely think this is too heavy. We already have 2 levels: a global project is made of several subprojects. What you are saying (if I understood correctly, probably not ;-)) is that subproject is made of several "deliverable projects". Hmmm.... -Vincent > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 12 November 2003 16:30 > To: Maven Developers List > Subject: RE: [Proposal] Project deliverables definition in POM > > On Wed, 2003-11-12 at 09:14, Vincent Massol wrote: > > > I would view deliverables as core information and hence put it in the > > POM/core driver properties. > > In the past we have tried to align the top-level POM fields with > dependencies so that there was a mesh for example we have: > > <project> > <groupId>foo</groupId> > <artifactId>bar</artifactId> > ... > </project> > > Now lets take that a step further ... > > > Don't you think defining a project's deliverables belong to the > > "standardized" property set? Isn't that a major structural information > > for a project? > > Yes, but I am still of the mind that a project produces one artifact. > I'll call it the primary artifact for lack of a better word because > there are always docs and distributions and whatever else. But adding a > type to the top-level: > > <project> > <groupId>foo</groupId> > <artifactId>bar</artifactId> > <type> > </project> > > Then this meshes an actual project more completely with the dependency > elements. > > > A project requires several information: > > 1- what dependencies it has on others > > 2- what it generates > > To me given a type at the top-level would indicate what we are > generating. > > I honestly do not like a <deliverables/> because it distinctly clashes > with a central notion of one artifact per project. Yes, in reality more > are produced but maybe this is an indication that projects need to be > separated further i.e. a small project for creating distributions and a > small project for creating various documentation artifacts. > > > 3- how to generate the distributables > > > > Number 2 is what we are discussing. Actually if you look at Gump's > > descriptors you'll find they have this information as it is required is > > you start managing several projects: the output from one project is the > > input from another project. It's also useful to verify if a full project > > build has been successful (i.e. if the distributables have all been > > generated). > > I think we could do that by adding a <type/> to the top-level and think > harder about how we work with projects on a daily basis. > > I often assume the output of one project and use it for the input to > another all the time. I guess typically I assume the default jar type > and I have my projects organized in such a way as I know where they are > deposited. > > I'm am not keen on a <deliverables/> element as I think allowing an > arbitrary number of deliverables versus forcing the thought of how to > decompose projects so that there is one artifact per project will lead > to problems down the line. > > > Thanks > > -Vincent > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
