> -----Original Message-----
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2003 14:21
> To: Maven Developers List
> Subject: Re: [Proposal] Project deliverables definition in POM
>
> Vincent Massol wrote:
>
> >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>
> >
> >
> >
>
> Why type is not sufficient?
Adding a type would be a good first step. But a project does not have a
single deliverable.
>
> >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 ;-)).
> >
> >
> >
> Some times ago I was thinking about doing this via plugin.
>
> Say we have "foo" plugin (no nice name is coming to my minds at the
> moment)
>
> with goals
>
> foo:install
> foo:install-snapshot
> foo:deploy
> foo:deploy-snapshot
>
>
> foo:all-install
> foo:all-install-snapshot
> foo:all-deploy
> foo:all-deploy-snapshot
>
> and then properties like
>
> maven.foo.main=jar
> maven.foo.all=jar, javadoc, javasources,
>
>
>
>
> For example Implementation of foo:all-install can look like
>
> foreach type in {maven.foo.all} do
> <attainGoal name="{$type}:install"/>
> end
>
>
> Then this plugin can be used by multiproject plugin (in
> multiproject:install, multiproject:deploy etc) andfor creation of
pages
> with download information
>
> I knew some reason why such functionality should not be based on
> informaton which is kept in POM (<deliverables>)
> (I have to refresh my memory and recall them...)
Everything can be done with plugins, even what is defined in the POM.
But for me the goal of the POM is to regroup all structural information
about the project and I believe deliverables is one of those.
Anyway, I'd like to see what others think. This could be added to the
POM without breaking anything.
BTW, I also think that the <build> elements should not be in the POM...
:-)
-Vincent
>
>
>
>
> Michal
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]
