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
Maven central?

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:
===================

Use:

<dependency>
  <groupId>org.apache.xmlgraphics</groupId>
  <artifactId>xmlgraphics-commons</artifactId>
  <version>1.5-SNAPSHOT</version>
</dependency>

Update the jar on your machine with:

mvn install:install-file
  -Dfile=/path/to/xmlgraphics-commons-1.5-svn.jar
  -DgroupId=org.apache.xmlgraphics
  -DartifactId=xmlgraphics-commons
  -Dversion=1.5-SNAPSHOT
  -Dpackaging=jar -DgeneratePom=true

Longer explanation:
===================

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,

<dependency>
  <groupId>org.apache.xmlgraphics</groupId>
  <artifactId>xmlgraphics-commons</artifactId>
  <version>1.5-SNAPSHOT</version>
</dependency>

"-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 latest one.

The Apache maven repository is here:
  https://repository.apache.org/index.html
and info about it is here:
  http://www.apache.org/dev/repository-faq.html

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
updated?

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) automatically.

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:

mvn install:install-file
  -Dfile=xmlgraphics-commons-1.5-svn.jar
  -DgroupId=org.apache.xmlgraphics
  -DartifactId=xmlgraphics-commons
  -Dversion=1.5-SNAPSHOT
  -Dpackaging=jar -DgeneratePom=true

... 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.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Reply via email to