On 07/05/2011 12:10 PM, David McCabe wrote:
We've been using a custom-made component-based build system for many years,
built using a number of Ant scripts, and we'd really like to move to
something more standard. We'd like to go with Maven, Subversion and Nexus,
but our build processes are a little different from the usual and it would
be nice to know what is the 'right' way to address some of the versioning
issues.
Our applications are made up of a few dozen components, some of which are
shared between projects and some of which are project-specific. Each of
these components currently has a 4-component build number
"major.minor.patch.build". When building a component, its build number is
incremented. A new major, minor or patch version resets the build version to
zero. I'm happy to change a dot to a hyphen, and I'd also be perfectly happy
for that build number to be a Subversion revision number, but I'm not happy
to go for a SNAPSHOT-style date/time: try telling someone your latest
version is "3.6.0.20110507170144".
A SNAPSHOT is not a release and ideally should never be spoken off
outside the immediate team and even then you need to explain what a
SNAPSHOT does and does not yet do and what are the restrictions on its
use and where it does not respect the specifications. Or you can just
let the other team members curse you out when they spend hours trying to
find out why their software does not work when they use your SNAPSHOTs.
SNAPSHOTS are very useful but version 1.3.5.6 is not the same as
1.3.5.6-SNAPSHOT.
One comes with a warranty and the other comes with a warning.
The 'released' version of a component is the last build number that
component is built with. Once a component has been 'released' it cannot be
built as a new version; the rest of the version number needs to be
incremented. This is somewhat like Maven's release process except that we do
not want to renumber or rebuild the components for release; integration and
system tests will reveal when a project (and its constituent components) are
ready for release, and we're not going to re-run the entire test suite on a
functionally identical build. It would be nice to protect a 'released'
component from being rebuilt but that's hardly mandatory.
Nexus will prevent you from redeploying the same release so you have
some protection. In Maven, releases are immutable.
If you follow best practices with your POM and stay away from such evils
as "Version Ranges", your builds are repeatable.
Never build a release with SNAPSHOT - there lies the road to damnation!
Obviously, when a component is built and its build number incremented, all
dependencies need to have their version numbers updated and be rebuilt. It
would be nice if the dependencies could automatically pick up the 'latest'
version of a major.minor.patch dependency version; I understand this can be
done using Maven version ranges.
Bad idea.
Leads to unrepeatable builds.
Make people release dependencies with a warranty.
It is better to use SNAPSHOTs until you are ready to release the top
level modules and insist that the lower level dependencies be released
first.
Everyone keeps their versions at SNAPSHOTs until they warrant it is
release quality.
When doing a 'real' build I would like the components to be 'tagged' in
Subversion with the built version numbers and for that tag to reference the
actual set of build dependencies (rather than a version range). Ideally, I'd
have a Subversion style:
Component-name
|- trunk
|- branches
|- |- 1.0.0
|- |- 1.0.1
|- |- 1.1.0
|- tags
|- |- 1.0.0-0
|- |- 1.0.0-1
|- |- 1.0.1-0
Yes. You are right. You can tag SNAPSHOTS but people seldom do.
I would also like to be able to do 'test' builds without tagging; maybe the
tagging should be separate so I can try to build the whole lot to my local
repository, and if the build is successful and all automated tests pass
along the way only then update Nexus and tag in Subversion.
Nexus will handle SNAPSHOTS and you can deploy them as long as your
friends are made aware of where you are in terms of functionality and
robustness.
What I want, therefore, is a system in which, for a set of top-level
components to be built, it would then evaluate the set of transitive
dependencies of those components as specified in Subversion (not Nexus or
the local repository), work out the complete list of out-of-date components
to build and then build all of those components such that the top-level
components represent the current state of Subversion. Plainly, if the build
is up-to-date with Subversion, nothing should be built.
Too much work. Just run a clean development workflow and do things the
Maven way and your life will be much more pleasant and your development
team much happier with each other.
Guys who release crap will soon find out that their friends will jump on
them and the boss will know that a crappy piece of software was released
when it was still at the SNAPSHOT stage.
I accept that this is a job for Python, but I am wondering how much of this
process can be done with Maven without cluttering the per-project POMs, even
if minor modifications need to be made.
Try not to reinvent a process that works for thousands of other projects.
Thanks in advance,
David McCabe
Our LMS Portal application has over 70 Maven projects and uses well over
50 third party libraries. It has been in production and development for
more than 3 years.
It includes Tomcat servlets, Web Services and standalone batch jobs.
We use a very clean out-of-the-box Maven workflow with no odd plug-ins
or version ranges.
Maven and Nexus are a great combination. We also use Subversion.
Good luck and you will find this forum a great place for advice. Not
everyone is as opinionated as me and some of them are really great Maven
experts and are willing to help others a lot.
You did a very good thing by starting off with a description of what you
are trying to accomplish. A lot of people show up with detailed
questions with no context and get "right" answers that lead them down a
bad path that takes weeks to straighten out.
I hope that this helps.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
