commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [proxy] Cutting a release...
Date Fri, 28 Sep 2007 21:43:43 GMT
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 <bspeakmon@apache.org> 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 <joerg@j-hohwiller.de> 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message