inline

On Fri, Sep 10, 2010 at 3:46 AM, Vincent Hennebert <vhenneb...@gmail.com>wrote:

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

[GA] When referring to snapshot versions of artifacts from a dependency
declaration, one may specify the latest snapshot, e.g.,

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

or specify a specific snapshot, e.g.,

    <dependency>
      <groupId>org.apache.xmlgraphics</groupId>
      <artifactId>xmlgraphics-commons</artifactId>
      <version>1.4*-20100911.000000-1*</version>
    </dependency>

Note that you can restrict dependency declarations to specific scopes:

   - compile - default scope, applies to all phases
   - test - applies to test compilation and test execution phases
   - runtime - applies to non-compilation phases that involve execution of
   target, e.g., testing and other execution of target
   - provided - used for compilation phases, but not deployed
   - system - like *provided*, but refers to artifact without using a
   repository
   - import - used to import dependencies from additional pom (other than
   the single parent pom)

So, e.g., one might define a dependency on a different version depending on
whether you are compiling but another for testing:

    <!-- use latest snapshot for compiling -->
    <dependency>
      <groupId>org.apache.xmlgraphics</groupId>
      <artifactId>xmlgraphics-commons</artifactId>
      <version>1.4*-SNAPSHOT*</version>
      *<scope>compile</scope>*
    </dependency>

    <!-- use the 2010-09-11 00:00:00Z build 1 snapshot for testing -->
    <dependency>
      <groupId>org.apache.xmlgraphics</groupId>
      <artifactId>xmlgraphics-commons</artifactId>
      <version>1.4-20100911.000000-1</version>
      *<scope>test</scope>*
    </dependency>

Note also that to create a dependency to a non-repository based artifact,
one can specify a specific "system path" which must be available on the
local system, e.g., to include a specific JAR from a lib directory, one
could use something like:

    <!-- use a local copy for compilation, testing, etc., but not deployment
-->
    <dependency>
      <groupId>org.apache.xmlgraphics</groupId>
      <artifactId>xmlgraphics-commons</artifactId>
      <version>1.4</version>
*      <scope>system</scope>*
      *<systemPath>${project.build.directory}/lib/xmlgraphics-common-1.4-svn
.jar</systemPath>*
    </dependency>

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

Reply via email to