Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It is not really feasible, or desirable to do so. Why would you want to "hide" the dependencies? Would you also want to hide a dependency on whatever logging package you may be using (for example)?</p> <p>If you have the dependencies in your implementation, then they are best published as it will cause a lot less grief on the part of users of your API since they will know what conflicts may exist before they even attempt to use your code.</p> <p>Don't forget, your users are actually developers and I am sure that they would rather be aware of any landmines or requirements up front.</p> <p><strong>Edit - Regarding OSGi:</strong></p> <p>OSGi will definitely take care of your conflicting dependencies issues, but it also would rely on deploying in an OSGi environment, which you haven't mentioned is the case for your clients. In addition, it is still not recommended to "hide" those dependencies in a bundle. The very nature of OSGi allows those conficting depencies to cooexist in the same application.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing Spring without exposing the dependencies to the Client app
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USRobin
    1. USRobin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUsing Spring without exposing the dependencies to the Client app
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COHiding the dependencies eliminates the following: What is this "jar" going to pull in for me that will conflict with my version of "X". Example 1) A client application uses spring 2.5 while internally I use spring 3.0. I don't want to force the client to upgrade. The intent is to internalize my dependencies so that the client doesn't care whats internally referenced. In my case we have spring clients and NON spring clients, but I don't want to directly tell them now, go load up a context and include 40 new jars for using my API. Just wondering if this is even easily possible in Java.
      singulars
      1. PO
      1. USNick N
    2. COThis is not practically doable. OSGi can help, but this would force your clients to use OSGi, or you will have to embed OSGi inside your implementation (never done this but I believe it is doable - Neil can probably confirm). Basically you will have to try some sort of classloader manipulation to hide those dependencies. Then the next problem will be that you will have to redeploy your lib when a bug is found in any of your dependencies, instead of simply having your client get Spring 3.0.1 (for example). I think this makes your solution more complicated and fragile in the long run.
      singulars
      1. PO
      1. USRobin
    3. CORobin - I agree that using OSGi for this purpose is predicated on actually running in an OSGi environment. Furthermore I would not advise OP to convert his environment if it is *only* for the reasons set out in his question. On the other hand if he does build on OSGi and uses it to hide implementation details from consumers of his API then he will end up with a simple, stabler and less fragile solution in the long run.
      singulars
      1. PO
      1. USNeil Bartlett
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload