We are planning to have a parent pom and which has four modules.We are thinking of using dependency management.
There are two versions of Junit and proj1 used 3.6 version and proj2 uses 4.6 for an example.
I would define both on the parent level.
Now when the child module runs.how will it understand that it should use 3.6 or 4.6 correspondingly.
please help.
Regards
Barath
I assume you will go via the following structure:
+-- root (pom.xml)
+--- proj1 (pom.xml)
+--- proj2 (pom.xml)
If come to the result to create a multi module build which have expressed by saying four modules than a situation like you described can be solved in two ways.
First you decide say both module have to use the same dependency and version of it. This can of course sometimes lead to problems or sometimes it's not really solvable.
You can't define both versions of the same artifact in dependencyManagement.
On the other hand you can define one version in depenendencyManagement (with an appropriate version but only one of them for example 4.6). Than a sub module can decide to override that suggestion and explicit define the dependency with a different version (3.6).
Related
Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
I would like to integrate an existing Xcode project A into another project B so the second one could reuse some features.
Project A :
quite complex, manage authenfication + session, a lot of dependencies betweens classes (notably UIViewController)
relies on a dozen of Cocoapods dependencies
the project lives on its own : it's a sale channel/ticket shop that is already deployed on the store as it
constant evolution
Project B :
Project customer side that would love to integrate some parts of the sale channel
Complexity might be very variable (using Cocoapods or not, etc)
Basically we can either deliver and package the e-commerce shop for one of our customer if he does not already have an iOS application, or we have to integrate it in their existing one.
Expectation :
ideally we could pursue the evolution and iteration on the core Project A without having a lot of work to make it available for integration (it would be more cost efficient for us to work on a single project than on the core one and separate SDK/Library made from scratch)
we want to make it easy to integrate for the customer on its own
The approach we have been thinking to are :
build a .a library file. But it does not seem really practical considering the size of the project
dropping the .xcodeproj from A into B (à la ZXing), but it was a pain because of Cocoapods dependencies
Simply adding all the classes from A into B (with a proper packaging into folders first), manage Cocoapods for B (add dependencies from A if Cocopoads already used or set it up), and make all imports easier by editing .pch accordingly.
What would be your suggestion ?
Since you are already using cocoapods I would try to do a private pod(s) with the shared characteristics. That way you can easily track versions across projects and use the same tool to manage all the dependencies.
This approach also would make easier for the customer to integrate as he will see the shared code from the pod as long he has access to the repository but not the complete main project.
I am trying to use the ":spring-security-core:2.0-RC2" (using Grails version 2.3.1), but have my own LoginController.groovy. Following Burt's notes (here and here), I copied the LoginController.groovy from the original location at "myapp\target\work\plugins\spring-security-core-2.0-RC2\grails-app\controllers\grails\plugin\springsecurity" to my project location at "myapp\grails-app\controllers\com\company". Now I get a bunch of import error messages like "Groovy:unable to resolve class ..." (I have attached am image below showing all the imports giving errors). How do I take care of these errors?
Sorry if this is a trivial question (still getting used to Grails), and thank you for the help!
It looks like GGTS/STS isn't entirely aware that the plugin is installed, since those classes are from the two jars that the plugin depends on. Try right-clicking the project node in the tree and running Grails Tools > Refresh Dependencies. If that's not enough, run Project | Clean to force a full recompile.
I have two projects in an F# solution.
1. main project with [EntryPoint] and set as the StarUp project.
2. support, the second project, holds a group of support modules. I.e. they are only called and never initiate anything nor serve as the entry point nor are the StartUp project.
For the last module in the support project, compiling in Visual Studio gives
warning FS0988: Main module of program is empty; nothing will happen
when it is run
While using compiler option nowarn inline as #nowarn "988" in the module causing the warning does suppress the message I would rather add something like a dummy function with comments that resolves the issue.
How does one make such a dummy function to resolve the warning?
EDIT
Jack is correct in that my support project was setup as a Console Application instead of a Class Library. Changing to Class Library resolved the warning. It is also nice to know about do () for the other case.
EDIT
While it seemed odd that I would have set a support project as a Console Application, I recently found that for some reason when I made a change to the code in the project, something changed the Output type from Class Library to Console Application. I suspect it has to do with the F# PowerPack and it's build rules, but it's only a guess.
Are you building the support project as a Library or as a Console Application? (This is set via the project properties page.)
If you're building it as a library, then you may need to add a do() at the end of the last file in the project. This is necessary to make the F# compiler happy in a few specific scenarios, like when you create a module which contains only assembly-level attributes (because they're applied to the assembly, the module appears "empty" to the compiler).
You can see an example in my code here:
https://github.com/jack-pappas/FSharp.Compatibility/blob/master/FSharp.Compatibility.OCaml/AssemblyInfo.fs
I'm adding some non-trivial functionality in my rails application and it needs to be in a module and not one of the auto generated models. I'd like a few suggestions on where the file containing the module should go (currently I've added a 'code' directory on the same level as 'models' and 'views' - but I don't know that that's a strong choice).
Most people add this type of code in lib
If it's related to the controller/view layer, consider putting the functionality in a helper. If not, lib is a good general storage directory for util classes and the like. If at all possible, think about making extra code like this a plugin, as it helps keep the codebase clean and reusable functionality available to other projects.