i get suddenly an error message, that 3 dependencies are missing: gwt-user.jar, gwt-dev.jar and gxt.jar. All jars are in my local repo:
dage [~/.m2/repository] $ ls -l com/google/gwt/gwt-user
insgesamt 12
drwxr-xr-x 2 dage Domain Users 4096 2010-01-13 14:55 1.5.3
drwxr-xr-x 2 dage Domain Users 4096 2010-01-13 11:10 1.6.4
drwxr-xr-x 2 dage Domain Users 4096 2010-01-13 16:10 2.0.0
dage [~/.m2/repository] $ ls -l com/google/gwt/gwt-dev/
insgesamt 12
drwxr-xr-x 2 dage Domain Users 4096 2010-01-13 14:55 1.5.3
drwxr-xr-x 3 dage Domain Users 4096 2010-01-13 11:02 1.6.4
drwxr-xr-x 2 dage Domain Users 4096 2010-01-15 09:58 2.0.0
dage [~/.m2/repository] $ ls -l com/extjs/gxt/
insgesamt 32
drwxr-xr-x 2 dage Domain Users 4096 2010-01-14 14:29 2.0.1
drwxr-xr-x 2 dage Domain Users 4096 2010-01-21 12:18 2.1.0
-rw-r--r-- 1 dage Domain Users 288 2010-01-21 12:18 maven-metadata-com.extjs.xml
-rw-r--r-- 1 dage Domain Users 40 2010-01-21 12:18 maven-metadata-com.extjs.xml.sha1
-rw-r--r-- 1 dage Domain Users 323 2010-01-21 12:01 maven-metadata-local.xml
-rw-r--r-- 1 dage Domain Users 288 2010-01-21 12:18 maven-metadata.xml
-rw-r--r-- 1 dage Domain Users 32 2010-01-21 12:18 maven-metadata.xml.md5
-rw-r--r-- 1 dage Domain Users 40 2010-01-21 12:18 maven-metadata.xml.sha1
and the pom entry is:
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-servlet</artifactId>
<version>${gwt.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>${gwt.version}</version>
<scope>system</scope>
<systemPath>${gwt.home}/gwt-user.jar</systemPath>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<scope>system</scope>
<systemPath>${gwt.home}/gwt-dev.jar</systemPath>
</dependency>
<!-- Needed for ExtGWT -->
<dependency>
<groupId>com.extjs</groupId>
<artifactId>gxt</artifactId>
<version>${gxt.version}</version>
<scope>provided</scope>
</dependency>
<properties>
<gwt.version>2.0.0</gwt.version>
<gxt.version>2.1.0</gxt.version>
</properties>
I don't have made any maven changes and the pom was also not changed. I've just added and modified java/css/hml files. Any ideas, what is wrong?
edit: Exact message is
Missing:
----------
1) com.google.gwt:gwt-user:jar:2.0.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-user -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.google.gwt -DartifactId=gwt-user -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
.
.
.
and I build the project in command line.
I get suddenly an error message, that 3 dependencies are missing: gwt-user.jar, gwt-dev.jar and gxt.jar. All jars are in my local repo:
Where? On the command line? In your IDE? If this is happening in your IDE and if you are using Eclipse and the m2eclipse plugin, I've noticed that Eclipse sometimes gets lost after POM changes. In that case, right click on the project, then select Maven > Update Project Configuration. Works for me.
i can't explain it, but after reboot is working again...
Related
I compiled wayland from source code with this command
meson --buildtype=release -D prefix=$HOME/mylib -D documentation=false
then installed it with ninja. Now in $HOME/mylib I have this structure:
total 24K
drwxr-xr-x 6 myuser myuser 4.0K Dec 3 19:52 .
drwxr-xr-x 16 myuser myuser 4.0K Dec 4 17:41 ..
drwxr-xr-x 2 root root 4.0K Dec 3 19:52 bin
drwxr-xr-x 2 root root 4.0K Dec 3 19:52 include
drwxr-xr-x 3 root root 4.0K Dec 3 19:52 lib
drwxr-xr-x 4 root root 4.0K Dec 3 19:52 share
Inside bin folder I have wayland-scanner and when I run this command
wayland-scanner -v
I got this output:
wayland-scanner 1.21.90
Now when I build other source code with meson that has wayland-scanner as dependency I got this error:
../tests/meson.build:2:0: ERROR: Invalid version of dependency, need 'wayland-scanner' ['>=1.20.0'] found '1.18.0'.
This is related to another wayland-scanner that is placed here:
/usr/bin/wayland-scanner
with version 1.18.0. The command
echo $PATH
reply with this output:
/home/myuser/mylib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
Why meson doesn't find the updated version of wayland-scanner? Using PKG_CONFIG_PATH doesn't work, same error as above
Hi don't know the wayland package, but from description
I could think that /usr/bin/wayland-scanner is a link to the old installation,
Try to look in your environment for the wayland-scanner scanner binary to check if there is some link do not updated to the new installation.
I have a java project that builds correctly using mvn
># mvn package
[ok]
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:55 target/app.jar
change sources, build it again and the mtimes change
># mvn package
[ok]
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app.jar
as expected. Also if I diff one of these jar files with a copy of an older one, it is different.
I import this project into IntelliJ IDEA and build
Build completed successfully with 3 warnings
however
># ls -il target/app.java target/app/ap.jar target/docker-app/app.jar
4239421 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/docker-app/app.jar
4239422 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app/app.jar
4239416 -rw-r--r-- 1 me domain users 25305467 Apr 27 08:56 target/app.jar
the mtime has NOT changed, and diff reports that the files are identical to copies of the earlier versions.
Why is IDEA not producing new jar files?
Your question is very similar to this one, which I have already answered: intellj IDEA doesnt build jar properly
It helps understanding.
Well looked at the catches. (click zoom)
This uses nvmw local to the project, nothing prevents you from using your nvm version.
Namely intellij provided well, its own build construction system, to create jars without maven. (Even though I personally have not been able to set it up correctly for it to work for starting the application.)
But if you are looking to create a war, I can give you more information to create a war file ...
I use spring boot but the principle remains the same with all simple java projects
We are facing an issue on the Databrick filesyste that considers files as directory and we are unable to read files with Pandas. The files exist in the Azure Storage Explorer, and are considered as files as seen here :
We have mounted the storage with oAuth 2.0.
On Databricks,
%sh ls -al '<path_to_files>'
returns the following :
total 1127
drwxrwxrwx 2 root root 4096 Jan 29 09:26 .
drwxrwxrwx 2 root root 4096 Jan 9 13:47 ..
drwxrwxrwx 1 root root 136705 Jan 28 16:35 AAAA_2019-10-01_2019-12-27.csv
drwxrwxrwx 1 root root 183098 Jan 28 16:35 BBBB_2019-10-01_2019-12-27.csv
-rwxrwxrwx 1 root root 313120 Jan 28 16:35 CCCC_2019-10-01_2019-12-27.csv
-rwxrwxrwx 1 root root 212935 Jan 29 09:26 df_cube.csv
-rwxrwxrwx 1 root root 298228 Jan 29 09:26 df_other_cube.csv
The thing is, the two first csv files are not directories at all. We can download them and read them as csv, but we cannot load them into a Pandas dataframe.
df = pd.read_csv(rootname_source_test + r'AAAA_2019-10-01_2019-12-27.csv',header=0,sep="|",engine='python')
>>> IsADirectoryError: [Errno 21] Is a directory: '/dbfs/mnt/<path>/AAA_2019-10-01_2019-12-27.csv'
They are generated the same way the 3rd csv is generated, and the 3rd on is loadable in pandas. Sometimes they appear as files, sometimes as directories and we are having trouble recreating and solving this consistently.
Cluster config : Runtime 6.2 ML (includes Apache Spark 2.4.4, Scala 2.11)
Any help will be very appreciated.
Currently I am creating a simple project which will install a utility shared library.
Here's my CMakeLists:
cmake_minimum_required (VERSION 2.6)
project(MathLibs CXX)
add_library (${PROJECT_NAME} SHARED
fact.cpp
fibo.cpp
isPrime.cpp
)
install (TARGETS ${PROJECT_NAME}
RUNTIME DESTINATION ${PROJECT_NAME}/bin
LIBRARY DESTINATION ${PROJECT_NAME}/lib
ARCHIVE DESTINATION ${PROJECT_NAME}/lib)
Since I do not have root privileges I cannot install the shared library in system lib folder. I override the CMAKE_INSTALL_PREFIX to $HOME/apps.
When I build the shared library it had the executable permissions.
Here's the build folder with the shared library:
-rw-rw-r-- 1 ameya ameya 9714 Jun 18 20:02 CMakeCache.txt
drwxrwxr-x 5 ameya ameya 4096 Jun 18 20:02 CMakeFiles
-rw-rw-r-- 1 ameya ameya 2701 Jun 18 20:02 cmake_install.cmake
-rw-rw-r-- 1 ameya ameya 84 Jun 18 20:02 install_manifest.txt
-rwxrwxr-x 1 ameya ameya 6808 Jun 18 20:02 libMathLibs.so
-rw-rw-r-- 1 ameya ameya 7748 Jun 18 20:02 Makefile
drwxrwxr-x 3 ameya ameya 4096 Jun 18 20:02 test
After installing the executable permissions disappears.
Here's the install folder location:
-rw-r--r-- 1 ameya ameya 6808 Jun 18 20:02 libMathLibs.so
What am I missing in the CMakeLists.txt to correct this?
They said that CMake doesn't set execute permissions on installed library because on Linux libraries don't need to be executable.
As for library's permissions in build tree, these are set not by CMake but by the linker.
If you want executable permissions of installed library for some reason, use PERMISSIONS option in install() command.
After looking for more details online I found this referenced in the CMake bugs report.
The handling of shared library on different systems is different I tried using Ubuntu and a Fedora workstation.
On Ubuntu system the system installed shared libraries do not have the executable bit set, but on the Fedora Workstation the same library had the executable bit set.
One can have look at the ${CMAKE_ROOT}/cmake/Modules/Platform/Linux.cmake,
which has the CMAKE_INSTALL_SO_NO_EXE macro defined(sorry for the typo in my earlier reply).
(see update at end. It defines a workaround, but that workaround raises questions too).
We are trying to port an application to JBoss EAP 6.2 from WebLogic. There will be many difficulties along the way, but now I am just trying to port a single war file and I am stubbing my toe on classloading issues. This war depends on two jars that it does not include. In Web Logic, these jars were on the classpath of the server. Whether or not it makes sense to continue with this pattern, the current effort is to do so. But I can't get it to work.
The strategy is load these jars as modules, as JBoss recommends.
This is the jboss-deployment-structure.xml file that we are placing in the war file's WEB-INF directory, again as Jboss recommends:
<?xml version="1.0"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deployment>
<dependencies>
<module name="com.whatever.ivss" export="TRUE"/>
<module name="com.whatever.vt.svcauthentication" export="TRUE"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
As per jboss, I then deploy these jars and module.xml descriptors into a directory structure under {JBOSS_EAP_HOME} /modules as follows:
$ pwd
/.../jboss-eap-6.2/modules/com/whatever
$ ls -alR
.:
total 16
drwxrwxr-x. 4 wevs wevs 4096 Aug 14 14:58 .
drwxrwxr-x. 4 wevs wevs 4096 Aug 13 14:07 ..
drwxrwxr-x. 2 wevs wevs 4096 Aug 15 09:44 ivss
drwxrwxr-x. 3 wevs wevs 4096 Aug 14 14:58 vt
./ivss:
total 132
drwxrwxr-x. 2 wevs wevs 4096 Aug 15 09:44 .
drwxrwxr-x. 4 wevs wevs 4096 Aug 14 14:58 ..
-rw-r-----. 1 wevs wevs 121414 Aug 13 14:22 ivsslib-jdk1.5.jar
-rw-r-----. 1 wevs wevs 356 Aug 15 09:44 module.xml
./vt:
total 12
drwxrwxr-x. 3 wevs wevs 4096 Aug 14 14:58 .
drwxrwxr-x. 4 wevs wevs 4096 Aug 14 14:58 ..
drwxrwxr-x. 2 wevs wevs 4096 Aug 14 15:02 svcauthentication
./vt/svcauthentication:
total 24
drwxrwxr-x. 2 wevs wevs 4096 Aug 14 15:02 .
drwxrwxr-x. 3 wevs wevs 4096 Aug 14 14:58 ..
-rw-r-----. 1 wevs wevs 306 Aug 14 15:02 module.xml
-rw-r-----. 1 wevs wevs 11524 Aug 13 14:21 svcauthentication-jdk1.5.jar
And here are the two module.xml files referred to above:
.../com/whatever/ivss/module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.whatever.ivss">
<resources>
<resource-root path="ivsslib-jdk1.5.jar"/>
</resources>
<dependencies>
<module name="javax.jms.api"/>
<module name="javax.servlet.api"/>
<module name="org.apache.log4j"/>
<module name="system"/>
</dependencies>
</module>
and .../com/whatever/vt/svcauthentication/module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.whatever.vt.svcauthentication">
<resources>
<resource-root path="svcauthentication-jdk1.5.jar"/>
</resources>
<dependencies>
<module name="com.whatever.ivss"/>
<module name="system"/>
</dependencies>
</module>
As far as I've been able to discern, I've done everything correctly.
Yet the class refuses to load, and looking at the jboss log (on trace level) the error seems to be an inability to FIND my module (rather than some downstream class dependency issue):
10:12:07,254 DEBUG [org.jboss.modules] (MSC service thread 1-4) Module deployment.dbAccess.war:main defined by Service Module Loader
10:12:07,254 TRACE [org.jboss.modules] (MSC service thread 1-4) Loaded module deployment.dbAccess.war:main from Service Module Loader
10:12:07,256 TRACE [org.jboss.modules] (MSC service thread 1-4) Locally loading module com.whatever.ivss:main from local module loader #65c404b3 (finder: local modul
e finder #2810b7f7 (roots: .../jboss-eap-6.2/modules,.../jboss-eap-6.2/modules/system/layers/base))
10:12:07,256 TRACE [org.jboss.modules] (MSC service thread 1-4) Module com.whatever.ivss:main not found from local module loader #65c404b3 (finder: local module find
er #2810b7f7 (roots: .../jboss-eap-6.2/modules,.../jboss-eap-6.2/modules/system/layers/base))
...
10:12:07,256 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.module.service."deployment.dbAccess.war".main:
org.jboss.msc.service.StartException in service jboss.module.service."deployment.dbAccess.war".main: JBAS018759: Failed to load module: deployment.dbAccess.war
:main
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14
]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-
1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.jboss.modules.ModuleNotFoundException: com.whatever.ivss:main
at org.jboss.modules.Module.addPaths(Module.java:1030) [jboss-modules.jar:1.3.0.Final-redhat-2]
at org.jboss.modules.Module.link(Module.java:1386) [jboss-modules.jar:1.3.0.Final-redhat-2]
at org.jboss.modules.Module.relinkIfNecessary(Module.java:1414) [jboss-modules.jar:1.3.0.Final-redhat-2]
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.0.Final-redhat-2]
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14
]
... 5 more
I must be doing something wrong but I can't figure out what it is. Why can't JBoss find my modules?
UPDATE:
I found a possible solution for this or maybe it's just a bandaid.
The first clue was this log entry included above:
Locally loading module com.whatever.ivss:main ...
What is that :main doing there? At no point did I ask for my module to be qualified by the term "main".
Looking a little further, I descended the tree of the JBOSS_EAP_HOME/modules/system directory. These are the factory default dependent modules supplied by JBoss. Every module in here has its module.xml and jar files inside a subdirectory called main.
For example:
[wevs#hdcas01 cal10n]$ pwd
.../jboss-eap-6.2/modules/system/layers/base/ch/qos/cal10n
[wevs#hdcas01 cal10n]$ ls -alR
.:
total 12
drwxrwxr-x. 3 wevs wevs 4096 Nov 20 2013 .
drwxrwxr-x. 3 wevs wevs 4096 Nov 20 2013 ..
drwxrwxr-x. 2 wevs wevs 4096 Nov 20 2013 main
./main:
total 44
drwxrwxr-x. 2 wevs wevs 4096 Nov 20 2013 .
drwxrwxr-x. 3 wevs wevs 4096 Nov 20 2013 ..
-rw-rw-r--. 1 wevs wevs 30262 Nov 20 2013 cal10n-api-0.7.3-redhat-2.jar
-rw-rw-r--. 1 wevs wevs 1419 Nov 20 2013 module.xml
In other words, in the system modules that JBoss defines, the module definition and modules themselves are located in the .../{module name}/main directory, not the .../{module name} directory.
Following this pattern in my modules, the war now loads successfully.
However, this still leaves a question? Why is this "main" subdirectory seemingly required? It is not documented in the JBoss docs. Is this just the solution, or is there some other problematic aspect of my deployment that makes it necessary. Or is it a bug?
JBoss Modules requires a module name and a slot. In your module.xml there is an attribute that can be used called slot which defaults to main. Since your module.xml was not in the main directory it couldn't anything.
In other words the general directory format is package/name/slot. Since the default slot is main JBoss Modules looked in com/whatever/ivss/main for the module.xml file.
Further investigation shows this to be a fairly serious documentation error. I have posted this as a bug on the JBoss bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1130642
There are some other jboss documents that contradict the ones I was reading, details are in the bug report.
This cost me close to a day's worth of headscratching.