So basically we have a project structure like below:
C:\Projects\Eclipse\Workspace->
afbEJB
rmcEJB
rmbEJB
**bridgesClient**
**sharedApp**
**framework**
**commonApp**
The ones marked in bold are standard java projects which are dependencies for the first 3 EJB projects. These standard projects are not built as JAR'rather actual projects so I am guessing in order to build EJB projects I would have to use ':Project' syntax.
Questions:
I was not able to refer to the standard projects without first creating settings.gradle file.
I had to create build.gradle file in all of the standard projects as well as the EJB projects. Why is there a mandate for creating gradle files in dependent projects as well? Cant the root project build it when it finds the project dependencies as part of the dependencies {...} ? that way there would be less number of build.gradle files in the entire workspace.
I think a better way around this would be to create JAR's for the standard projects and refer them as compile fileTree(dir: 'dir-where-jar-are-stored')?
What do you guys think?
Thanks,
Yogendra
ad 1) Yes, a settings.gradle is required for multi-project builds.
ad 2) It isn't necessary to create multiple build scripts. If you prefer, you can configure all projects from a single build script. Often, a mixture of these styles is used (configure commonalities from root script, remainder from subproject scripts).
ad 3) In general, I wouldn't turn the projects into separate builds, as this would complicate matters for build users. In particular, they'd have to execute multiple builds, and in the right order.
To learn more about multi-project builds, check out the "multi-project builds" chapter in the Gradle User Guide, and the many sample builds in the full Gradle distribution.
Related
In 10 minutes, I created an empty android library and an empty android application in this git repository
https://github.com/deanhiller/compositeAndroid
As seen in my last commit, I quickly convert the android application do depend on the library via gradle's awesome composite build feature (We use this feature a TON in our monorepo so loading a project loads all the libraries source code that it uses as well). Our library is shared amongst a few projects.
I cd into compositeAndroid/MyApplication and run ./gradlew build and it fails with
* What went wrong:
Could not determine the dependencies of task ':app:mergeReleaseAssets'.
> Could not resolve all task dependencies for configuration ':app:releaseRuntimeClasspath'.
> Could not resolve com.tray.android:MyLib.
Required by:
project :app
> No matching configuration of project :MyLib was found. The consumer was configured to find a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.0' but:
- None of the consumable configurations have attributes.
I am not sure how to work around this. I have a work around to publish/consume but would much prefer composite builds as it brings the source of libraries into intellij cleanly.
Why is composite builds not working? Is there something special I have to do for android projects? The above repo I setup in 10 minutes with those 2 projects(brand new).
You can always clone and play with it yourself as well. (We will actually be releasing our monorepo open-source template however it is not working to well with android just yet).
After looking into the code under MyLib folder in the repository you shared here - it seems you've opened a regular project and intend to use it as a library
Can you please follow the steps required here and test it under a new module?
Hint: your build should result with an aar file
I know this has been asked before but I haven't seen a working solution. I have two android studio (V 3.1.3) projects, MyAppBasic and MyAppPro. They each have 3 modules in common and one that is unique. My current implementation is duplicating the 3 common modules in each project. Obviously this is undesirable. What is the recommended way to implement these two apps and avoid code duplication? Thanks.
In case both of your project: MyAppBasic and MyAppPro, have almost a similar code, you can merge them and use build variant to differentiate between basic and pro app.
You also need to installing each module as a local library by using Gradle Android Maven plugin (you can see this answer for details: https://stackoverflow.com/a/33736043/4758255). Then you only need to maintain 3 common modules which is reusable as the libraries for both of your projects.
I am in the process of introducing NuGet into our software dev process, both for external binaries (eg Moq, NUnit) and for internal library projects containing shared functionality.
TeamCity is producing NuGet packages from our internal library projects, and publishing them to a local repository. My modified solution files use the local repository for accessing the NuGet packages.
Consider the following source code solutions:
Company.Interfaces.sln builds Company.Interfaces.1.2.3.7654.nupkg.
Company.Common.sln contains a reference to Company.Interfaces via its NuGet package, and builds Company.Common.1.1.1.7655.nupkg, with Company.Interfaces.1.2.3.7654 included as a dependency.
The Company.DataAccess.sln uses the Company.Common nupkg to add
Company.Interfaces and Company.Common as references. It builds
Company.DataAccess.1.0.8.7660.nupkg, including Company.Common.1.1.1.7655 as a dependent component.
Company.Product.A is a website solution that contains references to all three library projects (added by selecting the
Company.DataAccess NuGet package).
Questions:
If there is a source code change to Company.Interfaces, do I always need to renumber and rebuild the intermediate packages (Company.Common and Company.DataAccess) and update the packages in Company.Product.A?
Or does that depend on whether the source code change was
a bug fix, or
a new feature, or
a breaking change?
In reality, I have 8 levels of dependent library packages. Is there tooling support for updating an entire tree of packages, should that be necessary?
I know about Semantic Versioning.
We are using VS2012, C#4.0, TeamCity 7.1.5.
It is a good idea to update everything on each check-in, in order to test it early.
What you're describing can be easily managed using artifact dependencies (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) and "Finish Build" build triggers (or even solely "Nuget Dependency Trigger").
We wrote our own build configuration on the base project (would be Company.Interfaces.sln in this case) which builds and updates the whole tree in one go. It checks in updated packages.config files and .nuspec files along the way. I can't say how much of a time-saver this ended up being for us, even if it might sound like overkill at the beginning.
One thing to watch out for: the script we wrote checks in the files even if the chain fails somewhere in between, to give us the chance of fixing it on our local machine, check in the fix and restart the publishing.
I'm developing ASP.NET MVC with extensive usage of Spring.net.
I have lots of services implemented in different assemblies. The purpose of using Spring and abstract interfaces is to decouple the application from the implementation of services. For example, the Data Access Layer is currently implemented by NHibernate, but the solution is designed to allow this to change.
So I have defined lots of Spring objects from foreign assemblies e.g.
<object id="RepositoryFactory" type="Org.Zighinetto.MyApp.NHibernateBasedRepositoryFactory, Org.Zighinetto.MyApp,NHibernate" />
As we all know, this works as soon as Org.Zighinetto.MyApp.NHibernate.dll example assembly either
Is in GAC
Is in bin directory
As of today, in order to allow quick debugging by hitting F5, I have set a dependency from the main project to all projects it depends on. As we all know, Spring is designed to allow us to cut the dependency between projects, but in this case I use dependencies only to tell Visual Studio to compile and deploy the DLL automatically, otherwise I would have to copy the right DLLs every time I want to debug my project.
The question is straightforward: given that I want to compile, at least in Release mode, my DLLs without unneeded dependencies, how can I make sure that Visual Studio, when I hit F5, automatically compile and deploys all of the Spring-required DLLs (which can be hardcoded by me somewhere, e.g. in a post-compile script) into bin directory?
In the Org.Zighinetto.MyApp example above, I want that once Org.Zighinetto.MyApp.dll gets compiled, VS compiles and deploy also Org.Zighinetto.MyApp.NHibernate.dll without having an explicit reference from .MyApp to .NHibernate
The dependency in you project file does not make the resulting assembly in any way dependent on these referenced files. You can safely have the dependencies there during development and compile your project.
The resulting output will still work when you swap out the assemblies that contain the implementation.
I have a question about dependencies in CCNET. I have several projects, each of them are dependant on another project (a control library as it is referred to internally). When the control library project is changed, and triggers a recompile, how do I get the other dependent projects to be rebuilt?
By using project triggers.
We also have many interdependent projects too, which we solve by telling MSBuild to build a solution file which contains all the projects requires, and in the appropriate build order.