General comment: The definition that I had in my head was that parameters that were common to all plugins/projects were defined in the POM (project.xml) and parameters that belonged to specific plugins were put in properties in that plugin. Some would argue that what is in the POM is structural to all projects.
However, in practice none of these definitions are really applied. Also, the fact that we have a mix of XML definition + properties is not very consistent or convincing. In several other emails in the past I have proposed to put *all* properties in the POM, by having an extension mechanism that plugins would use but this has never been quite fully agreed. See below for specific comments... > -----Original Message----- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 12 November 2003 13:05 > To: Maven Developers List > Subject: RE: [Proposal] Project deliverables definition in POM > > > > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 12, 2003 12:28 PM > > To: 'Maven Developers List' > > Subject: RE: [Proposal] Project deliverables definition in POM > > > > > > I would be -1 to change the standard naming of > > <name>-<version>.<extension>. > > > > The problem is that there is no standard naming convention yet which deals > with artifacts like: > > > > <artifactId>-<version>.jar > > > <artifactId>-src-<version>.zip > > > <artifactId>-javadoc-<version>.zip > > > The standard convention is that every artifacts is describable by POM's > dependency element. > It means that we have four attributes to our disposition {groupId, > artifactId, version, type} > and artifact location in the repository (layout) is a simple function of > those four attributes (with exception to artifacts of type "ejb") and plugins, and ear (not sure for this one, would need to check). > > This is purely technical limitation of our implementation. > > For me the most natural way will be to have possibility to assign a > function > which computes the layout per each artifact type separately. > > so you can e.g. specify that layout of "javadoc" > is=${groupId}//javadocs/${artifactId}-javadoc-${version}.jar yep, that would be nice. > > > > > Could you explain why you think it doesn't belong to the POM? > > > > If it's not put in the POM (i.e. if we use properties), who will be the > > owner of them? driver.properties (i.e the core)? Or some other plugins > > (a deliverable plugin, the release plugin, etc)? > > > > In other thread I also asked about this (Re: cvs commit: > maven-plugins/multichanges/src/plugin-resources releases.jsl): > "The fundamental question is: shall we use properties which belong > to no plugin and what kind of problems they can cause?" > > > POM can be also seen as conglomerate of project.xml + and properties > files. > As we have methods like project.getProperties() > > So it's like we have first class (standardized) and second class > properties > (not standardized). I kinda agree with this. > In fact ownership of properties is needed purely for setting default > values. It's also important when you separate plugins (which we are doing). So you cannot assume all plugins will be loaded in a given maven installation. Hence the reason there needs to be "core" properties/POM (and for me, everything core should go in project.xml - the only problem is deciding what is core...). > > At the moment I don't have a good answer to the question "who will be the > owner of them?" > I think that probably plugins should. I would view deliverables as core information and hence put it in the POM/core driver properties. 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? A project requires several information: 1- what dependencies it has on others 2- what it generates 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). Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
