On 9/09/2010 1:30 AM, Simon Pepping wrote:
I think I mean something different. When XGC adds something new and
FOP uses that, a new XGC jar file must be used by builds. We do that
by having a new jar file in /lib, typically called
xmlgraphics-commons-1.5-svn.jar (which may be updated a few times
during development of the next release). How would that be handled by
the maven build? Would it require the deployment of a snapshot to
No, there's no need to deploy it to central. Everything can be done
entirely locally to your computer. In fact, you really should *NOT*
deploy artifacts to central if they're in-progress prereleases.
Very short version:
Update the jar on your machine with:
Here's how it works.
If it's not the final release, you'd usually version xmlgraphics-commons
it as a snapshot. So in fop you'd have, eg,
"-SNAPSHOT" is a special version that tells Maven the artifact will be
replaced with updated versions periodically. If it's from a remote
repository, Maven will periodically updates unless you tell it not to in
your repository settings. If the artifact was locally created it doesn't
do anything different.
In an "ideal maven" world, new xmlgraphics-commons builds would be
pushed to the Apache maven snapshot repositories (*NOT* to central) as
-SNAPSHOT versions. Your fop build would then automatically grab the
latest xmlgraphics-commons snapshot. You can use dated snapshot versions
to lock in a particular snapshot if you want, or automatically track the
The Apache maven repository is here:
and info about it is here:
You don't have to work using the Apache maven repositories, though. You
can just install a copy of the jar locally instead and update it when
required. See below.
And would the version number in the pom file be
Usually you'd use a -SNAPSHOT version and keep the version string the
same. You could do named prereleases (1.5.M1, 1.5.M2, etc) instead if
you wanted, but I usually don't find that to be worth the hassle unless
you have a large public userbase of your prerelease stuff.
If the xmlgraphics-commons jar is built using Maven you can simply build
it locally and it'll be installed to your local repository (cache)
If the xmlgraphics-commons jar is built with ant or some other way, you
can pop a new or updated copy in your local repo with:
... which is verbose but easily put in a script or task. An optional,
manually invoked ant task in xmlgraphics-commons could be used for example.
That's how I'm dealing with the offo hyphenation files, which don't seem
to be in any convenient maven repo. I just download the jar and push it
into my local repository (~/.m2, effectively download cache). As they
don't change much I pretty much did it once and forgot about it - the
dependency is "just there" in all my builds as and when required now.
It all sounds like a lot of hassle - but honestly, in practice it's not.
Some learning is definitely required, but is well worth it. I'm never,
ever, ever going back to wrangling a lib/ dir full of mixed direct and
transitive dependencies from several different 3rd party libraries again.
Tech-related writing at http://soapyfrogs.blogspot.com/