Am 24.01.2013 18:53, schrieb Ron Wheeler:
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 have little choice in that matter.
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.
I haven't had to work around a bug yet, so I'm not too worried about bug
fixes breaking my code, and I fact I haven't had a problem of that kind yet.
Once it becomes a problem, I'll stabilize the revision. Hopefully, that
will happen after they release a stable version, but that's Not There
Yet so I'm simply sticking with that works best at the time.
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.
Exactly.
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.
Yes, but it's not necessary yet.
And I wish to use the stable build when it comes out, so I'm sailing
along with the updates to see any problems as soon as they arise.
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.
I have little logic that I can test (yet).
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.
I have the sources, so I'm not even noticing much when I cross the
border to external code.
What I've been using of the external code isn't that much; I can easily
spot any problems that might have crept in.
Things will get differently as I use more and more of their code, and
I'll stabilize some day for sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
