You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Frank Maritato <fm...@attinteractive.com> on 2010/05/03 18:37:12 UTC

project version as a property?

Hi,

I have a multi module project and in my top level pom I am using a 
property to define the version number like this:

<version>${myproject.version}</version>

<properties>
   <myproject.version>0.1</myproject.version>
</properties>

All my submodules inherit from this pom and all define <version> the 
same way. Within the context of this project it all works and everything 
is cool. The problem I have is when I try to import one of these 
libraries into another project I get an error that it can't resolve the 
parent of my dependency because it isn't resolving that property value.
When I look in my .m2/repository directory at the pom for that project 
it still has the unresolved ${myproject.version} string in there. I have 
tried defining that property in the other project that is importing that 
dependency but it still doesn't work.

Is this not the way we should define our project? Should we just use 
explicit version numbers in our pom's?

--
Frank Maritato

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


Re: project version as a property?

Posted by Ron Wheeler <rw...@artifact-software.com>.
On 03/05/2010 7:48 PM, Marshall Schor wrote:
>
> On 5/3/2010 4:05 PM, Ron Wheeler wrote:
>    
>> Does this imply a rule 4) The parent should define properties for all
>> of the dependency versions for the shared libraries that the children
>> need?
>>      
> Things go in parents when you can see you are repeating yourself in the
> children;  moving those items to parents generally improves the
> maintainability.  But if a child is the only thing using a dependency,
> moving it to a parent makes the child less easy to read and understand
> (because, of course, you have to go and read the parent too).
>    
We are building portals so we have a lot of common dependencies and have 
built jars that just consolidate jars from different sources into larger 
jars to reduce the number of dependencies
For example, we have a POM that builds a single jar containing Spring, 
Hibernate, MySQL and Tomcat dependencies since every portlet that we 
build needs all of them.
This makes it easier for the portlet developer to get all the "right" 
versions.
We do the same thing for our WebServices, Jetspeed, general shared 
libraries and our own core utilities.
>    
>> Does this go in "dependency management" or simply as a set of
>> properties that are passed on to the children?
>>
>>      
> The POMs are clearer when you put these in dependencyManagement, I think.
>
>    
I am disappointed  to hear this. One of my most trusted developers has 
been arguing this point for a while.
It looks like I am on the wrong side of the argument.
I guess that "eating crow" will something that I will have to learn to 
enjoy. :-)

Ron
> -Marshall
>    
>> Ron
>>
>> On 03/05/2010 2:44 PM, Marshall Schor wrote:
>>      
>>> What I've surmised from the various sources of maven thinking, is that
>>>
>>> 1) The<parent>   element should identify the parent using explicit (no
>>> properties) values
>>> 2) The child project can then "inherit" from the parent the<groupId>
>>> 3) The child project should also define its version explicitly
>>>
>>> The release plugin expects this and has code to adjust these values
>>> inside the pom, as the release happens.  They go from x.y.z-SNAPSHOT to
>>> x.y.z  (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
>>> release snapshot (the last one is changeable, to correspond to your
>>> release numbering - see the documentation for the release plugin).
>>>
>>> The point of all that is that the tooling tries to take care of
>>> mass-updating these "fixed" version numbers.  This might reduce the
>>> motivation of using substitutable property names (that is, if the
>>> motivation was to have one spot to update, and have that update
>>> "propagated" to the other poms).
>>>
>>> -Marshall Schor
>>>
>>> On 5/3/2010 12:37 PM, Frank Maritato wrote:
>>>
>>>        
>>>> Hi,
>>>>
>>>> I have a multi module project and in my top level pom I am using a
>>>> property to define the version number like this:
>>>>
>>>> <version>${myproject.version}</version>
>>>>
>>>> <properties>
>>>>     <myproject.version>0.1</myproject.version>
>>>> </properties>
>>>>
>>>> All my submodules inherit from this pom and all define<version>   the
>>>> same way. Within the context of this project it all works and
>>>> everything is cool. The problem I have is when I try to import one of
>>>> these libraries into another project I get an error that it can't
>>>> resolve the parent of my dependency because it isn't resolving that
>>>> property value.
>>>> When I look in my .m2/repository directory at the pom for that project
>>>> it still has the unresolved ${myproject.version} string in there. I
>>>> have tried defining that property in the other project that is
>>>> importing that dependency but it still doesn't work.
>>>>
>>>> Is this not the way we should define our project? Should we just use
>>>> explicit version numbers in our pom's?
>>>>
>>>> -- 
>>>> Frank Maritato
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>          
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>        
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>    


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


Re: project version as a property?

Posted by Marshall Schor <ms...@schor.com>.

On 5/3/2010 4:05 PM, Ron Wheeler wrote:
> Does this imply a rule 4) The parent should define properties for all
> of the dependency versions for the shared libraries that the children
> need?

Things go in parents when you can see you are repeating yourself in the
children;  moving those items to parents generally improves the
maintainability.  But if a child is the only thing using a dependency,
moving it to a parent makes the child less easy to read and understand
(because, of course, you have to go and read the parent too).

>
> Does this go in "dependency management" or simply as a set of
> properties that are passed on to the children?
>

The POMs are clearer when you put these in dependencyManagement, I think.

-Marshall
> Ron
>
> On 03/05/2010 2:44 PM, Marshall Schor wrote:
>> What I've surmised from the various sources of maven thinking, is that
>>
>> 1) The<parent>  element should identify the parent using explicit (no
>> properties) values
>> 2) The child project can then "inherit" from the parent the<groupId>
>> 3) The child project should also define its version explicitly
>>
>> The release plugin expects this and has code to adjust these values
>> inside the pom, as the release happens.  They go from x.y.z-SNAPSHOT to
>> x.y.z  (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
>> release snapshot (the last one is changeable, to correspond to your
>> release numbering - see the documentation for the release plugin).
>>
>> The point of all that is that the tooling tries to take care of
>> mass-updating these "fixed" version numbers.  This might reduce the
>> motivation of using substitutable property names (that is, if the
>> motivation was to have one spot to update, and have that update
>> "propagated" to the other poms).
>>
>> -Marshall Schor
>>
>> On 5/3/2010 12:37 PM, Frank Maritato wrote:
>>   
>>> Hi,
>>>
>>> I have a multi module project and in my top level pom I am using a
>>> property to define the version number like this:
>>>
>>> <version>${myproject.version}</version>
>>>
>>> <properties>
>>>    <myproject.version>0.1</myproject.version>
>>> </properties>
>>>
>>> All my submodules inherit from this pom and all define<version>  the
>>> same way. Within the context of this project it all works and
>>> everything is cool. The problem I have is when I try to import one of
>>> these libraries into another project I get an error that it can't
>>> resolve the parent of my dependency because it isn't resolving that
>>> property value.
>>> When I look in my .m2/repository directory at the pom for that project
>>> it still has the unresolved ${myproject.version} string in there. I
>>> have tried defining that property in the other project that is
>>> importing that dependency but it still doesn't work.
>>>
>>> Is this not the way we should define our project? Should we just use
>>> explicit version numbers in our pom's?
>>>
>>> -- 
>>> Frank Maritato
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>

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


Re: project version as a property?

Posted by Ron Wheeler <rw...@artifact-software.com>.
Does this imply a rule 4) The parent should define properties for all of 
the dependency versions for the shared libraries that the children need?

Does this go in "dependency management" or simply as a set of properties 
that are passed on to the children?

Ron

On 03/05/2010 2:44 PM, Marshall Schor wrote:
> What I've surmised from the various sources of maven thinking, is that
>
> 1) The<parent>  element should identify the parent using explicit (no
> properties) values
> 2) The child project can then "inherit" from the parent the<groupId>
> 3) The child project should also define its version explicitly
>
> The release plugin expects this and has code to adjust these values
> inside the pom, as the release happens.  They go from x.y.z-SNAPSHOT to
> x.y.z  (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
> release snapshot (the last one is changeable, to correspond to your
> release numbering - see the documentation for the release plugin).
>
> The point of all that is that the tooling tries to take care of
> mass-updating these "fixed" version numbers.  This might reduce the
> motivation of using substitutable property names (that is, if the
> motivation was to have one spot to update, and have that update
> "propagated" to the other poms).
>
> -Marshall Schor
>
> On 5/3/2010 12:37 PM, Frank Maritato wrote:
>    
>> Hi,
>>
>> I have a multi module project and in my top level pom I am using a
>> property to define the version number like this:
>>
>> <version>${myproject.version}</version>
>>
>> <properties>
>>    <myproject.version>0.1</myproject.version>
>> </properties>
>>
>> All my submodules inherit from this pom and all define<version>  the
>> same way. Within the context of this project it all works and
>> everything is cool. The problem I have is when I try to import one of
>> these libraries into another project I get an error that it can't
>> resolve the parent of my dependency because it isn't resolving that
>> property value.
>> When I look in my .m2/repository directory at the pom for that project
>> it still has the unresolved ${myproject.version} string in there. I
>> have tried defining that property in the other project that is
>> importing that dependency but it still doesn't work.
>>
>> Is this not the way we should define our project? Should we just use
>> explicit version numbers in our pom's?
>>
>> -- 
>> Frank Maritato
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>    


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


Re: project version as a property?

Posted by Marshall Schor <ms...@schor.com>.
What I've surmised from the various sources of maven thinking, is that

1) The <parent> element should identify the parent using explicit (no
properties) values
2) The child project can then "inherit" from the parent the <groupId>
3) The child project should also define its version explicitly

The release plugin expects this and has code to adjust these values
inside the pom, as the release happens.  They go from x.y.z-SNAPSHOT to
x.y.z  (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).

The point of all that is that the tooling tries to take care of
mass-updating these "fixed" version numbers.  This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
"propagated" to the other poms).

-Marshall Schor

On 5/3/2010 12:37 PM, Frank Maritato wrote:
> Hi,
>
> I have a multi module project and in my top level pom I am using a
> property to define the version number like this:
>
> <version>${myproject.version}</version>
>
> <properties>
>   <myproject.version>0.1</myproject.version>
> </properties>
>
> All my submodules inherit from this pom and all define <version> the
> same way. Within the context of this project it all works and
> everything is cool. The problem I have is when I try to import one of
> these libraries into another project I get an error that it can't
> resolve the parent of my dependency because it isn't resolving that
> property value.
> When I look in my .m2/repository directory at the pom for that project
> it still has the unresolved ${myproject.version} string in there. I
> have tried defining that property in the other project that is
> importing that dependency but it still doesn't work.
>
> Is this not the way we should define our project? Should we just use
> explicit version numbers in our pom's?
>
> -- 
> Frank Maritato
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>

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


Re: project version as a property?

Posted by Justin Edelson <ju...@gmail.com>.
On Mon, May 3, 2010 at 12:37 PM, Frank Maritato <
fmaritato@attinteractive.com> wrote:

> Hi,
>
> I have a multi module project and in my top level pom I am using a property
> to define the version number like this:
>
> <version>${myproject.version}</version>
>
> <properties>
>  <myproject.version>0.1</myproject.version>
> </properties>
>
> All my submodules inherit from this pom and all define <version> the same
> way. Within the context of this project it all works and everything is cool.
> The problem I have is when I try to import one of these libraries into
> another project I get an error that it can't resolve the parent of my
> dependency because it isn't resolving that property value.
> When I look in my .m2/repository directory at the pom for that project it
> still has the unresolved ${myproject.version} string in there. I have tried
> defining that property in the other project that is importing that
> dependency but it still doesn't work.
>
> Is this not the way we should define our project? Should we just use
> explicit version numbers in our pom's?
>
Yes.


>
> --
> Frank Maritato
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>