I have this problem:
I have two Liferay projects, one with the 1.6 plugin and one with the 2.2 plugin. When I deploy My project called IPF-Hook in the 1.6, it deploys with the name IPF-Hook.
The problem is when I deploy my project with the 2.2. It deploys with the name: IPF-Hook-portlet (it adds portlet).
Anyone knows something about that? thank you so much!
Despite the comments (I still have no clue what versions you're talking about), now I'm seeing something that I've missed in the comments
Liferay uses a heuristic to detect the type of plugin that's deployed. This can be helped by naming a plugin *-hook, *-portlet, *-theme etc. . Typically you rather want to help Liferay than depend on the heuristic, thus the development environment tries its best to enforce this naming best practice.
Your hook seems to be named *-Hook (note the capital H) - rename it to have a lower case extension (-hook) and try again. Then it shouldn't be renamed any more.
If you're using the plugins sdk, check that this hook is indeed in the hook folder, not in the portlets folder.
Related
I am using Eclipse Liferay IDE for making a hook to a Liferay native portlet. I mean a porlet that comes with default installation, eg. blogs, content management or similar.
I have done the steps like following:
Select new Liferay Project
Enter project name MyHook
Made configurations (found an SDK directory and Liferay Server instance for Runtime)
Selected Plugin type to Hook
My only option after that was Finish and I ended up having a project with certain structure without any class or properties file inside.
My problem is that I could only get an empty project and don't know how to make the modifications to the files of Liferay because no Liferay originated package names can be found if I make a new class file and try to start typing com.Liferay. or org.Liferay. Because this is a Liferay Hook project, I suppose some Liferay originating tips should normally pop up for my selection, but I didn't see any.
What I am making wrong? What I am missing? Should I know the filenames by myself or is there a trick somewhere to tell the IDE to give me some help?
I use Liferay 6.0 and my IDE version is 6.0.5. At least in my eyes they should match together.
In the IDE you first create a "Liferay Hook Project". This is indeed an empty project. Then you create a Hook, select the Hook project to create it in. You can do the second step manually, but there's a wizard helping you to do this. This might be what you've been missing
I made the same steps again and it worked! Somehow at first time I managed to do a Java project although the project should be interpreted as a Liferay project.
Maybe the IDE is not 100% working always. Whoever knows.
I use the google plugin for eclipse with GWT and Appengine libraries. Every so often I upgrade one of the libraries, which currently involves:
I install the update somewhere on my HD
I add the update as an alternative SDK in eclipse, with a generic name
I update the project settings to point to the new generic name
I commit the changed settings files (which do NOT include the upgraded library) to our source control
The problem here are in unfortunate steps 5-7:
5 Everyone else's builds stop working past the change,
6 I go from machine to machine, repeating steps 1 and 2, and
7 I think for the nth time, "I should really find a way to automate this."
I'm here for the elusive step 8: Actually automating this. I want to include the SDK in my source control, so when I switch between versions or set up shop on a new machine, the relevant SDKs are automatically installed and downloaded. I don't want to have to configure eclipse settings at all. In my ideal situation, I am willing to install Eclipse and the GPE on each machine, but after that I just want to clone my repository and go.
I've tried doing this by removing the GWT library from my build settings, copying the entire GWT installation folder into the root of my project, and adding gwt-user.jar and gwt-dev.jar to the build path from there. This almost works, but eclipse complains that it can't find gwt-servlet.jar (even though it exists precisely where it claims to be looking for it!). There also seem to be other magical settings I don't understand.
Finally, the question: If this is the right track, what settings do I need to manually control? If this is the wrong track, what's the right one?
+1 good question. This may or may not answer your question, but I can share with you what I do. I also work with GAE and GWT.
I just include the SDK .tar/.zip files in my repository, remove the version numbers from the filename, and update it when I want to move to a new version. If that version migration fails, I can easily revert to the old SDKs. I also use GXT and a bunch of other GWT extensions, so my problem is even worse than yours. I don't use eclipse for GAE nor GWT, so I can't relate to the problems you are having there. If you don't want to have to configure eclipse every time, then don't use eclipse.
Disclaimer: I hate eclipse.
I am struggling with the configuration of the Eclipse Dali plugin and Hibernate. The version I'm using is as recommended:
Eclipse 3.6.1 (Helios SR1) IDE for Java EE Developers (including Dali 2.3)
JBoss Tools 3.2 (for the Hibernate Tools plugin)
When configuring the Java Persistence properties for my project, I created a user library named "Hibernate JPA" and included the following JARs:
hibernate-distribution-3.6.1.Final\hibernate3.jar
hibernate-distribution-3.6.1.Final\lib\jpa\hibernate-jpa-2.0-api-1.0.0.Final.jar
hibernate-distribution-3.6.1.Final\lib\required\dom4j-1.6.1.jar
hibernate-distribution-3.6.1.Final\lib\required\slf4j-api-1.6.1.jar
hibernate-distribution-3.6.1.Final\lib\required\javassist-3.12.0.GA.jar
hibernate-distribution-3.6.1.Final\lib\required\commons-collections-3.1.jar
hibernate-distribution-3.6.1.Final\lib\required\antlr-2.7.6.jar
hibernate-distribution-3.6.1.Final\lib\required\jta-1.1.jar
As long as the hibernate-distribution-3.6.1.Final folder is outside of my project directory, everything works fine. However, if I put the Hibernate folder into the project directory, I get an error saying "Required class org.hibernate.SessionFactory does not exist in selected libraries":
The error text is wrong, the required class is definitely included in hibernate3.jar, and everything works as expected when I move the JARs outside of my project directory.
I have two questions about that:
I do not understand why the User Library behaves differently depending on whether the JARs are placed inside or outside of my project directory. Could anybody explain what's happening here?
I would like to have my project in SVN, including all the required libraries. Is there any way to configure Dali to accept User Libraries within the project directory?
Thank you very much.
I was having the same problem cos I forgot to add hibernate-jpa-2.0-api-1.0.0.Final.jar.
The only difference is that I'm using 3.5.1-Final cos 3.6.x seems not stable at the moment.
Actually, I'd prefer EclipseLink: everything works fine as a charm. I've wasted many hours with environment configuration :( Last time I've used Hibernate was years ago and looks like troubles to configure still are the same :(
I have a plugin which at present doesn't have any extension points (neither does it extend any other plugin). To resolve a certain issue I have to create an extension-point for this plugin and an appropriate extension somewhere else.
When doing this eclipse forced me to set singleton:=true in the Manifest file. I know the reason why this parameter has to be set, but I wanted to know if there are any implications on the functioning of the plugin within the product by introducing this parameter.
Thank you.
"singleton:=true" means that bundle only have one version could exist in the OSGi runtime.
Eclipse automatically adds the flag due to you provide an extension point in your bundle. If there are two version of your bundles providing the same extension point(have the same identity, might different attributes or elements) would make things mess.
From the Book Eclipse plugin Development by Dr Alex Blewitt:
The clause
singleton:=true
is an OSGi directive, which means that only one version of this plug-in can be installed in Eclipse at one time.
For plug-ins which add dependencies to the UI, there is a restriction that they must be singletons. (This constraint is one of the main reasons why installing a new plug-requires the IDE to restart.)
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.