You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2011/01/17 14:18:27 UTC
Improving the build and adjusting to changed dependencies
Working towards preparing the color branch for a merge into trunk I
noticed how much code duplication there is in the Ant build and how many
hard-coded JAR names are in manifest Class-Path entries or security
policy files. Also, the code to create the Maven artifacts seems to be
very similar to the code to create the regular JARs. I think that can
easily be merged by the use of Ant's macrodef feature.
Batik currently has an Ant 1.6.5 in lib\build. I would suggest that this
be removed in favor of an Ant installed on the developer's machine. We
don't have any negative experience on this in FOP that I can remember.
I'm always building with my local Ant installation rather than the
build.bat from Batik anyway. And the crimson.jar in lib\build is by now
an ancient relic. ;-)
I've written some code that gets rid of the need for the Class-Path
entry in the various application JARs by using some class loader magic.
I've done something similar for FOP and that seems to work. I don't
really like the hard-coded JAR names in "Class-Path". The class loader
"magic" also allows to replace (or add) certain JARs without a rebuild.
I don't know, yet, if that will also work with the Mac-specific build
target.
I'm not sure, yet, how best to handle the policy files. There's quite
some moving and copying going on there. I found it difficult to find all
the places where I can find references to the various JAR names of all
used dependencies. Maybe some XML+XSLT (i.e. more code generation) would
make things easier here.
Finally, I would also like to look into the image codec issue. With XGC
added as new dependency it would make sense to do a final sync between
the codecs in Batik and XGC and then remove the ones in Batik. During
that task I could see if I can resolve the OpenJDK issue without losing
sight of the finer issues with PNG. But since the color branch work is
already on my own time I won't promise anything on this just yet.
If any of you have any thoughts on the above, I'd love to hear them.
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Improving the build and adjusting to changed dependencies
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thomas, Cameron, thanks for your feedback!
On 17.01.2011 21:52:28 Cameron McCormack wrote:
> I agree with much of what Thomas says.
>
> Jeremias Märki:
> > > Batik currently has an Ant 1.6.5 in lib\build. I would suggest that
> > > this be removed in favor of an Ant installed on the developer's
> > > machine. We don't have any negative experience on this in FOP that
> > > I can remember. I'm always building with my local Ant installation
> > > rather than the build.bat from Batik anyway. And the crimson.jar in
> > > lib\build is by now an ancient relic. ;-)
>
> Thomas DeWeese:
> > Personally I'm fond of a more or less standalone dev tree (we
> > do have a dependency on the JDK), but I recognize that this is not the
> > typical approach taken these days.
>
> Yeah, I think for a Java developer not to have ant installed would be
> atypical. I dont think it is too much to ask for them to have it (or
> to get it) these days.
C/C++ devs on Unix also have to have "make" installed, just to give
another example.
> Also I dont know if its possible to have a JDK without an XML parser
> in it any more. So if crimson could go away, thatd be great. Actually
> Im not sure why we cant just use the bundled Xerces
Maybe Ant 1.6.5 is so old that it doesn't support JAXP, yet. But I
haven't checked. But yes, since we're moving to Java 1.5, there is
always an XML parser. So that also ask the question if the direct
dependency on Xerces is still a good idea. But that's for another day.
So, I gather you're not opposed to remove Ant, Thomas?
> > > I've written some code that gets rid of the need for the Class-Path
> > > entry in the various application JARs by using some class loader
> > > magic. I've done something similar for FOP and that seems to work.
> > > I don't really like the hard-coded JAR names in "Class-Path". The
> > > class loader "magic" also allows to replace (or add) certain JARs
> > > without a rebuild. I don't know, yet, if that will also work with
> > > the Mac-specific build target.
> >
> > My main requirement here is that you be able to double click
> > on the various 'application' jars and have them run. So as long as the
> > classloader stuff works with that it sounds fine.
That is the idea. I like double-clicking JARs, too.
> I think the batik-squiggle.jar is the only one that will do something
> useful if you double click on it (i.e. without passing it any command
> line arguments). That one and the other application jars do make it a
> bit easier to run the applications, so I agree we should keep them or
> something like them. Without them, the user needs to set up the
> classpath correctly and know what the main class name is. (Plus they
> also house the resources for the application.)
>
> I think as long as it is no more difficult for a user to run Squiggle,
> or the rasterizer, or the ttf2svg tool, then I am fine with whatever
> approach is taken here.
It will surely take some testing, especially on MacOSX (since I don't
have that). But for the user, I don't expect anything to change. What I
would like to achieve is to make life easier for us maintaining these
app JARs.
> What is the approach typically taken in other Java projects? Do they
> tend to always rely on shell scripts and batch files for launching the
> application?
FOP has been using shell scripts for ages and that usually works ok.
Older Windows batch files had some ugly limitations that didn't allow to
gather all JARs from a directory. We've been able to get rid of that
which makes things easier. Most Apache projects I know use a combination
of a Windows batch and a Unix shell script for starting. A few Java
projects I know are using native wrapper applications but that's not
wide-spread. See:
http://www.excelsior-usa.com/articles/java-to-exe.html
IMO, executable JAR files are good for double-clicking, but for
command-line usage, I actually prefer shell scripts, because they can
more easily pickup environment variables. Example:
> ./fop.sh -fo test.fo -pdf out.pdf
> $JAVA_HOME/bin/java -jar build/fop.jar -fo test.fo -pdf out.pdf
Both lines do the same but the shell script is less to deal with in this
case.
> BTW, when I write my own applications that use Batik, it always annoys
> me a little that I have to add all of the jars in lib/ to my classpath
> (or to work out exactly which ones I need). Is there any way to make
> this simpler?
See:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop?view=co
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop.cmd?view=co
The Unix script can be simplified if things like Cygwin compatibility
are not important. Both scripts scan a directory and add all JARs to the
classpath.
Or you wait until I commit my command-line tools for Batik which
contains an AppStarterUtil class that handles the dynamic class path
setup inside the JVM. Then you're back to easily doing "java -jar
myjar.jar". With AppStarterUtil, you create a very small starter class
like this:
public class MainDynamic {
public static void main(String[] args) {
AppStarterUtil.startApp(MainDynamic.class, args);
}
}
This assumes there is a "Main" class in the same package (i.e.
"MainDynamic" minus "Dynamic"). The original Main class remains
untouched. You'd have to adjust AppStarterUtil only minimally for
non-Batik applications.
> > > I'm not sure, yet, how best to handle the policy files. There's
> > > quite some moving and copying going on there. I found it difficult
> > > to find all the places where I can find references to the various
> > > JAR names of all used dependencies. Maybe some XML+XSLT (i.e. more
> > > code generation) would make things easier here.
> >
> > This is where I start to get concerned. Unlike FOP there is
> > a strong possability that Batik may be used to surf "the web". This
> > means that security needs to be taken extremely seriously. So anything
> > that touches the current security framework needs lots of review.
>
> Agreed. Although I know the way the policy files are generated in the
> build file is kind of convoluted.
That's why I brought it up. We'll have to do some careful testing there.
But if we can get rid of the manual Class-Path entries that's already an
improvement. So the security policies can be a step two.
> > > Finally, I would also like to look into the image codec issue. With XGC
> > > added as new dependency it would make sense to do a final sync between
> > > the codecs in Batik and XGC and then remove the ones in Batik. During
> > > that task I could see if I can resolve the OpenJDK issue without losing
> > > sight of the finer issues with PNG.
> >
> > This has always been the stated goal that has just been more
> > trouble than it has been worth in the past. I suspect that is now
> > changing (especially given the developing issues in the Java community
> > process area).
Probably not as much trouble as simply a lot of work without much hard
benefit.
> What is the OpenJDK issue? That it doesnt include the com.sun codecs?
Yes.
> > > But since the color branch work is already on my own time I won't
> > > promise anything on this just yet.
> >
> > Thanks a lot, for looking at this stuff...
>
> Yes, thanks Jeremias! Those daily gump messages do get me down, so if
> you are able to find the time to resolve the codec issue that would make
> me happy. :-)
I'll try hard.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Improving the build and adjusting to changed dependencies
Posted by Cameron McCormack <ca...@mcc.id.au>.
I agree with much of what Thomas says.
Jeremias Märki:
> > Batik currently has an Ant 1.6.5 in lib\build. I would suggest that
> > this be removed in favor of an Ant installed on the developer's
> > machine. We don't have any negative experience on this in FOP that
> > I can remember. I'm always building with my local Ant installation
> > rather than the build.bat from Batik anyway. And the crimson.jar in
> > lib\build is by now an ancient relic. ;-)
Thomas DeWeese:
> Personally I'm fond of a more or less standalone dev tree (we
> do have a dependency on the JDK), but I recognize that this is not the
> typical approach taken these days.
Yeah, I think for a Java developer not to have ant installed would be
atypical. I don’t think it is too much to ask for them to have it (or
to get it) these days.
Also I don’t know if it’s possible to have a JDK without an XML parser
in it any more. So if crimson could go away, that’d be great. Actually
I’m not sure why we can’t just use the bundled Xerces…
> > I've written some code that gets rid of the need for the Class-Path
> > entry in the various application JARs by using some class loader
> > magic. I've done something similar for FOP and that seems to work.
> > I don't really like the hard-coded JAR names in "Class-Path". The
> > class loader "magic" also allows to replace (or add) certain JARs
> > without a rebuild. I don't know, yet, if that will also work with
> > the Mac-specific build target.
>
> My main requirement here is that you be able to double click
> on the various 'application' jars and have them run. So as long as the
> classloader stuff works with that it sounds fine.
I think the batik-squiggle.jar is the only one that will do something
useful if you double click on it (i.e. without passing it any command
line arguments). That one and the other application jars do make it a
bit easier to run the applications, so I agree we should keep them or
something like them. Without them, the user needs to set up the
classpath correctly and know what the main class name is. (Plus they
also house the resources for the application.)
I think as long as it is no more difficult for a user to run Squiggle,
or the rasterizer, or the ttf2svg tool, then I am fine with whatever
approach is taken here.
What is the approach typically taken in other Java projects? Do they
tend to always rely on shell scripts and batch files for launching the
application?
BTW, when I write my own applications that use Batik, it always annoys
me a little that I have to add all of the jars in lib/ to my classpath
(or to work out exactly which ones I need). Is there any way to make
this simpler?
> > I'm not sure, yet, how best to handle the policy files. There's
> > quite some moving and copying going on there. I found it difficult
> > to find all the places where I can find references to the various
> > JAR names of all used dependencies. Maybe some XML+XSLT (i.e. more
> > code generation) would make things easier here.
>
> This is where I start to get concerned. Unlike FOP there is
> a strong possability that Batik may be used to surf "the web". This
> means that security needs to be taken extremely seriously. So anything
> that touches the current security framework needs lots of review.
Agreed. Although I know the way the policy files are generated in the
build file is kind of convoluted.
> > Finally, I would also like to look into the image codec issue. With XGC
> > added as new dependency it would make sense to do a final sync between
> > the codecs in Batik and XGC and then remove the ones in Batik. During
> > that task I could see if I can resolve the OpenJDK issue without losing
> > sight of the finer issues with PNG.
>
> This has always been the stated goal that has just been more
> trouble than it has been worth in the past. I suspect that is now
> changing (especially given the developing issues in the Java community
> process area).
What is the OpenJDK issue? That it doesn’t include the com.sun codecs?
> > But since the color branch work is already on my own time I won't
> > promise anything on this just yet.
>
> Thanks a lot, for looking at this stuff...
Yes, thanks Jeremias! Those daily gump messages do get me down, so if
you are able to find the time to resolve the codec issue that would make
me happy. :-)
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Improving the build and adjusting to changed dependencies
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 01/17/2011 08:18:27 AM:
> Batik currently has an Ant 1.6.5 in lib\build. I would suggest that this
> be removed in favor of an Ant installed on the developer's machine. We
> don't have any negative experience on this in FOP that I can remember.
> I'm always building with my local Ant installation rather than the
> build.bat from Batik anyway. And the crimson.jar in lib\build is by now
> an ancient relic. ;-)
Personally I'm fond of a more or less standalone dev tree (we do
have a dependency on
the JDK), but I recognize that this is not the typical approach taken
these days.
> I've written some code that gets rid of the need for the Class-Path
> entry in the various application JARs by using some class loader magic.
> I've done something similar for FOP and that seems to work. I don't
> really like the hard-coded JAR names in "Class-Path". The class loader
> "magic" also allows to replace (or add) certain JARs without a rebuild.
> I don't know, yet, if that will also work with the Mac-specific build
> target.
My main requirement here is that you be able to double click on
the various 'application'
jars and have them run. So as long as the classloader stuff works with
that it sounds fine.
> I'm not sure, yet, how best to handle the policy files. There's quite
> some moving and copying going on there. I found it difficult to find all
> the places where I can find references to the various JAR names of all
> used dependencies. Maybe some XML+XSLT (i.e. more code generation) would
> make things easier here.
This is where I start to get concerned. Unlike FOP there is a
strong possability that Batik
may be used to surf "the web". This means that security needs to be taken
extremely seriously.
So anything that touches the current security framework needs lots of
review.
> Finally, I would also like to look into the image codec issue. With XGC
> added as new dependency it would make sense to do a final sync between
> the codecs in Batik and XGC and then remove the ones in Batik. During
> that task I could see if I can resolve the OpenJDK issue without losing
> sight of the finer issues with PNG.
This has always been the stated goal that has just been more
trouble than it has been
worth in the past. I suspect that is now changing (especially given the
developing issues in the
Java community process area).
> But since the color branch work is already on my own time I won't
> promise anything on this just yet.
Thanks a lot, for looking at this stuff...
Thomas DeWeese | CDG Advanced Development |
Eastman Kodak Company | 343 State Street | Rochester, NY 14650-0128 |
Thomas.DeWeese@Kodak.com | 585 724-0294 |
www.kodak.com
Re: Improving the build and adjusting to changed dependencies
Posted by Helder Magalhães <he...@gmail.com>.
> [...] I was preparing an upgrade Ant to 1.7.1 (I memory doesn't
> fail, it's the latest version compatible with Java 1.4 but I need to
> double check this).
Correction: I was thinking about upgrading to Ant 1.7.1 as it was the
last version to support Java 1.3 (the minimum supported Java version,
up to a while ago). I guess we're in the process of moving to Java 1.5
[2] (although 1.4 is apparently the current minimum for Batik, AFAIK),
so read my upgrade to "Ant 1.7.1" as to the "Ant's latest release".
:-)
Cheers,
Helder
[1] http://ant.apache.org/faq.html#java-version
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=46434#c6
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Improving the build and adjusting to changed dependencies
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hey Helder
On 12.02.2011 16:32:23 Helder Magalhães wrote:
> Hi Jeremias and everyone,
>
> Sorry for the delay in answering, I did notice your
> build-simplification branch creation but was too overflow to keep
> up...
No apologies required.
>
> > Working towards preparing the color branch for a merge into trunk I
> > noticed how much code duplication there is in the Ant build and how many
> > hard-coded JAR names are in manifest Class-Path entries or security
> > policy files.
>
> I got a few minor fixes for the builld.xml file. Should I commit them
> to the trunk?
Absolutely. Don't feel blocked by anything I announced to do but still
haven't done. ;-)
>
> > Batik currently has an Ant 1.6.5 in lib\build. I would suggest that this
> > be removed in favor of an Ant installed on the developer's machine. We
> > don't have any negative experience on this in FOP that I can remember.
> > I'm always building with my local Ant installation rather than the
> > build.bat from Batik anyway.
>
> I guess it's fair to assume a developer to install Ant. In the
> meantime, I was preparing an upgrade Ant to 1.7.1 (I memory doesn't
> fail, it's the latest version compatible with Java 1.4 but I need to
> double check this).
>
> In the meantime, I do like the convenience of a build script. Unless
> the Ant-equivalent commands are easy enough to memorize, of course.
> ;-)
>
>
> > And the crimson.jar in lib\build is by now
> > an ancient relic. ;-)
>
> This is where one needs to have some care. I'm also preparing a few
> fixes for the build scripts of "contrib/rasterizertask" which were
> broken for a similar reason (a Java parser unavailable and reference
> to crimson was broken).
>
>
> > If any of you have any thoughts on the above, I'd love to hear them.
>
> What do you think? Should I commit my stuff to the trunk ASAP (as bugs
> are fixed) and integration will be performed afterward or should I try
> to integrate applicable stuff in the branch already? (I'd vote for the
> first approach!)
I can always merge into the build branch. Just do what you think is
useful.
>
> > Thanks,
> > Jeremias Maerki
>
> Thank you very much for all the hard work in getting us rid of those
> broken build nagging messages! :-)
Hold that thought until I've really gotten rid of the com.sun problem.
;-)
> Cheers,
> Helder
>
>
> --
> Helder "Lthere" Magalhães
> http://heldermagalhaes.com/
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Improving the build and adjusting to changed dependencies
Posted by Helder Magalhães <he...@gmail.com>.
Hi Jeremias and everyone,
Sorry for the delay in answering, I did notice your
build-simplification branch creation but was too overflow to keep
up...
> Working towards preparing the color branch for a merge into trunk I
> noticed how much code duplication there is in the Ant build and how many
> hard-coded JAR names are in manifest Class-Path entries or security
> policy files.
I got a few minor fixes for the builld.xml file. Should I commit them
to the trunk?
> Batik currently has an Ant 1.6.5 in lib\build. I would suggest that this
> be removed in favor of an Ant installed on the developer's machine. We
> don't have any negative experience on this in FOP that I can remember.
> I'm always building with my local Ant installation rather than the
> build.bat from Batik anyway.
I guess it's fair to assume a developer to install Ant. In the
meantime, I was preparing an upgrade Ant to 1.7.1 (I memory doesn't
fail, it's the latest version compatible with Java 1.4 but I need to
double check this).
In the meantime, I do like the convenience of a build script. Unless
the Ant-equivalent commands are easy enough to memorize, of course.
;-)
> And the crimson.jar in lib\build is by now
> an ancient relic. ;-)
This is where one needs to have some care. I'm also preparing a few
fixes for the build scripts of "contrib/rasterizertask" which were
broken for a similar reason (a Java parser unavailable and reference
to crimson was broken).
> If any of you have any thoughts on the above, I'd love to hear them.
What do you think? Should I commit my stuff to the trunk ASAP (as bugs
are fixed) and integration will be performed afterward or should I try
to integrate applicable stuff in the branch already? (I'd vote for the
first approach!)
> Thanks,
> Jeremias Maerki
Thank you very much for all the hard work in getting us rid of those
broken build nagging messages! :-)
Cheers,
Helder
--
Helder "Lthere" Magalhães
http://heldermagalhaes.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org