DO NOT REPLY [Bug 49881] [PATCH] add maven build support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49881 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-06 23:40:03 UTC --- lack of consensus for committing patch; reconsider this addition in the future -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support]
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: offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support]
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/
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
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.euwrote: 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
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
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, bugzi...@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
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.euwrote: 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, bugzi...@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
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.euwrote: 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
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 spepp...@leverkruid.euwrote: 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
