I need to overwrite /util-java/src/com/liferay/util/Normalizer.java
I found code on git.
I followed this instructions and able to do ant clean
I read this
Putted my .java file in my-ext-plugin/docroot/WEB-INF/ext-util-java/com/liferay/util/Normalizer.java
ant build
BUILD FAILED
`/liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/build-common-ext.xml:122: The` following error occurred while executing this line:
/liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/build-common-ext.xml:173: The following error occurred while executing this line:
/liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/build-common.xml:80: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/normalizer-ext/docroot/WEB-INF/ext-service/src does not exist.
I know that the right way is to create an child of Normalizer.java and overwrite those private methods but I'm wondering where to put those files.
I surprised how little information you can find about this. And all Liferay gurus acting like it's very simple. But it's not.
UPDATE
buld.username.properties
app.server.dir = /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23
ext.work.dir = /liferay/bundles
app.server.zip = /liferay/portal/liferay-portal-tomcat-6.1.0-ce-ga1.zip
UPDATE 2
I created ext-service/src folder and was rewarded by BUILD SUCCESSFUL.
ant compile and ant deploy is working
url-redirect-fix-ext is the name of my ext plugin.
[root#localhost url-redirect-fix-ext]# ant deploy
Buildfile: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/url-redirect-fix-ext/build.xml
compile:
compile-with-global-class-loader:
compile-java:
compile-with-portal-class-loader:
compile-java:
compile-with-portal-class-loader:
compile-java:
compile-with-portal-class-loader:
compile-java:
compile-with-portal-class-loader:
compile-java:
war:
war-util:
war-util:
war-util:
[delete] Deleting: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/dist/url-redirect-fix-ext-6.1.0.1.war
[zip] Building zip: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/dist/url-redirect-fix-ext-6.1.0.1.war
[delete] Deleting: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/url-redirect-fix-ext/docroot/WEB-INF/ext-url-redirect-fix-ext.xml
deploy:
[copy] Copying 1 file to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/deploy
BUILD SUCCESSFUL
But ant deploy not working
[root#localhost url-redirect-fix-ext]# ant build
Buildfile: /liferay/plugins/liferay-plugins-sdk-6.1.0-ce-ga1/ext/url-redirect-fix-ext
/build.xml
BUILD FAILED
Target "build" does not exist in the project "url-redirect-fix-ext".
I followed instructions and deployed my plug-in, then rebooted server.
Here is my Tomcat log. I guess plug-in was deployed successfully.
15:36:18,815 INFO [AutoDeployDir:167] Processing url-redirect-fix-ext-6.1.0.1.war
15:36:18,818 INFO [ExtAutoDeployListener:43] Copying extension environment plugin for /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/deploy/url-redirect-fix-ext-6.1.0.1.war
Expanding: /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/deploy/url-redirect-fix-ext-6.1.0.1.war into /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829
Copying 1 file to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829/WEB-INF
Copying 1 file to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829/WEB-INF/classes
Copying 1 file to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829/WEB-INF/classes
Copying 1 file to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829/WEB-INF
Warning: WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies/ext-url-redirect-fix-ext-util-bridges.jar modified in the future.
Warning: WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies/ext-url-redirect-fix-ext-util-java.jar modified in the future.
Warning: WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies/ext-url-redirect-fix-ext-util-taglib.jar modified in the future.
Warning: WEB-INF/ext-impl/ext-impl.jar modified in the future.
Warning: WEB-INF/ext-service/ext-service.jar modified in the future.
Warning: WEB-INF/ext-util-bridges/ext-util-bridges.jar modified in the future.
Warning: WEB-INF/ext-util-java/ext-util-java.jar modified in the future.
Warning: WEB-INF/ext-util-taglib/ext-util-taglib.jar modified in the future.
Warning: WEB-INF/ext-web/docroot/WEB-INF/liferay-portlet-ext.xml modified in the future.
Warning: WEB-INF/ext-web/docroot/WEB-INF/portlet-ext.xml modified in the future.
Warning: WEB-INF/ext-web/docroot/WEB-INF/struts-config-ext.xml modified in the future.
Warning: WEB-INF/ext-web/docroot/WEB-INF/tiles-defs-ext.xml modified in the future.
Warning: WEB-INF/liferay-plugin-package.properties modified in the future.
Warning: WEB-INF/ext-impl/classes modified in the future.
Warning: WEB-INF/ext-impl/classes/com/liferay modified in the future.
Warning: WEB-INF/ext-impl/classes/com/liferay/portal modified in the future.
Warning: WEB-INF/ext-impl/classes/com/liferay/portal/deploy modified in the future.
Warning: WEB-INF/ext-impl/src modified in the future.
Warning: WEB-INF/ext-lib modified in the future.
Warning: WEB-INF/ext-lib/global modified in the future.
Warning: WEB-INF/ext-lib/portal modified in the future.
Warning: WEB-INF/ext-service/classes modified in the future.
Warning: WEB-INF/ext-service/src modified in the future.
Warning: WEB-INF/ext-util-bridges modified in the future.
Warning: WEB-INF/ext-util-bridges/classes modified in the future.
Warning: WEB-INF/ext-util-bridges/src modified in the future.
Warning: WEB-INF/ext-util-java modified in the future.
Warning: WEB-INF/ext-util-java/classes modified in the future.
Warning: WEB-INF/ext-util-java/com modified in the future.
Warning: WEB-INF/ext-util-java/com/liferay modified in the future.
Warning: WEB-INF/ext-util-java/com/liferay/util modified in the future.
Warning: WEB-INF/ext-util-java/src modified in the future.
Warning: WEB-INF/ext-util-taglib modified in the future.
Warning: WEB-INF/ext-util-taglib/classes modified in the future.
Warning: WEB-INF/ext-util-taglib/src modified in the future.
Warning: WEB-INF/ext-web modified in the future.
Warning: WEB-INF/ext-web/docroot modified in the future.
Copying 8 files to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/webapps/url-redirect-fix-ext
Copying 2 files to /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/webapps/url-redirect-fix-ext
Deleting directory /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/tomcat-7.0.23/temp/20120605153618829
15:36:19,062 INFO [ExtAutoDeployListener:50] Extension environment for /liferay/bundles/liferay-portal-6.1.0-ce-ga1-new/deploy/url-redirect-fix-ext-6.1.0.1.war copied successfully. Deployment will start in a few seconds.
Jun 5, 2012 3:36:25 PM org.apache.catalina.startup.HostConfig checkResources
INFO: Reloading context [/url-redirect-fix-ext]
15:36:25,612 INFO [PluginPackageUtil:1099] Reading plugin package for url-redirect-fix-ext
15:36:25,618 INFO [ExtHotDeployListener:226] Extension environment for url-redirect-fix-ext will not be undeployed
15:36:26,090 INFO [PluginPackageUtil:1099] Reading plugin package for url-redirect-fix-ext
15:36:26,133 INFO [ExtHotDeployListener:234] Registering extension environment for url-redirect-fix-ext
15:36:26,133 INFO [ExtHotDeployListener:152] Extension environment for url-redirect-fix-ext has been applied.
Not working. There is still bug in my portal.
So ether the solution I found on Git not handled my bug
Or the new Normalizer.java not overrided old Normalizer.class
How can I be sure?
UPDATE 3
ant deploy
ERROR [ExtHotDeployListener:189] Extension environment for normalizer-ext cannot be applied because of detected conflicts:
url-redirect-fix-ext:
ext-util-java/com/liferay/util/Normalizer.java
ext-web/docroot/WEB-INF/liferay-portlet-ext.xml
ext-web/docroot/WEB-INF/portlet-ext.xml
ext-web/docroot/WEB-INF/struts-config-ext.xml
ext-web/docroot/WEB-INF/tiles-defs-ext.xml
ext-web/docroot/WEB-INF/web.xml
You change code from util-java, but put it into util-bridges? Try putting it in ext-util-java. It seems that there's no spring autowiring involved calling this, and there are only static methods in that class, so you probably just need to copy the existing code and patch it as you like, then compile.
Edit/Added:
From the error message it looks like you followed this paragraph from http://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/creating-an-ext-plugin too hard:
Tip: after creating an Ext plugin, remove all of the files added by
default that are not necessary for the extension. This is important
because Liferay keeps track of the files deployed by each Ext plugin
and it won't allow deploying two Ext plugins if they override the same
file to avoid collisions. By removing any files not really necessary
from an ext plugin it will be easier to use along with other Ext
plugins.
You should only remove the unrequired files in the plugin - not the directories. The errormessage you state says that
normalizer-ext/docroot/WEB-INF/ext-service/src does not exist
Edit 2:
In your latest edit you say that "ant deploy" is not working but the command that you actually execute is "ant build" - with ant complaining that the "build" target is not found. Try again with "ant deploy"
Edit 3:
This is more an interactive debugging session than a Q&A :-)
You can have as many ext plugins as you like, but every file can only be overridden (contained) in one ext plugin. The error message tells you what's wrong: The files that the build process complains about are modified from different ext-plugins. That's why the quote (see above in my answer, the "Tip" section) says to remove the files from your plugin unless you really need&override them. The files that the build process is complaining about are exactly the files that the create-script automatically starts an ext plugin with.
Related
I have a rather complex CMake configuration, which contains several execute_process commands which create files during the configuration stage. Sometimes after some changes in the CMake configuration the generation stage deletes these files. I can reproduce that.
I've checked that the files exist after the configuration stage but are gone after the Makefile generation and before actually calling make.
The files are created in some cases simply by ${CMAKE_COMMAND} -E copy and in other cases by calling a script with ${CMAKE_COMMAND} -P which contains a configure_file call to replace some placeholders in a template.
The files are created in the source tree. Their purpose is to provide the developer with some initial code. When the developer has edited the files, they should be committed to version control and not be re-created again unless they are missing. I have add_custom_commands to recreate the files if they're missing, but those are not the culprit.
I know, you'd prefer a simple test example, but unfortunately this is not so easy to create, so my question is:
What might be the cause and how can I debug that?
Unfortunately, the --trace options of cmake do not give any log data about the generation stage.
Versions
OS: Ubuntu 16.04
CMake 3.5.1 (belonging to Ubuntu 16.04)
Update
I've compiled CMake itself with the current master commit (696b2d4) and the behavior is still the same.
By running CMake under a debugger I've discovered that the line
cmSystemTools::RemoveFile(fname);
in function cmGlobalGenerator::CheckRuleHashes(std::string const& pfile, std::string const& home) actually deletes the files. It is called from cmGlobalGenerator::Generate().
With further debugging (see update in the question) I've found the cause of my problem.
CMake's behavior
CMake's global generator creates the file ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeRuleHashes.txt. It contains a line for every custom command with outputs. Each line contains a hash and the path to the first output of the custom command.
The hash is made over the current binary dir of the custom command and the entire content of the COMMAND arguments of add_custom_command.
On generation CMake executes cmGlobalGenerator::CheckRuleHashes to check if the hashes are still up to date. If a hash is not up to date the corresponding output file will be removed, obviously to trigger re-execution of the custom command in the build stage.
Cause of my problem
As mentioned in the question I execute the file creation command with execute_process during configuration and call add_custom_command with the same file creation command to trigger re-creation of the file in case it was missing.
So, CMake creates a hash line in its CMakeRuleHashes.txt for the file to be created.
Some of my add_custom_command calls are contained in a CMake file included from different CMakeLists.txt belonging to different sub-directories of the source. Depending on my actual configuration only specific sub-directories are added with add_subdirectory.
Thus, because the sub-directory is part of the hash of the custom command, the hash changes depending on the sub-directory added which includes the custom command. The changed hash then causes the deletion of the output file.
Conclusion
I have to redesign my CMake configuration to resolve the dependency of the custom command on the CMake binary directory.
Debugging generation stage
This could be done by compiling CMake itself as Debug build type and run it under a debugger.
I am following the manual packaging guide on the AppImage GitHub manual. For AppRun I am using the AppRun-x86_64 from https://github.com/AppImage/AppImageKit/releases (7th July 2019)
I have a name.desktop file in a name.AppImage folder where I replaced name with the project name and the name.desktop gives no error if validated by desktop-file-validate.
Yet, I receive the following error message when running the created AppImage and when running ./AppRun directly:
Error: No .desktop files found
Where does it look for the file and what is the required naming scheme?
Version of appimagetool appimagetool, continuous build (commit fef038a), build 2093 built on 2019-07-07 12:07:34 UTC.
Solved. Accidentally copied the AppRun to my executable. So AppRun -> calls AppRun can't find the .desktop in the usr/bin directory.
I leave the question in case somebody makes the same mistake.
First, I'm a Jenkins neophyte. I have made a free-style software project in Jenkins to perform my Linux build. The Jenkins server is running on Windows so there are slave nodes configured for doing this Linux build. The sources are kept in a TFS server.
I updated our TFS plugin to the latest of 4.0.0. This plugin says that it is no longer necessary for slave nodes to have the Team Explorer Everywhere package installed as it uses the Java API. However, when I kick off my build, I get this:
Started by user Andy Falanga (afalanga)
[EnvInject] - Loading node environment variables.
Building remotely on dmdevlnx64-01 (PY27-64 CENTOS6-64 LOG4CPLUS PY26-64) in workspace /home/builder/jenkins/workspace/Linux Autotools Build
Deleting project workspace... done
Querying for remote changeset at '$/Sources/Branches/Andy/AutotoolsMigration' as of 'D2015-10-05T18:26:27Z'...
Query result is: Changeset #4872 by 'WINNTDOM\afalanga' on '2015-09-25T23:36:24Z'.
Listing workspaces from http://ets-tfs:8080/tfs/SoftwareCollection...
... Long list of workspaces
Workspace Created by Team Build
Getting version 'C4872' to '/home/builder/jenkins/workspace/Linux Autotools Build'...
Finished getting version 'C4872'.
[Linux Autotools Build] $ /bin/bash /tmp/hudson7081873611439714406.sh
Bootstrapping autotools
/tmp/hudson7081873611439714406.sh: line 4: ./bootstrap: No such file or directory
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE
I log into that system and look in the directory /home/builder/jenkins/workspace/Linux Autotools Build and sure enough, there's nothing there. My configuration is pretty simple.
I have discard old builds checked and a simple rotation (this is just me learning how to use it).
I have it set to "Restrict where the build is done" and a label which associates to the 3 slave nodes for doing this build.
All TFS credentials are input and correct.
No build triggers
A simple shell script for Build->Execute Shell which bootstraps the autotools and calls configure and then make.
What am I doing incorrectly?
I found the answer and am posting it here in case someone runs into this. This seems better than simply deleting the question. The TFS plugin doesn't seem to like spaces in the project name. The name before Linux Autotools Build which didn't work and the name now, LinuxAutotoolsBuild which does.
The errors provided by the Jenkins system didn't provide enough information for this to be apparent. After trying a few other things the thought occurred, "Perhaps the spaces are causing grief."
Hope this helps someone.
While attempting to bootstrap Haskell on Windows without the Haskell Platform I ran into the following error
C:\git\Haskell\ghc\libraries\haskeline\dist-install\build/libHShaskeline-0.7.1.2.a: could not read symbols: Archive has no index; run ranlib to add one
Note that C:\git\Haskell\ghc is where I put the ghc git repo.
However whenever I looked at the file it appeared to be building correctly.
I have attempted completely clean rebuilds, and deleting the whole repo and regetting it, everything short of deleting anything related to this build and starting fresh.
I eventually figured out what was causing the issue, I realized it when I found the following notice on the Windows Platform notes for GHC.
However, the makefiles do use whatever ld and ar happen to be in your path.
This didn't seem right, and reading the configure script I noticed the following lines:
mingwbin="$hardtop/inplace/mingw/bin/"
LD="${mingwbin}ld.exe"
Note that mingwbin refers to the location that the tarballs are extracted to. Looking at the timestamps of the executables did not match up to the version that which ld returned (in /mingw/bin).
Given the note that meant that at some point /inplace/mingw/bin/ld.exe was being used while at another point /mingw/bin/ld.exe was being used, possibly causing the issue.
Running the following command before make resolved the issue.
export PATH=/c/git/Haskell/git/inplace/mingw/bin:$PATH
An earlier attempt to compile ICU for Windows using MSVC and Cygwin worked fine. This time, however, after a successful
.../icu/source/runConfigureICU Cygwin/MSVC
make ends with the following error:
.../icu/source/stubdata/stubdata.c(20) : fatal error C1083: Cannot
open include file: 'unicode/utypes.h': No such file or directory
No problems with the non-MSVC Cygwin version. I am in a different directory, but it seems that this worked before.
Update. I must have compiled it in the icu/source directory before. I went back and did runConfigureICU in-place and did not see the error. I feel sad that I have to ruin my pristine icu folder, but perhaps there is no other way to compile Cygwin/MSVC. It might have something to do with how the Microsoft compiler handles paths.
Update2. making it in icu/source makes the other location work.
The answer to this is that runConfigureICU can only be called for Cygwin/MSVC in the icu/sources directory, otherwise, cl cannot get to the cygwin-based include path.