Re: [PROPOSAL] dh_ant
Hello Arnaud,
Friday, August 15, 2003, 11:46:31 PM, you wrote:
> Jan Schulz <jan@katzien.de> wrote:
>> IMO the big enchancement is, that you only have to specify the
>> Depends once: in debian/control and everything else is added from
>> there on.
> That's what we all want ;)
Ok, I take that as an agrrement and will add that to my upcoming
proposal :) I will also try to implement the buildtime debhelper
dh_java (is that name already taken?`)
>> With my method, you don't have to either of this (if dh_ant will
>> work as I would like it :)
> Yes, I think it's the sort of code there will be in something like
> dh_java (but I'll first test Stefan's code ;)).
Yes, I will also test (and probably switch to it after I have
understood the mechnism) CDBS, but having a dh_java, which does the
actual job is IMO fine as well. CDBS can then make use of it. The
advantage about a complete CDBS based solution would be, that
someone not using CDBS still has a way to do it...
>> Yes: they implement the same interfaces/classes. So whatever comes
>> first will win. eclipse itself figures ot the 'Window System' to use
>> with a param at startup time (default is compiled in). I use the
>> 'jars' file to provide this bit as well.
> They maybe have good reasons... I don't know how I'd do that but I think
> it's a strange way of implementing this. But well, it's difficult.
The system is quite nice: you have a xml file, which declares all
the feature your 'plugin' has and 'extention points' where others
can add features to your plugin. eclipse is one small core and the
rest is extention to extention points. In this xml you also declare
which jars holds the implemnting classes and the 'PluginClassLoader'
automgically only has this jar and the declared dependencies on its
classpath.
In eclipse 3.0, all the IDE independend features are factored out,
so that one can build a apps with UI (non UI are already possible),
based on this mechanism.
> Well it's a very difficult question because the classpath and
> j2(sdk|re)1.4 have the jaxp api merge in the core api. The upcoming
> kaffe 1.1.1 will also have it. But J2sdk1.3 and earlier versions did not
> have jaxp. So if you look at libgnujaxp-java which is an implementation
> of jaxp, and if you look at libxerces?-java, you'll have these
> javax.xml.* packages and also org.xml.sax.* and org.w3c.dom.*.
Maybe it is possible to add a package which:
* Depends: on all this newly introduced API packages
* Depends: on a special version of 1.3 JRE
* Provides: JRE-1.4
* sets the alternative symlinks
> All these
> classes MUST be the same... but Sun's javax.xml... and gnu javax.xml do
> not have the same license's terms!
? I thought javax.xml is a JCP thingie? How did they manage to
relicense it? And how diffrently did they relicense it? From free to
DFSG unfree?
[eclipse]
> Well, it seems to be a very very difficult package!
I'm learning every time I put my hands on it :)
> Well, Jan, I think that anyone who would maintain eclipse would orphan
> all his other packages! :-D
I'm thinking of packaging some more eclipse plugins. It should be
fairly easy to do it, as almost every plugin is build via a eclipse
buildin machnism, which is available as ant-script.
> As everyone could read to night, Ean will soon upload a new kaffe
> release, I suggest you have a try to build eclipse and run it with kaffe
> and submit as many bugs as you can ;)
I will do that, at the next time my time permits :) First will
probably go to the eclipse BTS thouigh, as eclipse currently only
accepts 'java|java.exe|javaw.exe' as 'debug target' (JVM, which runs
my developed programm and whichc an be used to debug it). The RH
eclipse ML has already a patch for accepting gcj...
Have a nice week, I will go on holiday from tomorrow on :)
Jan
Reply to: