I have recently started using Sightly in AEM 6.1, which allows the Java files to be located in the same folder as the component and use the WCMUse class. However, I am noticing that whenever I do a Maven build that involves a change to one of those Java files that the page functionality operates as if the Java class had not been changed, though the Java file in the crx does include the changes. As a workaround I have been been able to modify the Java file in the crx, save it, then modify it back and save again in order to update the functionality, but I do not have that capability on all of my instances.
Anybody have an idea how to force the recompile of the Sightly Java within the components either during or following the build?
A few things to validate:
1- Do you change the version of the software when doing a maven build/deploy? Sometime if your zip or jar does not have -SNAPSHOT in it AEM won't update the code when maven deploys.
2- there a /var/classes/sightly in CRX/DE that you can delete compiled classes, I think even in the system console there is an entry
Hope this help.
Bambara actually helped me get to the answer that I needed. It turns out the /var/classes folder holds the compiled sightly files, but it doesn't naturally recompile on build. Deleting that folder on build, then running a page that uses the sightly code forces a recompile and shows the new functionality.
Hopefully others can answer why this happens and how to avoid it. Having faced this a number of times, I'm beginning to think placing Java code into the component folders is not a very good idea. Using a maven multi-module project with a Services/Core bundle, then all Java code could go there. Calling it from the view just requires using the fully qualified classname (including the package). Placing the Java into the services bundle has the following benefits
Allows the classes to be extended. For some reason compilation was unpredictable when extending classes from component folders.
Easier IDE setup. Java classes in component folders in the view module have a Sling specific folder structure, so getting IDE's to provide code assist requires extra effort.
Sling folder conventions follow URI practices and might have dashes, Java packages cannot have dashes... import apps.my-cool-project.components.pages.base.Header; // won't compile
Related
I want to run adempiere customization with webui from eclipse using webtool and tomcat server, so i can run and debug code more efficiently for webui customziation.
These thing i have tried in adempiere trunk by using following link :-
http://www.adempiere.com/Creating_WebUI_Workspace_using_Eclipse_Webtool
,but for this i can not do in customization. As i build trunk project using utils_dev/build.xml after that it created webui.war which showing while adding project in server. As for customization given directory were not available i have copied that in customization and try to build it it's not working and showing a lot of files not found. As i think that's not correct way because many of files will not be there in customization.
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
Secondly i have tried one another link :- https://github.com/adempiere/Customization-Template, in which it showing i have to customize ant build.xml files. As the project is available to me i referred the build.xml files also created build.xml files in client,base and zkwebui folder. But while executing that xml file it showing following error message. I think it's related issue with deprecation, but i am confused in this i will get proper output or not.Any one please suggest me how can i accomplish this things.
The given link http://www.adempiere.com/Creating_WebUI_Workspace_using_Eclipse_Webtool worked successfully for adempiere trunk project but that's not worked for customization. Can any one suggest me how can i accomplish same for customization
Second link i have followed :- https://github.com/adempiere/Customization-Template the same process i followed which i mentioned above.
Check the online book section on development environments. This may be a copy of what you were reading in the wiki. (Note, the wiki has moved to wiki.adempiere.net).
To create customizations in ZK, you'll need to create a file zkcustomization.jar and add it to the install ADEMPIERE_HOME/lib directory (not the eclipse project) before you RUN_Setup/RUN_SilentSetup to build. Any class you add to this jar will override the equivalent class in the main project.
From Eclipse, you can modify the main project directly and debug it normally but you will need to keep track of the classes you modified and add them to the jar file manually. This is a bit tedious.
The template approach is useful when you have many customized classes and need to ensure you get the jar file correct. It allows you select or add the specific java files you require and modify them while keeping the core project untouched. It suffers from the lack of a "hot-swap" feature which is so useful in the SWING interface and also that the web deployment doesn't span projects. For this reason, when debugging the customized ZK interface, the template needs to copy all the compiled classes from the main project in order to deploy the web server. There are ANT configurations/scripts to help with this but they may need some tweaking as the main project is updated. Also, the template needs access to the correct libraries so you may have to update the build configuration as you add customizations. Once you can run the adempiere zk interface from the template, you can create the zkcustomization.jar file automatically. Then be sure to add it to your deployment package.
Its a bit of a hassle getting the template configured but it works quite well once you have it set up.
I have a class BaseLoginDialog under a dependency which needs to be modified as it is not extendable out of the box. For this reason, I have created another file BaseLoginDialog under my project's module with the same package path as the original BaseLoginDialog. After adding some new methods in my own local BaseLoginDialog, I cannot use them anywhere in my project without IDEA complaining about the method not being declared. However, the project still compiles and the methods work fine on runtime. If I click the import to browse to the file, IntelliJ still links to the old file but it seems to correctly compile with the new one.
How can I go about fixing this issue? Always having error lines and red markers everywhere makes it confusing when coding.
Some background:
The project uses Gradle for the dependencies and compilation. Compiling and running works both with Gradle and with the IntelliJ run operation, it is only the errors being incorrectly displayed that is an issue.
The Grade file adds the required libraries as dependencies. Even though Gradle has both the source and class files, opening a file imported through Gradle still links to the class files. To get around this I also added the required files as sources under Libraries.
Any help would be appreciated, thanks!
EDIT:
Switched to use a Maven repo on the project, now I don't need to additionally add libraries anymore but this problem still persists.
If two classes of the same name and package exists in the classpath of an application, it's the one that is contained in the first dependency on the command line that gets used.
In IntelliJ, you can reorder dependencies, so you can put your local dependency before the other library. I'm not sure if that works with gradle projects, however.
But I don't think that's a good practice? Why can't you put the extra methods in a subclass, e.g. EnhancedLoginDialog, and use that one?
Or, if the original library is open source, fork it, make the changes and install it as a custom version, e.g. dialogs-1.0-CUSTOM-1.jar, and use this version in your project. And while you're at it, create a pull request for the library's maintainer to include your fixes in the next version :-)
I have resolved the issue.
The file I was copying into my local files was BaseLoginDialog. The file showing errors was my NewLoginDialog which extends LoginDialog which extends BaseLoginDialog. It seems that when IntelliJ goes to my NewLoginDialog, it sees that I have extended LoginDialog. Therefore it jumps into the library files and finds that LoginDialog extends BaseLoginDialog, now when it goes to find BaseLoginDialog, it uses the library files and ignores my local copy of BaseLoginDialog.
Essentially, once IntelliJ branches into a library, it does not move back out when looking for additional files if it can already find it inside the library.
To solve this issue, I simply also copied LoginDialog locally, even though it is identical (simply branched it and did not change anything). Now IntelliJ finds LoginDialog in my local files and as a result also finds BaseLoginDialog locally.
Hope this helps anyone having the same problem in the future.
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
I'm currently working in a big java project with quite a few submodules that are worked on by different teams. Some of these teams are building the "framework", others are building the "application" based on the framework.
When the framework guys move or rename a class, the applications guys get compile errors wherever they are using a refactored framework class. Is there a way in Eclipse (Galileo Release) to record the change and update the references in another workspace?
What I've tried so far is creating a refactoring script during the rename refactoring, but when I try to apply that script to another workspace, it fails with The refactoring 'Rename Type' (org.eclipse.jdt.ui.rename.type) cannot be performed, since its input 'xxx.TestClass" does not exists. Well, it does not exist (anymore) alright, but what I want is for all references for xxx.TestClass in my project to be changed to xxx.MyRenamedTestClass. Is there a way in Eclipse to do this with built-in functionality or an existing plugin or do I have to write one myself?
Thanks for your help!
EDIT: By now I found out that the "Migrate JAR"-Plugin provides the functionality I am looking for, although we build our JARs with Maven, not Eclipse. I'm going through the source code now to find out what parts I can reuse.
Answering my own question to get some closure here.
The easiest way to do it is to use the Migrate JAR File... refactoring which uses a refactoring script in META-INF called REFACTORINGS.XML. You can get a JAR with this included automatically by using Export JAR in Eclipse. We build with Maven and thus just do Refactoring->Create Script... and put it into the appropriate position in the JAR.
The JDT-internal code that Migrate JAR executes creates Stubs for the source classes in a temporary source folder, so it actually executes the refactoring first and then updates the references. The user never gets to see these temporary files.
I'm beginning to play with Clojure a bit and my Java experience is pretty limited. I'm coming from the dynamic world of Ruby and OO, so the functional side of things is very interesting!
Anyway, as I discover libraries and various tools for use (and the tutorial files for the Pragmatic Clojure Book), everything typically calls for placing files in the CLASSPATH in order for Clojure to see the library for use.
Is there such thing as good CLASSPATH practice? Would I ever want to only have a CLASSPATH with just the external libraries of files I need or can I go ahead toss any library or file I would ever need in a directory and simply define it as my CLASSPATH and only require what's needed?
If it helps, I'm an OSX and Emacs user (Using slime and swank-clojure).
I recommend using leiningen and lein-swank to manage this. You can start a REPL in the directory and connect to it from Emacs.
Personally, I'm using a variant of a clojure-project elisp function by Phil Hagelberg, see source in this post to the Clojure group. It sets up the classpath appropriately for the project you'll be working on, then launches SLIME. (EDIT: You'll need to change the value which gets assigned to swank-clojure-jar-path to point to clojure.jar. I'm using (expand-file-name "~/.clojure/clojure.jar") as the default.)
To answer the question about having everything on the classpath all the time vs only throwing in what's needed: to the best of my knowledge, nothing will actually break if you take the first approach (I know I do that for experimental purposes), but apparently things might break with the first approach (see cjstehno's comment below) and in a proper project I find the second to be cleaner. At some point it'll be necessary to determine what libs are being used (and which versions of them), if only to tell leiningen (or maven) about it -- why not keep tabs on it as you go.
We are using Clojure and use a number of infrastructure tools, especially Eclipse (IDE) (http://en.wikipedia.org/wiki/Eclipse_%28software%29) and maven (http://en.wikipedia.org/wiki/Apache_Maven). maven manages libraries and jar dependencies so if you have a number of these and they are likely to grow start using maven.
In answer to your original question you can just put your jars in one directory and you can access them by name every time you run. But you will benefit from the tools...
If you are just exploring then Eclipse will probably manage your jar files fairly painlessly. You can add these to the project as required through the Build Path -> Configure Build Path option.
As your work progresses you will possibly wish to split it into Projects which Eclipse supports so you can add your (or other projects) to your Build Path.
If you use external Clojure libraries look to see if they have been packaged as maven projects (they will have a pom.xml file). The POM will give a list of dependencies.
#
The usual CLASSPATH practice for Java is to put only the jar files needed for a project into this projects class path, which means to have potentially different class paths for diffent projects. This is usually managed by the IDE as part of it's project properties.
Since you are using Emacs and thus probably don't have or use something like projects it might be more convinient for you to set up and use a single global class path for all your clojure related stuff or maybe even simply put all the needed jar files into the java2se/jre/lib/ext directory of your java installation.
The two main problems that could arise from having unneded jar files in your class path are: 1. it has a minor negative impact on the start up time of the JVM and 2. it becomes more difficult to make sure that you are not having classes with different versions in the same class path (i.e. different classes with the same package and name in different jar files).
Since Java SE 1.6 (or JDK 1.6) you can include class path entries by wildcard. If your class files live in .\bin, and your library jar files live in .\lib, then on Windows you could define your class path like this:
set CLASSPATH=bin;lib\*;
This will let you add jar files into the .\lib directory and they will automatically be added to the class path for new instances of the JRE.
See this link for details: Setting the class path
Prior to JDK 1.6 you had to add each jar file onto the ClassPath individually.
I just discovered this bit which I need to give a shot:
(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))
clojure-contrib/launchers/bash/clj-env-dir has an interesting property that you can point it at a directory and it will basically include anything in there. In the past I've had a ~/classpath directory which I would dump any jars into and link any commonly used directories and it worked great. Very simple way to dump and use. Now I tend to use Maven clojure-maven-plugin and that works well also though can be a bit tedious when you just want to muck around with some ideas.