What is the best way to organize the patch files? Imagine you have a patch file for an open source application and you modify it and want to keep the modifications in a patch.
What is the best solution: add the new modifications to the other patch in order to have a single big patch file or create the second patch file and have a bunch of them one for each modification.
If you choose the second one, what about patchs that modify the same files and lines and therefore can cause conflicts while patching? Do i have to stablish an order?
One patch per issue posted to the projects issue tracker. Otherwise, keep your changes in Git or whatever and use a branch for major projects. Often I have a branch for each module, then a branch for each patch that I'm working on.
Related
I'm trying to figure out how to set a flag in the Bazel BUILD file or .bazelrc file so that I can turn on the --warn_duplicate_resources or --no_duplicates flags when building a Java jar (actually Scala in my case, but the answer should be the same). I want to make it so that if Bazel sees duplicate files when packaging a jar (such as two different logback.xml files) the build will fail instead of picking one file and discarding the other.
I had some issues with shadowing of different resources when building a new jar using an old jar. After rummaging through the internet I found the --warn_duplicate_resources flag in the bazel code base in a few different places as well as a --no_duplicates flag. These seem like they would be helpful making sure to avoid the problem of multiple jar files defining the same resource file.
https://github.com/bazelbuild/bazel/blob/master/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/SingleJar.java
https://github.com/bazelbuild/bazel/blob/master/src/tools/singlejar/output_jar.cc
However, I have no idea what flags to put in the BUILD or .bazelrc files to get the --warn_duplicate_resources or --no_duplicates flags turned on. The java_library rule doesn't seem to have any direct connection and simply adding "build --warn_duplicate_resources" to the .bazelrc caused the build to fail.
https://docs.bazel.build/versions/master/be/java.html#java_library
Any help will be much appreciated, thanks!
Can I use a styles.css file uploaded on GitHub as styles for multiple projects? I'm trying to define a default style for my projects here: https://raw.githubusercontent.com/GhitaB/default-design/master/styles.css
I prefer to link this file instead of copying it in multiple projects.
RawGit serves raw files directly from GitHub with proper Content-Type headers.
Or, consider using Github Pages
Here we need to distinguish between duplication of code and resources. What you don't want is copying code, because those files would diverge and you'd need to repeat every change for all of them. Having one file uploaded to multiple servers, however, shouldn't be a problem as long as you have one place to edit them all at once.
For this case there's Git submodules. The idea is basically having a repository with the shared part and then including that repository in a specified path in your other projects. You can read more about it here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
This way all your IDE-based and external tools will still work and your website can be deployed as a whole. If, at some point in the future, you decide to have separate CSS files, you can simply replace the submodule with a file and you won't need to change the paths in HTML.
Of course, you can also use the same exact resource in multiple projects simply by pointing them to the same URI, but then the uncoupling might be harder afterwards and you can't see the file in your IDE.
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
Doxygen is a bit slow - it takes about a couple of minutes to process my whole project, so for small incremental changes this is longer than actually building the rest of my code. There are thousands of files without any documentation so I guess it is spending most of its time processing them. Is there any way to get it to skip files without any documentation?
What about getting it to only process changed files?
From Doxygen documentation:
How can I exclude all test directories
from my directory tree?
Simply put an exclude pattern like
this in the configuration file:
EXCLUDE_PATTERNS = /test/
So, you should be using patterns to exclude files. It's been a long time since I've used Doxygen, but i don't remember any option to process only changed files.
I found that turning off the option SEARCH_INCLUDES made a big difference. It was looking through the whole platform SDK and include paths for the compiler which were not documented anyway and would not appear in the generated documentation.
There is a DOT_NUM_THREADS options which may increase the performance on multicore machines. Unfortunately doxygen itself is just single threaded.
Another approach would be to organize your code into modules run for each module a separate doxygen instance and link the resulting tags together: http://www.doxygen.nl/manual/external.html
Doxygen is good at finding connections between files, either changed or not. But Doxygen does not remember informations about unchanged files, so it must process the whole codebase each time.
May be a solution would be to organize the project such that never changed files belong to one module which is excluded from Doxygen scope and whose documentation is already available. Then it would be possible to tell Doxygen to link newly built documentation to this existing module documentation.
Going further, it would also be possible to make Doxygen running module by module, processing only changed modules and a top level documentation which links to all module documentations.
I don't think having Doxygen run on a normal dev cycle is a good idea. Our Doxygen build runs as part of our Continuous Integration server's responsibilities.
That said, there are some benefits of running doxygen every build to catch missing docs.
So I would trim the doxygen config for dev builds removing diagrams, and even stop apple importing it into xcode.
if you're familiar with Liferay you'll know that when you make an itsy-bitsy change to a css file you shall rebuild the theme and redeploy it.
As for redeploying I made a symlink (mind you I'm on Windows: for the curious creating a symlink on Vista is just a matter of issuing mklink /d dir1 dir2).
But what about rebuilding the stuff with maven? I'd rather skip that step. Basically what it does is combyining and packing all CSS in one everything_packed.css. Is there a sort of config variable to tell liferay just to include the raw files and skip redeployment alltogether?
Thanks
Guys I found the solution myself.
You should have a file called portal-ext.properties file in
$TOMCAT_DIR/webapps/ROOT/WEB-INFO/classes
Or more specifically for my win setup in
C:\liferay\webapps\ROOT\WEB-INF\classes
The file would hold the value
theme.css.fast.load=false
This will prevent liferay to be looking for the everything_packed.css and so you're free to modify your stuff without rebuilding and CTRL-R to refresh the page and see the changes.
Just for completeness, as this question is somewhat old and the problem already solved: There's a lot more along these lines, e.g. javascript, layouts etc. that can be used uncached. This is documented in either the Liferay Wiki (as Developler Mode) or the Development Guide, available from the documentation site (though currently it's not there for the last version - if it's still not there when you're reading it, look for it (PDF) in the older versions.
It's advisable to use these settings only in development, not in production, as putting all css and javascript in as few files as possible results in a huge performance impact.
to include all those settings, just can also just add the following line into your portal-ext.properties file:
include-and-override=portal-developer.properties
this will include all the developer specific settings, and when you want to remove them, you can just comment out this line.
you can edit the css files of your theme from Webapps{your theme}\css
And can see the changes directly.
You can edit almost every file which doesn't require compilation.like .jsp files but not .java files