Hi all,
working on dh_java i encountered this:
Duplicate library path: org/w3c/dom in both lib-dom-java and
lib-openxml-java,libxerces-java!
In other words, the org.w3c.dom classes are given in three packages...
They probably have some version differences, but it seem not correct that
this red
On Wed, May 30, 2001 at 10:28:20AM +0200, Egon Willighagen wrote:
> In other words, the org.w3c.dom classes are given in three packages...
> They probably have some version differences, but it seem not correct that
> this redundancy is available...
They do indeed implement different DOM versions:
On Wednesday 30 May 2001 10:42, Stefan Gybas wrote:
> On Wed, May 30, 2001 at 10:28:20AM +0200, Egon Willighagen wrote:
> > In other words, the org.w3c.dom classes are given in three packages...
> > They probably have some version differences, but it seem not correct that
> > this redundancy is ava
On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote:
> But if they are different implementations they should not use the
> same namespace... (see below)
But they implement the same interface (DOM in this case) and the XML for
Java standard says that the DOM interface classes have to
0> In article <[EMAIL PROTECTED]>,
0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
Egon> working on dh_java i encountered this:
Egon>
Egon> Duplicate library path: org/w3c/dom in both lib-dom-java and
Egon> lib-openxml-java,libxerces-java!
Egon>
Egon> In other words, the org.w3c.dom
On Wednesday 30 May 2001 11:16, Stefan Gybas wrote:
> On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote:
> > But if they are different implementations they should not use the
> > same namespace... (see below)
>
> But they implement the same interface (DOM in this case) and the XML fo
On Wednesday 30 May 2001 12:19, Toby Speight wrote:
> 0> In article <[EMAIL PROTECTED]>,
> 0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
>
> Egon> working on dh_java i encountered this:
> Egon>
> Egon> Duplicate library path: org/w3c/dom in both lib-dom-java and
> Egon> lib-openxml-
* Egon Willighagen
| > Surely then the dependency will be on "( lib-dom-java | lib-openxml-java
| > | libxerces-java )", since having any of those will satisfy the runtime?
|
| This will indeed be the outcome of dh_java...
A virtual package might be appropriate here - maybe also making a
standa
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> > Surely then the dependency will be on "( lib-dom-java | lib-openxml-java
> > | libxerces-java )", since having any of those will satisfy the runtime?
>
> This will indeed be the outcome of dh_java...
I don't think this will wo
0> In article <[EMAIL PROTECTED]>,
0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
Egon> Stefan argued that interface and implementation should not be
Egon> seperated:
Egon>
Egon> "The classes for interfaces might be identical for all
Egon> containers but at
Egon>least the ex
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I'm don't think this is po
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> For interfaces, it may be ok to require only one
> instance (even that is arguable), but for the classes, it is not
> fair to allow only one implementation.
Argh, I just deleted the mail showing who suggested this, but I really
like the idea of using vi
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote:
> AIUI, the packages in question simply bundle W3C's interfaces[1]
> (unchanged - W3C's licence may require this)
I was curious about this, and I would like to ask if there is any
consensus on how this affects free software. For exampl
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I may have misunderstood w
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> I was curious about this, and I would like to ask if there is any
> consensus on how this affects free software. For example, the
> copyright notice at
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/copyright-notice.html
> says
>
> Conse
On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> > But it might indeed be "good" to place the interface classes in a
> > seperate jar/package... this would enforce that the implementation *does*
> > implement the actual inte
On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > It is fine to split packages into the official API classes, and
> > supporting classes. However, it is not fine to say that there can
> > be only one "official API classes"
On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > While this does allow modification of the software, it effectively
> > says that when you modify it, you must break the API. This seems
> > like an onerous requirement.
>
> Modifying it
On Wednesday 30 May 2001 21:14, Andrew Pimlott wrote:
> On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> > On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > > It is fine to split packages into the official API classes, and
> > > supporting classes. However, it is not fin
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> > [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > > While this does allow modification of the software, it effectively
> > > says that when you modify it, you must break the API. This seems
On Wed, May 30, 2001 at 02:31:17PM -0600, Eric Schwartz wrote:
> No, no, I mean what they seem to be saying is that you cannot modify the
> classes that define the API to either extend or contract the scope of the
> API. My interpretation of what they're saying is thus:
>
> "Anything that curre
Hi all,
working on dh_java i encountered this:
Duplicate library path: org/w3c/dom in both lib-dom-java and
lib-openxml-java,libxerces-java!
In other words, the org.w3c.dom classes are given in three packages...
They probably have some version differences, but it seem not correct that
this re
On Wed, May 30, 2001 at 10:28:20AM +0200, Egon Willighagen wrote:
> In other words, the org.w3c.dom classes are given in three packages...
> They probably have some version differences, but it seem not correct that
> this redundancy is available...
They do indeed implement different DOM versions
On Wednesday 30 May 2001 10:42, Stefan Gybas wrote:
> On Wed, May 30, 2001 at 10:28:20AM +0200, Egon Willighagen wrote:
> > In other words, the org.w3c.dom classes are given in three packages...
> > They probably have some version differences, but it seem not correct that
> > this redundancy is av
On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote:
> But if they are different implementations they should not use the
> same namespace... (see below)
But they implement the same interface (DOM in this case) and the XML for
Java standard says that the DOM interface classes have to
0> In article <01053010282003.00794@catv6142>,
0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
Egon> working on dh_java i encountered this:
Egon>
Egon> Duplicate library path: org/w3c/dom in both lib-dom-java and
Egon> lib-openxml-java,libxerces-java!
Egon>
Egon> In other words, the
On Wednesday 30 May 2001 11:16, Stefan Gybas wrote:
> On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote:
> > But if they are different implementations they should not use the
> > same namespace... (see below)
>
> But they implement the same interface (DOM in this case) and the XML f
On Wednesday 30 May 2001 12:19, Toby Speight wrote:
> 0> In article <01053010282003.00794@catv6142>,
> 0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
>
> Egon> working on dh_java i encountered this:
> Egon>
> Egon> Duplicate library path: org/w3c/dom in both lib-dom-java and
> Egon>
* Egon Willighagen
| > Surely then the dependency will be on "( lib-dom-java | lib-openxml-java
| > | libxerces-java )", since having any of those will satisfy the runtime?
|
| This will indeed be the outcome of dh_java...
A virtual package might be appropriate here - maybe also making a
stand
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> > Surely then the dependency will be on "( lib-dom-java | lib-openxml-java
> > | libxerces-java )", since having any of those will satisfy the runtime?
>
> This will indeed be the outcome of dh_java...
I don't think this will w
0> In article <01053013545202.00861@catv6142>,
0> Egon Willighagen mailto:[EMAIL PROTECTED]> ("Egon") wrote:
Egon> Stefan argued that interface and implementation should not be
Egon> seperated:
Egon>
Egon> "The classes for interfaces might be identical for all
Egon> containers but at
Egon>
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I'm don't think this is p
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> For interfaces, it may be ok to require only one
> instance (even that is arguable), but for the classes, it is not
> fair to allow only one implementation.
Argh, I just deleted the mail showing who suggested this, but I really
like the idea of using v
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote:
> AIUI, the packages in question simply bundle W3C's interfaces[1]
> (unchanged - W3C's licence may require this)
I was curious about this, and I would like to ask if there is any
consensus on how this affects free software. For examp
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I may have misunderstood
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> I was curious about this, and I would like to ask if there is any
> consensus on how this affects free software. For example, the
> copyright notice at
> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/copyright-notice.html
> says
>
> Cons
On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> > But it might indeed be "good" to place the interface classes in a
> > seperate jar/package... this would enforce that the implementation *does*
> > implement the actual int
On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > It is fine to split packages into the official API classes, and
> > supporting classes. However, it is not fine to say that there can
> > be only one "official API classes
On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > While this does allow modification of the software, it effectively
> > says that when you modify it, you must break the API. This seems
> > like an onerous requirement.
>
> Modifying i
On Wednesday 30 May 2001 21:14, Andrew Pimlott wrote:
> On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> > On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > > It is fine to split packages into the official API classes, and
> > > supporting classes. However, it is not fi
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> > [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > > While this does allow modification of the software, it effectively
> > > says that when you modify it, you must break the API. This seem
On Wed, May 30, 2001 at 02:31:17PM -0600, Eric Schwartz wrote:
> No, no, I mean what they seem to be saying is that you cannot modify the
> classes that define the API to either extend or contract the scope of the
> API. My interpretation of what they're saying is thus:
>
> "Anything that curr
42 matches
Mail list logo
