On 18-Jul-08, at 10:30 AM, Ralph Goers wrote:
Jason van Zyl wrote:
On 17-Jul-08, at 8:08 PM, Ralph Goers wrote:
Michael McCallum wrote:
why not just specify the dependencies with version ranges, if you
do there is no need to rewrite anything it just works...
My builds never use version ranges. We require that builds be
reproduceable at any time in the future. Version ranges don't
guarantee that.
Version ranges by themselves don't guarantee anything, but I think
what you're saying is that they don't guarantee a released versions
artifacts being reproducible.
The way OSGi works is that the ranges play a part at build time and
runtime. During the time working up to a release ranges are useful
to allow flexibility of testing new versions of code, much like the
way snapshots work and at the time of release you can choose to
lock the versions down. If you lock the versions down then there is
no flexibility in the runtime to accept new versions. Oleg and I
have been trying to work out a way where we can have our cake and
eat it too: allow the flexibility of variable runtime versioning
while keeping an exact list of what actually worked for a release.
I think anyone who has been doing this for a while realizes that
once a project has been QA'd it makes no sense to allow everything
to vary. I think it's a hybrid of these approaches that will allow
the most utility across build and deployment.
That pretty much sums up what I am saying. I view an OSGi bundle a
little differently than a maven project build primarily because the
bundle presumably has a larger granularity.
In can, and a lot of people I've seen use OSGi use ranges.
In both cases though, I would want a version upgrade to be
deliberately controlled. Even while in development we don't use
version ranges. If we choose to upgrade the version of an artifact
we do it in our third party pom's dependencyManagement and then
retest. With OSGi I'd imagine doing more or less the same thing by
installing the new bundle and testing long before QA. However, this
would be done deliberately, not automagically.
Sure, this is sane for your 3rd party deps, but I think you have to be
a little more dynamic while integrating team code. You just need to be
able to track the point at which it was stable and lock it all down.
Vary freely while in determination mode, when successful make that
deterministically reproducible.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
