I was using old version for JHipster and recently I updated to version 3.0. I am facing trouble with the generated front end code(js, html etc). In previous version it was generating these files at below location:
\src\main\webapp\scripts\app\entities
But due to new version it is generating to:
\src\main\webapp\app\entities
Can someone help to provide the configuration location to correct it??
Related
I am taking this one straight from the repo.
I am using this scenario Azure Samples and when I try to upload the base I get the following error (cut for brevity):
The specified page contract 'urn:com:microsoft:aad:b2c:elements:contract:unifiedssp' has invalid version '2.0.0'. The available versions are: '["1.0.0","1.1.0","1.2.0"]'.
Any thoughts on this?
The current available versions for page layout are ["1.0.0","1.1.0","1.2.0"]. You can find the version change log here.
Try to change the version from 2.0.0 to the available version in PasswordlessEmailAndPhoneBase.xml file.
I have an instance of crafter running with crafter-studio-publishing-receiver-2.5.3-aio.jar, I need to locate the source code for the jar file.
Is this the right repository
What is the significance of the word "legacy" in the name of the project?
You can find the source code here:
https://github.com/craftercms/legacy-deployer
The specific version can be found by checking the manifest of the jar.
- unzip the jar
- open ./META-INF/MANIFEST.MF
- locate the property Implementation-Build: 87c84d58313b2bcbdca306de69758320aee174d0
This value can be placed in github to get the exact code you are looking for.
Example:
https://github.com/craftercms/legacy-deployer/blob/87c84d58313b2bcbdca306de69758320aee174d0/cstudio-publishing-receiver-zip/pom.xml
The reason we renamed the project "legacy-deployer" in github is that with Crafter 3.x we are moving to a new deployment system. Without going too deep on this: The new system is based on Git pulls, as you can imagine, this approach has many benefits. It will support the same concepts (callbacks etc) as the now "legacy" deployer.
I've been trying to figure out how to create a gx:Track with the current version of the Java API for KML. Even though JAK claims to support the latest 2.2 extensions, the kml22gx.xsd that is packaged with the source code does not match the actual latest.
Can someone detail the build process for taking new XSD's and generating a new jak?
I got the jar from someone on Google Groups, here it is: https://drive.google.com/file/d/0B1Y3FuLhrOkHdDRNNTlpaGJuQTg/edit?usp=sharing
(PS I may have made some little changes)
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
Can someone explain to me how to upgrade taxonomies-module? Im currently running version 1.4 of taxonomy-module and I see that the current version is 1.4.2.
Must i disable the module in backend and clone the new source for contrib.taxonomies and rebuild in VS?
I am running 1.6 of Orchard.
Unless stated otherwise in a module's release notes you can simply overwrite the old source with the new (or over-install it with the new version from the Gallery or you have it as a cloned repository then just updating to tip). DB migrations will take care of themselves and you don't necessarily have to rebuild the solution as dynamic compilation will compile the new code on the next page load. (That is, unless you have a deployed Orchard site with dynamic compilation disabled.)