Multi-module project publishing

[Maatary Okouya]

Hi, 

I have red most of the doc of Ivy, which i think i understand better, especially in the context of SBT. 

However, i still need to clarify something about dependency resolution and multi-module project. This is because i'm porting an Eclipse workspace into an Sbt Multi-module project. 

Of course there is some dependency between the projects. Nothing circular of course. Although they are mainly divided in 2 groups or two principale modules. We could call it client and server. However Client and server rely on some commons modules. To sum it up, we have the servers modules, the clients modules, and the commons modules. 

In a sense the servers modules (including the commons) can be published separately. For instance someone else could implements its own client modules. The clients modules (including the commons) as well to a certains extends. Although their exist, to test and demonstrate or guide other people how to build a applications to communicate with the servers application. The real project is the server application. In any case my point here is: 

I would like people to be able to install/download the servers application independently of the client applications. Also, the case of development, I would like them to be able to depends separately on the respective (set of) module (clients and servers) if necessary.  Would that be possible ? what is the proper strategy? 

If there is something that i am missing please could you point me to the right documentation ?

Many thanks,

M

[Josh Suereth]

Does this fit the bill?


`build.sbt`

lazy val common = project
lazy val client = project.dependsOn(common)
lazy val server = project.dependsOn(server)


Just expand that out for multiple projects in common.  If you want to create an 'aggregate all" jar, just use something like sbt-assembly.

See:  https://github.com/sbt/sbt-remote-control/blob/master/project/build.scala#L140-L171 for a rather complicated example of how we do client/server (and scala cross versioning) splits in sbt server.

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.
To post to this group, send email to simple-b...@googlegroups.com.
Visit this group at http://groups.google.com/group/simple-build-tool.
For more options, visit https://groups.google.com/d/optout.

[Maatary Okouya]

Hi Josh, 

I got the MEAP of your Book on Manning where you explain well about the dependency between project  in a multi-module settings (I'm still reading and re-reading tho) . In any case I'm fine with what you wrote here. But like in the book, this address only the problem of compile time dependencies. It does not however says how to publish different module indepently either for use by other developer or by user with sbt-assembly. What I mean is that all the ingredient are in the book. how to publish for different case, how to to set up a multi-module project, however how to apply the task in "project scope" is not yet clear to me. I think this is where lies the issue right? 

Best, 

M

--
You received this message because you are subscribed to a topic in the Google Groups "simple-build-tool" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simple-build-tool/aGFm0hcLe44/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simple-build-t...@googlegroups.com.

[Guofeng Zhang]

If I was you, I will organize my code base as the following way:

1. if the server module and common module developed/maintained by the same team, I will create a build (that is, a directory tree) contain two projects, one for the server moudule and one for the common module:

projectRoot

     project      --- the directory to defined the build

     server       -- the source directory contains the source for the server moudle

     common   -- the source directory contians the source for the common module

     build.sbt   --- if you do not want to place your build definition in the above project directory, you could define it here.

See http://www.scala-sbt.org/0.13/tutorial/Multi-Project.html to know how to define the build for this two projects, or see https://github.com/guofengzh/swagger-core for a example.

You 'd better have a root project definition in your build definition.

On the Sbt console, you could run "projects" task to list your projects in the build

    a) you could build all projects (compile/test/pacakge/publish) at the root project, or

    b) run "project <project-name>" to build a specific project, for example, run "project server" to go to the server project, then build only this project, for examle, only publish this project's artifacts

Then any other teams for the client module can reference the server module as the 3rd dependencies in their projects (for transitive dependency, common module is referenced automatically), like you reference 3rd library in your build.

if you also want to develop your own client module:

         1) if you want to share the source code of the client module to public, you could defined it as a separate build (I say a separate build).

         2) if you do not want to share your client source code, you may add your client module as a PROJECT to your above build (that is, now the build contains 3 projects).

If your common module is developed internally by a different team, and you want to reference the source as a dependency in your build, see ProjectRef (google it for detail). https://github.com/guofengzh/mp-aggr is a simpe demo for it.

Hope the above is helpful to you.

[Maatary Okouya]

Hi Zhang, 

Thanks for your help. I'm digging into it to understand everything step by step, checking the example as well. although in the mean time i would appreciate to clarify few points? 

What do you mean when you say: 

>>>You 'd better have a root project definition in your build definition.

Did you mean than rather taking the default that sbt would create for me, i should define the root project explicitly in the build.sbt of the root project ?

Also when you say:

>>>if you also want to develop your own client module:

         1) if you want to share the source code of the client module to public, you could defined it as a separate build (I say a separate build).

could you clarify that point ?

Just for the record, yes i need those clients, they help me do some end-to-end test on the server. I want those clients available to the public as example on how to build a client against the server. They will be able to download executable along with the server executable just for a try, but then download the source separately for development, thereby, the clients will be more like a template. 

If you could answer that i would appreciate, and in the mean time i will keep on reading all materials provided. 

Many thanks.

[Guofeng Zhang]

For root project, i mean the aggregate project, which "running a task on the aggregate project will also run it on the aggregated projects. ".

Simply say, a separate build means a different source directory tree for the build.

[Maatary Okouya]

Thx