You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by William Uther <wi...@cs.cmu.edu> on 2000/02/22 18:30:24 UTC
Re: Platform specific code (was: Meta-info on Mac)
--On Tue, Feb 22, 2000 1:02 PM +0100 Stefano Mazzocchi <st...@apache.org>
wrote:
> sometimes devs don't have all the free time they'd like to :(
I understand. Believe me, I understand. :)
>> > I don't want to have dependencies on stuff like that.
>> >
>> > Can't you use reflection to instance the classes?
>>
>> Ok. I'll rewrite it with reflection and repost it. Given that the other
>> would compile and run fine on all platforms I didn't bother before.
>
> As a standard design pattern and development guideline, ant should not
> depend on packages for compilation that are platform dependent. Say I
> want to have a task that sets the windows registry, I use reflection.
> Say I want a task for compilation dependencies that uses another
> packages and that is redistributable, then yes, it's fine for me...
> we'll make the build.xml file work around its absence, if required.
What do you mean by 'platform dependant'? Do you mean 'This only works on
one platform', or 'This is only needed on one plaform'? In this case it
seems you mean the second definition - I originally assumed the first.
It is a little annoying to use reflection for the whole thing. How does
this setup look:
Add a package: org.apache.tools.ant.platform
with a sub-package: org.apache.tools.ant.platform.mac
add an interface
interface org.apache.tools.ant.argRunnable {
Object run(Object[] args);
}
modify build.xml to exclude the platform package. Add extra rules to
comile the individual platforms:
<target name="compile" depends="prepare">
<mkdir dir="${build.classes}"/>
<javac srcdir="${src.dir}"
destdir="${build.classes}"
excludes="**/platform/**"
classpath="${classpath}"
debug="on"
deprecation="on"
/>
</target>
<target name="mac" depends="compile">
<javac srcdir="${src.dir}"
destdir="${build.classes}"
includes="**/platform/mac/**"
classpath="${classpath}"
debug="on"
deprecation="on"
/>
</target>
Then in the main code you can try to load the appropriate
platform-dependant class, make a new argRunnable instance and call it.
Most of the plaform dependant code goes into the argRunnable instance and
doesn't have to use reflection. This gives you compile-time type checking,
etc.
> (BTW, have you guys looked at javadep?)
No, I hadn't. I just went searching for it and found:
<http://ptolemy.eecs.berkeley.edu/~cxh/java/javadepend/>
and
<http://www.cs.McGill.CA/~stever/software/JavaDeps/>
It looks like both of these process the source to get the dependancies.
Arnout Kuiper's method of looking in the .class files looks cool too.
later,
\x/ill :-}
RE: Platform specific code (was: Meta-info on Mac)
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, 23 February 2000 5:09
> To: ant-dev@jakarta.apache.org
> Subject: Re: Platform specific code (was: Meta-info on Mac)
>
>
> William Uther wrote:
> >
> >
> > No, I hadn't. I just went searching for it and found:
> >
> > <http://ptolemy.eecs.berkeley.edu/~cxh/java/javadepend/>
> >
> > and
> >
> > <http://www.cs.McGill.CA/~stever/software/JavaDeps/>
> >
> > It looks like both of these process the source to get the dependancies.
> > Arnout Kuiper's method of looking in the .class files looks cool too.
>
> to be honest, I didn't quite get Arnout's idea... :/
>
When a Java class references another class (a dependency), the class file's
constant pool will have a constant pool entry for the referred class. It is
possible to read the constant pool entries and thereby determine the
dependencies. I would guess that parsing the source is generally harder :-)
Conor
Re: Platform specific code (was: Meta-info on Mac)
Posted by Stefano Mazzocchi <st...@apache.org>.
William Uther wrote:
>
> --On Tue, Feb 22, 2000 1:02 PM +0100 Stefano Mazzocchi <st...@apache.org>
> wrote:
>
> > sometimes devs don't have all the free time they'd like to :(
>
> I understand. Believe me, I understand. :)
>
> >> > I don't want to have dependencies on stuff like that.
> >> >
> >> > Can't you use reflection to instance the classes?
> >>
> >> Ok. I'll rewrite it with reflection and repost it. Given that the other
> >> would compile and run fine on all platforms I didn't bother before.
> >
> > As a standard design pattern and development guideline, ant should not
> > depend on packages for compilation that are platform dependent. Say I
> > want to have a task that sets the windows registry, I use reflection.
> > Say I want a task for compilation dependencies that uses another
> > packages and that is redistributable, then yes, it's fine for me...
> > we'll make the build.xml file work around its absence, if required.
>
> What do you mean by 'platform dependant'? Do you mean 'This only works on
> one platform', or 'This is only needed on one plaform'? In this case it
> seems you mean the second definition - I originally assumed the first.
>
> It is a little annoying to use reflection for the whole thing. How does
> this setup look:
>
> Add a package: org.apache.tools.ant.platform
> with a sub-package: org.apache.tools.ant.platform.mac
>
> add an interface
>
> interface org.apache.tools.ant.argRunnable {
> Object run(Object[] args);
> }
>
> modify build.xml to exclude the platform package. Add extra rules to
> comile the individual platforms:
>
> <target name="compile" depends="prepare">
> <mkdir dir="${build.classes}"/>
> <javac srcdir="${src.dir}"
> destdir="${build.classes}"
> excludes="**/platform/**"
> classpath="${classpath}"
> debug="on"
> deprecation="on"
> />
> </target>
>
> <target name="mac" depends="compile">
> <javac srcdir="${src.dir}"
> destdir="${build.classes}"
> includes="**/platform/mac/**"
> classpath="${classpath}"
> debug="on"
> deprecation="on"
> />
> </target>
>
> Then in the main code you can try to load the appropriate
> platform-dependant class, make a new argRunnable instance and call it.
> Most of the plaform dependant code goes into the argRunnable instance and
> doesn't have to use reflection. This gives you compile-time type checking,
> etc.
+1
> > (BTW, have you guys looked at javadep?)
>
> No, I hadn't. I just went searching for it and found:
>
> <http://ptolemy.eecs.berkeley.edu/~cxh/java/javadepend/>
>
> and
>
> <http://www.cs.McGill.CA/~stever/software/JavaDeps/>
>
> It looks like both of these process the source to get the dependancies.
> Arnout Kuiper's method of looking in the .class files looks cool too.
to be honest, I didn't quite get Arnout's idea... :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------