You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/11/11 13:19:39 UTC

[Proposal] Project deliverables definition in POM

Hi,

Shouldn't we define project deliverables in the POM? I think this could
be very useful. Let me give some potential usages:

- ability to automatically say "build me this project", whether the
project generates a war, an ejb, an ear, a jar, a plugin jar, etc. ATM,
there is no way to recognize a project's type.

- ability to develop maven plugins that uses deliverable information.
For example the maven site plugin could automatically generate download
links pointing to the project's deliverables. The multichanges plugin
could provide links for the latest releases, etc.

Here's how it could be defined in the POM:

Example for a plugin project:
-----------------------------

<deliverables>
  <deliverable>
    <artifactId>${pom.artifactId}</artifact>
    <type>plugin</type>
  </deliverable>
</deliverables>

Note 1: <groupId> is already defined at the global level and this is
fine.
Note 2: <id> should be removed. Indeed, it is not enough as there are
possibly several deliverables per project (for example a typical jar
project will deliver: a jar, a zipped javadoc, a source distribution, a
website zip, etc.
Note 3: We would of course only deprecate the <id> tag to preserve
compatibility. It would be equivalent to saying:

<deliverables>
  <deliverable>
    <artifactId>${pom.artifactId}</artifact>
    <type>jar</type>
  </deliverable>
</deliverables>

Example for a standard jar project:
-----------------------------------

<deliverables>
  <deliverable>
    <artifactId>${pom.artifactId}</artifact>
    <type>jar</type>
  </deliverable>
  <deliverable>
    <artifactId>${pom.artifactId}</artifact>
    <type>javadoc</type>
  </deliverable>
</deliverables>

etc.

Summary: I believe the existing mechanism (i.e. global <groupId>, <id> -
BTW, there is no global <type>) is too limitative and that it is
preventing us from providing further added value for projects. The
proposal above suggest a mechanism for extending it to support several
deliverables.

Comments? (I'm sure there'll be plenty ;-)).

-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Proposal] Project deliverables definition in POM

Posted by Rafal Krzewski <Ra...@caltha.pl>.

Vincent Massol wrote:
> I would be -1 to change the standard naming of
> <name>-<version>.<extension>.

I think its a minor change if you look at it in the following way:

<name>-<version><extension>

old extensions: .jar .zip .war ...
new extensions: .jar -debug.jar -source.zip ...

> Could you explain why you think it doesn't belong to the POM?

I have no strong opinion on that. Putting in into properties seemed
natural, by analogy to multiproject. Besides the current policy of
attribute-less XML in the pom makes it look sooo awkward...

<deliverables>
  <deliverable>jar</deliverable>
  <deliverable>source</deliverable>
  <deliverable>javadoc</deliverable>
  <main-deliverable>jar</main-deliverable>
</deliverables>

vs.

<deliverables>
  <deliverable type="jar" main="true"/>
  <deliverable type="source"/>
  <deliverable type="javadoc"/>
</deliverables>

> 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)?

A plugin I think, not sure about the naming though. I imagine we could
reach a point where most things could be achieved with the following goals:

install
install-all
deploy
deploy-all

R.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Proposal] Project deliverables definition in POM

Posted by Jason van Zyl <jv...@maven.org>.

On Wed, 2003-11-12 at 11:35, Kurt Schrader wrote:
> On Nov 12, 2003, at 10:29 AM, Jason van Zyl wrote:
> 
> > 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.
> 
> I agree with you in general that there should only be one deliverable
> per project, but I think that we need to address things like how to
> deliver a src distribution and/or a debug enabled distribution of the
> same artifact.  

Right, there is definitely the primary thing being produced but you
certainly have everything else.

> Maven currently doesn't handle different permutations
> of an artifact well, and I think that this would be helpful in those
> instances.

Yah, I think we will get somewhere with this discussion. I hope
something falls out because people are definitely generating other
things and it would be useful to capture what people are doing and try
to provide a standard way of doing it.

> -Kurt
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Proposal] Project deliverables definition in POM

Posted by Kurt Schrader <ks...@karmalab.org>.

On Nov 12, 2003, at 10:29 AM, Jason van Zyl wrote:

> 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.

I agree with you in general that there should only be one deliverable
per project, but I think that we need to address things like how to
deliver a src distribution and/or a debug enabled distribution of the
same artifact.  Maven currently doesn't handle different permutations
of an artifact well, and I think that this would be helpful in those
instances.

-Kurt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Proposal] Project deliverables definition in POM

Posted by Nicola Ken Barozzi <ni...@apache.org>.

Jason van Zyl wrote:
...
> I would just like to avoid the complete arbitrary nature of the gump
> descriptor when it comes things that are generated from a project.

In Centipede we use the Gump descriptor for the artifacts, and we
had the same need of having to extend it to specify the artifact type.

Hence I agree with this. From the Gump perspective having arbitrary
artifacts is ok, but for systems that automate things it's vitally
important that artifact types are clearly defined.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org