You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2007/09/28 12:45:30 UTC
[proxy] Cutting a release...
All,
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. 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] Cutting a release...
Posted by James Carman <ja...@carmanconsulting.com>.
Done.
On 10/15/07, Jörg Schaible <jo...@gmx.de> wrote:
> James Carman wrote:
>
> > All,
> >
> > 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. 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.
>
> Please update the CGLIB dependency. The cglib-full contains ASM 1.x classes
> which cause all kind of trouble for packages using later ASM versions
> (Hibernate, Groovy, ...). cglib-nodeps 2.1_3 is a proper replacement that
> hides the ASM classes in a private package.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: [proxy] Cutting a release...
Posted by Jörg Schaible <jo...@gmx.de>.
James Carman wrote:
> All,
>
> 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. 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.
Please update the CGLIB dependency. The cglib-full contains ASM 1.x classes
which cause all kind of trouble for packages using later ASM versions
(Hibernate, Groovy, ...). cglib-nodeps 2.1_3 is a proper replacement that
hides the ASM classes in a private package.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] Cutting a release...
Posted by James Carman <ja...@carmanconsulting.com>.
Ok, then I'll change mine to optional. Thanks for the clarification, Dennis.
On 9/28/07, Dennis Lundberg <de...@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 <bs...@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 <jo...@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
Re: [proxy] Cutting a release...
Posted by Dennis Lundberg <de...@apache.org>.
Here's a page with more details:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Dennis Lundberg 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 <bs...@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 <jo...@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
Re: [proxy] Cutting a release...
Posted by Dennis Lundberg <de...@apache.org>.
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 <bs...@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 <jo...@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
Re: [proxy] Cutting a release...
Posted by James Carman <ja...@carmanconsulting.com>.
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 <bs...@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 <jo...@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
Re: [proxy] Cutting a release...
Posted by Ben Speakmon <bs...@apache.org>.
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 <jo...@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
>
>
Re: [proxy] Cutting a release...
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----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
Re: [proxy] Cutting a release...
Posted by Niall Pemberton <ni...@gmail.com>.
On 9/28/07, James Carman <ja...@carmanconsulting.com> wrote:
> All,
>
> 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. 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.
I think it must be this thread:
http://tinyurl.com/2d7e3q
We need to vote on promoting proxy out of the Sandbox first, then if
that passes do a release.
Niall
> James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] Cutting a release...
Posted by janszm <me...@jansz.com>.
Hi,
Has a Proxy 1.0 release been cut yet? I couldnt find any details on the
website or find anything in the download area.
Cheers,
Menno
--
View this message in context: http://www.nabble.com/-proxy--Cutting-a-release...-tf4533693.html#a13875539
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org