I'm bit cunfused with building the WSO2 IS user store from source code.
The documentation says checkout from:
https://svn.wso2.org/repos/wso2/carbon/platform/tags/turing-chunk01
and there is a turing-chunk01\carbon-platform\components\user-stores
However, the binary distribution seems to be compiled from
https://svn.wso2.org/repos/wso2/carbon/kernel/tags/4.2.0
and there is a carbon-kernel\core\org.wso2.carbon.user.core\4.2.0\
The implementation of both user stores differes a bit.
Besides turing-chunk01...\user-stores\org.wso2.carbon.user.store is missing a parent POM.
Is WSO2 IS intended to be compiled from carbon/kernel or turing-chunks? I would like to do few modifications.
User kernel source of 4.5.0 release can be found at here that you have mentioned. Basically you can find user.core source from here. If you have the change in user.core, you can modify the code,, Build it and then new jar file can be copied to /repository/component/plugins directory and replaced the existing jar. When you restart the server you can see the new changes.
If you want to build the all source... then you need to build the carbon/kernel and carbon/platform also.
Related
I used Draper in Source Edition UE5(release version UE4.24 and UE5.0.3 works correctly ), operated 1,2, and 3 according to ReadMe in the installation path, and also replaced BuildId. However, when I opened the project tips : build through you IDE
I get an error when I don't follow the README:
enter image description here
ReadMe Info:
uDraper plugin is distributed in a binary form (without source code).
There where some undocumented but well known ways to achieve this without breaking the build of C++ projects in UE4.
But in UE5 it seems not to be the case anymore (there are plenty of complaints about this issue on the Internet).
At this point we can suggest a somwhat hacky way to make your C++ projects work properly in the presence of uDraper plugin:
Copy UnrealBuildTool.DraperHook.* files into [UE5 Root]\Engine\Binaries\DotNET\UnrealBuildTool
Replace "UnrealBuildTool.exe" with "UnrealBuildTool.DraperHook.dll" in [UE5 Root]\Engine\Build\BatchFiles\Build.bat
replace "UnrealBuildTool.exe" with "UnrealBuildTool.DraperHook.exe" in [UE5 Root]\Engine\Config\BaseEngine.ini ("UnrealBuildTool" value under "PlatformPaths" section)
It's still a work in progress so we hope to find a better solution in the future.
Regarding custom Engine builds we expect that the binary distribution of the uDraper plugin should be compatible as long as ABI didn't change.
Just replace "BuildId" in Draper\Binaries\Win64\UnrealEditor.modules to your "CompatibleChangelist" from [UE5 Root]\Engine\Build\Build.version
step 1:
enter image description here
step 2: The original file says "UnrealBuildTool.dll" not "UnrealBuildTool.exe"
enter image description here
step 3:
enter image description here
The above modification is still the error of FIG. 1
step 4:
enter image description here
open project
enter image description here
I opened the project with VS and compiled it successfully, and opened it again with the same erro.Previously, the plug-in was placed in the project path to open the project promptFailed to generate Projiect files,
We try to keep uDraper plugin up to date with official UE releases and do not attempt to support custom builds from GitHub.
The instructions you're referring to might be helpful but we do not guarantee that it will work with any GitHub version.
You can try to find an earlier UE version on GitHub to better match an officially released version and try it out.
I’ve been trying to explore WSO2 Microgateway and set up a Microgateway project. Building the project in Windows 10 with the command “micro-gw build project-name” is giving this error: “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”.
I’ve downloaded the Toolkit and Runtime from https://wso2.com/api-management/api-microgateway/. I've set the Path environment variable to the /bin directory of the Toolkit and Runtime extracted folders, but still the “micro-gw build project-name” command is giving error “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”. I’ve also cloned the source code from Github (https://github.com/wso2/product-microgateway/) which has the Main.java class and tried setting environment variables to its path.
I also tried setting the environment variables to the path where Toolkit batch file is present. I also followed the steps mentioned here, https://github.com/wso2/product-microgateway/#running-the-microgateway.
I'm assuming the Toolkit batch file (micro-gw) would execute the Main.java class coming up in the error.
These steps did not resolve the error. I'm new to Java based product, and I'm sure I'm missing something here.
Problem is with the init command not the build command. Init command is suppose to setup the TOOLKIT after the first use. It should extract the platform.zip file and copy all of the required resources to relevant places for you.
I hope you get the Project ___ successfully initialized message after running the init command. Just check $TOOLKIT_HOME/logs/ directory to see if there are any information on the log file.
If the log file also doesn't help, as a workaround, copy all the .jar files inside $TOOLKIT_HOME/lib/gateway/platform and $TOOLKIT_HOME/lib/gateway/cli to $TOOLKIT_HOME/lib/platform/bre/lib and try again, that should work.
Also please report this issue at https://github.com/wso2/product-microgateway/issues
How I can build local sources and dependancies with flatpak-builder?
I can build local sources
flatpak build ../dictionary ./configure --prefix=/app
I can extract and build application with dependancies with a .json
flatpak-builder --repo=repo dictionary2 org.gnome.Dictionary.json
But no way to build dependancies and local sources? I don't find sources type
like dir or other, only archive, git (no hg?) ...
flatpak-builder is meant to automate the whole build process, with a single entry-point: the JSON manifest.
Everything else it obtains from Git, Bazaar or tarballs. Note that for these the "url" property may be a local URL starting with file://.
(There is indeed no support for Hg. If that's important for you, feel free to request it.)
In addition to that, there are a few more source types (see the flatpak-manifest(5) manpage), which can be used to modify the extracted sources:
file which point to a local file to copy somewhere in the extracted sources;
patch which point to a local patch file to apply to the extracted sources;
script which creates a script in the extracted sources, from an array of commands;
shell which modifies the extracted sources by running an array of commands;
Adding a dir source type might be useful.
However (and I only flatpaked a few apps, and contributed 2 or 3 patches to the code, so I might be completely wrong) care must be taken as this would easily make builds completely unreproducible, which is one thing flatpak-builder tries very hard to enable.
For example, when using a local file source, flatpak-builder will base64-econde the content of that file and use it as a data:text/plain;charset=utf8;base64,<content> URL for the file which it stores in the manifest included inside the final build.
Something similar might be needed for a dir source (tar the folder then base64-encode the content of the tar?), otherwise it would be impossible to reproduce the build. I've just been told (after submitting this answer) that this changed in Git master, in favour of a new flatpak-builder --bundle-sources option. This would probably make it easier to support reproducible builds with a dir source type.
In any case, feel free to start the conversation around a new dir source type in the upstream bug tracker. :)
There's a expermental cli tool if you want to use it https://gitlab.com/csoriano/flatpak-dev-cli
You can read the docs
http://docs.flatpak.org/en/latest/building-simple-apps.html
http://docs.flatpak.org/en/latest/flatpak-builder.html
In a nutshell this is what you need to use flatpak as develop workbench
https://github.com/albfan/gnome-builder/wiki/flatpak
I've cloned the OpenLayers 3 repo and merged the latest from master. There exists a recently merged pull request that I'm interested in exploring, but I'm not sure how to create a regular old comprehensive, non-minified build.
Does anyone know how to create a non-minified, kitchen sink (everything included) build for OpenLayers?
(similar to ol-debug.js).
You can use the ol-debug.json config to concatenate all sources for the library without any minification.
node tasks/build.js config/ol-debug.json ol-debug.js
Where the ol-debug.json looks like this:
{
"exports": ["*"],
"umd": true
}
The build.js task generates builds of the library given a JSON config files. The custom build tutorial describes how this can be used to create minified profiles of the library. For a debug build, you can simply omit the compile member of the build config. This is described in the task readme:
If the compile object is not provided, the build task will generate a "debug" build of the library without any variable naming or other minification. This is suitable for development or debugging purposes, but should not be used in production.
if a file is checked out in ClearCase; it would use the earlier version and still would build, is this correct? I'm thinking they had a checkout that was to fix a build issue and the build failed because of the checkout
as far as I know, clearcase using the current file, so if file is checked out in a view and you build this view it will take the checked out file
However, note that if you do uncheckout and you are not using cmake, it might miss this change, since the timestamp of the file after the uncheckout operation is older
The config spec of a view usually starts with:
element * CHECKEDOUT
That means that, yes, your view will select the current file, whatever the other selection rules are.
I recommend checking for files in checkout, but also hijacked files (modified locally without having been checked out, for snapshot view, or even eclipsed files for dynamic views) before starting a build.
Check also for any other "private" files (not initially present and selected in the view), because they also can influence a build by their presence.