I'm looking at the webpush-java code. I run into a problem attempting to build the project using gradle. (I'm a gradle newbie).
:signArchives FAILED
FAILURE: Build failed with an exception.
What went wrong: Execution failed for task ':signArchives'.
Cannot perform signing task ':signArchives' because it has no
configured signatory
I guess that I need to configure a signatory. How do I do that?
Quoting the Signing plugin documentation you should be able to resolve the error when you provide the expected GPG variables in the gradle.properties file in your HOME directory:
# File location: ~/.gradle/gradle.properties - see https://docs.gradle.org/current/userguide/directory_layout.html
signing.keyId=24875D73
signing.password=secret
signing.secretKeyRingFile=/Users/me/.gnupg/secring.gpg
Gradle resp. the Signing plugin will automatically pick them up in the build process.
Another option that does not require a special command-line option is to add the following in your build.gradle:
signing {
setRequired {
// signing is only required if the artifacts are to be published
gradle.taskGraph.allTasks.any { it.equals( PublishToMavenRepository) }
}
....
See e.g. https://github.com/Vampire/command-framework/blob/master/buildSrc/src/main/kotlin/net/kautler/publishing.gradle.kts#L157
I got the same problem and it was because of several things:
I didn't distribute the gpg key to any server;
I was using inMemory to sign and I shouldn't
the link of the complete answer with build.gradle file and gradle.properties file: https://stackoverflow.com/a/68505768/7937498
Found solution here https://github.com/jaegertracing/jaeger-client-java/issues/202
Use the below command.
./gradlew assemble -x signArchives
I have this error in eclipse helios:
Exception occurred executing command line.
Cannot run program "C:\Program Files (x86)\Java\jre6\bin\javaw.exe" (in directory "C:\Users\motiver\helios_workspace\TimeTracker"): CreateProcess error=206, The filename or extension is too long
I researched a bit but most of the issues were related to DataNucleus when working on Google App Engine. But I am not using anything remotely related to Google App Engine. I am doing a small project with Servlet 3.0 on JBOSS 6. I am using Hibernate 4.1.2 for ORM and RESTEasy to expose a web service. I created a util file that has a main() method that basically drops and re-creates the schema. I run the main() methos when I need a clean database for testing purposes. It worked fine on Tomcat 7 but it stopped working when I moved to JBoss 6.
Any hint or solution would be greatly appreciated.
There is no simple (as in a couple of clicks or a simple command) solution to this issue.
Quoting from some answers in this bug report in Eclipse.org, these are the work-arounds. Pick the one that's the least painful to you:
Reduce the classpath
Use directories instead of jar files
Use a packed jar files which contains all other jars, use the classpath variable inside the manifest file to point to the other jars
Use a special class loader which reads the classpath from a config file
Try to use one of the attached patches in the bug report document
Use an own wrapper e.g. ant
Update: After July 2014, there is a better way (thanks to #Brad-Mace's answer below:
If you have created your own build file instead of using Project -> Generate Javadocs, then you can add useexternalfile="yes" to the Javadoc task, which is designed specifically to solve this problem.
In intellij there is an option to 'shorten command line', select 'JAR manifest' or '#argFiles' would solve the problem, basically it will put your lengthy class path into a jar file or a temp file
I faced this problem today and I was able to solve it using this Gradle plugin
It's github url is this
IF you, like me, have no idea what Gradle is but need to run a backend to do your front end work, what you need to do is find the build.gradle file that is being called to start your BE server and add this to the top:
plugins {
id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}
If you create your own build file rather than using Project -> Generate Javadocs you can add useexternalfile="yes" to the javadoc task, which is designed specifically to solve this problem.
I was running into this issue trying to execute a JPQL query in the Hibernate / JPA console of IntelliJ 2020.2
Adding this to my .idea/workspace.xml fixed it
<component name="PropertiesComponent">
...
<property name="dynamic.classpath" value="true"/>
...
</component>
Origin of the solution: https://youtrack.jetbrains.com/issue/IDEA-166929?_ga=2.167622078.1290412178.1604511702-23036228.1574844686
Answering my own question here so that the solution doesn't get buried in comments. I exported the project as a runnable jar from within eclipse and did a command line "java -jar MyJar.jar" and it works perfectly fine
This is not specifically for eclipse, but the way I got around this was by creating a symbolic link to my maven repository and pointing it to something like "C:\R". Then I added the following to my settings.xml file:
<localRepository>C:\R</localRepository>
The maven repository path was contributing to the length problems in my windows machine.
Try updating your Eclipse version, the issue was closed recently (2013-03-12). Check the bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193
Question is old, but still valid. I come across this situation often whenever a new member joins my team or a new code segment is added to existing code. Simple workaround we follow is to "Reduce the classpath" by moving up the directories.
As question mentioned, this is not specific to eclipse. I came across this issue in IntelliJ Idea 14 and 2018 as well.
After a long research, I found the solution is to set the
fork = false
in javc of ant build file.
<javac destdir="${build.dir}" fork="false" debug="on">
<classpath .../>
<src ... />
<patternset ... />
</javac>
This is how my ant build javac looks now. To learn about more on fork, please refer ant documentation.
In bug report Bug 327193 it is considered fixed, but it happen to me recently with Eclipse Kepler 4.3.2.
Please download patch for Eclipse Juno or newer:
https://bugs.eclipse.org/bugs/attachment.cgi?id=216593
After download back up existing
eclipse/plugins/org.eclipse.jdt.launching_3.*.jar
Copy and paste classes in the patch to org.eclipse.jdt.launching JAR
(replace existing files).
Restart Eclipse.
How many people sad above, there are a lot of plugins to gradle execute a by pass in this problem like:
plugins {
id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}
or
plugins {
id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}
But the better solution that I found was kill the JVM process and everything is done.
Add below to your gradle file:
plugins {
`id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}
See https://plugins.gradle.org/plugin/com.github.ManifestClasspath
Try adding this in build.gradle (gradle version 4.10.x) file and check it out com.xxx.MainClass this is the class where your main method resides:
plugins {
id "ua.eshepelyuk.ManifestClasspath" version "1.0.0"
}
apply plugin: 'application'
application {
mainClassName = "com.xxx.MainClass"
}
The above change must resolve the issue, there is another way using script run.sh below could fix this issue, but it will be more of command-line fix, not in IntelliJ to launch gradle bootRun.
Try this:
java -jar -Dserver.port=8080 build/libs/APP_NAME_HERE.jar
To solve it:
If you are using Eclipse:
Move .m2 repository to
c:\
Go to Eclipse > Windows/Preferences/Maven/User Settings -> Create your own setting.xml with its content:
<settings>
<localRepository>c:/.m2/repository</localRepository>
</settings>
If you are using IntelliJ:
Go to IntelliJ > clicking the right mouse button on "pom.xml" > maven > create "settings.xml"
with its content:
<settings>
xmlns="yourcontent"
xmlns:xsi="yourcontent"
xsi:schemaLocation="yourcontent.xsd">
<localRepository>c:/.m2/repository</localRepository>
</settings>
In my case the error was showing because system java version was different from intellijj/eclipse java version. System and user had diff java versions. If you compile your code using one version and tried to run using a different version, it will error out.
#The system java version is 1.7.131
$ java -version
java version "1.7.0_131"
Long story short, make sure your code is compiled and ran by the same java version.
I am using legacy version of gradle plugins and this plugin solved the issue for me.
Usage (check source for more details):
Build script snippet for plugins DSL for Gradle 2.1 and later
plugins {
id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}
Build script snippet for use in older Gradle versions or where dynamic
configuration is required
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "gradle.plugin.com.github.viswaramamoorthy:gradle-util-plugins:0.1.0-RELEASE"
}
}
apply plugin: "com.github.ManifestClasspath"
I have got same error, while invoking Maven.
The root cause for my problem was the classpath was very huge. Updating the classpath fixed the problem.
There are multiple ways to update the large classpath as mentioned in this: How to set a long Java classpath in Windows?
Use wildcards
Argument File
Pathing jar
Since I am using Intellij, they provide the option to use Argument File that i used.
In a Windows machine, there is a limitation of the jar file name/path length in the command-line, due to which you see the below error message, I tried searching a lot, even I tried applying the above solution, some reason, it didn't work, I found the working snippet for Gradle (gradle-4.10.2-all.zip)
Error:
CreateProcess error=206, The filename or extension is too long
Use this below gradle.build code snippet to fix the above problem in IntelliJ or STS, or eclipse anything.
Gradle Code Fix:
apply plugin: 'application'
task pathingJar(type: Jar) {
dependsOn configurations.runtime
appendix = 'pathing'
doFirst {
manifest {
attributes "Class-Path": configurations.runtimeClasspath.files.collect { it.getName() }.join(' ')
}
}
}
task copyToLib(type: Copy) {
into "$buildDir/libs"
from configurations.runtime
}
bootRun {
systemProperties = System.properties
//This below line is for if you have different profiles prod, dev etc...
//systemProperty 'spring.profiles.active', 'dev'
jvmArgs('-Djava.util.logging.config.file=none')
mainClassName = "com.xxxx.Main"
dependsOn pathingJar
dependsOn copyToLib
doFirst {
classpath = files("$buildDir/classes/java/main", "$buildDir/resources/main", pathingJar.archivePath)
}
}
If you are using VSCode:
create launch.json file insde .vscode/
add
{"configurations": [{ "type": "java","shortenCommandLine ": "auto",}]}
If you are using intellij :
open .idea/workspace.xml
inside <component name="PropertiesComponent">
add <property name="dynamic.classpath" value="true"/>
it happens due to DataNucleus sometimes overwrite the Arguments with many paths.
You have to overwrite them with this:
-enhancerName ASM -api JDO -pu MediaToGo
Hope help you!
I got the same error. Tried solutions like cleaning, rebuild, invalidateCache, retart etc but nothing works.
I just have created a new folder with short name and copied all the files(app folder, gradle files etc) in new folder. Opened application in android studio and its working fine.
For me it was wrong JDK path. Please make sure you have right path to the JDK file
File -> Project Structure
If you are using Android Studio try Invalidate Caches/ Restart.. option present in File menu
I used com.virgo47.ClasspathJar plugin to fix this issue
https://plugins.gradle.org/plugin/com.virgo47.ClasspathJar
To fix this below error, I did enough research, not got any great solution, I prepared this script and it is working fine, thought to share to the public and make use of it and save there time.
CreateProcess error=206, The filename or extension is too long
If you are using the Gradle build tool, and the executable file is placed in build/libs directory of your application.
run.sh -> create this file in the root directory of your project, and copy below script in it, then go to git bash and type run.sh then enter. Hope this helps!
#!/bin/bash
dir_name=`pwd`
if [ $# == 1 ] && [ $1 == "debug" ]
then
port=$RANDOM
quit=0
echo "Finding free port for debugging"
while [ "$quit" -ne 1 ]; do
netstat -anp | grep $port >> /dev/null
if [ $? -gt 0 ]; then
quit=1
else
port=`expr $port + 1`
fi
done
echo "Starting in Debug Mode on "$port
gradle clean bootjar
jar_name="build/libs/"`ls -l ./build/libs/|grep jar|grep -v grep|awk '{print $NF}'`
#java -jar -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=$port $jar_name
elif [ $# == 1 ] && [ $1 == 'help' ]
then
echo "please use this commands"
echo "------------------------"
echo "Start in Debug Mode: sh run.sh debug"
echo "Start in Run Mode: sh run.sh"
echo "------------------------"
else
gradle clean bootjar
word_count=`ls -l ./build/libs/|grep jar|grep -v grep|wc -w`
jar_name=`ls -l ./build/libs/|grep jar|grep -v grep|awk '{print $NF}'`
jar_path=build/libs/$jar_name
echo $jar_name
#java -jar $jar_path
fi
Hope this helps!!
You can use below commands:
mklink /J c:\repo C:\<long path to your maven repository>
mvn -Dmaven.repo.local=c:\repo any mvn command
Valid answer from this thread was the right answer for my special case.
Specify the ORM folder path for datanucleus certainly reduce the java path compile.
https://stackoverflow.com/a/1219427/1469481
I got the error below when I run 'ant deploy'
Cannot run program "C:\java\jdk1.8.0_45\bin\java.exe": CreateProcess error=206, The filename or extension is too long
Fixed it by run 'ant clean' before it.
I got the same error in android studio. I was able to resolve it by running Build->Clean Project in the IDE.
After compiling my Android application using the Android Studio (Beta), I have the following error:
Error:error: Resource entry background is already defined.
res\drawable-xhdpi-v4\background.9.png:0: Originally defined here.
This occurred when I had a image file called "background" in my res folder.
I then made a 9 patch version of it and pasted it in the same folder. This meant that there was 2 files with the same name. So I unsurprisingly I had this error.
However I now deleted all instances of the background image file (including the 9 patch version and original image) in my code and layout file and I still have this error.
You could try to do one of the following:
Clean and Build or gradle clean build assemble
Invalidate and restart Android Studio
1 Build > Clean Project
2 Build > Rebuild Project
I am using Android studio and I run exactly into the same issue and none of the answers I found on the web helped me solve the problem, including the previous one. So reading through all details of the error messages and found this lines:
Error:Execution failed for task ':app:processDebugResources'.
com.android.ide.common.internal.LoggedErrorException: Failed to run command:
C:\Users\user\AppData\Local\Android\android-studio\sdk\build-tools\android-4.4W\aapt.exe package -f --no-crunch -I C:\Users\user\AppData\Local\Android\android-studio\sdk\platforms\android-20\android.jar -M C:\Users\user\AndroidStudioProjects\DartsApp\app\build\intermediates\manifests\debug\AndroidManifest.xml -S C:\Users\user\AndroidStudioProjects\DartsApp\app\build\intermediates\res\debug -A C:\Users\user\AndroidStudioProjects\DartsApp\app\build\intermediates\assets\debug -m -J C:\Users\user\AndroidStudioProjects\DartsApp\app\build\generated\source\r\debug -F C:\Users\user\AndroidStudioProjects\DartsApp\app\build\intermediates\libs\app-debug.ap_ --debug-mode --custom-package com.dartstransit.dartsapp -0 apk --output-text-symbols C:\Users\user\AndroidStudioProjects\DartsApp\app\build\intermediates\symbols\debug
Error Code:
1
Output:
res\drawable-hdpi-v4\bus_w.png:0: error: Resource entry bus_w is already defined.
res\drawable-hdpi-v4\bus_w.jpg:0: Originally defined here.
As you can see there are two files of name bus_w with different extensions on the same folder. I had already removed those files from the project and still getting the error, so I decided to check every single folder of the project that was reference in the compiler line in the error message. Finally found that there was a copy of the file bus_w.png in the folder app\build\intermediates\res\debug\drawable-mdpi-v4.
I just deleted it and voila, problem solved.
A simple Build > Rebuild project helped me
Did you try rename this file to other name? It seem one of your libraries have same resource.
I see that many devs(include me) had issue with ic_launcher too. I think you want to try mipmap instead drawable. So we will have something like this:
\res\mipmap-hdpi
\res\mipmap-mdpi
\res\mipmap-xhdpi
\res\mipmap-xxhdpi
Hope this help.
I have also encountered this error recently.Here is my solution that works,hope it will help you.
1.only keep 9 patch version image in the drawable-hdpi folder
2.make sure the code related to this problem in xml file remains the same: android:background="#drawable/msg_left"
instead of using the code:
android:background="#drawable/msg_left.9"
PS:My original image name is msg_left,and my 9 patch version image name is msg_left.9
I did the trick by moving the icon
drawable/ic_launcher
to
mipmap/ic_launcher
and it worked fine :)
In my case the problem was that I had more than one '.' in the filename. like:
a.png
a.bold.png
Solution was to rename to
a.png
a_bold.png
In our case, problem started occurring (error shows 'duplicate value for resource' in a library) when some other library was upgraded to it's latest version.
We just downgraded the version of the library that was upgraded.
Real pain was because that we have many dependencies which can be dynamically upgraded when there is a new version available in repositories. So my teammate had to go through all libs that can be dynamically upgraded and see if there is one that is recently upgraded, try to downgrade it and check if build goes fine. He identified many were upgraded on previous day. Downgrading one of them got the build back.
Conclusion we made is not to use Dynamic Versioning. Don't use dynamic versions for your dependencies.
This was the error by the way:
Task :app:generateDebugResources UP-TO-DATE
AGPBI: {"kind":"error","text":"error: duplicate value for resource \u0027attr/itemBackground\u0027 with config \u0027\u0027.","sources":[{"file":"/Users/unknownuser/.gradle/caches/transforms-1/files-1.1/singledateandtimepicker-1.2.2.aar/86ae3786d70c769e610c8a01d58aa638/res/values/values.xml","position":{"startLine":15,"startColumn":4,"startOffset":2427,"endColumn":48,"endOffset":2471}}],"original":"","tool":"AAPT"}
AGPBI: {"kind":"error","text":"error: resource previously defined here.","sources":[{"file":"/Users/unknownuser/.gradle/caches/transforms-1/files-1.1/singledateandtimepicker-1.2.2.aar/86ae3786d70c769e610c8a01d58aa638/res/values/values.xml","position":{"startLine":15,"startColumn":4,"startOffset":2427,"endColumn":48,"endOffset":2471}}],"original":"","tool":"AAPT"}
Task :app:mergeDebugResources FAILED
Error: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
FAILURE: Build failed with an exception.
I've installed Flume and Hadoop manually (I mean, not CDH) and I'm trying to run the twitter example from Cloudera.
In the apache-flume-1.5.0-SNAPSHOT-bin directory, I start the agent with the following command:
bin/flume-ng agent -c conf -f conf/twitter.conf -Dflume.root.logger=DEBUG,console -n TwitterAgent
My conf/twitter.conf file uses the logger as the sink. The conf/flume-env.sh assigns to CLASSPATH the flume-sources-1.0-SNAPSHOT.jar that contains the definition of the twitter source. The resulting output is:
(...) [ERROR org.apache.flume.lifecycle.LifecycleSupervisor$MonitorRunnable.run(LifecycleSupervisor.java:253)] Unable to start EventDrivenSourceRunner: { source:com.cloudera.flume.source.TwitterSource{name:Twitter,state:IDLE} } - Exception follows. java.lang.NoSuchMethodError:
twitter4j.FilterQuery.setIncludeEntities(Z)Ltwitter4j/FilterQuery;
at com.cloudera.flume.source.TwitterSource.start(TwitterSource.java:139)
The conflict results from a FilterQuery class that is defined elsewhere in the flume lib and that does not contain the setIncludeEntities method. For me, the file that contains this class is the twitter4j-stream-3.0.3.jar and I cannot exclude the file from the classpath as suggested here.
I believe this experience was quite frustrating for you, for me it was for sure. The main problem is, both the files, flume-sources-1.0-SNAPSHOT.jar and twitter4j-stream-3.0.3.jar contains the same FilterQuery.class. That is why the conflict message is generated in the log file.
I am not a Java or Big Data expert, but I can give you an alternate to this problem. Download the Twitter4j-stream-2.6.6.jar or lower version from here and replacethe twitter4j-stream-3.0.3.jar. All the 3.X.X uses this class. After replacing, everything should work fine. But you may get some heap error after downloading huge amount of tweets. Please google the solution as it was resolved in 3.X.X files.
-Edit
Also, please don't forget to download and replace all the twitter4j files in /usr/lib/flume-ng folder. Namely, twitter4j-media-support-2.2.6.jar, twitter4j-stream-2.2.6.jar and twitter4j-core-2.2.6.jar. Any mismatch related to version among these files will also create problem.
As suggested in the post a problematic file can be search-contrib-1.0.0-jar-with-dependencies.jar too.
You need to recompile flume-sources-1.0-SNAPSHOT.jar from the git:https://github.com/cloudera/cdh-twitter-example
Install Maven, then download the repository of cdh-twitter-example.
Unzip, then execute inside (as mentionned) :
$ cd flume-sources
$ mvn package
$ cd ..
This problem happened when the twitter4j version updated from 2.2.6 to 3.X, they removed the method setIncludeEntities, and the JAR is not up to date.
PS: Do not download the prebuilt version, it is still the old.
Simply rename all twitter4j-stream* jar files and rerun your flume. It will work with charm. :)
I had the same problem and at last I solved following these steps:
First I renamed all jar files in jarx: from twitter4j-stream-3.0.3.jar -> twitter4j-stream-3.0.3.jarx, ...
This solved the error, but when it tried to estabilish connection, I got error 404:
(Twitter Stream consumer-1[Establishing connection])
[INFO - Twitter4j.internal.logging.SLF4JLogger.info(SLF4JLogger.java:83)] 404:
The URI requested is invalid or the resource requested, such as a user, does not exist.)
After reading this page (https://twittercommunity.com/t/twitter-streaming-api-not-working-with-twitter4j-and-apache-flume/66612/11) finally I solved downloading a new version of twitter4j (in the page there's a link).
Probably not the best solution, but worked for me.
Today I signed up for github, and converted an existing filesystem into a git repo using the technique described here:
http://crashingdaily.wordpress.com/2009/09/02/initing-a-new-remote-git-repository-with-existing-files/
Most importantly (I think) it involved this line:
git --bare init
I then followed the rest of github.com's setup tutorials (this was part of that) and was done. The existing filesystem was within Dropbox, so I performed the same setup on the two other machines that use the filesystem (now a git repo).
Tonight I tried to get JGit to add a file, commit it and then push it. Here's the gist of the code up until the point it breaks:
FileRepositoryBuilder builder = new FileRepositoryBuilder();
Repository repository = builder.setGitDir(new File("path/to/my/repo"))
.readEnvironment() // scan environment GIT_* variables
.findGitDir() // scan up the file system tree
.build();
Git git = new Git(repository);
AddCommand add = git.add();
try{
add.addFilepattern("PlayState.as").call();`
This is basically taken verbatim from a JGit tutorial, incidentally. It throws an exception at that last quoted line and states:
org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
at org.eclipse.jgit.lib.Repository.getIndexFile(Repository.java:838)
at org.eclipse.jgit.lib.Repository.lockDirCache(Repository.java:886)
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:136)
at flipa.FLIPAGame.writeToFlixel(FLIPAGame.java:77)
at flipa.FLIPAGame.main(FLIPAGame.java:58)
Now, I'm not saying it's unreasonable to claim that, because truth be told I am not the best friend of version control. I get that a bare repo is one with just git in and no other files, but it seems to me that now it has files in it. I've already manually added, committed and pushed to github using git from Terminal. So I can't immediately see why it won't even recognise the repo.
Any takers?
EDIT - For clarification, killing off this repo is no big deal if someone can propose another solution. I want a git repo to use the filesystem in my dropbox, and be able to commit to github via Java.
For your code, I would say the options setGitdir() and findGitDir() are not supposed to be used at the same time.
To retrieve an existing repository, I use findGitDir(new File("path/to/my/repo") and it is enough.
This sounds like you've added the files to a bare repository. A bare repository should not be touched, except through git push and pull commands (or git commands in general). As a guide, I don't ever look in my bare repositories.
It should be used as a central location. Once you've created the git bare repo, you should clone it and then work on it from the clone, pushing and pulling from the clone.
$ cd /dropbox/repo
$ git init --bare
$ cd /workdir
$ git clone file:///dropbox/repo
$ add files in here
$ git add .
$ git commit -m "initial version"
$ git push origin master
$ more changes here
$ git add etc.
The difference between this and github is the git clone, which then comes from a different place. To be quite honest, unless you've got a really good reason to have a local copy, I'd just forget about the dropbox repo and just use github.
Your third line of code, right after .build(); should be:
repository.create();
This is the equivalent of the "git init" command.
In your case since you are working in an existing directory, you may find more convenient using Git.open().
Git git = Git.open(new File(".git"));
System.out.println("Repository: " + git.getRepository().toString());
//Do some git action for instance:
RevCommit rev = git.commit().setAmend(true)
.setAuthor("me", "me#mail.com")
.setMessage("Testing commit from jGit").call();
git.close();
Source: Article written by Rüdiger Herrmann available in Code Affine.