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.
Related
How can I share components across multiple react projects without having to publish them on a public package manager like NPM?
Option 1: You can use npm and use private packages so they're not external facing. There are also artifactories and scoped packages that usually represent company-wide projects that can be public or private. See https://docs.npmjs.com/private-modules/intro and https://docs.npmjs.com/misc/scope.
Option 2: Essentially, you can develop projects with a flattened structure. You can then import various projects and/or components into other projects or folders. This is entirely dependent on your codebase and configuration. With this model though, a lot of times publishing to npm comes fairly naturally since each folder may be its own project with its own package.json.
Updated:
Option 3: Bit focuses on the composability of components from everything from the little things like a button to the actual view and app itself—each target is its own package. Overall, it's an opinionated, yet customizable framework that can enable quicker development, managed dependencies, and organized code.
Option 4: RushJS is a monorepo manager built by Microsoft that allows for flexibility of different kinds of apps and services utilizing pnpm underneath (as opposed to yarn and npm), which alleviates problems that stem from dependency issues.
Check out Bit:
Bit is an open-source cli tool for collaborating on isolated components across projects and repositories. Use Bit to distribute discrete components from a design library or a project into a standalone reusable package and utilize it across applications.
You could also upload them to a private git repo such a Github and then pull them in from there.
Ryanve has a nice example over here: https://stackoverflow.com/a/28729646/1592783
You could create a repo of shared components and then have your Node.js start script call a shell script to do a git pull from that repo and the move the shared components from that directory to your project's directory. That way, every time you call run 'npm start' you will have the latest version of the shared components loaded into your project
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.
I've got a VS2013 solution with a mix of NodeJS (using TypeScript) and C# class library projects (they're bound together by EdgeJS). Where the NodeJS projects are concerned, one can be considered a library (for a RabbitMQ bus implementation), two are applications which are meant to be hosted as part of a fourth project with both using the bus.
So, one project (host) which will depend on three projects (bus, app1 and app2) (it starts the bus, and passes it to app1 and app2).
Of course, I could just lump all these projects together and be done with it - but that's a horrible idea.
How do I package these projects up for proper reuse and referencing (like assemblies in traditional .NET)?
Is that best done with NPM? If so, does VS provide anything in this area? If not, then what?
Note that, aside from the Bus project, I'm not looking to release these publicly - I'm not sure if that changes anything.
In general, if something can be bundled together as an independent library, then it's best to consider this a Node package and thus, refactor that logic out to it's own project. It sounds like you've already done this to some extent, separating out your bus, app1, and app2 projects. I would recommend they each have their own Git repositories if they are separate packages.
Here's some documentation to get you started with Node packages:
https://www.npmjs.org/doc/misc/npm-developers.html
The host project, if it's not something you would package but instead deploy, probably does not need to be bundled as a Node package. I would instead just consider this something that would be pulled down from Git and started on some server machine.
With all that said, your last line is important:
I'm not looking to release these publicly
GitHub does have private repositories, but as of now npmjs.org does not have private repositories. There are options to create your own private repository (Sinopia and Kappa offer different ways of accomplishing this), but if you don't want this code available for everyone do not deploy it do npmjs.org. You can still package it up in the way I've outlined it above, just not deploy it as of yet.
I'm a Node n00b starting a couple web app projects using Express, and I've got some common client-side libraries I'd like to share between the two projects. This seems like a very common problem, so there must be several solutions available already.
I come from a java background, and in java, I'd create a separate "common" project and "overlay" common WAR over my project during packaging. This would also allow for r.js optimization during the build process.
My best guess in Node is that I need to create a private NPM module, and map those common files into express via a use() middleware plugin. Is that right?
How, then, can I package both my common and project specific javascript into a minified file using r.js?
Or is source control the answer? Checking out my "common" repository inside each project?
Any help would be most appreciated. Thanks.
This seems like a very common problem, so there must be several solutions available already.
Good news: Yes, this is a common problem. Yes, there are several "solutions".
Bad News: All of the "solutions" are at least partially terrible.
Here's my advice:
1) Individual .js files should be coded as CommonJS modules
2) Groups of related .js files should be made into npm packages
3A) Use them in node via the regular node.js/CommonJS require function and use browserify to use them in the browser
3B) OR use a built tool like grunt to wrap commonjs into AMD format for use with requireJS in the browser
3C) OR consider something like component.io components
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.