Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Benson Margulies]

Please, please, please do not create a new ant task from scratch :-).

Simon, I will have a look presently and see if I have any assistance to
offer.

On Tue, Sep 7, 2010 at 9:15 AM, Simon Pepping wrote:

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

DO NOT REPLY [Bug 49885] Varying page breaks with multi columned region-body

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=49885

Jeremias Maerki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jeremias Maerki  2010-09-07 09:47:10 
EDT ---
Fixed in http://svn.apache.org/viewvc?rev=993357&view=rev
Thanks for the test case.

-- 
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: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Simon Pepping]

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

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Simon Pepping]

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

[Craig Ringer]

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

[Benson Margulies]

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

[Glenn Adams]

On Tue, Sep 7, 2010 at 4:40 PM, Jeremias Maerki wrote:

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


  
org.apache.xmlgraphics:batik-*


  ${fop.lib.dir}/batik-all-1.7.jar



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 
task requires all kinds of strange work arounds.

G.

Re: base 14 font kerning

[Glenn Adams]

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

> 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>> 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=revision&revision=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.,
>> >
>> > 
>> >   ...
>> >   true
>> >   ...
>> > 
>> >
>> > 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

[Craig Ringer]

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



  local
  somejar
  2.2


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

[Chris Bowditch]

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 > 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=revision&revision=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.,
 >
 > 
 >   ...
 >   true
 >   ...
 > 
 >
 > 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

[Jeremias Maerki]

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 th

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Craig Ringer]

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

[Glenn Adams]

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

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

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Glenn Adams]

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

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

[Jeremias Maerki]

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

[Glenn Adams]

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

DO NOT REPLY [Bug 49835] Wrong page break with 2 columned region and tables

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=49835

--- Comment #3 from Jeremias Maerki  2010-09-07 03:02:34 
EDT ---
Created an attachment (id=25995)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25995)
Reduced test case

I've reduced the test case to the minimum (attached). It appears to be the same
problem I've noticed when I tried to fix column balancing (Bug 49801). It
appears to be triggered by the preceding span="all". Something about that
algorithm restart after the span change seems to be fishy.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.