I'm getting error message Could not find Janino library on the class path. Skipping conditional processing. What should I incude in classpath to fix this (lib and version)?
Logback requires the Janino library for conditional logging. You don't need it if you aren't using the structures in your config files.
If you are using conditionals, you will need to add the Janino dependency. You can add this to your pom.xml file to get the dependency:
<!-- The org.codehaus.janino:commons-compiler:2.6.1 dependency -->
<!-- will be automatically pulled in by Maven's transitivity rules -->
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<version>2.6.1</version>
</dependency>
I believe this question is a duplicate of this one.
Related
I'm using the maven-bundle-plugin and trying to bundle Google maps dependency.
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-ClassPath>*;scope=compile|runtime</Bundle-ClassPath>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Directory>OSGI-INF/lib</Embed-Directory>
<Import-Package>
*
</Import-Package>
<_exportcontents>
*
</_exportcontents>
</instructions>
</configuration>
</plugin>
When I inspect the JAR (Manifest.MF) I can see com.google.maps.model in Export-Package but not in Import-Package. How can I get it in the Import-Package as well?
This question is linked to a previously unresolved question How to import a class from third party jar file in an OSGi component
Well, there shouldn't be anything in the Import-Package here, as you're not importing the google maps classes, you are embedding them. You're packing the google jar inside your own bundle, and Import-Package applies only when you want to use those classes exported from another bundle.
As of the other question, I'm not entirely sure (I don't use the maven bundle plugin at all) but the 'exportcontents *' seems suspect, exporting too much can lead to subtle problems.
I'd say start by exporting nothing and add packages as needed.
If you are embedding the jar in your bundle and want to access its classes, use the Include-Resource instruction, it has an option to unroll a JAR resource (see # option)
I'm following a example of HttpClient4.4, which is
https://hc.apache.org/httpcomponents-client-4.4.x/httpclient-win/examples/org/apache/http/examples/client/win/ClientWinAuth.java
However, this class cannot be compiled, because of NOT FOUND WinHttpClients.
I'm sure that the lib I imported is 4.4. So, is there anyone knows what's going on? (I have already checked my classpath. Still not found this class also.)
Thanks
Windows specific is shipped as a separate module. Make sure to add httpclient-win as a dependency to your project
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient-win</artifactId>
<version>4.4</version>
</dependency>
I have got a library project (written in ActionScript), that has two build outputs: One is made by including library A, the other is made by including library B.
My goal is to mavenize this library, and I've come up with the following solution:
I have a multi module Maven project that looks like this:
myLib-Mobile
\- pom.xml
myLib-Web
\- pom.xml
src
\- main
\- actionScript
...code is here
pom.xml
The parent pom.xml holds everything except the one dependency that changes based on the build target (and the FlexMojos compiler, since one needs to be built with AIR the other with Flash). Since the code is not at the usual location I define it this way in the pom files of the children:
<build>
<sourceDirectory>../src/main/actionscript</sourceDirectory>
...
This works fine if I build it in the console, but when I import this as a Maven project in IntelliJ, it does not find the source files - it seems to me that IntelliJ cannot handle if the <sourceDirectory> tag has a reference to the parent directory. The only workaround I found was to manually specify the content root in the project settings.
Anyone knows a better solution? Maybe using modules is not the way to go?
I'm trying to use the new org.omnifaces.converter.ListConverter in a primefaces picklist.
I added the new dependency in my project with maven and rebuilt the project in order to download the jar file:
<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>omnifaces</artifactId>
<version>1.5</version>
</dependency>
I'm importing the namespace in my facelets as follows:
xmlns:o="http://omnifaces.org/ui"
Still, when I try to use <o:converter> in my picklist as follows:
<o:converter converterId="omnifaces.ListConverter" list="#{projectBean.clientSource}" />
I get a message from netbeans 7.3 saying :
The attribute list is not defined in the component converter
It doesn't seem to cause any build failure though...
Am I missing something? Do I not use omnifaces as it is meant to be?
This is, unfortunately, "by design".
Netbeans apparently validates the attributes rather strictly based on their registration in the *.taglib.xml file.
The <o:converter> is supposed to support all attribtues of any arbitrary converter, such as pattern and locale of <f:convertDateTime>, the minFractionDigits and integerOnly of <f:convertNumber>, etcetera. It's however impossible to register all of those attributes in the *.taglib.xml file in order to satisfy all possible use cases of <o:converter>. It namely also supports custom converters instead of standard ones.
It's however valid to specify a "custom" tag attribute and this is where the <o:converter> relies on. The list attribute is actually an attribute of the omnifaces.ListConverter converter. I don't have Netbeans at hands and I'm not sure whether it interpretes it as an error or as an warning and or if it's configurable somewhere in its validation settings, but I can assure you that this is absolutely harmless and should at most generate a warning (and thus not as an error).
In case you didn't understood the use of <o:converter>, it's a special tag handler which evaluates the attributes of the specified converter during view render time instead of view build time. This way it's possible to supply "dynamic" attributes tied to bean properties instead of hardcoded string attributes.
I worked around this issue in netbeans by unzipping omnifaces-2.1.jar.
Edit omnifaces-2.1\META-INF\omnifaces-ui-taglib.xml
Find converter
Add an attribute under converter:
<attribute>
<description>
<![CDATA[
Model source list http://showcase.omnifaces.org/converters/ListConverter
]]>
</description>
<name>list</name>
<required>false</required>
<type>java.lang.String</type>
</attribute>
Just before < /tag >.
Zip the extracted contents (META-INF and org folders) into onmifaces-2.1.jar.
Use that jar in netbeans.
The first time when you add the dependency, netbeans don't update its namespaces list.
Then,
Execute "Clean and Build"
In some cases, restart Netbeans
And its all
The same has happened to me with omnifaces 1.7 and Netbeans 7.3.1
I was wondering why www.json.org/anyone else doesn't provide an official JAR package of org.json for download? All queries I find of people asking where they can download the JAR results in replies to the page which just lists the source files.
It seems a bit cumbersome to expect everybody to download each source file and prepare the JAR file themselves.
Have you considered using Maven? for instance, if you wanted a JAR to pars JSON you could just include...
http://mvnrepository.com/artifact/org.codehaus.jackson/jackson-core-asl/1.9.6
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
<version>1.9.6</version>
</dependency>
in a pom.xml, this will give you the jar for JSON.
Or better yet, use the org.json one...
http://mvnrepository.com/artifact/org.json/json
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20090211</version>
</dependency>
I downloaded a jar from here:
http://code.google.com/p/org-json-java/downloads/detail?name=org.json-20120521.jar&can=2&q=
The implementation from json.org by Douglas Crockford is nōn-free. Luckily, a Free almost drop-in replacement exists (apparently, Google’s code packaged by someone else for Maven Central):
<dependency>
<groupId>com.vaadin.external.google</groupId>
<artifactId>android-json</artifactId>
<version>0.0.20131108.vaadin1</version>
</dependency>
Add this to pom.xml instead of using the json.org one. We had to do only one minor change to our code for this: the vaadin one can throw JSONException in more places, so we had to either catch them or pass them through to the callers (extend the throws declaration).
Beware that the json.org software has a non-open source license. This causes downstream problems in many cases.
The issue is that the license is essentially the MIT license, but it adds a line that says that the software should only be used for good, not evil. This sounds fine, but if you have to get a corporate lawyer to sign off it gets nasty because there is no consensus legal definition of "evil". If you use json.org's library, you can't put your software into Debian, for instance. Your software likewise can't be a dependency for any Apache project.
To help with this, I have adapted and packaged the android clean-room rewrite of the json.org library. The source is on github and is Apache licensed. See https://github.com/tdunning/open-json. To use this, add something like this to your pom (or equivalent):
<!-- https://mvnrepository.com/artifact/com.tdunning/json -->
<dependency>
<groupId>com.tdunning</groupId>
<artifactId>json</artifactId>
<version>1.3</version>
</dependency>
Ping me with pull requests or issues on github or however you like.
Using the com.tdunnning package can lead to dependency conflicts, especially if you make your project available to others as a library. The implementation does not have 100% compatibility with org.json
That package(com.tdunning) has been forked to https://github.com/openjson/openjson with the package renamed to com.github.openjson instead of org.json to prevent conflicts.
The maven dependency:
<dependency>
<groupId>com.github.openjson</groupId>
<artifactId>openjson</artifactId>
<version>1.0.10</version>
</dependency>