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]
