Hello! Does Amper support the equivalent of compos...

# amper

[louiscad]

Hello! Does Amper support the equivalent of composite builds?

Long term:
I'm interested in embedding an Amper project into another Amper project.

Short term:
I want to embed an Amper project into a Gradle project to consume internal libraries (present as a git submodule). Not having to publish them on a maven repo, and not have to use Amper for the app build that relies on some Gradle plugins is key here.

[joffrey]

We don't support composite builds yet, in either of the 2 forms you mentioned.

An alternative would be to publish the Amper project to maven local, and then consuming it from there from the Gradle build. Would that suit your short term needs? What do you need from the included builds feature?

[gildor]

Our experience shows that composite build is really a must have for active development of libs in conjunction with the main repo (if you don't have monorepo), publishing to maven local is way slower and more inconvenient (so one shouldn't forget to publish before building/running tests)

[joffrey]

That's why I'm asking about what you need from it. If the only reason you need included builds over shared maven artifacts is performance, then maybe the solution could be different. Included builds in Gradle have lots of other implications, like changing your whole build classpath.

[gildor]

Well, yes, convenience, speed of development, simplicity of setup

[gildor]

I don't mind changing the build class path, usually it's fine, as soon as Gradle versions are compatible, I don't remember any problems with it for a long time

[gildor]

I'm not talking about technical implementation, just the way how it works on practice, an ability to link local project without additional changes is very useful for lib development

[joffrey]

yes, convenience, speed of development, simplicity of setup

Sorry, this is not what I meant. Of course everyone wants convenience, speed, and simplicity, but that's not about the use case, these are just nice properties that any solution to the problem should have. For now I'm rather trying to figure out the exact problem we're trying to solve.

[gildor]

Maybe there are another solutions, but publishing to maven local is just worse in all ways during active development (not a big deal if it just a matter of fixing something small and than they it)

[joffrey]

Yeah sorry I'm not saying that maven local is the solution. I was just mentioning it as a workaround initially. Now I'm trying to figure out the problem, without assuming any solution.

> an ability to link local project without additional changes is very useful for lib development
Thanks, that's what I'm after, but that's still rather vague. So in your case, what are you doing in terms of "lib development"? For example, are you trying to test your own library against a sample app that consumes it? Are you trying to fix one of your 3rd party dependencies with the goal of contributing a PR to it, but you want to test if it would fix a problem in your own app? Do you own both the library and the consumer, and you want to somehow test that they work together? If yes, is it for local experiments only? Or does the consumer project run tests on CI with an included build?

[joffrey]

Without this kind of information, it's not really clear how to proceed with such feature requests

[gildor]

We use it mostly for internal libs, we have a few use cases, where development is not a part of monorepo (for many reasons)
So it's useful for developers to do changes and immediately build app with them
And not for test app, for our main app

But when we have cases when we need to fix something for third party lib, we usually also use composite builds

We don't use it for CI but there are probably good use cases for it

[gildor]

I don't really ask for feature requests, just saying why it's important feature of Gradle for us

[joffrey]

Thanks a lot for sharing!

> So it's useful for developers to do changes and immediately build app with them
This is what feels strange to me. I wonder how useful this actually is, because it seems very manual and error-prone, as opposed to checking this on the CI, for instance.
There could be an integration/e2e test in the lib that runs the app build, so the devs could run it, and the CI as well. This would prevent breaking the app's build in future versions of the lib. Wouldn't making these things easy in Amper be better for this case?

[gildor]

Obviously when change is ready it pushed to corresponding repo with test and passes CI there with own set of checks and code review, not more error prone than do this with publishing to own repo

[gildor]

Not sure how is it strange to grab code, experiment with it and test locally, submit changes , isn't it what you do with any dependency if it's not a part of mono repo