You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Hanno Braun <h....@gmx.net> on 2010/08/06 15:47:20 UTC
A use case for non-constant artifact ids
Hi everyone,
when I build my project, Maven tells me the following:
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.hannobraun:scalable-dynamics_2.8.0:jar:0.3-SNAPSHOT
[WARNING] 'artifactId' contains an expression but should be a constant.
@ com.hannobraun:scalable-dynamics_${scala.version}:0.3-SNAPSHOT,
/home/hanno/Projects/ScalableDynamics/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
I think the ability to have an expression in the artifactId is very
useful for Scala projects built with Maven.
Due to binary incompatibility between code that was compiled with
different versions of the Scala compiler, Scala projects have adopted
the convention of adding the Scala version used to the artifact id. See
this for example: http://mvnrepository.com/artifact/org.scala-tools.testing
Due to the ability to use an expression in the artifact id I can do
something like this:
<properties>
<scala.version>2.8.0</scala.version>
</properties>
<artifactId>scalable-dynamics_${scala.version}</artifactId>
...
<dependencies>
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>${scala.version}</version>
</dependency>
<dependency>
<groupId>org.scala-tools.testing</groupId>
<artifactId>specs_${scala.version}</artifactId>
<version>1.6.5</version>
<scope>test</scope>
</dependency>
</dependencies>
This approach is pretty much error-proof and low-maintenance. Requiring
a constant artifactId would introduce the possibility of errors every
time I update to another Scala version.
While I understand the notion of wanting to restrict what a user can do
for safety reasons, I think it would be a shame to take power away from
the users. You'll never be able to anticipate what kind of productive
uses people will find for this power.
Regards,
Hanno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: A use case for non-constant artifact ids
Posted by Hanno Braun <h....@gmx.net>.
Hey Frank,
The Maven provided solution for your situation is 'classifiers'. You
are building a single artifact for multiple classes of compiler.
I know about classifiers and I completely agree that they might have
been a better solution to express this. Unfortunately that doesn't
change the fact that Scala projects are already built this way (although
most are built by sbt and not Maven these days, I think) and potential
users would probably expect my library to work like that too.
In the language of Maven, "non-constant artifact ids" is an oxy-moron.
I agree that using that expression was probably not the smartest thing I
did today :)
However, it's not really as if the artifact id varies for the same
artifact. Once you deployed it, it stays the same of course. It's just
that artifacts built from future versions of the same codebase might
have a different id than the current ones.
But it doesn't matter all that much. Maybe I could just use a classifier
and educate my users about this deviation from the Scala/sbt-way.
All I'm doing here is presenting an argument for keeping things the way
they are, especially since I can't see any harm in it.
By the way, I dug up some information on this from the sbt documentation:
http://code.google.com/p/simple-build-tool/wiki/CrossBuild
It doesn't say anything about classifiers though. Maybe there were good
reasons for not using them, maybe not.
Regards,
Hanno
On 08/06/2010 04:09 PM, Gorham-Engard, Frank wrote:
> Hi Hanno
> The Maven provided solution for your situation is 'classifiers'. You are building a single artifact for multiple classes of compiler.
>
> In the language of Maven, "non-constant artifact ids" is an oxy-moron. The 'Id' part of this field label stands for 'identifier'. An identifier is, by nature, a constant. You don't have a different birthday when you where different shoes. Your birthday is one piece of identifying information about you. The intention in Maven is for the GroupId and ArtifactId to be identifiers. This affects the dependency resolution, storage, acquisition processes that Maven uses.
> Notice that 'version' and 'classifier' are not labeled 'Ids'. These are where your variations can be registered.
>
> <!-- Frank Gorham-Engard →
> "Be kinder than necessary.
> Everyone is fighting some kind of battle."
>
>
> -----Original Message-----
> From: Hanno Braun [mailto:h.br@gmx.net]
> Sent: Friday, August 06, 2010 9:47 AM
> To: Maven Users List
> Subject: A use case for non-constant artifact ids
>
> Hi everyone,
>
> when I build my project, Maven tells me the following:
>
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for com.hannobraun:scalable-dynamics_2.8.0:jar:0.3-SNAPSHOT
> [WARNING] 'artifactId' contains an expression but should be a constant.
> @ com.hannobraun:scalable-dynamics_${scala.version}:0.3-SNAPSHOT,
> /home/hanno/Projects/ScalableDynamics/pom.xml
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
>
>
> I think the ability to have an expression in the artifactId is very
> useful for Scala projects built with Maven.
> Due to binary incompatibility between code that was compiled with
> different versions of the Scala compiler, Scala projects have adopted
> the convention of adding the Scala version used to the artifact id. See
> this for example: http://mvnrepository.com/artifact/org.scala-tools.testing
>
>
> Due to the ability to use an expression in the artifact id I can do
> something like this:
>
> <properties>
> <scala.version>2.8.0</scala.version>
> </properties>
>
> <artifactId>scalable-dynamics_${scala.version}</artifactId>
>
> ...
>
> <dependencies>
> <dependency>
> <groupId>org.scala-lang</groupId>
> <artifactId>scala-library</artifactId>
> <version>${scala.version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.scala-tools.testing</groupId>
> <artifactId>specs_${scala.version}</artifactId>
> <version>1.6.5</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
>
>
> This approach is pretty much error-proof and low-maintenance. Requiring
> a constant artifactId would introduce the possibility of errors every
> time I update to another Scala version.
>
> While I understand the notion of wanting to restrict what a user can do
> for safety reasons, I think it would be a shame to take power away from
> the users. You'll never be able to anticipate what kind of productive
> uses people will find for this power.
>
> Regards,
> Hanno
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: A use case for non-constant artifact ids
Posted by "Gorham-Engard, Frank" <Fr...@cable.comcast.com>.
Hi Hanno
The Maven provided solution for your situation is 'classifiers'. You are building a single artifact for multiple classes of compiler.
In the language of Maven, "non-constant artifact ids" is an oxy-moron. The 'Id' part of this field label stands for 'identifier'. An identifier is, by nature, a constant. You don't have a different birthday when you where different shoes. Your birthday is one piece of identifying information about you. The intention in Maven is for the GroupId and ArtifactId to be identifiers. This affects the dependency resolution, storage, acquisition processes that Maven uses.
Notice that 'version' and 'classifier' are not labeled 'Ids'. These are where your variations can be registered.
<!-- Frank Gorham-Engard →
"Be kinder than necessary.
Everyone is fighting some kind of battle."
-----Original Message-----
From: Hanno Braun [mailto:h.br@gmx.net]
Sent: Friday, August 06, 2010 9:47 AM
To: Maven Users List
Subject: A use case for non-constant artifact ids
Hi everyone,
when I build my project, Maven tells me the following:
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.hannobraun:scalable-dynamics_2.8.0:jar:0.3-SNAPSHOT
[WARNING] 'artifactId' contains an expression but should be a constant.
@ com.hannobraun:scalable-dynamics_${scala.version}:0.3-SNAPSHOT,
/home/hanno/Projects/ScalableDynamics/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
I think the ability to have an expression in the artifactId is very
useful for Scala projects built with Maven.
Due to binary incompatibility between code that was compiled with
different versions of the Scala compiler, Scala projects have adopted
the convention of adding the Scala version used to the artifact id. See
this for example: http://mvnrepository.com/artifact/org.scala-tools.testing
Due to the ability to use an expression in the artifact id I can do
something like this:
<properties>
<scala.version>2.8.0</scala.version>
</properties>
<artifactId>scalable-dynamics_${scala.version}</artifactId>
...
<dependencies>
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>${scala.version}</version>
</dependency>
<dependency>
<groupId>org.scala-tools.testing</groupId>
<artifactId>specs_${scala.version}</artifactId>
<version>1.6.5</version>
<scope>test</scope>
</dependency>
</dependencies>
This approach is pretty much error-proof and low-maintenance. Requiring
a constant artifactId would introduce the possibility of errors every
time I update to another Scala version.
While I understand the notion of wanting to restrict what a user can do
for safety reasons, I think it would be a shame to take power away from
the users. You'll never be able to anticipate what kind of productive
uses people will find for this power.
Regards,
Hanno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org