You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Anil Ramnanan <li...@peppersauce.org> on 2005/08/12 12:40:55 UTC
Daisy Repository
I am trying to implement a class in the plugin to read the Daisy
Repository using the API at
http://cocoondev.org/daisydocs-1_3/repository/interfaces/28.html
This requires that a number of jars be included. Would I be able to
include the Daisy jars in the plugin ?
Here is a list of the basic jars needed from their example:
DAISY_HOME/lib/daisy/jars/daisy-repository-api-1.3.jar
DAISY_HOME/lib/daisy/jars/daisy-repository-client-impl-1.3.jar
DAISY_HOME/lib/daisy/jars/daisy-repository-spi-1.3.jar
DAISY_HOME/lib/daisy/jars/daisy-util-1.3.jar
DAISY_HOME/lib/avalon-framework/jars/avalon-framework-api-4.1.5.jar
DAISY_HOME/lib/daisy/jars/daisy-repository-common-impl-1.3.jar
DAISY_HOME/lib/commons-httpclient/jars/commons-httpclient-2.0-rc2.jar
DAISY_HOME/lib/xmlbeans/jars/xbean-20040211.jar
DAISY_HOME/lib/daisy/jars/daisy-repository-xmlschema-bindings-1.3.jar
DAISY_HOME/lib/concurrent/jars/concurrent-1.3.2.jar
DAISY_HOME/lib/commons-logging/jars/commons-logging-1.0.3.jar
DAISY_HOME/lib/commons-collections/jars/commons-collections-3.1.jar
DAISY_HOME/lib/daisy/jars/daisy-jmsclient-api-1.3.jar
DAISY_HOME/lib/jms/jars/jms-1.0.2a.jar
Anil.
Re: Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Anil Ramnanan <li...@peppersauce.org>.
Ross Gardler wrote:
>
> I think you are right, the Java API is probably best.
>
> So does all this mean that we have something like:
>
> package org.apache.forrest.view
>
> /**
> * A tree navigator that displays the contents of a repository
> */
> public class RepositoryNavigator
>
> ---
>
> package org.apache.forrest.repository
>
>
> /**
> * An interface describing the methods required to interface with
> * and interact with an external repository.
> */
> public class IRepositoryConnection
>
> /**
> * A content provider that presents the content of a repository
> * to a graphical widget for display.
> */
> public class RepositoryContentProvider implements
> IStructuredContentProvider
>
>
> /**
> * A label provider that provides labels for the content of a
> * repository for display in a treeView.
> */
> public class RepositoryLabelProvider extends LabelProvider implements
> ITreeLabelProvider
>
> ---
>
> package org.daisy.forrest.repository;
>
> /**
> * An implementation of a connection to a Daisy Repository
> */
> public class RepositoryConnection implements
> IRepositoryConnection
>
> ---
>
> The RepositoryConnection can do all the communicating with the
> repository as you suggest. It would provide instances of the content
> and label providers for the view.
>
> ---
>
> Does this fit with what you were planning?
>
That was the general idea I had. Thanks for refining it bit for me.
Anil.
Re: Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Ross Gardler <rg...@apache.org>.
Anil Ramnanan wrote:
> Ross Gardler wrote:
>
>
>>You tell me. It is certainly easier to use the HTTP in the Forrest
>>plugin environment. However, you are working in a Java environment so
>>it may be better to use the Java API. Perhaps if you outline your
>>design ideas it will help us decide.
>>
>>Ross
>>
>
>
> That as my thinking as well when I decided to use the Java API.
>
> Here is the basic idea:
>
> A Repository View that has a form that show a list of documents
> available in the repository. This is the interface where the user
> selects the documents that they want to include in the locatiomap. You
> should be bale to drag and drop from here to the locatiomap view.
A form? Why not a tree, seems more natural to me and you already have an
abstract class to handle tree views.
> This Repository View will get it's information from a Document List
> class. This class provides a listing of documents available from the
> repository. This is not linked to a any particular repository but gets
> its document list from classes that would query repositories specified
> by the user such as the Daisy repository.
Tis sounds more like an interface. I'm not sure you can create *one*
class that would be able to retrieve documents form multiple
repositories. It would probably make more sense to define an interface
and then have specific repository plugins provide implmentations for
that interface.
Doing it this way you don't have one central class to be maintained by
all the different repository instances. Instead each repository
maintains its own implementation. If we are really lucky some of them
(like lenya) will maintain this class in their own code base (where it
should be really).
> The Document List class can be
> configured by a Preferences page which would allow you to select which
> repository you are using and the settings for that particular repository
> (username, password etc).
This preferences would then be provided by the repository plugins.
> Then there are the repository specific classes for Daisy which would
> query the daisy repository and return the list of documents to the
> Documents List class. Here we use Daisy's Java API to query the repository.
And these also would be a part of the DaisyPlugin.
I think you are right, the Java API is probably best.
So does all this mean that we have something like:
package org.apache.forrest.view
/**
* A tree navigator that displays the contents of a repository
*/
public class RepositoryNavigator
---
package org.apache.forrest.repository
/**
* An interface describing the methods required to interface with
* and interact with an external repository.
*/
public class IRepositoryConnection
/**
* A content provider that presents the content of a repository
* to a graphical widget for display.
*/
public class RepositoryContentProvider implements
IStructuredContentProvider
/**
* A label provider that provides labels for the content of a
* repository for display in a treeView.
*/
public class RepositoryLabelProvider extends LabelProvider implements
ITreeLabelProvider
---
package org.daisy.forrest.repository;
/**
* An implementation of a connection to a Daisy Repository
*/
public class RepositoryConnection implements
IRepositoryConnection
---
The RepositoryConnection can do all the communicating with the
repository as you suggest. It would provide instances of the content and
label providers for the view.
---
Does this fit with what you were planning?
Ross
Re: Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Anil Ramnanan <li...@peppersauce.org>.
Ross Gardler wrote:
>
> You tell me. It is certainly easier to use the HTTP in the Forrest
> plugin environment. However, you are working in a Java environment so
> it may be better to use the Java API. Perhaps if you outline your
> design ideas it will help us decide.
>
> Ross
>
That as my thinking as well when I decided to use the Java API.
Here is the basic idea:
A Repository View that has a form that show a list of documents
available in the repository. This is the interface where the user
selects the documents that they want to include in the locatiomap. You
should be bale to drag and drop from here to the locatiomap view.
This Repository View will get it's information from a Document List
class. This class provides a listing of documents available from the
repository. This is not linked to a any particular repository but gets
its document list from classes that would query repositories specified
by the user such as the Daisy repository. The Document List class can be
configured by a Preferences page which would allow you to select which
repository you are using and the settings for that particular repository
(username, password etc).
Then there are the repository specific classes for Daisy which would
query the daisy repository and return the list of documents to the
Documents List class. Here we use Daisy's Java API to query the repository.
Anil.
Re: Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Ross Gardler <rg...@apache.org>.
Anil Ramnanan wrote:
> Ross Gardler wrote:
>
>
>>However, I would like to discuss the design you have in mind for this
>>as this is a complex task and we need to make sure it is done right
>>(or as close to right as we can get it within a reasonable amount of
>>discussion).
>>
>>In particular, I'm confused as to why you say you need so many jars. I
>>have a Java Daisy client that only uses the following from your list:
>>
>>
>>>DAISY_HOME/lib/daisy/jars/daisy-repository-api-1.3.jar
>>>DAISY_HOME/lib/daisy/jars/daisy-repository-client-impl-1.3.jar
>>>DAISY_HOME/lib/daisy/jars/daisy-repository-spi-1.3.jar
>>
> The extra jars were from the example on Daisy's site. You are right that
> only those jars are needed. I put the others because I wasn't sure if I
> would need the rest.
>
>
>>And, if you examine the daisy plugin you'll find that it communicates
>>effectively with the repository without the need for any JARs as it
>>uses the REST API to the repository.
>>
>>This question and the list of jars you have identified makes me think
>>there are some problems with either your approach or my approach. I
>>would like to know which it is.
>>
>
> Following Daisy's documentation, I see that there are three interfaces:
> Javascript, the Java API and the HTTP API. I was planning to use the
> Java API
> (http://cocoondev.org/daisydocs-1_3/repository/interfaces/28.html) to
> get the documents from the repository.
> I believe your method uses the HTTP API. Should I be going in this
> direction instead ?
You tell me. It is certainly easier to use the HTTP in the Forrest
plugin environment. However, you are working in a Java environment so it
may be better to use the Java API. Perhaps if you outline your design
ideas it will help us decide.
Ross
Re: Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Anil Ramnanan <li...@peppersauce.org>.
Ross Gardler wrote:
>
> However, I would like to discuss the design you have in mind for this
> as this is a complex task and we need to make sure it is done right
> (or as close to right as we can get it within a reasonable amount of
> discussion).
>
> In particular, I'm confused as to why you say you need so many jars. I
> have a Java Daisy client that only uses the following from your list:
>
>> DAISY_HOME/lib/daisy/jars/daisy-repository-api-1.3.jar
>> DAISY_HOME/lib/daisy/jars/daisy-repository-client-impl-1.3.jar
>> DAISY_HOME/lib/daisy/jars/daisy-repository-spi-1.3.jar
>
The extra jars were from the example on Daisy's site. You are right that
only those jars are needed. I put the others because I wasn't sure if I
would need the rest.
>
> And, if you examine the daisy plugin you'll find that it communicates
> effectively with the repository without the need for any JARs as it
> uses the REST API to the repository.
>
> This question and the list of jars you have identified makes me think
> there are some problems with either your approach or my approach. I
> would like to know which it is.
>
Following Daisy's documentation, I see that there are three interfaces:
Javascript, the Java API and the HTTP API. I was planning to use the
Java API
(http://cocoondev.org/daisydocs-1_3/repository/interfaces/28.html) to
get the documents from the repository.
I believe your method uses the HTTP API. Should I be going in this
direction instead ?
Anil.
Respository brwoser for eclipse plugin Re: Daisy Repository
Posted by Ross Gardler <rg...@apache.org>.
Anil Ramnanan wrote:
> I am trying to implement a class in the plugin to read the Daisy
> Repository using the API at
> http://cocoondev.org/daisydocs-1_3/repository/interfaces/28.html
> This requires that a number of jars be included. Would I be able to
> include the Daisy jars in the plugin ?
First I will answer your question because it is useful information
generally (and can be applied to other binary files you may wish to
include in an Open Source project.
You need to check the licenses for any jars you want to include. Any BSD
style license is compatible. If you are in doubt then ask about the
specific license. What I can tell you is that Daisy itself is Apache
licensed so no problem with the daisy-* jars.
For all jars you must include the license for each jar with the correct
naming convention. See lib in the forrest distribution for lots of
examples of this. Note this means duplicating the license file for each
of the individual jars. You also need to check the license terms to see
if you need to add any acknowledgments elsewhere (such as in a NOTICE file).
---
However, I would like to discuss the design you have in mind for this as
this is a complex task and we need to make sure it is done right (or as
close to right as we can get it within a reasonable amount of discussion).
In particular, I'm confused as to why you say you need so many jars. I
have a Java Daisy client that only uses the following from your list:
> DAISY_HOME/lib/daisy/jars/daisy-repository-api-1.3.jar
> DAISY_HOME/lib/daisy/jars/daisy-repository-client-impl-1.3.jar
> DAISY_HOME/lib/daisy/jars/daisy-repository-spi-1.3.jar
And, if you examine the daisy plugin you'll find that it communicates
effectively with the repository without the need for any JARs as it uses
the REST API to the repository.
This question and the list of jars you have identified makes me think
there are some problems with either your approach or my approach. I
would like to know which it is.
Can you please outline you design.
Ross