[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [proxy] Cutting a release...
From:       "James Carman" <james () carmanconsulting ! com>
Date:       2007-09-28 22:54:58
Message-ID: f2e8eedf0709281554t4cc74746v1e9dadf6dbc94a6a () mail ! gmail ! com
[Download RAW message or body]

Ok, then I'll change mine to optional.  Thanks for the clarification, Dennis.

On 9/28/07, Dennis Lundberg <dennisl@apache.org> 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 <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
> >
> >
>
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> 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


[prev in list] [next in list] [prev in thread] [next in thread]