You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/09/04 12:42:56 UTC
DO NOT REPLY [Bug 49881] [PATCH] add maven build support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
--- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53 EDT ---
Created an attachment (id=25986)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
Patch to add maven build support.
This patch has been verified against repository version 992575.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add
maven build support]
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
On 9/09/2010 3:00 PM, Simon Pepping wrote:
> I found offo in maven central:
> http://repo1.maven.org/maven2/net/sf/offo/fop-hyph/1.2/. I did not put
> it there.
Hmm. That makes me officially blind.
Thanks :-)
Ah well, it served as a useful example of the methods.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add maven
build support]
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Sep 09, 2010 at 08:07:01AM +0800, Craig Ringer wrote:
>
> 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.
I found offo in maven central:
http://repo1.maven.org/maven2/net/sf/offo/fop-hyph/1.2/. I did not put
it there.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Craig Ringer <cr...@postnewspapers.com.au>.
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/
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
inline
On Fri, Sep 10, 2010 at 3:46 AM, Vincent Hennebert <vh...@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 <spepping@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 <spepping@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
> >>
> >
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Vincent Hennebert <vh...@gmail.com>.
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 <sp...@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 <spepping@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
>>
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
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.
G.
On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping <sp...@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 <spepping@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
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
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 <sp...@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
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Glenn Adams <gl...@skynav.com>.
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 <sp...@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
>
> On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzilla@apache.org wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> > --- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53
> EDT ---
> > Created an attachment (id=25986)
> > --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
> > Patch to add maven build support.
> >
> > This patch has been verified against repository version 992575.
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Posted by Simon Pepping <sp...@leverkruid.eu>.
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
On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
>
> --- Comment #1 from Glenn Adams <gl...@skynav.com> 2010-09-04 06:42:53 EDT ---
> Created an attachment (id=25986)
> --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986)
> Patch to add maven build support.
>
> This patch has been verified against repository version 992575.
--
Simon Pepping
home page: http://www.leverkruid.eu