Good idea. I will think about this week-end ;p and come back to you next week
James.Strachan wrote: > > 2008/7/4 cmoulliard <[EMAIL PROTECTED]>: >> >> Hi, >> >> What is the best strategy to organize a Camel ESB project in term of >> maintenance, ease to read the code and to have a global overview of what >> the >> ESB is doing ? >> >> 1) Create several packages containing the route(s) >> >> ex : >> >> com.mycompany.myapplication.camel.routing.in >> com.mycompany.myapplication.camel.routing.in.file >> com.mycompany.myapplication.camel.routing.in.mq >> ... >> >> com.mycompany.myapplication.camel.routing.out >> com.mycompany.myapplication.camel.routing.out.file >> com.mycompany.myapplication.camel.routing.out.ftp >> >> 2) One containing all the route(s) >> >> com.mycompany.myapplication.camel.routing > > I guess some kind of package hierarchy would be good; as then you'll > get tooling (such as the visualisation stuff) to render related routes > in groups. > > Grouping by business function might be better than via in/out/protocol. > > e.g. you might have sales, products and accounting routing rules all > using in & out & jms & file; grouping by function might make more > sense than in/out/protocol? > > I guess if your deployment unit (jar) is a business function, its no > biggie if all the routing rules are in the same package; but if you > can find a way to group them together it might make things easier to > grok if they are in different packages > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > -- View this message in context: http://www.nabble.com/Strategy-to-organise-a-camel-esb-project-tp18281538s22882p18282393.html Sent from the Camel - Users mailing list archive at Nabble.com.
