You should discourage people from checking in things that will break
other people's releases.
Breaking libraries into smaller chunks that have more stable interfaces,
reduces the interference between developers.
Having a good interface specification for your libraries' APIs will make
your life easier.
Dependent modules should be upward compatible. Implementation should
not affect the interface.
Our biggest problem is database changes since these tend to drive lower
level modules.
A good plan and good communication is important in this area with a
small team.
We are moving to SOA which does force better control over functional
design at the interface level.
I hope that this helps.
Ron
I've been trying to read up on best practices with Maven in a team
environment where different groups are working on different but related
modules. Been reading over chp7 of 'Better Builds With Maven' but still
have
some questions.
To keep it simple for sake of discussion... war project depends on jarA,
jarA depends jarB. Three different teams are working on those three
separate
modules.
For this current project we have not set up a continuous integration server
yet. (We're still on CVS here for source control management but I know
another team using CruiseControl for continuous builds so at some point
we'll use that as well.)
We are using Artificatory for our local internal repository.
Right now since the project is still very young we're just declaring the
version number as 1.0-SNAPSHOT. Ultimately all that we care about building
to the dev server is the webapp (war) project. We started out for a while
having the various jar projects do a 'mvn deploy' when they were ready to
deploy their jars, the problem with that is how does jarB know that he's
not
going to break jarA who depends on jarB if he does a deploy? jarA team can
be happily going along coding against a local repository version of jarB
that allows him to not break. Lets say jarA doesn't do a deploy, but now a
dev build of the war project needs to take place - it ends up pulling in
the
new jarB snapshot which causes things to break. How is that kind of thing
best avoided (other than forcing down locked version numbers?)
How do you make sure you can always get a good build of a dev war that is
dependent on various interrelated modules? Typically we've done this the
harder way and not relied on teams using mvn deploy - and instead we would
require teams to tag their code with a DEV tag (since we still want to
allow
people to check in code that compiles but isn't DEV server ready yet.) On
the server we then go through and do a cvs update from the DEV tag for all
the modules and build them which makes sure we get a decent build or catch
any problems. I'm guessing this is where a continuous integration build
system would help? ( I assume it can do the same thing and build from a tag
and build in the correct order? )
I'm just wondering what the best practice is in making sure you can 1)
allow
developers to always be checking in code (that compiles, but could break
another person depending on it) and 2) easily get a quick dev build of the
main project (war) to a server?
Next probably somewhat naive question, but in regard to increasing a
version
number, I take the best practice is when some sub-module feels its ready
for
a new version number, they simply update their pom version number (remove
the -SNAPSHOT) and check in their pom and possibly do a mvn deploy. Then
they go back with maybe a 1.1.1-SNAPSHOT declared for their project so they
can continue to work on the next release with snapshots? I take it then
they
just communicate with the other teams that a new version or snapshot
version
is ready.
So to sum up what I 'think' is the way day-to-day operations run for teams
1) team works on their code with 1.0-SNAPSHOT version number
2) before checking in any code, run mvn clean install with the -U flag to
get any new dependent snap shot versions
3) assuming code builds, it can be checked in
4) when happy with code as stable enough for others to use, tag it to DEV,
do mvn deploy
There is something still really wrong with the above though. It doesn't
allow someone to ALWAYS be able to make a good dev build, but I guess
that's
the drawback to using snapshots.
Any suggestions and articles on the best way to handle a combination of
doing source control management and maven for multiple module projects
would
be appreciated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
