Hi
On Mon, Apr 9, 2012 at 11:03 PM, Glen Mazza <gma...@talend.com> wrote: > I guess for those (and only those) components for which Camel wishes to > maintain multiple versions (e.g., http3 & http4, mina1 & mina2), it might be > best for such components to always have a version number as part of their > names instead of renaming whatever the standard version becomes back to the > unnumeric version; i.e., a new component http5 always remains named http5, > whether its market share is a just starting out 5% or the mainstream 80%, > because ultimately such a component is not so much about sending messages > over HTTP as it is about using a specific version of the Apache HTTP library > (and its version-specific options and settings) to do that task. "http", > OTOH, would be a useful name for a generic component whose underlying > implementation is black-boxed and allowed to change. > > For that reason, if we wish to retain camel-http in 3.0 (which most do not > want to do anyway making this point moot), I would probably recommend a > rename to the more specific "http3" while having no component named "http". > Yeah I would actually prefer to not rename components even for Camel 3.0, as we will have end users on both Camel 2.x and 3.x at the same time (and I guess some few on Camel 1.x as well). And with the state of how for example the documentation at the Camel website is presented, then it will confuse users which component is what. As its a shared website for the docs among the versions of Camel. I also agree we should add notes to the Camel documentation to refer people to http4, mina2 etc. But I don't necessary think we should mark these components as deprecated and to be removed. Http Client 3.1 and Mina 1.x is still in very much use. Despite being EOL or whatever. And btw Http Client 3.1 is still going strong. For example Spring Integration 2.1.1 (their latest release). Uses that for their http component http://search.maven.org/#artifactdetails%7Corg.springframework.integration%7Cspring-integration-http%7C2.1.1.RELEASE%7Cjar The same for Mule 3.2.1 http://search.maven.org/remotecontent?filepath=org/mule/transports/mule-transport-http/3.2.1/mule-transport-http-3.2.1.pom They have the versions defined in a parent pom http://search.maven.org/remotecontent?filepath=org/mule/mule/3.2.1/mule-3.2.1.pom > Glen > > > On 04/09/2012 04:24 PM, Christian Schneider wrote: >> >> If we rename http4 to http for camel 3.0 I think it is acceptable as it is >> a major version. >> >> On the other hand if we do not do it then what would we do? Keep http4 >> forever and not have http. For new users this will look just weird. >> >> Christian >> >> Am 09.04.2012 22:04, schrieb Christian Müller: >>> >>> My 0,02 $: >>> I would add a warning on page [1] that new user should prefer to use >>> camel-http4 over camel-http (as we did it already for iBatis). Camel-http >>> should mark as deprecated and will be deleted in Camel 3.x. >>> I would *NOT* rename camel-http to camel-http3 and camel-http4 to >>> camel-http. This will confuse our users. >>> >>> [1] http://camel.apache.org/http.html >>> >>> Best, >>> Christian >>> >> > > > -- > Glen Mazza > Talend Community Coders > coders.talend.com > blog: www.jroller.com/gmazza > -- Claus Ibsen ----------------- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
