aspose file tools*
The moose likes Ant, Maven and Other Build Tools and the fly likes versioning components independently Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "versioning components independently" Watch "versioning components independently" New topic
Author

versioning components independently

attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20


Component versions are not the same when we do builds, it keeps on changing. We need a proper version schema.

Example: if we have three components A,B,C. First build will give them versions A1,B1,C1. Now lets suppose that a developer or anybody is working and did some changes on the B then the version should be A1,B2,C1. I mean to say that it doesn't have to reversion the components that are not changed.

or can we maintain separate versions for each components and it should be incremented only when the component has changed.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2404
    
  28

Which build tool are you using?

If you are using maven, you can use maven-buildnumber plugin to get the SVN rev number. You can use the build number anywhere in the POM, or any of the filtered resources. Here's a sample that shows how to add svn rev number to manifest.
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Thanks Jayesh for the quick reply.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<doCheck>false</doCheck>
<doUpdate>true</doUpdate>
</configuration>
</plugin>

Please give me a solution either in maven or Jenkins

Do you mean just add this plugin in the existing POM. Let me explain you my module structure.

--Parent
-- ModuleA ( inside it has some components)
----- ModuleB ( inside it has some components)
------- ModuleC (inside it has some components)

So lets assume module A components are X,Y,Z ----- so after the build their versions will be x1,y1,z1
so lets assume modole B components are D,E,F ---- so after the build their versions will be d1,e1,f1
so lets asssume module C components are K.L.M-- so after the build their versions will be k1,L1,M1

so the build package will be x1,y1,z1,d1,e1,f1,k1,l1,m1 ---- This is the build package.

Lets think that when we have to do the next build we worked only on module B then we need to build only that module ( and its affected components ) over here means d1,e1,f1..... So i do the build it must have x1,y1,z1,d2,e2,f2,k1,l1m1 in other words we are not reversion the module A and module B components.

Appreciate for your replies and waiting for the response
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
attu baba wrote:Thanks Jayesh for the quick reply. you mean to add this in the my parent pom

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<doCheck>false</doCheck>
<doUpdate>true</doUpdate>
</configuration>
</plugin>

Please give me a solution either in maven or Jenkins

Do you mean just add this plugin in the existing POM. Let me explain you my module structure.

--Parent
-- ModuleA ( inside it has some components)
----- ModuleB ( inside it has some components)
------- ModuleC (inside it has some components)

So lets assume module A components are X,Y,Z ----- so after the build their versions will be x1,y1,z1
so lets assume modole B components are D,E,F ---- so after the build their versions will be d1,e1,f1
so lets asssume module C components are K.L.M-- so after the build their versions will be k1,L1,M1

so the build package will be x1,y1,z1,d1,e1,f1,k1,l1,m1 ---- This is the build package.

Lets think that when we have to do the next build we worked only on module B then we need to build only that module ( and its affected components ) over here means d1,e1,f1..... So i do the build it must have x1,y1,z1,d2,e2,f2,k1,l1m1 in other words we are not reversion the module A and module B components.

Appreciate for your replies and waiting for the response
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2404
    
  28

What do you mean by components? Does your module create multiple jars using assembly plugin? or do you mean inside module a you have sub modules X, Y and Z? Are all modules in the same SVN?

Either way, is seems like you have run into the classis situation of trying to use solution Y to solve problem X, and coming here to ask us how to do Y, when you should be telling us more about problem X. Or in other words, why are you trying to revision modules independently? Is it just so you can track what changes have gone into which module? or are you trying to streamline your build process?
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
What do you mean by components? Does your module create multiple jars using assembly plugin? or do you mean inside module a you have sub modules X, Y and Z? Are all modules in the same SVN?

Yes you are right we have a nested module like structure. Inside module we have sub modules and these sub modules produces an ear,war depending on the assembly.xml. These all modules are in the same SVN.

Either way, is seems like you have run into the classis situation of trying to use solution Y to solve problem X, and coming here to ask us how to do Y, when you should be telling us more about problem X. Or in other words, why are you trying to revision modules independently? Is it just so you can track what changes have gone into which module? or are you trying to streamline your build process?

Jayesh: The things which I am trying to achieve is to track which module's component have changed or I can say which submodules has changed that has produced ear's or war's. The idea behind versioning independently is we dont have to re-version the components which are already built during our first build. ex i wrote like when A -X.YZ and their versions as x1,y1,z1 and B d1,e1,f1, and C K1,L1,M1.

If we do second build we must get x1,y1,1, d2,e2,f2,k1,l1m1..
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Hi,

So any ideas behind this approach
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Hi

Any alternative thoughts about my problem
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Is there any other thoughts behind this process.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5836
    
    7

I already point out in you other post that using the Maven master/submodule hierarchy is not a good idea.

At work we build dozens of modules that end up being packaged together in numerous ways. Our versioning scheme uses a base version (2.3 at this point) and appends the Subversion revision number (and optionally the Jenkins build number, we do this mostly for 'package only' modules where we package other modules for distribution). Then within our POMs, when we refer to other modules that we build, we always use a version range: [2.3,2.4). This way we get the latest version of any component.It has worked very well for us; we have been using this scheme for over a year now.


JBoss In Action
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Hi,

can you please elaborate on your points, little bit lost. Thanks though for your help
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5836
    
    7

We wrote our own plugin to handle artifact versions. Within the POM for an artifact, the coordinate includes this version:



Our plugin replaces the token 'BUILD' with a generated version number which can be specified as an attribute of our versioning plugin. By default, 'BUILD' is replaced by the Subversion revision number. For example, we might get a final version number of 2.3.23781. The great thing about this scheme is that we know exactly what Subversion revision was used to build the artifact.

By the way, you can achieve a similar result by using SNAPSHOTs; the only thing you lose is the ability to associate a Subversion revision number with a particular build. For example, the arrtifact's coordinate could include:



and then all other artifacts will use the same text to refer to it, and you will always get the latest one. Additionally, you will at some time have to decide when to release the final version (i.e., remove the SNAPSHOT from the version number), but there are ways to do that.
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Thanks
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Hi,

So how does it help us in not building up the same component which has not changed.
attu baba
Greenhorn

Joined: Dec 20, 2012
Posts: 20
Sorry I mean if the component has been built previously and has not been changed then their version should be same. In other words each time it gets checked out from svn the version changes how to keep a constant track of that.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5836
    
    7

If the files in your project have not changed, then the revision number for that project will be the same. For example, I have projects A and B. I check in changes to both projects at the same time and the revision number is now 1001. Thus after a build, if I use the revision number in my artifact numbers, I get A-1001.jar and B-1001.jar. Later, I make a change only to B and now have revision 1002. Jenkins builds only B and I get B-1002.jar. If I try to rebuild A, I would get A-1001.jar because Jenkins uses the latest revision number that caused a change to the project.

Note, however, that I can check out project A using either revision 1001 or 1002 and get the exact same source code. This is because the revision number is global to the entire Subversion repository. But as I mentioned, when Jenkins builds it gets the last changed revision number for the project and uses that.

I hope that makes it clear.
 
 
subject: versioning components independently