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] > >
