I'm seeing some of SF2 components have a folder named stubs placed inside the Resources/ folder. I wonder what is it for? And for my bundle I need to define some global functions, would the stubs folder be a good location to place the files containing these functions?
It seems there are a few meanings for stub. The most relevant I could find was one that described a stub as 'code that is used to stand in for some other programming functionality'.
I.e. acting as a substitute for code that is yet to be developed, or to simulate the behaviour of existing code that isn't usable (or viably usable) under certain circumstances, for example, in a development environment.
Related
I'm creating a template for our server-side codegen implementation, but I ran into an issue for a feature request...
The developers who are going to use the generated base want the following pattern (the generator is based on the dotnetcore):
Controllers
v{apiVersion}
{endpoint}ApiController : Controller, I{endpoint}Api
Interfaces
v{apiVersion}
I{endpoint}Api
I{endpoint}DataProvider
DataProviders
-v{apiVersion}
-{endpoint}DataProvider : I{endpoint}DataProvider
Both interfaces are the same, describing the endpoints. The DataProvider implementation will allow us to use DI to hot-swap the actual data provider/business logic layer during runtime.
The generated ApiControllers will refer to the IDataProviders, and use the actual implementation (the currently active one, that is). For that we're going to use dotnetcore's built-in dependency injection system.
However I can't seem to find a way to have the operations generator output to three different folders, based on the template. It will all end up jumbled in a single folder, and I will need to manually move them.
Is there a way to solve these requirements, or should I solve it all the time manually?
Is there a way to tell the sbt-onejar SBT plugin to produce a JAR in such way that the .class files of my project are in "expanded" form and not under lib/myproject.jar?
Alternatively, is it possible to tell sbt-onejar to produce a JAR that, when it's loaded, it actually unpacks/expands the nested JARs into a temporary folder and loads them from there, so that things like getResource(...) return paths to physical files as opposed to jar:file:... URLs?
Alternativel, I'd also happy with any vanilla OneJar solutions that help me produce a fat JAR wherein my own .class files would be directly under the fat JAR as opposed to under lib/myproject.jar.
I'm asking because Jetty does not seem to be able to load JSP files from inside of nested JAR files. There does seem to be a workaround by using a custom resource loader (see http://dev.eclipse.org/mhonarc/lists/jetty-users/msg01174.html for a report of the same problem and the workaround) but I don't seem to be able to get my servlets to actually use the overridden getResource method provided in the workaround.
After having read sbt-onejar's source code:
packageOptions in oneJar ++=
Seq(sbt.Package.ManifestAttributes(
new java.util.jar.Attributes.Name("One-Jar-Expand") -> "some-file.txt"))
However, I've realized using OneJar with Jetty is quite a problematic beast due to how Jetty loads JSP files—doesn't seem to work with nested JARs—so I'm looking into alternatives now.
EDIT: I've found https://github.com/xerial/sbt-pack and it seems to achieve the same effect as OneJar with the difference of being standard and thus free of problems, much faster, more customizable, and allows defining of convenient custom program entry points.
I am new to ASP.Net MVC. I have a couple of controllers and models. They all use a set of static functions and constants which I call common code.
In my MVC project I have folders for Controller, models and view etc,
Where is all the common code supposed to be put ?
Is is OK to create a Common folder and create new class for my static functions and same for global constants ?
If you reuse this common code often across solutions, you might want to consider compiling it into its own class library and simply referencing the assembly.
Another thing you'll want to consider is the nature of the common functions. Are they truly just helper functions (like manipulating strings and stuff like that) or do they make more sense mixed into your business layers?
Basic rule is to keep it organized be consistent. There's no right or wrong way to structure your application...only hundreds of thousands of opinions.
Exactly you can create Helper folder when you set your extension methods or another common utility.
But for constants suggest you to create Ressource File
Remarks : All text , warning or info messages, put theses elements in ressource and don't write in code, for gloabalization need(It's my case on project)
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.
is there a simple way to generate a JAR file, that contains only the classes that depend transitive from a certain "main" class (reflection omitted of course).
I want to provide a little part of my application to someone else but do not want to export the whole application.
Thanks,
M.
Probably the easiest approach is using a tool like yGuard which "...provides elaborate code shrinking functionality through dependency analysis." This would also solve the same problem where you give it an entry point, and it performs dependency analysis to work out which classes can be excluded from the Jar.
However, I have throught about this problem myself a few times and fancied having a go at it myself for the challenge. All it would take would be to parse the import statements of Java source files and build a dependncy graph of how the classes interact with each other. Each reference from the main class should be recursively scanned until a complete graph is assembled. Then once the graph is assembled it would be a case of outputting this in a way that some packaging logic could process (or if you are feeling daring, the JDK has its own built in Jar creating/modifying code to do it yourself). Granted, this approach would require writing this custom utility and would also miss fully qualified class references in the code.