maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Artifact life cycle
Date Thu, 06 Dec 2007 20:29:22 GMT
Put this in the user wiki. It's look interesting to discuss but it  
will get lost in this mailing list.

On 5 Dec 07, at 1:41 PM 5 Dec 07, Johann Gyger wrote:

> Hi,
> When I compare the Maven dependency mechanisms with our home-brewn
> solution in our company then among others one major thing is
> different: Maven does not know the concept of an artifact life cycle.
> (At least I do not know about such a mechanism and I do not refer to
> the build life cycle). Such life cycle status information would allow
> to extend the dependency management in a new dimension. One could
> declare whether certain dependencies are actually allowed to be used
> in a project, enabling effective technology management.
> ----------
> Consider the following use cases:
> Scenario 1: Flawed versions
> It turns out that my-app-1.4.2.jar contains a serious security issue
> and is therefore flawed. Clients of this JAR should actually switch to
> a newer version my-app-1.4.3.jar which fixes the bug and which is safe
> to use.
> Scenario 2: Decommissioning
> Let's assume that my-app-1.4.2.jar is not supported anymore and
> projects should actually switch to a new release stream
> (my-app-2.x.y.jar).
> Scenario 3: Restricted usage
> Consider a library which has a restricted set of client projects, e.g.
> only certain projects are allowed to depend on a specific artifact.
> On one hand, this life cycle information could be used to manage a
> repository in a more restrictive way, which makes it actually possible
> to perform technology management. On the other hand, when developers
> try to depend on an artifact which is actually not allowed, Maven
> could perform checks during the build life cycle and warn the user
> about inappropriate technology usage (dependency enforcement). Based
> on a flag the build would either fail or print a warning.
> ----------
> Our solution works as follows. The technology board decides which
> versions of a dependency are actually allowed and this information is
> declared in an XML file:
> <product name="struts">
>  <version pattern="*" status="prohibited.not.investigated" />
>  <version pattern="1.0*" status="prohibited.removed" />
>  <version pattern="1.2.4" status="prohibited.flawed"
>    comment="security issue (bug:38374). upgrade to 1.2.9"/>
>  <version pattern="1.2.4clx" status="approved.restricted"
>    comment="technology preset by APP1 release">
>    <scope name="app1" />
>  </version>
>  <version pattern="1.2.9" status="approved.mainstream"
>    comment="resolves security (DOS) issue (bug:38374)" />
> </product>
> The build output would be as follows (ant target):
> init:
> [echo] - status -- external project dependencies --------------
> [depend] [ OK ] VALIDATOR_HOME='jakarta/commons-validator/1.1.3'
> [depend] status 'approved.mainstream' defined for version pattern
> '1.1.3': fixes dtd fetch issue of version 1.0.*, used in struts
> [depend] [ OK ]  JAVA_HOME='/share/java/jdk/1.5.0_10'
> [depend] status 'approved.mainstream' defined for version pattern
> '1.5.0_10': Regard company guidelines for J2SE 5
> [depend] [FAIL]  STRUTS_HOME='jakarta/struts/1.2.4'
> [depend] status 'prohibited.flawed' defined for version pattern
> '1.2.4': security issue (bug:38374). upgrade to 1.2.9
> Total time: 5 seconds
> ----------
> Would such an extension make sense in Maven? Software companies
> definitively have to solve their technology management and if they
> choose Maven for dependency management they could immediately benefit
> from such a feature. The question is if the open source community
> would benefit as well? I would say yes: just consider scenarios 1 and
> 2 above.
> So how would this feature be implemented? Adding a life cycle status
> field to the POM is one way but the problem is that this information
> changes over time and is actually only needed in the repository. So is
> yet another meta-data file necessary? Would an additional Maven
> plug-in be enough to implement the checks?
> Regards,
> Johann Gyger
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message