Ok, then I'll change mine to optional. Thanks for the clarification, Dennis.
On 9/28/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Optional means that you can use the product without these dependencies > present. Take commons-logging as an example. It has optional > dependencies on log4j and the other logging implementations. In the real > world though it will only use one of these. So they are optional. > > Provided means that that dependency will be provided by the target > environment. A good example of this is the servlet-api, which will be > provided by the servlet container. > > James Carman wrote: > > The dependencies are truly optional. I marked them as provided so > > that they wouldn't get picked up transitively (as you stated) by > > client projects. If they want to use the pieces of commons-proxy that > > need those extra libs, then they can explicitly add them to their POM. > > So, does that mean I should be using optional rather than provided? > > > > On 9/28/07, Ben Speakmon <[EMAIL PROTECTED]> wrote: > >> Using <scope>provided</scope> doesn't tell maven to ignore the dependency, > >> it just means that it's expected that the user will install it into his > >> local repository himself or that it will be on the same classloader as the > >> application when it's running. maven will still complain if it can't find > >> it. > >> > >> Optional dependencies are available from the repository, but not downloaded > >> unless specifically requested in the POM. > >> > >> Projects with optional dependencies where client code doesn't call them are > >> supposed to not break when the optionals are missing. Several projects > >> happily violate this rule, but I think we should hold ourselves to a higher > >> standard :) > >> > >> On 9/28/07, Joerg Hohwiller <[EMAIL PROTECTED]> wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> James Carman wrote: > >>>> All, > >>> Hi James, > >>>> It's been a while since Commons Proxy has had any attention, but I > >>>> have received two emails in the past two days about it. So, I would > >>>> like to cut a 1.0 release for it. > >>> A 1.0 would be excellent. I am also still hoping this project will come > >>> out of > >>> sandbox. The problem seems to be that the apache foundation started to > >>> only put projects out on the official places if there is a "healty > >>> community". > >>> However commons-proxy is a lib with a tight focus and already does what is > >>> needs > >>> to do. There are no great new features to discuss. > >>> In my opinion we should bring out a 1.0 that is well tested > >>> and then I personally do NOT see why it should remain in sandbox. > >>> > >>> Can someone give a reason against? > >>> > >>> Should otherwise the project start to add various of other utilities > >>> into commons-proxy only in order that the community grows, bugs are made > >>> and > >>> fixed, etc.? > >>> > >>> If I look at maven2 -what is an excellent tool- and the > >>> dependency-management > >>> it introduces, then I see that if I depend on axis2, I also depend on > >>> commons-fileupload, commons-httpclient and on commons-logging and > >>> therefore on > >>> avalon-framework, junit, logkit, etc. etc. So my client needs JUnit or > >>> avalon to > >>> talk SOAP? > >>> > >>> Maven2 is right with the way it goes. But projects have to focus more on > >>> specific issues. This is exactly what commons-proxy does. > >>> > >>> BTW: I have seen that commons-proxy is declaring its dependencies with the > >>> scope > >>> "provided" what prevents from the problem noted above with the transitive > >>> dependencies. Maybe you should have a chat with the maven guyz if it > >>> should be > >>> <optional>true</optional> instead. Do you know the difference? I can not > >>> remember right now... > >>> > >>>> I know I need to do a little work, > >>>> since the site is a bit out-dated (the SVN links are incorrect) from > >>>> the TLP move. Were there any more objections to anything fundamental > >>>> with Proxy? I believe my last release candidate failed because of > >>>> some signature problems or something. I can't remember. > >>>> > >>>> James > >>> Regards > >>> Jörg > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG v1.4.5 (GNU/Linux) > >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> > >>> iD8DBQFG/VXsmPuec2Dcv/8RAgBIAKCPSUsAOR+UcEN1kwIkMzEk/n2BqQCdFSZ3 > >>> 4JVYZ352nRGIbO4a27q9u/w= > >>> =lB27 > >>> -----END PGP SIGNATURE----- > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Dennis Lundberg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]