On 01/06/2011 10:29 AM, Ron Wheeler wrote:
We build a very large project in a very simple way.
The handling of software sources is handled separately from Maven.
SOURCE POLICY
All software changes are recorded in the Subversion repository in the
trunk or branch or tag regardless of the build status.
Anyone should be able find the sources for any piece of software that a
programmer has decided is worth keeping.
It is considered bad form to put a version into the SVN repo that will
not build but I do it all the time. As the "boss", I often want to
sketch out a design of a piece of code and let someone else flesh it
out. I generally do this to new modules since it is annoying to the rest
of my team. For some reason, they think that I should be able to write
code as well as they do.
A more professional way to to this is to use branches. Sometimes someone
will run into a problem that they need some help with so they commit
their broken version onto a branch and ask someone else to fix it. This
branch will eventually be abandoned as the working code is merged back
into the trunk or tag(if we are fixing an older version)
This works if your modules are small and the team is not too large.
We need to maintain several versions of the released code so we are
careful with tags and branches
RELEASE
Each new release starts with SNAPSHOTs of the modules that are changing.
We originally made new versions of every module in the system that made
up a new application release.
We stopped doing this because it was a lot of work for nothing. Now a
new release of an application will frequently contain only 3 or 4
components with updated version numbers.
We use a simple spreadsheet to document this at the start of a new
release as we determine which modules will require rebuilding and which
ones are going to be included in the release untouched.
We release fairly often so this works well for us.
Deploy
We deploy SNAPSHOTS as soon as they pass the unit tests and are ready
for someone else to use.
These SNAPSHOTS may include mock functionality if that is what other
members of the team require in order to move forward with their tests.
This involves communication as to what the SNAPSHOT is capable of doing.
If it always returns account 123456 regardless of the search criteria
provided, the other programmer needs to know that.
Once we have got through integration testing of the whole application,
the SNAPSHOTs are converted to releases and deployed.
At this point the SVN projects are tagged so we can find the released
version.
No special Maven plug-ins are required.
You might want to visit our technical blog at
http://blog.artifact-software.com/tech for more information about our
processes.
Ron
On 06/01/2011 9:51 AM, Steve Cohen wrote:
On 01/06/2011 08:31 AM, Wendy Smoak wrote:
On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<[email protected]>
wrote:
Set all your versions to end in -SNAPSHOT, that way you can leave them
in the aggregated build without the repository manager complaining on
deploy.
Yes, I suppose I could do that (which is pretty much what I did
before), but
it sort of defeats the whole purpose of what I'm trying to
accomplish here,
which is, be a little more organized about what is release and what
is in
development.
If one of the modules is stable, do a release of it and have the other
modules depend on that released version (but you can still build the
next snapshot in your aggregator build.)
Is what you are saying, then, that I need to "comment out" the stable
modules as modules in the aggregator project? That would pull them
from the
repo (they are then just dependencies, like third party jars)? It
would be
nice not to have to mess with the POMs in this way. That's what I'm
looking
for.
No commenting out. I was trying to make the fewest changes to your
current setup as possible, since you said you didn't want to redesign
the build.
Following the Maven conventions, you never have a non-SNAPSHOT version
number checked in on a trunk or branch -- only on a tag. (Or briefly
while a release is happening.)
<sigh> Convention over configuration again. Another convention I
didn't know was a convention and am not following. I have a bunch of
projects under one master project heading and I simply branch/tag from
the trunk of that master as needed. Very convenient and I'd rather not
give it up.
What a frustrating beast Maven is. Can't live with it, can't live
without it.
It sounds like right now you are building an artifact with a
non-snapshot version number over and over. That goes against the idea
that 'releases never change' -- releases should be built once, put in
the repository, and pulled from there when needed.
The version numbers make it clear what's under development and what's
not. If module A depends on B-1.1-SNAPSHOT (being built in the
aggregated build,) then B is under development. If A depends on
B-1.0, then you are using a stable version of B.
Maven does not currently have the concept of 'skip deployment if my
version number does not end in -SNAPSHOT'. You'd probably have to put
the deploy plugin configured to with 'skip=true' in a profile, and
patch the profile activation code to understand that concept.
Does anyone else think my desires here are not a terrible idea but a
valid wish list item?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks, Ron, this sounds similar to what I'm aiming for, at least in
your conception of how mvn and svn should fit together.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
