When I applied pattern in JDL, the generated entity classes has #Patternannotation, but the value for that annotation is not the exact pattern which applied in JDL.
For example, if I've defined patterns as pattern('/[^\\s]+.*[^\\s]+/') and in java
it reflects as
#Pattern(regexp = "[^\\\\s]+.*[^\\\\s]+")
If you noticed in java class, there are 4 (slash) which indeed should be 2 only. Because of this functionality is getting failed.
It looks to me like you are trying to use regex control characters in your pattern, which do not need to be doubled up in your JDL: see https://www.jhipster.tech/jdl/entities-fields, especially the part under "Regular Expressions" where it says: "/.../ the pattern is declared inside two slashes... \ anti-slashes needn’t be escaped"
So it's acting correctly. Since you have double-backslants in your JDL, Java is correctly interpreting it with quadruple-backslants. Your solution is just to use single backslants in your JDL, as per the documentation.
Related
The JOOQ Java code generation tools uses regular expressions defined in the includes and excludes elements to control what is generated. I cant find an explanation of what the schema structure is that these expressions are run against.
I want to have the ability to exclude specific databases in the server as well as tables by prefix or specifically.
Simple examples:
Given a SQL server with two DBs 'A' and 'B', how do I instruct JOOQ to only generate for tables in DB 'A'?
How do in instruct JOOQ to only generate for tables starting with the prefix "qtbl"?
It would be great if there were some example use cases available showing some simple common configurations.
The jOOQ manual section about includes and excludes, as well as a few other sections that explain the code generator's usage of regular expressions to match identifier establishes that the code generator will always try to:
Match fully qualified identifiers
Match unqualified identifiers
Or, if you're using jOOQ 3.12+ and did not turn off <regexMatchesPartialQualification/>:
Match partially qualified identifiers (see #7947)
For example:
<excludes>
(?i: # Using case insensitive regex for the example
database_prefix.*?\. # Match a catalog prefix prior to the qualifying "."
.*?\. # You don't seem to care about schema names, so match them all
table_prefix.*? # Match a table prefix at the end of the identifier
)
</excludes>
In addition to the above, if you want to exclude specific databases ("catalogs") from being generated without pattern matching, you'll get even better results if you specify your <inputCatalog>A</inputCatalog>. See also the manual's section about schema mapping.
Benefits include a much faster code generation, because only that catalog will be searched for objects to generate, prior to excluding them again using regular expressions. So, your configuration could be this:
<!-- Include only database A -->
<inputCatalog>A</inputCatalog>
<!-- Include only tables with this (unqualified) prefix -->
<includes>qtbl.*</includes>
I'm working on a math word problem solver, and would like to pass whole problems to my GATE Embedded application using JAPE. I'm using GATE IDE to display the output, as well as run the pipeline of GATE components. Each problem will be in its own paragraph, and each document will have several problems on it.
Is there a way to match any paragraph using the JAPE left-hand side regex?
I see three options here (there may be more elegant solutions):
1) Use simple rule like:
Phase: find
Input: Token
Options: control = once
Rule:OneToken
(
{Token}
)
In RHS you could get a text and use standard Java approach for getting paragraphs from plain text.
2) Use LHS (if you really want only LHS)
Rule: NewLine
(
({SpaceToken.string=="\n"}) |
({SpaceToken.string=="\r"}) |
({SpaceToken.string=="\n"}{SpaceToken.string=="\r"}) |
({SpaceToken.string=="\r"}{SpaceToken.string=="\n"})
):left
Build annotation NewLine, then write a Jape rule similar to 1) but with NewLine instead of Token. Take all NewLines from outputAS and build your Paragraph annotations.
3) Sometimes there may be right paragraphs in Original markups. In this case you could use Annotation Set Transfer PR and get them in Default Annotations Set.
why not just use RegEx Sentence splitter PR to use Split as the Input in your jape rules?
I see that in the cobertura-maven-plugin, I can configure my instrumentation with both excludes and ignores. What is the difference between these two?
Really sorry, but parroting the horrible documentation is not helpful. You quoted:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
This inconsistent paragraph starts by stating "...to ignore certain classes by passing in 'ignore' regular expressions.", then a second sentence later, "This will ignore any calls to any method that matches the ignore regular expression."
Well, so which is it? Does "ignore" ignore classes or methods? The command-line reference seems to imply ignore is ignoring a line of code based on RegEx matching (I wish that was true):
None of these interpretations works for <ignore> in the maven plugin.
Experimentally I have found that <exclude> is the way to exclude at the class-level. I have not found a way to exclude at a granularity less then class. However, what they also don't tell you is that <exclude> expects a relative filesystem path, not a Java package.class expression, which means <exclude> expects e.g. one/two/three/Myclass.class, rather then "one.two.three.Myclass".
Ignore and exclude really function nothing alike. Exclude will remove a file from Cobertura's scan. Ignore will remove all usages of a class from contributing to line coverage.
Consider the following code snippet:
public class Foo {
public void someMethod() {
Bar bar = new Bar();
}
}
If you configure <exclude>Foo.class</exclude>, then the entirety of the Foo class will not show up on your reporting.
Semi-confusingly, if you configure <ignore>Foo.class</ignore>, then Foo will still show up on your reporting, but uses of Foo in other classes will be ignored.
If you configure <ignore>Bar.class</ignore>, then the scan of Foo will ignore the line in which Bar is initialized.
To really make that stick, let's talk about why you would use ignore. Let's say that there is an object (such as a Logger) that you do not want to show up in the code coverage scan of any classes. Ignore allows you to do this.
The maven plugin does not contain any documentation for this configuration options (but they are included in the docs). The ant cobertura doc contains the following documentation:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
See also: https://github.com/cobertura/cobertura/wiki/Ant-Task-Reference#cobertura-instrument-task
I am trying to do an XSL transform on an xml structure in a bpel assignment statement. There is a syntax problem, but I am having trouble finding official documentation. There are examples all over the internet but I have not found a clear explanation. Here is my best shot. What do the last two parameters do? Why is eclipse saying the first argument must be a literal, even though test3.xsl is a string?
<bpel:assign validate="yes" name="Assign">
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("test3.xsl", $personalInfoServiceOutput.parameters), "middle", $positionSkillManagementInput]]>
</bpel:from>
<bpel:to variable="positionSkillManagementInput"></bpel:to>
</bpel:copy>
</bpel:assign>
The signature of doXSLTransform looks as follows:
object bpel:doXslTransform(string, node-set, (string, object)*)
The first parameter is the name of the XSLT script, the second parameter is an XPath identifying the source document (e.g. a variable, part, nodeset, node). The third and the fourth parameter is a key-value pair, the string is the key and the object is the value. Those pairs are mapped into the script's parameter context so that you can access these values by their name in the script. There can be any number of these pairs.
The best resource to look up such things is the WS-BPEL 2.0 specification, doXSLTransform is described in Sect. 8.4
When I use the following code :
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("parseSample.xsl", $output.payload)]]>
</bpel:from>
<bpel:to variable="output"></bpel:to>
</bpel:copy>
I also get the error, that first argument must be literal string.
But, when I deploy my service (with error) to wso2 bps, it works fine.
You can try with this.
I faced the same issue. Agree with NGoyal. Shows error in BPEL but works when deployed.
i have something like
<s:link view="/member/index.xhtml" value="My News" propagation="none"/>
<s:link view="/member/index.xhtml" value="#{msg.myText}" propagation="none"/>
where the value of myText in the messages.properties is
myText=My News
The first line of the example works fine and replaces the text to "My News", but the second that uses a value from the resource bundle escapes the ambersand, too "My News".
I tried also to use unicode escape sequences for the ambersand and/or hash with My\u0026\u0023160;News, My\u0026#160;News and My\u0026nbsp;News in the properties file without success.
(Used css no-wrap instead of the previous used xml encoding, but would be interested anyway)
EDIT - Answer to clarified question
The first is obviously inline, so interpreter knows that this is safe.
The second one comes from external source (you are using Expression Language) and as such is not safe and need to be escaped. The result of escaping would be as you wrote, basically it will show you the exact value of HTML entity.
This is related to security (XSS for example) and not necessary i18n.
Previous attempt
I don't quite know what you are asking for but I believe it is "how to display it?".
Most of the standard JSF controls contain escape attribute that if set to false won't escape the text. Unfortunately it seems that you are using something like SeamTools which does not have this attribute.
Well, in this case there is not much to be done. Unless you could use standard control, maybe you should go and try to actually save your properties file as Unicode (UTF-16 BigEndian in fact) and simply put valid Unicode non-breaking space character. Theoretically that should work; Unicode-encoded properties files are supported in latest version of Java (although I cannot recall if it was Java SE 5 or Java SE 6)...