On 09/09/10 04:39, Glenn Adams wrote: > Ah, ok. Off hand, I see three ways to handle this, one of which you mention: > > (1) deploy xmlgraphics-commons-1.5-SNAPSHOT.jar to a public maven repo and > update the maven/pom.xml to refer to this version; > (2) install xmlgraphics-commons-1.5-SNAPSHOT.jar in your local maven repo > and update the maven/pom.xml to refer to this version; > (3) modify maven/pom.xml to exclude the dependency from the class path, but > then add a reference to the local XGC jar to the classpath (for compiles and > tests); > > I would probably choose option (2), since that puts the onus on the user of > the maven build config rather than on the updater of XGC (who may not be > familiar with deploying a snapshot). The change to maven/pom.xml to use the > snapshot version could be committed, and not just a local copy; instructions > to set up the local repo copy of the snapshot would then be added to the > maven readme file I created.
Can one have several local Maven repositories? What if I’m working on several branches of FOP that all require different, snapshot versions of XML Graphics Commons? With option (2), how can we make sure that all the developers work with the same snapshot jar of XGC? Thanks, Vincent > G. > > On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping <spepp...@leverkruid.eu>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? And would the version number in the pom file be >> updated? >> >> Simon >> >> On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote: >>> If I understand you correctly, the answer is no. The file maven/pom.xml >> in >>> the patch explicitly references revision 1.7 of the batik artifacts. So >> any >>> use of upward revisions of those artifacts would require updating the >>> pom.xml file to reflect use of a newer revision. >>> >>> At present, I worked around the headless problem (testWMF) by specifying >>> java.awt.headless as false in the pom.xml configuration for those test >>> suites that invoke testWMF. Of course, that also means that the this >> patch >>> will fail those tests when invoked on a truly headless platform. >>> >>> Does that answer your query? Or are you asking if I can adjust the >>> configuration to make automatic use of snapshot updates? >>> >>> Regards, >>> Glenn >>> >>> On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping <spepp...@leverkruid.eu >>> wrote: >>> >>>> Does this build system require us to deploy snapshots of >>>> xmlgraphics-commons and batik to the maven repository, whenever we use >>>> snapshot versions in our lib directory? We do routinely for xgc, and >>>> we may need to do so for batik if the headless problem is fixed (see >>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). >> >> -- >> Simon Pepping >> home page: http://www.leverkruid.eu >> >
