Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well? regards, glenn On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. Introducing an external repository immediately adds a new dependency in form of the repository to the build which is one more point of failure. And how many times did a Maven/Ivy build download half the Internet just to build a small project? For a private project I started out using Ant+Ivy but I'm in the process of dropping the Ivy part again. And I've had the repository hand-maintained in a project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Repositories are probably ok in a corporate environment where you can run over to the admin to fix the server. For open source projects, my opinion and experience is that a repository only adds head-aches for some users. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. I know at least a couple of ASF projects which didn't notice a license problem by themselves and had to be pointed to it. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of the source (and binary) release, as well as maintain them in the repository; FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos to obtain and manage dependencies, but doesn't require the use of Maven for builds. http://ant.apache.org/ivy/ That said, personally I'm reasonably fond of Maven, though I do sometimes find the maze of plugins and options difficult to deal with and find managing its configuration challenging. I do really like the consistency and standardisation it brings to builds - if it's a Maven project, you know how to build and use it, you can figure out build issues immediately, you already know how the sources are structured, etc etc etc. I've come from the C/C++ world of autotools (autoconf/automake/libtool), CMake, and other nightmare build systems from hell ... so Maven is a real breath of fresh air - despite its flaws. In any case, I view this patch as being experimental, and am willing to maintain it. If after some time elapses I am the only user of it, then it could be removed. However, at present, there seems few negatives in commit it, particularly since it does not touch any other parts of the hierarchy. It'll also make it easier to maintain a Maven snapshot repository, which should improve user testing in real-world use of embedded fop significantly. I use in-progress code a *lot* more when there's a Maven snapshot repo availible for it, so I don't have to track svn and manually update the built jars periodically. If you're interested in running a snapshot repo, Sonatype Nexus may be worth looking into. -- Craig Ringer Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
Because I want to hear other opinions from the other committers first. So far, none of the others responded. And I've stated in the past I won't spend any more time on anything Maven-related, so I'm unlikely to process the patch myself. I won't veto the addition but I certainly won't spend any time maintaining it. On 07.09.2010 09:29:15 Glenn Adams wrote: ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well? regards, glenn On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. Introducing an external repository immediately adds a new dependency in form of the repository to the build which is one more point of failure. And how many times did a Maven/Ivy build download half the Internet just to build a small project? For a private project I started out using Ant+Ivy but I'm in the process of dropping the Ivy part again. And I've had the repository hand-maintained in a project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Repositories are probably ok in a corporate environment where you can run over to the admin to fix the server. For open source projects, my opinion and experience is that a repository only adds head-aches for some users. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. I know at least a couple of ASF projects which didn't notice a license problem by themselves and had to be pointed to it. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of the source (and binary) release, as well as maintain them in the repository; FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos to obtain and manage dependencies, but doesn't require the use of Maven for builds. http://ant.apache.org/ivy/ That said, personally I'm reasonably fond of Maven, though I do sometimes find the maze of plugins and options difficult to deal with and find managing its configuration challenging. I do really like the consistency and standardisation it brings to builds - if it's a Maven project, you know how to build and use it, you can figure out build issues immediately, you already know how the sources are structured, etc etc etc. I've come from the C/C++ world of autotools (autoconf/automake/libtool), CMake, and other nightmare build systems from hell ... so Maven is a real breath of fresh air - despite its flaws. In any case, I view this patch as being experimental, and am willing to maintain it. If after some time elapses I am the only user of it, then it could be removed. However, at present, there seems few negatives in commit it, particularly since it does not touch any other parts of the hierarchy. It'll also make it easier to maintain a Maven snapshot repository, which should improve user testing in real-world use of embedded fop significantly. I use in-progress code a *lot* more when there's a Maven snapshot repo availible for it, so I don't have to track svn and manually update the built jars periodically. If you're interested in running a snapshot repo, Sonatype Nexus may be worth looking into. -- Craig Ringer Jeremias Maerki Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
By the way, I live in a third world country (Philippines) with highly variable connectivity and usually get no more than 20-30kB/s for downloads. Furthermore, I don't have an IT infrastructure or servers, but am using an isolated Macbook Pro for my work. Yet, with all that, I have not had any particular trouble with maven dependency downloads. Regarding transitive dependency analysis and license verification, it seems that maven provides useful tools to audit this. If Apache applications of maven fail to pay attention to this information, then it isn't the fault of maven. In any case, I have not and am not proposing to substitute maven for ant. I only wish to share a useful build process with others that are comfortable with using maven. Those that are not can ignore this feature. Regards, G. On Tue, Sep 7, 2010 at 3:29 PM, Glenn Adams gl...@skynav.com wrote: ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well? regards, glenn On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. Introducing an external repository immediately adds a new dependency in form of the repository to the build which is one more point of failure. And how many times did a Maven/Ivy build download half the Internet just to build a small project? For a private project I started out using Ant+Ivy but I'm in the process of dropping the Ivy part again. And I've had the repository hand-maintained in a project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Repositories are probably ok in a corporate environment where you can run over to the admin to fix the server. For open source projects, my opinion and experience is that a repository only adds head-aches for some users. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. I know at least a couple of ASF projects which didn't notice a license problem by themselves and had to be pointed to it. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of the source (and binary) release, as well as maintain them in the repository; FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos to obtain and manage dependencies, but doesn't require the use of Maven for builds. http://ant.apache.org/ivy/ That said, personally I'm reasonably fond of Maven, though I do sometimes find the maze of plugins and options difficult to deal with and find managing its configuration challenging. I do really like the consistency and standardisation it brings to builds - if it's a Maven project, you know how to build and use it, you can figure out build issues immediately, you already know how the sources are structured, etc etc etc. I've come from the C/C++ world of autotools (autoconf/automake/libtool), CMake, and other nightmare build systems from hell ... so Maven is a real breath of fresh air - despite its flaws. In any case, I view this patch as being experimental, and am willing to maintain it. If after some time elapses I am the only user of it, then it could be removed. However, at present, there seems few negatives in commit it, particularly since it does not touch any other parts of the hierarchy. It'll also make it easier to maintain a Maven snapshot repository, which should improve user testing in real-world use of embedded fop significantly. I use in-progress code a *lot* more when there's a Maven snapshot repo availible for it, so I don't have to track svn and manually update the built jars periodically. If you're interested in running a snapshot repo, Sonatype Nexus may be worth looking into. -- Craig Ringer Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
That's reasonable. I wasn't asking you to personally commit it. I would commit it myself if I had the privileges, but am dependent on the good graces of other committers at present. Perhaps someone will volunteer. G. On Tue, Sep 7, 2010 at 3:42 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Because I want to hear other opinions from the other committers first. So far, none of the others responded. And I've stated in the past I won't spend any more time on anything Maven-related, so I'm unlikely to process the patch myself. I won't veto the addition but I certainly won't spend any time maintaining it. On 07.09.2010 09:29:15 Glenn Adams wrote: ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well? regards, glenn On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. Introducing an external repository immediately adds a new dependency in form of the repository to the build which is one more point of failure. And how many times did a Maven/Ivy build download half the Internet just to build a small project? For a private project I started out using Ant+Ivy but I'm in the process of dropping the Ivy part again. And I've had the repository hand-maintained in a project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Repositories are probably ok in a corporate environment where you can run over to the admin to fix the server. For open source projects, my opinion and experience is that a repository only adds head-aches for some users. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. I know at least a couple of ASF projects which didn't notice a license problem by themselves and had to be pointed to it. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of the source (and binary) release, as well as maintain them in the repository; FWIW, you can also achieve that with Apache Ivy, which uses the Maven repos to obtain and manage dependencies, but doesn't require the use of Maven for builds. http://ant.apache.org/ivy/ That said, personally I'm reasonably fond of Maven, though I do sometimes find the maze of plugins and options difficult to deal with and find managing its configuration challenging. I do really like the consistency and standardisation it brings to builds - if it's a Maven project, you know how to build and use it, you can figure out build issues immediately, you already know how the sources are structured, etc etc etc. I've come from the C/C++ world of autotools (autoconf/automake/libtool), CMake, and other nightmare build systems from hell ... so Maven is a real breath of fresh air - despite its flaws. In any case, I view this patch as being experimental, and am willing to maintain it. If after some time elapses I am the only user of it, then it could be removed. However, at present, there seems few negatives in commit it, particularly since it does not touch any other parts of the hierarchy. It'll also make it easier to maintain a Maven snapshot repository, which should improve user testing in real-world use of embedded fop significantly. I use in-progress code a *lot* more when there's a Maven snapshot repo availible for it, so I don't have to track svn and manually update the built jars periodically. If you're interested in running a snapshot repo, Sonatype Nexus may be worth looking into. -- Craig Ringer Jeremias Maerki Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On 7/09/2010 1:52 PM, Jeremias Maerki wrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. First: I'd like to note that none of the following is meant to sound like some kind of ra ra ra you should use maven and only maven, maven is the truth and the light. It's just a tool, and like all tools has things it's good for and things it's not so good for. That said, I've never had issues with remote repositories - I routinely use sonatype nexus (jboss) repos, Central, java.net, and a couple of private repositories. I guess it helps that once files are fetched by maven and cached in the local repository, that's it. Unless you change a dependency's version or use snapshot versions, there's no more network access. There's always the option of doing the same thing you currently do with ant - bundle copies of the dependencies in shipping versions or maintain a separate 3rd pty dependencies repo under version control. I guess I don't really see the difference. Here I keep a common repo under version control, but that's mostly to save download time on big files, and is exactly the same thing I do for non-Maven resources like JDK snapshots. It would insulate me a bit from transient failures in remote repositories, though. (I do wish that Maven would print a warning and use the last-downloaded -SNAPSHOT version if it didn't have network access and snapshot updates were enabled, though. It's the only area where connectivity requirements do cause me issues.) And how many times did a Maven/Ivy build download half the Internet just to build a small project? Generally only if it's misconfigured, or that small project uses plugins/libraries with a lot of dependencies. In the latter case, you're going to need to get them one way or the other. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Aaah. I don't use Eclipse - and given the nature of my experences with it when I've tried using it for something, I wouldn't be surprised by problems. I use NetBeans for most work, and the command line where convenient. I don't suppose you were relying on any SNAPSHOT version plugins or libraries? Because if you were and you had snapshot updates enabled (the default - unfortunately IMO) then I can certainly see it seeming like it wants to download the internet whenever you run a build. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. Now that can be a problem. Again, though, I'm not sure how different it is to a 3rd party library you use bundling libraries of unknown licensing as dependencies. Either way, you have to check. release Maven artifacts won't change dependencies without a version change, and you have to do that kind of checking whenever you update anything, maven-based or not. I can check out (or extract) FOP and build at least a basic version locally with no outside connection. I like that and would like it to stay that way. The same is true with Maven. It doesn't have to try to download the Internet, nor does it need 'net access for builds. I routinely do (re) builds on my laptop while disconnected. I have the required artifacts in my local ~/.m2 repository already, and that's all I need. If I was using an Ant project I'd have to have obtained the required dependencies to put on the classpath somehow; same deal. Whether I populate my ~/.m2 from Internet repositories, or check out a private pre-populated maven repo from version control, I still have to obtain it somehow. That said, I do find that the way it doesn't tend to include most of the core plugins in the initial Maven download - and therefore fetches them when you first do a build - to be annoying. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On 07.09.2010 09:56:00 Craig Ringer wrote: On 7/09/2010 1:52 PM, Jeremias Maerki wrote: Well, Ivy has one fundamental problem in common with Maven that many regard as a great feature: the repository. Numerous times, I couldn't get a Maven build to complete successfully because some artifact was temporarily or permanently unavailable. First: I'd like to note that none of the following is meant to sound like some kind of ra ra ra you should use maven and only maven, maven is the truth and the light. It's just a tool, and like all tools has things it's good for and things it's not so good for. I didn't take it that way. My apologies if I made that impression. I myself can't stand Maven. I can't speak for the whole FOP project. But see my last paragraph below for the reason I react so strongly when Maven is brought up. That said, I've never had issues with remote repositories - I routinely use sonatype nexus (jboss) repos, Central, java.net, and a couple of private repositories. I guess it helps that once files are fetched by maven and cached in the local repository, that's it. Unless you change a dependency's version or use snapshot versions, there's no more network access. It wasn't always like this. Maybe they improved on it in later version. I distinctively remember when I tried to compile Cocoon during the hackathon at ApacheCon Ireland 2006. I've had at least four Cocoon committers at the table to help me and I still spent a whole day unsuccessfully trying to compile it. Every time I ran Maven it failed in a different place. Undoubtedly, Maven has improved since then, but if I watch my colleagues struggling with Maven in a webapp project today, I can basically just pity them. There's always the option of doing the same thing you currently do with ant - bundle copies of the dependencies in shipping versions or maintain a separate 3rd pty dependencies repo under version control. I guess I don't really see the difference. That could solve the problem for users compiling the distribution but not those working off SVN. Here I keep a common repo under version control, but that's mostly to save download time on big files, and is exactly the same thing I do for non-Maven resources like JDK snapshots. It would insulate me a bit from transient failures in remote repositories, though. That's what I tried to do using Ivy. Sadly without luck. Ivy's resolver wasn't good enough and I didn't get help from the Ivy community. It was much easier to drop it than to try and fix the problem myself. Maybe Maven is better at this. Still, I prefer the flexibility of Ant with imports and macrodefs. (I do wish that Maven would print a warning and use the last-downloaded -SNAPSHOT version if it didn't have network access and snapshot updates were enabled, though. It's the only area where connectivity requirements do cause me issues.) And how many times did a Maven/Ivy build download half the Internet just to build a small project? Generally only if it's misconfigured, or that small project uses plugins/libraries with a lot of dependencies. In the latter case, you're going to need to get them one way or the other. My Eclipse's Maven and Ivy plug-ins are long uninstalled because of the trouble they caused. Aaah. I don't use Eclipse - and given the nature of my experences with it when I've tried using it for something, I wouldn't be surprised by problems. But even running mvn eclipse:eclipse didn't always give my a project setup that worked. :-( I use NetBeans for most work, and the command line where convenient. I don't suppose you were relying on any SNAPSHOT version plugins or libraries? Because if you were and you had snapshot updates enabled (the default - unfortunately IMO) then I can certainly see it seeming like it wants to download the internet whenever you run a build. Sometimes that could have been the case when working with third-party projects like Felix. But I think if you have to know such subtleties, that's a problem by itself if you're just trying to compile something. Another problem of an external repository is the lack of license management. ASF projects have clear requirements what kinds of dependencies are allowed. If you can't control transitive dependencies based on a license policy you're bound to run into a problem there. Now that can be a problem. Again, though, I'm not sure how different it is to a 3rd party library you use bundling libraries of unknown licensing as dependencies. Either way, you have to check. Yes, you have to check but you have everything under control locally and can then document the dependencies in a text file that makes it easy for users to verify a project against their own license policy. And a dependency upgrade will immediately show additional dependencies which gives you a trigger to check the licenses of the new depencendies, too. Glenn mentioned the license
Re: base 14 font kerning
Glenn Adams wrote: Hi Glenn/Jeremias, I've already implemented in my complex scripts work, so it will make it into trunk in due time. However, I think I'll leave the default setting as it is for the time being. Users can explicitly enable it via their config. We can take up the issue of whether to change the default at a future time. I do not like the idea of changing the default value of Kerning from off to on. The reason being that users who decide to upgrade their FOP version will suddenly find the appearance of their documents changing. Better to let users who are unsatisfied with the default inter character spacing to go and enable kerning than force users to regression test every document to make sure the changes to appearance is acceptable. Thanks, Chris G. On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki d...@jeremias-maerki.ch mailto:d...@jeremias-maerki.ch wrote: I think that is for historical reasons. When this was implemented (I think it was me) I guess we didn't want to change the layout behaviour for existing users. For a long time, kerning for base 14 fonts was not supported. http://svn.apache.org/viewvc?view=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=389086 You're right: this setting doesn't seem to be tied into the FontManagerConfigurator. It would be great if you added that. That said, I'm not sure if enabling that would be so bad. I guess I'm not opposed to it. On 06.09.2010 07:58:41 Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique is used to enable it during testing in one test case: layoutengine/standard-testcases/kerning_1_on.xml, by means of special code in org.apache.fop.layoutengine.TestEnvironment. However, there appears no way for a user to enable it via non-programmitc means. To support this (which I need in testing the new generalized position adjustments for text drawing), I'm adding a base14-kerning element to be placed in the top-level fop element in the FOP configuration file, e.g., fop ... base14-kerningtrue/base14-kerning ... /fop The rationale for making this a child of the top-level fop element is that the enable/disable state is presently maintained in the singleton FontManager instance, which is configured (in FontManagerConfigurator) from other top-level children of the fop element. For consistency, it my be better to enable base14 kerning by default, then allow a user to disable it using the above mechanism. However, I have not made this latter change (yet). Comments? G. Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On 7/09/2010 4:40 PM, Jeremias Maerki wrote: I guess we're in a religious dispute here, like PC vs. Mac. So we can't expect to reach a consensus. Well, certainly a discussion of preference. I know it gets religious for some Java folks, but myself I don't mind too much so long as nobody tries to force their choice on me. I can use Maven without having to care what others use or force it on them. I'm only weighing in on this discussion to say that I'd like the option for maven builds if it doesn't get in anyone else's way, and address some possible misunderstandings about maven. I like dealing with maven in projects because for me it is a known quantity and imposes some consistency on projects that I personally like. OTOH, I manage ok if a project doesn't use maven, at least so long as I don't have to wrangle the guts of its build system. Anyway, I won't to stand in the way if something is added to FOP that can help some users. [snip] just because Maven can't include a simple JAR that is not in a repository. Not strictly true. One option is to use scopesystem/scope with an explicit path to the jar. Maven doesn't have a wild-card include everything under lib/ though, and using system scope to fudge in local depencies is a bit of a hack. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies Usually what you'd do if you have a jar you want to use - but no repo or pom for it - is drop the jar you want to use into your local ~/m2/ (or wherever you keep your local repository, ie download cache) then declare a dependency on it in your pom.xml. This is within a repository but it's only your local repo, it doesn't involve any network access or anything except putting a file in a particular place. Maven will look for the dependency in a location defined by the repo layout. So if I declared dependency groupIdlocal/groupId artifactIdsomejar/artifactId version2.2/version /dependency ... then it'd look for local/somejar-2.2.jar within my local repository. If I put the jar where it should be found, no problem. I don't personally find that to be any worse than dropping everything in lib/ ... and I find it makes it a LOT easier in the long run to let mvn take care of the mess of secondary (transitive) dependencies involved in using things like Hibernate. (OK, so maven does whine annoyingly about not being able to find the pom.xml for the artifact, which bugs me - but it works fine nonetheless). But I consider Maven viral as we're seeing here. Due to its inflexibility, projects are almost forced to adopt it to keep everyone happy, I can't speak for the obsolete Maven 1.x, but that's not true of 2.x . To keep everyone happy it *does* help to publish artifacts to a maven repository (be it Central or somewhere else) but there's no need to get Maven anywhere near your builds if you don't want to, and there's no need for the people maintaining the project and doing the development work to have anything to do with pushing project releases to maven central. If you *do* want to create and push maven artifacts yourself but don't want to use Maven in builds, a Maven artifact can be created with the cp command and a text editor, or with an Ant task to spit out a suitable generated pom.xml . No biggie. You can use Maven builds with jars not created or managed with Maven, you can use Ant to produce Maven artifacts, and you can use Ant to consume Maven-produced artifacts. It doesn't really force anything on you at all. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
Re: base 14 font kerning
Agreed. That is why I thought it best not to change that, while still adding the ability for the user to configure it. G. On Tue, Sep 7, 2010 at 5:00 PM, Chris Bowditch bowditch_ch...@hotmail.comwrote: Glenn Adams wrote: Hi Glenn/Jeremias, I've already implemented in my complex scripts work, so it will make it into trunk in due time. However, I think I'll leave the default setting as it is for the time being. Users can explicitly enable it via their config. We can take up the issue of whether to change the default at a future time. I do not like the idea of changing the default value of Kerning from off to on. The reason being that users who decide to upgrade their FOP version will suddenly find the appearance of their documents changing. Better to let users who are unsatisfied with the default inter character spacing to go and enable kerning than force users to regression test every document to make sure the changes to appearance is acceptable. Thanks, Chris G. On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki d...@jeremias-maerki.chmailto: d...@jeremias-maerki.ch wrote: I think that is for historical reasons. When this was implemented (I think it was me) I guess we didn't want to change the layout behaviour for existing users. For a long time, kerning for base 14 fonts was not supported. http://svn.apache.org/viewvc?view=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=389086 You're right: this setting doesn't seem to be tied into the FontManagerConfigurator. It would be great if you added that. That said, I'm not sure if enabling that would be so bad. I guess I'm not opposed to it. On 06.09.2010 07:58:41 Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique is used to enable it during testing in one test case: layoutengine/standard-testcases/kerning_1_on.xml, by means of special code in org.apache.fop.layoutengine.TestEnvironment. However, there appears no way for a user to enable it via non-programmitc means. To support this (which I need in testing the new generalized position adjustments for text drawing), I'm adding a base14-kerning element to be placed in the top-level fop element in the FOP configuration file, e.g., fop ... base14-kerningtrue/base14-kerning ... /fop The rationale for making this a child of the top-level fop element is that the enable/disable state is presently maintained in the singleton FontManager instance, which is configured (in FontManagerConfigurator) from other top-level children of the fop element. For consistency, it my be better to enable base14 kerning by default, then allow a user to disable it using the above mechanism. However, I have not made this latter change (yet). Comments? G. Jeremias Maerki
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On Tue, Sep 7, 2010 at 4:40 PM, Jeremias Maerki d...@jeremias-maerki.chwrote:
Due to its inflexibility, projects are
almost forced to adopt it to keep everyone happy, just because Maven
can't include a simple JAR that is not in a repository.
Perhaps this has changed, because while I was debugging a problem with
getting the junit tests to run, I found it necessary to temporarily exclude
certain maven dependency generated JARs and explicitly include a local
non-repository JAR. This was possible in the surefire plugin by using:
classpathDependencyExcludes
classpathDependencyExcludeorg.apache.xmlgraphics:batik-*/classpathDependencyExclude
/classpathDependencyExcludes
additionalClasspathElements
additionalClasspathElement${fop.lib.dir}/batik-all-1.7.jar
/additionalClasspathElement
/additionalClasspathElements
I'll admit this is a bit verbose expression-wise, but it did the job.
Perhaps some of your bad experiences derive from its growing pains. On the
other hand, now that I am looking, I don't see the same configuration
options on the compiler plugin. This kind of inconsistency is one I find in
ant as well; e.g., support for if/unless clauses seems particularly
inconsistent in ant tasks. For example, the lack of if/unless on the echo
task requires all kinds of strange work arounds.
G.
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
I want to inject one fact, and one collection of experience, but I'm still not trying to talk anyone into anything. Fact: the Apache Software Foundation maintains a comprehensive maven infrastructure. There is a repository manager, there are standard parent POMS. All projects that use Maven get the advantage of it. Experience: I commit on CXF, XmlSchema, and Mahout (all using Maven), and we use Maven internally at my day job. I've found the dependency system to be a great advantage. I've never seen a message to one of the mailing lists complaining that connectivity issues were making people miserable. Why? You need connectivity to update from svn. Then you need connectivity to run a build. And once you've run a build, you have all the maven stuff, and you're done until someone changes the dependencies. Keep in mind that, at a project like FOP, the goal is to produce code that other people can use and integrate. 'Central' is a discipline. If the code does not work with commonly available versions of its dependencies, that probably means that someone, somewhere, is going to have a lot of trouble using it. If Maven downloads a truckload of stuff as a result of one of your dependencies, then you have a truckload of dependencies. (Well, OK, an oversimplification. Some things have enthusiastic dependency graphs which can be pruned.) As previously noted here, Maven itself likes to download a lot of Maven. In the past, there was a design error in Maven in which it would update its internal components 'behind your back'. Aside from removing predictability from the build, this means that you could need more connectivity less predictably. Nowadays, the versions of the pieces are fixed unless you move them. So, once you've built something once, you can build --offline until and unless you decide to change a dependency. Other than dependency management, the primary virtue of Maven is the lack of build configuration. Sadly, it's bimodal: there's hardly any, and then there's much too much. The cure for that is sometimes a new maven plugin.
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On 7/09/2010 7:22 PM, Benson Margulies wrote: I've never seen a message to one of the mailing lists complaining that connectivity issues were making people miserable. Why? You need connectivity to update from svn. Then you need connectivity to run a build. ... and to get any libraries or other dependencies if you don't already have them locally. Just like with Maven. BTW, I suspect many people who have trouble with Maven's apparent net access requirements don't know about mvn dependency:go-offline and mvn -o for offline operation that doesn't try to check snapshot repos etc. mvn -o is kind of hard to miss, but people seem to anyway; the go-offline goal is rather less obvious but really handy. Meh. I'd like to see maven support in fop, but I'm not working with fop's code much at all so it's hardly something I can claim any say in. Maybe I should bash together an ant task to spit out Maven artifacts after a build, though, to make it easier to use fop's existing build tools to integrate with maven. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On Tue, Sep 07, 2010 at 03:44:37PM +0800, Glenn Adams wrote: That's reasonable. I wasn't asking you to personally commit it. I would commit it myself if I had the privileges, but am dependent on the good graces of other committers at present. Perhaps someone will volunteer. On Tue, Sep 7, 2010 at 3:42 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Because I want to hear other opinions from the other committers first. So far, none of the others responded. And I've stated in the past I won't spend any more time on anything Maven-related, so I'm unlikely to process the patch myself. I won't veto the addition but I certainly won't spend any time maintaining it. On 07.09.2010 09:29:15 Glenn Adams wrote: ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well? I would be happy to accommodate FOP developers who prefer Maven as a build tool. However, as Jeremias pointed out, maintenance is a problem. At the moment we do have ant tasks that build a maven bundle, and a wiki page telling us how to deploy the maven bundle. But that committer is no longer around and has not responded to my requests for assistance with the maven deployment. And his constructs no longer work because the ASF has changed its repository structure and/or instructions. Therefore we now have a problem. Your patch is a good piece of work, for which thanks. But with it we will be good as long as you are willing to maintain it, or as long as the maven environment is not changing. After that, its existence makes a false promise, and none of the committers may be able to remedy or even notice that. As Jeremias already mentioned, for enterprise developers maintaining a maven build framework may be of advantage, but for developers who are on their own and are working on projects with a manageable set of dependencies, the step to maven may not pay off. I realize you did it, but that depends on a personal preference to go such roads or not. When some developers use such a maven build and others FOP's ant build, which guarantee do we have that both use the same dependency versions? Craig Ringer wrote: If you *do* want to create and push maven artifacts yourself but don't want to use Maven in builds, a Maven artifact can be created with the cp command and a text editor, or with an Ant task to spit out a suitable generated pom.xml . No biggie. It is no biggie if you understand the maven world. If you do not know it, there is a world of questions: What is a bundle, what is nexus, what is sonatype, what is a central repository, how does staging work, what are the elements of a pom file, what is maven about, what are all those repositories, etc. If a project is willing to contribute their jar files to a maven repository, but otherwise does not want to take time to understand maven, the above questions remain unanswered, and the task of deployment is really a big problem. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support
On Tue, Sep 07, 2010 at 08:47:16PM +0800, Craig Ringer wrote: Meh. I'd like to see maven support in fop, but I'm not working with fop's code much at all so it's hardly something I can claim any say in. Maybe I should bash together an ant task to spit out Maven artifacts after a build, though, to make it easier to use fop's existing build tools to integrate with maven. Please, see my efforts to complete the ant target for maven artifacts in xmlgraphics-commons, http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/build.xml?view=markup, line 655, and the wiki page on maven deployment, http://wiki.apache.org/xmlgraphics/Maven, and suggest improvements. When I am convinced that this works, I will make similar changes to the fop build file. Or send us a patch to the build file. Simon -- Simon Pepping home page: http://www.leverkruid.eu
