My Maven site contains serveral Asciidoctor documents. I would like to use the properites declared in the configuration of the Maven Site plugin, but it seems so that they are not overhanded to Asciidoctor.
<plugin>
<artifactId>maven-site-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
</dependency>
</dependencies>
<configuration>
<attributes>
<ta>ddd</ta>
</attributes>
</configuration>
</plugin>
Here is an example how I try to use the attribute ta in my Asciidoctor documents.
= Example Document
Value of ta is: {ta}
How can I use the attributes defined for Maven Site plugin in my Asciidoctor documents?
At the moment (as of AsciidoctorJ 1.52) it is not possible to use the attributes of Maven Site in Asciidoctor documents.
I filed an issue on this (https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/170).
For the time being I found a workarount. I use the resouces plugin to write all properties to a file and include this file in my documents. A workaround. A direkt access to defined attributes would be more convenient.
Related
I googled the following questions, but answers to them I was unable to find. They are interrelated so I am putting them together in one post. I am a Java backend developer using Eclipse IDE, using JSTL fmt:message tags in a Maven Spring 4 Java project.
Question #1:
If you have a jsp file, that includes another jsp file in it, where does the fmt taglib go?
Question #2:
Can the fmt:setBundle tag have a nested fmt:message tag?
Question #3:
Where does the message.properties file have to be located for use with the fmt:setBundle tag?
Answer #1:
If you are going to use fmt:message with fmt:setBundle and fmt:setLocale, you will need the fmt taglib. This is obvious I am sure. However, in addition, if you have a jsp file, that includes another jsp file, using the jsp:includes tag, and the included file is the one that contains the fmt tags, then the fmt taglib goes into the included file, and NOT in the wrapper file.
<%# taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%>
Answer #2:
I was unable to get the following to work. Eclipse said that the fmt:setBundle tag must be empty. However, I did see examples on the web that nested the fmt:message tag within open and close fmt:setBundle tags.
<fmt:setBundle basename="message">
<fmt:message key="name"/>
</fmt:setBundle>
See: https://www.baeldung.com/jstl
I WAS able to get the following to work.
<fmt:setLocale value="en_US" />
<fmt:setBundle basename="com.studypartner.properties.message" var="lang"/> // approach #1
<h1><fmt:message key="name" bundle="${lang}" /></h1>
<fmt:setBundle basename="message" var="lang"/> // approach #2
<h1><fmt:message key="name" bundle="${lang}" /></h1>
To make this code i18n, you can set the locale to whatever you want from the list of language_COUNTRY codes, and if you have a matching property file, the code above will print the value of key "name" to the page. For instance, I created a properties file called "message_en_US.properties". Since I set the locale to "en_US", and the end of the basename is "message", the properties file I have will be found and the key "name" that is in this file, that matches the fmt:message tag, will end up in the tag above. That part about "lang" in the tags above just seems to be necessary to link the bundle to the message.
See: https://www.tutorialspoint.com/jsp/jstl_format_message_tag.htm
Here's a list of language and country codes:
https://docs.oracle.com/cd/E13214_01/wli/docs92/xref/xqisocodes.html
Answer #3:
Ok, look at the code for "approach #1" and "approach #2" again, in Answer #2. Why did I repeat it? I wanted to prove that either approach will work. It seems that it is important to place the properties file in the correct location. However, in a Maven Spring 3 Java web project, you can locate it in a few surprising locations, and it will work for any of them. Take a look at the project setup in the link below:
project setup
First, if you don't have a message_en_US.properties file, but you do have a message.properties file, then the fmt:setBundle tag will still work. Also, you can place your properties file in 3 different places, and it will still work.
a) src/main/java > com.studypartner.properties
b) src/main/resources > com > studypartner > properties
c) src/main/resources
"a" and "b" work for
"c" works for
Where of course you would replace "com.studypartner.properties" with your own package name (a, b) or name of nested folders (c).
Basically, this is what they mean when they say that the properties file has to be on your "classpath".
I have the following code to pull in two different categories but this outputs 6 separate files and I would like the output to be just one. How can this be done in AEM 6.0?
<clientlib data-sly-call="${clientLib.js # categories=['cq.foundation-main','cq.shared']}" data-sly-unwrap />
Thanks
In AEM, a category include will merge and compress all the files into a single js (or css) include. This is done per category include.
If you want to merge multiple categories, you should consider using the embed option in categories dependencies. How this works is:
Create a new category (for e.g. cq-embed)
Define embed dependencies ('cq.foundation-main','cq.shared') for the new category you have created.
Reference your new category.
You can also use this tool from ACS to optimise the includes:
https://adobe-consulting-services.github.io/acs-aem-tools/features/clientlibs-optimizer/index.html
It allows you to create the embed categories and reference them in a much cleaner way.
I have Tree.ecore as source Metamodel. I need to write something like this:
model Tree driver EMF {nsuri="http://www.eclipse.org/emf/2002/Tree"};
How can I get exact nsuri of my registered ecore in eclipse?
If you are using #namespace(uri="Tree", prefix="Tree") in your Emfatic metamodel, then the nsuri you're looking for is Tree (nsuri stands for "namespace URI")
I suppose you have generated the model code for your Tree.ecore
Then you get the nsuri and all other elements (like all EAttributes, EReferences etc) via the generated static Package class.
In your case it is probably called TreePackage.
So you get the nsuri like this:
TreePackage.eNS_URI or TreePackage.eINSTANCE.getNsURI()
Update:
If you only have the *.ecore file and want to know the uri, open the file with a text editor and look in the <ecore:EPackage tag at the beginning of the file. There you see the attribut nsURI
I know XSLT in general can be debugged, but how exactly would one go about debugging a DITA transformation, considering its modular XSLT structure and the fact that stylesheets are pointed to by the catalog.xml file?
I want to be able to step through the code during runtime, and be able to set break points, etc.
If you are using the Oxygen editor, you can debug Toolkit transforms using the technique described here (from the Oxygen 14.2 documentation):
Debugging PDF Transformations
To debug a DITA PDF transformation scenario using the XSLT Debugger follow these steps:
Go to Options > Preferences > XML > XML Catalog, click Add and select the file located at [Oxygen Install Directory]\ frameworks\dita\DITA-OT\plugins\org.dita.pdf2\cfg\catalog.xml;
Open the map in the DITA Maps Manager and create a DITA Map PDF transformation scenario;
Edit the scenario, go to the Parameters tab and change the value of the clean.temp parameter to no;
Run the transformation scenario;
Open in Oxygen XML the stage1.xml file located in the temporary directory and format and indent it;
Create a transformation scenario for this XML file by associating the topic2fo_shell.xsl stylesheet located at OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/org.dita.pdf2/xsl/fo/topic2fo_shell_fop.xsl;
In the transformation scenario edit the Parameters list and set the parameter locale with the value en_GB and the parameter customizationDir.url to point either to your customization directory or to the default DITA OT customization directory. It's value should have an URL syntax like:file://c:/path/to/OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/org.dita.pdf2/cfg.
Debug the transformation scenario.
I found this topic by searching for "debug toolkit" in the Oxygen online help.
These instructions are specifically for PDF, but you should be able to adapt these instructions to HTML-based transforms as well.
There is always the good old trick of adding print statements around in the code, which is xslt translates to <xsl:message>. Here is a snippet from my frontmatter transformation:
<!--
<xsl:message>createFrontMatter_1.0</xsl:message>
<xsl:message>artworkPrefix=<xsl:copy-of select="$artworkPrefix"/></xsl:message>
<xsl:message>customizationDir.url=<xsl:value-of select="$customizationDir.url"/></xsl:message>
<xsl:message>imageLogoPath=<xsl:value-of select="$imageLogoPath"/></xsl:message>
<xsl:message>imageNotePath=<xsl:value-of select="$imageNotePath"/></xsl:message>
<xsl:message>imageWatermarkPath=<xsl:value-of select="$imageWatermarkPath"/></xsl:message>
<xsl:message>page-width=<xsl:value-of select="$page-width"/></xsl:message>
<xsl:message>page-height=<xsl:value-of select="$page-height"/></xsl:message>
-->
If I uncomment this, I get a nice debugging block of text in the output log, showing the various values for the settings I use.
In my wicket application i have 3-4 different packages say pack1,pack2 and so on .
In pack1 i have different html and java classes. I am validating the null check by setRequired(true) and getting the message from properties file.I am naming my properties file as Send.properties ... as i have Send.html and Send.java in pack1.In properties file i am mentioning like this
formname.field.Required=The ${label} is missing
I want to validate all the html fields which are present in different html pages of the same package (pack1)in one properties file say pack1.properties .So my question here is will one singe properties will be sufficient for one package where in all the validation will be taken care.
Yes, wicket first looks for the property in the properties file associated to the page, and then in the properties asociated to the package (and after that in parents packages...).
But, as long as I know the package properties file is called package.properties (independently of the package name).