You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Johann Gyger <jo...@gyger.name> on 2007/12/05 22:41:06 UTC
Artifact life cycle
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
BUILD FAILED
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Artifact life cycle
Posted by Johann Gyger <jo...@gyger.name>.
Hi Jason,
On Dec 6, 2007 9:29 PM, Jason van Zyl <ja...@maven.org> wrote:
> Put this in the user wiki. It's look interesting to discuss but it
> will get lost in this mailing list.
My refined proposal is now part of the User proposals page:
http://docs.codehaus.org/display/MAVENUSER/Technology+management+using+artifact+life+cycles
Regards,
Johann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Artifact life cycle
Posted by Jason van Zyl <ja...@maven.org>.
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
> BUILD FAILED
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org