Hi Simone,
Thanks a lot haven't thought about ranges for this but now it seems to
be the obvious solution :-)
I still might have a challenge when I have multiple branches of one
artifact (e.g. 1.0-patch-customer1, 1.0-patch-customer2) but in all the
other cases it should solve my problem.
Regards
Stefan
Simone Gianni wrote:
Hi Stefan,
I don't know if I got the problem right and if this could be a solution,
but I do as follows (obviously, we are talking about "maven branching",
not SVN or CVS branching, which is another story) :
- setup a developers only maven repository
- setup a production only maven repository
- use range versions instead of fixed ones
.. This means that instead of having a dependency on artifact
com.yourcompany:artifact:1.0.0 you have a dependency on
com.yourcompany:artifact any version > 1.0.0
- when a subproject is buggy, a team (or single developer, or whatever)
will start working on it
- they will build it on their own computers (in their local repository),
so no problem with them testing their own work
- they will occasionally deploy it TO THE DEV ONLY repository
.. deploying it there, will let the other teams use the new artifact and
test that their own work is correct related to the new
bugfixes/refactorings and so on
.. obviously, when they deploy, they should increment the minor
version/revision, but only on that project specific pom (for example
1.0.0-r1 1.0.0-r2 or 1.0.1 1.0.2 etc...)
- when the bugs have been fixed, the deploy can be made on the
production only maven repository
- from there, a complete build and test of the application can be done,
and final release (war, jars or whatever) created to send to customers
This way, every project can have its own "lifecycle", its own releases,
and probably its own SVN branches and so on. While using fixed version
dependencies is a good practice when linking to something outside your
control (artifacts on the main repo), for internal dependencies
(artifacts produced inside your company/team) it is a maintenance
nightmare and most of the time useless, cause you know when a new
version will break compatibility and can adjust versioning only when
that happens.
Using SNAPSHOTS can save a bit of time making the "change the version
when sending to other developers" step not necessary, but I think that
it should be avoided when there is a high number of developers : that
step can potentially break the build and stop other developers' work if
the new package breaks compatibility when it should not or introduces
more bugs than the previous one (which obviously happens :) ), and
having also these "internal" releases versioned is IMHO more time-saving
than using automagic snapshot updates.
Hope this helps,
Simone
Stefan Fritz wrote:
Hi,
We use Maven in an environment where we have ca. 150 projects.
One project is the toplevel project (= the final deliverable to the
customer/user).
This project has dependencies to 10 projects, which have dependencies
to other projects etc. In the end we have 150 different projects in
the dependency hierachy.
The challange now is what happens if in one of the projects on the
lowest level is bug.
This means we have to branch from our released version to work on a
patch and then release the patched version.
From my understanding the only way to do that is to branch all
projects which depend on the "buggy" project. And the same has to be
done for all levels up to toplevel project.
Most low level components are referenced by multiple projects and
therefore a patch-branch would afect ca. 30 projects :-(
As you can imagine this can end up in a nightmare of manual steps
and/or scripting.
Therefore I hope anybody has a better approach to that.
Is there a simple way to do that?
Any automation in Maven?
Any best practices?
Thanks
Stefan
---------------------------------------------------------------------
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]
