On 24/01/2013 11:54 AM, Joachim Durchholz wrote:
Am 24.01.2013 15:00, schrieb Ron Wheeler:
On 24/01/2013 3:34 AM, Joachim Durchholz wrote:
Am 24.01.2013 05:39, schrieb Ron Wheeler:
You manually put the jars in your Maven repo through its manual upload
procedure with some version number (nice if it relates to the version
that the authors gave them) and reference them as dependencies.
That's 13 jars to be built from their sources, and 10 jars that they
bundle as external dependencies.
And since they're in pre-beta, I want to do that on a more-or-less
daily basis.
Are the 10 external dependencies changing each day?
Extremely rarely, but since changes there aren't announced anywhere, I
have to act as if it might change any day.
Do you really want to always get the changes without any notice about
what has changed?
I would be worried about seemingly random changes in my artifacts'
behaviour that might take a long time to debug if they were caused by
bug fixes in the external software that affected my stuff.
We stick with a version of an external library as long as possible and
when we do upgrade, we communicate this to everyone so that no one
spends hours trying to find out why a change in their code caused a
change in another part of the project.
It was better to be a bit behind in a stable state than right up to date
but in an unstable environment.
Who is building the 13 jars?
I can choose, they're delivering the sources as well as precompiled jars.
No source jars though, so I'll just svn checkout/update in the
generate-sources phase and let the standard compile etc. mechanisms of
maven do their thing. Sounds easier than explicitly configuring an
attach-sources etc. goal.
This is almost the same as your own code except that you are not writing
it. It is like being part of a team where they are letting you do the
maven build.
Same discussion as above.
I would prefer to build a set of libraries, put them in my repo with a
made up version and freeze the version dependency in my POMS until my
code required an updated version.
How are you going to use SNAPSHOTS in the pre-beta phase?
I build my project based on that.
Whenever I hit a bug, I submit a bug report, which usually gets fixed.
Since my own project is months from a release, that's okay. If I find
I'm nearing release before the external project doesn, I'll probably
drop the SNAPSHOT qualifier and hardcode a known good pre-beta revision.
I would do that during development and only upgrade to their latest
version when:
a) I really needed a new feature or bug fix to move forward or
b) My code was stable and I had time to test their code for integration
issues.
If your code works with the last version of other people's stuff that
you downloaded and placed in your repo, you can release with perfect
confidence that you can come back at anytime and rebuild your
application and get the same product out of your build.
You can apply a patch to your code and know that your patch is
responsible for all of the new behaviour.
Trying to test and debug your own stuff is hard enough without having
odd behaviours creep in while you are working.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
