Hi Henryk That is a good approach. I have already contacted the Scomp developer and I am waiting for a response. Should that not be forthcoming I shall follow your suggestion. Regards Ian
On 31 Jan 2013, at 9:55 AM, "hekonsek [via Camel]" <ml-node+s465427n572659...@n5.nabble.com> wrote: > Hi Ian, > > > The original project has not been maintained for more than a year. > > ... > > I have tried to contact Dejan to get his input in this regard. > > ... > > I am happy to collaborate with the original author but it might be simpler > > to work of the branch > > In my opinion core Camel components should be dependent only on the > stable 3rd party libraries. We violated this rule in the case of the > CSV [1] data format and once I run into some production issues at the > client site for this reason. Keeping local fork of the library in the > component is not the way to go, if you ask me. > > I propose the following - try to settle an agreement with the Scomp > team. If in collaboration with the Scomp guys you could release new > version of the library, then use it in the Camel component. If not > (i.e. Scomp team explicitly tells you that the project will not be > released anymore), then fork Scomp on GitHub, fix it and distribute > your Camel component with your library. > > Does it sound reasonable? > > [1] http://camel.apache.org/csv.html > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com > > > If you reply to this email, your message will be added to the discussion > below: > http://camel.465427.n5.nabble.com/Contributing-Apollo-Component-tp5726153p5726597.html > To unsubscribe from Contributing Apollo Component, click here. > NAML -- View this message in context: http://camel.465427.n5.nabble.com/Contributing-Apollo-Component-tp5726153p5726599.html Sent from the Camel Development mailing list archive at Nabble.com.
