Main reason for 2a is for better dependency management. For example, App reading from S3 would add dependency on S3 related mvn sub-project dependency in its pom.xml. That dependency can pull in other transitive dependencies.
I am not an expert in mvn. But, I think above should be possible if we have separate pom sub-projects. I believe this was the idea behind 'break up contrib' activity which Thomas mentioned in his reply on this thread. ~ Yogi On 5 March 2016 at 04:10, Pramod Immaneni <[email protected]> wrote: > 1a and 2b as module is also implemented in a class. Do you have other > artifacts today along with your module? > > On Thu, Mar 3, 2016 at 5:11 AM, Priyanka Gugale <[email protected]> > wrote: > > > Hi, > > > > Recently we added Modules feature in Apex platform. Using this feature > we > > are planning to write few modules (module is set of operators connected > > together to achieve unit of work). We would like to submit them to > Malhar. > > My question is what would be the appropriate place to add these modules. > > Following are the options we are considering: > > > > 1. Malhar-library: If module code is not dependent on third part > libraries, > > we can put the module in Malhar-library. Under Malhar library we can put > > them in > > a) same package as relevant operators > > b) a different package, where package name indicates it's a module. > > > > 2. Malhar-contrib: When module depends on third party libraries, we can > put > > them in contrib. Now in contrib, do we want to > > a) add each module as indipendent project? > > b) add module in some packages? > > > > > > I would prefer to got with 1-a and hybird of 2-a and 2-b. i.e. if > external > > source versions etc changes frequently we can use 2-a. If external > library > > version doesn't change frequently and is commonly used module we can go > > with 2-b. > > > > Please share your opinion. > > > > -Priyanka > > >
