You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by baumar <mb...@active.ch> on 2007/10/22 16:47:41 UTC

reading pom.version from a file

Hi,

What would be the right way to read the version number from a file?

We decided that not all users (who maybe don't know maven very well) should
check out the delicate pom file .
We have a file like version.properties containing 

tavx.current.version=1.2.3a

and defined in the pom

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.abc.tat.tavx</groupId>
	<artifactId>tavx</artifactId>
	<name>adapter</name>
	<packaging>jar</packaging>
	<version>${tavx.current.version}</version>
...
<build>
    <filters>
         <filter>src/resources/version/version.properties</filter>
    </filters>

but that doesn't work. 


Thanks for help

Markus

-- 
View this message in context: http://www.nabble.com/reading-pom.version-from-a-file-tf4670564s177.html#a13342350
Sent from the Maven - Users mailing list archive at Nabble.com.


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


Re: reading pom.version from a file

Posted by Michael McCallum <gh...@apache.org>.
Pom? in the singular? Checkin of pom breaks another develper?

I have a team of 9 developers, we have over 113 artifacts... i.e. poms with 
independent versions. we must have over 4000 tags with another 20 live 
branches (i.e. 20 other version of some of those artifacts)

10 or so of those are aggregations i.e. jars, wars that are deployed into dev, 
staging, uat and production environments.

the definition of each artifact is its poms... some of the aggregating poms 
are too complex but that only because people didn't take the time to 
understand the code they are trying to write and deploy...

you should not be thinking of poms in the singular, just like you would not 
write one giant class but refactor it into smaller units dealing with each 
particular aspect of the system, you should do the same thing with artifacts

It only takes one person to really learn maven2 to produce a system that 
functions well at this level of complexity... but then I would argue that the 
system is by its nature complex... maven2 just lets us formally define 
exactly what the system is at all levels... 

IOC and DI
-----------------
all of our code is based around DI and IOC we make heavy use of spring... 

if you work hard you can have clearly defined efferent and afferent couplings 
between not just classes but artifacts, this will give you the most and 
stablest reuse of all the code you produce. 

one significant advantage is the ability to branch at all levels and to 
rapidly alter the structure of any assembly/aggregate

Source vs Binary dependency
-------------------------------------------
One of the crappest things ever is having another developer on your team waste 
hours of your time because they checked in some code that was not correct. 
Maven solves this problem very elegantly... with the concept of an artifact 
release.... DONT depend on trunk but depend on the last release in a version 
range... e.g. 

Source dependency can be equated directly with snapshots and the head of any 
trunk or branch

Binary depedencies relate to a dependency to a tag of a trunk or branch.

Now obviously it is desirable for a developer to integrate often thereby 
commit code changes but at the same time not breaking other developers.

If you only ever binary deps then as the developer of one artifact you can 
choose when you upgrade the efferent coupling and as such waste the least 
amount of time.

You may also choose at what stage your artifact is most suitable for release 
to other developers... so many commits result in a release... 

By definition - unless you are doing something dodgy - each release will mean 
that all the the tests pass! So you are far less likely to be wasting your 
peers time... as a bonus if you do screw things up you can roll back to the 
last tag

rpm, urpmi, yum, portage, deb,  oh and the poor cousin dpkg
-----------------------------------

if you don't already know linux i would highly recommend that you read up on 
package managers and what they try to achieve and how they do it.... the most 
common problem I find is that because Windows(tm) has no proper package 
management people never get, it by that i mean understand the power and 
simplicity of actually managing the software that is deployed on a system...

On Tuesday 23 October 2007 20:13, baumar wrote:
> Thanks Michael for the mental aid and please be leniant to my slow
> reception. I am working in the area of OO programmer since 91 (and used ant
> as few as possible because of the reason you hint at), I read a lot of use
> and abuse and it seems to me the term OO is often a bit dilapidated, isn't
> it.
>
> Shouldn't we more often think of solving practical problems instead of
> getting stuck with fighting for technological concepts an supremacy? A good
> example for this seems to me the pattern oriented approach trying to build
> a layer in top of technical solutions. In this case I'm thinking about a
> pattern called "Dependency injection" also known as "Inversion of control";
> this title describes better what we would like to do.
>
> We are a team of 6 people working - what a surprise - under heavy load.
> Everybody needs to be able to run a build as easy as possible, that's why
> we wanted to try Maven. But not everybody has time to study Maven
> thoroughly; our pom has become a bit bigger and complex, it is under
> version control, thus an error or just a typo would affect the whole team.
> If unfamiliar people start to fumble in the pom, which IMU is essentially
> the heart of the build process, this seems (a bit exagerated, ok) like a
> nurse taking over during a heart surgery while the doctor goes for a
> coffee. However, the team decided to keep the version number as simple as
> possible and therefore would like to have it in a clearly dedicated file to
> focus on only that action (isn't separation of concerns a highly praised
> paradigm of maven?)
> I see that reading in values into the pom adds a new layer of complexity
> and you may you should not multiply things to much. However, it seems to be
> practical to separate basic setup parameters into something like a
> configuration file.
>
> Eventually, we would also have the version number being generated by an
> algorithm in the versioning system. Of course we could use an ant task to
> write that version into the pom file, but I understood that's what you
> wanted to bring us away from. How else is an automated build process
> stuffing the build number into the maven process? Isn't it the most simple
> and robuste way to write it into a - separate - file?
>
> I hope I made our point clear that there might good arguments to allow
> values being feeded into the pom from an external source and maybe give
> some motivation to make the pom file a bit "semipermeable"
>
> Thanks for the discussion
>
> Markus
>
> Michael McCallum-3 wrote:
> > there is no right way to read the version from a file.. the pom is the
> > file
> > that contains the version...
> >
> > stop thinking like an ant script and start thinking like an OO programmer
> >
> > BTW thats not meant to be critical or offensive just to catch your
> > attention
> > and make you think...
> >
> > On Tuesday 23 October 2007 03:47, baumar wrote:
> > t> Hi,
> >
> >> What would be the right way to read the version number from a file?
> >>
> >> We decided that not all users (who maybe don't know maven very well)
> >> should
> >> check out the delicate pom file .
> >> We have a file like version.properties containing
> >>
> >> tavx.current.version=1.2.3a
> >>
> >> and defined in the pom
> >>
> >> <project>
> >> 	<modelVersion>4.0.0</modelVersion>
> >> 	<groupId>com.abc.tat.tavx</groupId>
> >> 	<artifactId>tavx</artifactId>
> >> 	<name>adapter</name>
> >> 	<packaging>jar</packaging>
> >> 	<version>${tavx.current.version}</version>
> >> ...
> >> <build>
> >>     <filters>
> >>          <filter>src/resources/version/version.properties</filter>
> >>     </filters>
> >>
> >> but that doesn't work.
> >>
> >>
> >> Thanks for help
> >>
> >> Markus
> >
> > --
> > Michael McCallum
> > Enterprise Engineer
> > mailto:gholam@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org

-- 
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org

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


Re: reading pom.version from a file

Posted by baumar <mb...@active.ch>.
Thanks Michael for the mental aid and please be leniant to my slow reception.
I am working in the area of OO programmer since 91 (and used ant as few as
possible because of the reason you hint at), I read a lot of use and abuse
and it seems to me the term OO is often a bit dilapidated, isn't it. 

Shouldn't we more often think of solving practical problems instead of
getting stuck with fighting for technological concepts an supremacy? A good
example for this seems to me the pattern oriented approach trying to build a
layer in top of technical solutions. In this case I'm thinking about a
pattern called "Dependency injection" also known as "Inversion of control";
this title describes better what we would like to do. 

We are a team of 6 people working - what a surprise - under heavy load.
Everybody needs to be able to run a build as easy as possible, that's why we
wanted to try Maven. But not everybody has time to study Maven thoroughly;
our pom has become a bit bigger and complex, it is under version control,
thus an error or just a typo would affect the whole team. 
If unfamiliar people start to fumble in the pom, which IMU is essentially
the heart of the build process, this seems (a bit exagerated, ok) like a
nurse taking over during a heart surgery while the doctor goes for a coffee. 
However, the team decided to keep the version number as simple as possible
and therefore would like to have it in a clearly dedicated file to focus on
only that action (isn't separation of concerns a highly praised paradigm of
maven?)
I see that reading in values into the pom adds a new layer of complexity and
you may you should not multiply things to much. However, it seems to be
practical to separate basic setup parameters into something like a
configuration file.

Eventually, we would also have the version number being generated by an
algorithm in the versioning system. Of course we could use an ant task to
write that version into the pom file, but I understood that's what you
wanted to bring us away from. How else is an automated build process
stuffing the build number into the maven process? Isn't it the most simple
and robuste way to write it into a - separate - file?

I hope I made our point clear that there might good arguments to allow
values being feeded into the pom from an external source and maybe give some
motivation to make the pom file a bit "semipermeable"

Thanks for the discussion

Markus


Michael McCallum-3 wrote:
> 
> there is no right way to read the version from a file.. the pom is the
> file 
> that contains the version...
> 
> stop thinking like an ant script and start thinking like an OO programmer
> 
> BTW thats not meant to be critical or offensive just to catch your
> attention 
> and make you think...
> 
> On Tuesday 23 October 2007 03:47, baumar wrote:
> t> Hi,
>>
>> What would be the right way to read the version number from a file?
>>
>> We decided that not all users (who maybe don't know maven very well)
>> should
>> check out the delicate pom file .
>> We have a file like version.properties containing
>>
>> tavx.current.version=1.2.3a
>>
>> and defined in the pom
>>
>> <project>
>> 	<modelVersion>4.0.0</modelVersion>
>> 	<groupId>com.abc.tat.tavx</groupId>
>> 	<artifactId>tavx</artifactId>
>> 	<name>adapter</name>
>> 	<packaging>jar</packaging>
>> 	<version>${tavx.current.version}</version>
>> ...
>> <build>
>>     <filters>
>>          <filter>src/resources/version/version.properties</filter>
>>     </filters>
>>
>> but that doesn't work.
>>
>>
>> Thanks for help
>>
>> Markus
> 
> -- 
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/reading-pom.version-from-a-file-tf4670564s177.html#a13358592
Sent from the Maven - Users mailing list archive at Nabble.com.


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


Re: reading pom.version from a file

Posted by Michael McCallum <gh...@apache.org>.
there is no right way to read the version from a file.. the pom is the file 
that contains the version...

stop thinking like an ant script and start thinking like an OO programmer

BTW thats not meant to be critical or offensive just to catch your attention 
and make you think...

On Tuesday 23 October 2007 03:47, baumar wrote:
t> Hi,
>
> What would be the right way to read the version number from a file?
>
> We decided that not all users (who maybe don't know maven very well) should
> check out the delicate pom file .
> We have a file like version.properties containing
>
> tavx.current.version=1.2.3a
>
> and defined in the pom
>
> <project>
> 	<modelVersion>4.0.0</modelVersion>
> 	<groupId>com.abc.tat.tavx</groupId>
> 	<artifactId>tavx</artifactId>
> 	<name>adapter</name>
> 	<packaging>jar</packaging>
> 	<version>${tavx.current.version}</version>
> ...
> <build>
>     <filters>
>          <filter>src/resources/version/version.properties</filter>
>     </filters>
>
> but that doesn't work.
>
>
> Thanks for help
>
> Markus

-- 
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org

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