DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41995>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41995





------- Additional Comments From jeremias@apache.org  2007-04-04 06:57 -------
Pete, I took a look at your patch. I must say, I'm not happy with the approach
you've taken. You've copied many classes from Barcode4J, adjusted some of them
and put them in a new package under the FOP source tree. This is a maintenance
nightmare and the legal paperwork also needs to be considered.

That aside, I'm not comfortable with the bcoca package having a dependency into
the classes coming from Barcode4J. From an architecture perspective, it would be
much cleaner to simply provide the object model of the BCOCA functionality in
the bcoca package and then fill that from the Barcode extension. Like we do it
for formats like PDF, PostScript and RTF, I'd prefer to keep that pattern,
because that makes it possible to use the AFP code outside the FOP context, too.
Until now, that pattern was preserved. The package o.a.fop.render.afp.modca had
only dependencies into:
- o.a.fop.render.afp.exceptions
- o.a.fop.render.afp.fonts
- o.a.fop.render.afp.tools
- o.a.commons.logging

With your patch, o.a.fop.render.afp.bcoca and the forked Barcode4J classes are
added. Ideally, the modca package wouldn't even have a dependency into bcoca.
Right now, there's a circular dependency in your patch.

I have a proposal: Let's reuse (and adapt if necessary) Barcode4J and build a
cleaner dependency tree. Let's rid the bcoca package of references to Barcode4J
classes and only concentrate on the object model there. In a second step, let's
extend the FOP extension in Barcode4J to support native AFP barcodes. It's more
or less what I saw as the ideal solution in the first place but since you
introduced so many aspects from Barcode4J I think this is the right solution.
I can offer you some help with that. I've already locally removed all the forked
classes and started to correct the remaining issues. I would be comfortable with
just applying the part of the patch with the BCOCA object model after I've done
some changes. We can then go from there.

Please note that we once talked about bundling Barcode4J with FOP. We could take
this as an additional incentive to actually do it.

WDYT?

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