As we know, in order to modify the core classes of Liferay (classes which cannot be changed using hooks), we usually create EXT environment.
Since EXT is quite complex, I think creating a jar containing a modified class would be a good choice (Liferay does the same while giving patch for any bug).
Anybody can provide me the exact steps to create Liferay patch like jar.
Since Liferay 6.0 there's only ext plugins - I find them a lot easier to handle than the old EXT environment. Which version are you using?
The "supported" way is ext, anything else that you add to the application server is most likely depending on the way your appserver loads classes: E.g. if you add jars that should be loaded before the core classes, you might need to name the jar like aaaa-something.jar on one, zzzz-something.jar on another (figuratively). Also, depending on the platform, capitalization might matter.
I believe with all the eventualities, you'll find that ext is a bit more than just dropping a jar, but it solves a quite complex problem. My advice: Use this to your favour.
And, probably most important: Whenever there's a possibility to change some behaviour in hooks: Do so! They're a lot less invasive. If your ext gets changed frequently and is of considerable size, you'll make migrations a lot harder. Keep it as minimal as possible.
Related
I have a jar that works on Java 8.
I would like to create a new jar, that is going to be Multi-Release JAR but empty, just with 'patched' classes in META-INF/versions.
I would like to have a separate jar, so people can include it on Java9, otherwise, they use the default one. Why? Because so many tools are not yet prepared for Java9 MR-Jars.
Would this be possible? Would Java9 MR-Jar override classes from others jars?
Why?
The idea behind Multi-Release jars is that they provide simple patching. In my humble opinion, the way MR jars works is not satisfying.
There are two reasons why I can't make 2 separate Jars:
try to make cross-compile source base that works with Java8 and Java9. You would end up with folders like java, java8 and java9... and then have the build produce two jars, two poms... Yeah, good luck.
Imagine that I even build a library for java9. What about transient dependencies? That would mean that all other libraries that uses mine, would need to have jre8 version that depends on my jre8 version. Just because there is Java9 version!
Here is the story:
My A is a Java library built on Java8 but packaged as Multi-Release Jar which means it contains additional classes for when jar is run on Java9. Additional classes are built separately on JDK9 and I copied them manually (yeah, I know, but it works for now).
Unfortunately, some tools and servers (Jetty) are not aware of MR Jars and this makes them NOT working.
For that reason, I have A-jre8 version of my library, that comes without any extra classes, so servers can use it.
However, if user is using library B that depends on my A, he will still get the MRJar version of A and this will fail again. I want to be able to prevent this somehow. And I can't say to B: hey, could you make B-jre8?
Possible solution
JAR is just about packaging!
Allow the separate jar to patch existing jar.
In my case, I would just include A.jar9 and Java would consider A.jar and A.jar9 together as a package. No need for META-INF/versions. Very clean. And, best of all, it would help in situations like above! If run on Java8, the jar9 jar would make no difference; if run on Java9 the jar9 jar would patch the jar with the same name. Simple as that. No transitive dependency hell.
Rename classes in META-INF/versions.
Common Oracle, have you ever heard about the classpath scanning? Could you at least rename the classes in versions to e.g. *.class9 so not to be caught by existing classpath scanners.
As it is today (Java v9.0.4) - no.
So allegedly, the configuration tool for Qt went through some changes, necessary to be able to make more streamlined Qt builds, a.k.a "Qt Lite". However, there doesn't seem to be any documentation about how to use that feature, or at least I don't find any, and looking at the comments from the release announcement, others can't neither.
What's more, the changes are definitely in there, judging by the fact that the configuration that I've been using for the last couple of years fails in a bunch of ways. I am not sure how up-to-date the built in help is, since the last time I tried using it for guidance, it turned out it was largely outdated and contained options that were no longer supported.
So it would be nice if someone could shed some light on what has changed and how, and how to configure for "Lite" builds. And especially on module and feature dependencies, because I think we'd all like to avoid wasting time on builds that will start building despite an improper configuration that omits necessary dependencies just to have it inevitably fail and result in nothing but a waste of time.
Per to the changelog:
The configuration system has been rewritten almost from scratch. This improved the consistency between builds on Unix and Windows, but some subtle unintended behavior changes are also possible. Also, some obsolete options have been entirely removed and will now cause errors.
It is not permissible any more to manually #define QT_NO_
anywhere. Instead, configure's -no-feature-* options must be used.
Note that this does not apply to defines which modify behavior rather
than entirely removing features.
The -no-feature-* option family was integrated with the rest of the
configuration system. Numerous existing features were made optional,
and build problems in various reduced configurations were fixed.
This is an ongoing effort known as "Qt Lite".
Features for -no-feature-* lists are in qtbase\src\corelib\global\qfeatures.txt.
All features are enabled by default.
More information can be found in the Qt Lite Overview Presentation and its slides.
You can also use the new UI Tool which is known as Qt Configuration Tool and which is a part of Qt for Embedded Devices package - see its documentation. The configuration tool is available for commercial Qt customers only at the moment (Qt 5.8).
The changes that are behind my failed configuration:
there is no longer the option to specify whether sql support is built-in or plug-in, so the format is now just -sql-<driver>, the documentation is still not updated and lists the old format - -<option>-sql-<driver>.
the -l option to add a specific library has been removed, which is turning out to be problematic in multiple areas.
Edit: Also, this blog entry just posted on doing lite builds might be useful.
Everything that describes what the new configuration system understands is given in the configure.json files scattered around Qt modules. The configure tool uses these files to build a list of command line arguments it understands.
Without the use of other tools, to learn about Qt features you need to inspect these json files and choose the features/options you wish turned on or off.
Sub Configurations
These act as includes, and refer to the configure.json file in a given folder. E.g. qtbase/configure.json includes qtbase/src/corelib/configure.json, qtbase/src/network/configure.json etc.:
"subconfigs": [
"src/corelib",
"src/network",
[...]
],
Explicit Command Line Options
The commandline/options value lists the configure options a given Qt module understands. These options are separate from the feature system, although they may be used for convenience to provide shorthand aliases that control features. For example, in qtbase/configure.json, we have:
{ "commandline": { "options": { "accessibility": "boolean", [...] }
This command line option controls the identically named accessibility feature. It is more convenient to use than dealing with the feature system's option [-no]-feature-accessibility. The following pairs have identical effects:
-accessibility or -feature-accessibility
-no-accessibility or -no-feature-accessibility
Values:
boolean options are given to configure as -option and -no-option, meaning true and false, respectively.
all other options are given as -option value.
Feature Options
The features value lists the features available in a given module. The features are effectively booleans. They are all enabled by default, subject to passing configuration tests that enable them.
To control a feature foo:
-no-feature-foo disables the feature. E.g. to disable the iconv feature, you'd do configure -no-feature-iconv [...].
-feature-foo enables the feature and ensures that it is available. This will cause an error if a configuration test for the feature fails. It's useful in build systems that build a particularly configured Qt along with your application: it ensures that the features your code depends on will be available.
Failing Builds
Generally speaking, no matter what combination of feature selections you provide, if configure doesn't fail, the build is supposed to succeed.
we'd all like to avoid wasting time on builds that will start building despite an improper configuration
The configure tool will detect any invalid configurations. If configure succeeds yet the build fails, it's a Qt bug and you should report it.
I'm frustrated by the lack of flexibility in the Visual Studio project/solution, but I realized that now that it uses MSBUILD it might be quite powerful but just doesn't expose that to the IDE. So I took a look at MSBUILD docs and don't know where to start! I wish there was a Nutshell book for that. Is there any good tutorial someone could point me to?
More specifically, here is the kinds of things I want to do:
Run a utility pre-processor to generate .CPP and .H files, which are then used by a regular C++ project. There are multiple inputs (to figure dependencies of; specifically should know if a normal .h file it uses has changed) and multiple outputs (at least one .cpp and one .h file) that are used as files in another project.
FWIW, the most complex case involves using Qt in a "normal" C++ project that can be built using VS Express 2010 or MSBUILD directly from a script on a server. Since that is a common library, there might be some guides or whatever to help? Note that a VS plug-in is not useful for the building stage, but could be used to initially generate project files that then rely only on MSBUILD and stuff included with the source code.
Would somebody please point me in the right direction?
--John
It gets worse from there, but that's my first goal.
I found the kind of information I was looking for in a book MSBuild Trickery: 99 Ways to Bend the Build Engine to Your Will by Brian Kretzler.
In the first 18 pages I found a few key pieces of information that, along with the on-line documentations I've already gone through, helps clear things up enough to try tackling my project. Details of interest include the processing order of how MSBuild reads and operates on the things in the file, quick points on when wildcard in items are expanded and how to handle generated files, and how to see what's happening in some practical cases or even step in the debugger.
FWIW, I managed to attack my problem without using the murky ".targets"/rules files that I have yet to understand, but only using better documented/exampled features (in particular, a Target that has wildcard items doesn't care that the file name extension is not in any ".target"; is simple enough to copy from example and allows the files to be seen in the IDE Project and added to the list using the IDE; again, the FileExtension there just works OK.)
I have modifyed XMLEncoder class from Flex SDK (XMLEncoder.as)
After it I run my project but I don't see any changes...
What should I do to realy modify project's behaviour?
Thanks!!!
It's not usually recommended but what you are trying to do is Monkey Patching. You can just copy your modified source file into your project and then you application's XMLEncoder will overwrite the one used in Flex (because of how the Flex linker works). This doesn't work with the framework RSLs though.
If you don't see changes, this means sources aren't used - swc is used instead. To use modified sources, recreate folder structure for the class you modified and put source there. You may see a lot of errors (most of the time because include directive), this means you need to copy files needed to satisfy dependencies.
Maybe this is not the right way, but sometimes it's the only option to fix broken Flex class, so professional Flex developer masters it sooner or later :)
Setting up Flex project for group development can be a bit tricky. There are lots of little local settings that might need to be tweaked in order to have a project that can be easily checked out.
I've had limited success using the built-in import/export flex project utilities. I seem to wind up editing by hand a lot and I think I might be missing something.
UPDATE
I neglected to mention originally that my goal is to make it possible to checkout a project from subversion and get up and running with as little fuss as possible. The biggest problems that I have run into all revolve around managing the "dot" files and how to make them flexible enough to deal with different developer environments.
For example, even with just me, I would like to have this ability: at work, I use a Vista machine and at home I use a Mac. There are certainly differences in the way certain paths are described, but they really are quite similar. On Vista, the flex root is c:/ColdFusion8/wwwroot, on OS X, it is /Applications/ColdFusion8. I have been able to set up a linked resource path variable for both CF_FLEX_SERVER and WEBSERVER that I then reference using the ${WEBSERVER}/myProject syntax.
So far, it seems to work pretty well, but I find there are a few places that it still has issues. Specifically, in the .project file you find something like:
<linkedResources>
<link>
<name>bin-debug</name>
<type>2</type>
<location>c:/inetpub/wwwroot/myProject-debug</location>
</link>
</linkedResources>
Unfortunately, if I try to change the location entity to ${WEBSERVER}/wwwroot/myProject-debug, flex throws a compiler error. That's a shame, because pretty much everything else works.
I have worked through this problem before and generally set my projects up as such:
Application/trunk/source/ <-- workspace is here (can also be in 'trunk')
Application/trunk/source/Application <-- Application here
I DO keep my project (.actionScriptProperties, .flexProperties, .project, .settings) in SVN, but NOT my workspace (.metadata) because it's too big.
I find that importing projects via Import -> Flex Project enforces alot of restrictions. For example, if your workspace was in the 'trunk' directory above then importing as a Flex Project will cause the project to be copies into trunk/Application or simply complain about the location.
The better way to go about it is to create the workspace and then Import -> [General] Existing Projects into Workspace. The only difference is that you will have to manually add the Flex Development perspective.
Edit: I'd also recommend setting your compiler options to "Use default SDK" and then setting the appropriate SDK as default. This will prevent commit-tennis when each developer names his SDK differently.
Since Flex Builder is written on top of Eclipse, it can integrate with Subclipse. This allows you to pretty easily tag files as 'SVN ignore' to avoid project-specific settings. I've used this to add my Flex projects to an existing SVN repository, which I've checked out to multiple sites. I have noticed a few issues here and there (some checkins get errors, but they're relatively rare), but it generally works.