I've pushed my artifact to oss nexus repo, added it as dependency to another project. Idea keeps me warning:
[warn] Unable to reparse com.github.kondaurovdev#jsonapi_2.11;0.1-SNAPSHOT from sonatype-snapshots, using Fri May 13 17:12:52 MSK 2016 [warn] Choosing sonatype-snapshots for com.github.kondaurovdev#jsonapi_2.11;0.1-SNAPSHOT
Maybe i pushed artifact somehow in a wrong way? But i did it earlier, everything was ok. How to get rid of these warnings? Or just ignore them?
I had the same issue.
Did you publish your SNAPSHOT version to your artifactory? If so this might be your problem.
As you know when publishing locally your snapshot version is stored in the .ivy2/local directory. The remote version are stored in the .ivy2/cache directory.
When looking into the .ivy2/cache/{dependency} folder you will see that it has only downloaded the xml and properties file. So just the metadata and no jars. This is the actual reason why it can't be parsed since it's not there.
Since the .ivy2/cache takes precedence over .ivy2/local it won't see your local published version. There are 2 ways to fix this.
Update your snapshot version number(recommended)
Remove the SNAPSHOT from your artifactory and remove the .ivy2/cache/{dependency} folder on every client that has a local version.
In my opinion the first one is the way to go.
I had the same issue, and it goes away after I add the follow in my build.sbt:
updateOptions := updateOptions.value.withLatestSnapshots(false)
You can find more detail from https://github.com/sbt/sbt/issues/2650
Related
In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
I followed this tutorial but at the end I got an 404 Not Found.
http://localhost:8080/TomEE_war_exploded/
The requested resource [/TomEE_war_exploded/] is not available
In Intellij I don't see a mistake. The Apache Tomee runs under windows in ~/software/apache-tomee-plume-8.0.11 and the code in ~/playground/TomEE
Unfortuately I'm not able to understand how the war file will be copied to the ~/software/apache-tomee-plume-8.0.11/webapps directory or where the configuration error exists.
From the log file I'm not really sure that the deployment happend correct:
30-May-2022 16:49:53.486 WARNING [http-nio-8080-exec-4] org.apache.batchee.container.services.ServicesManager.init You didn't specify org.apache.batchee.jmx.application and JMX is already registered, skipping
30-May-2022 16:49:53.486 INFO [http-nio-8080-exec-4] org.apache.openejb.assembler.classic.Assembler.createApplication Deployed Application(path=/home/maggus/playground/TomEE/target/TomEE-1.0-SNAPSHOT)
30-May-2022 16:49:53.664 INFO [http-nio-8080-exec-4] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Artifact is deployed successfully
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Deploy took 823 milliseconds
Does anybody see the mistake?
Thanks,
Markus
I ran into somewhat similar problem today and after sometime I was able to figure it out that it does not deploy at the following Application Context that is configured under Deployment tab in Run/Debug Configurations.
/TomEE_war_exploded
If you try to access http://localhost:8080/TomEE_war_exploded/, it gives 404.
Instead, (in my case) it is accessible at http://localhost:8080/TomEE-1.0-SNAPSHOT/
Where 1.0-SNAPSHOT is the version number defined in pom.xml.
Now in order to find the exact path where it is deployed, you need to go to Tomcat Web Application Manager at the following address:
http://localhost:8080/manager/html
Replace 8080 with the port number on which TomEE is running on your machine.
Default user & password is tomee.
Look under Path and you'll find it. Just click on it, it will be accessible.
I hope it helps.
EDIT: The Workaround
In order to define your own path, you need to update the path in the Artifact Output Directory. See the attached photo.
I've got an error on my Build server. It looks like this:
Bot Issue for My OSX Project (build service error)
Integration #1300 of My OSX Project
Open in Xcode: xcbot://xwserver/botID/d127cd23bd4cee1081dfcc192904a85b/integrationID/699d47fa9105419469cca90c6a2a7286
Assertion: Could not open '/Library/Developer/XcodeServer/Integrations/Caches/d127cd23bd4cee1081dfcc192904a85b/Source/xwrtrunk/.git/logs/refs/remotes/origin/AnotherProjectFolderName'
for writing: Is a directory (-1) File: (null):(null)
Introduced 5 integrations ago
Full logs for this integration are attached.
When I changed git repo, everything was great. but with this git repo it always fail. And I don't know what I must do. And even no ideas.
What did we do:
Cut checkouted repo on build server
Checked file system using disc utilities.
P.S. Any way thanks for attention.
Whenever a repo is problematic with XCode, the first workaround is to:
clone it again.
Make XCode reference the newly cloned repo
The OP ZevsVU (doing just that) adds in the comments:
We got this problem when I created a branch folder which name was equal to folder name in the repo.
We just deleted this branch and everything is great at the moment.
Another instance of a similar issue is now (Q4 2021) better presented:
See commit 66e905b, commit a7439d0 (25 Aug 2021) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 7b06222, 08 Sep 2021)
xopen: explicitly report creation failures
Signed-off-by: René Scharfe
If the flags O_CREAT and O_EXCL are both given then open(2) is supposed to create the file and error out if it already exists.
The error message in that case looks like this:
fatal: could not open 'foo' for writing: File exists
Without further context this is confusing: Why should the existence of the file pose a problem? Isn't that a requirement for writing to it?
Add a more specific error message for that case to tell the user that we actually don't expect the file to preexist, so the example becomes:
fatal: unable to create 'foo': File exists
I'm using pentaho BI (spoon) and I have a problem with it.
At each action (open job/transformation or save for example) it show this window
http://i.stack.imgur.com/bqmZQ.jpg
now I can't open existing transformation. Does anyone know this issue?
I know this is an old post, but the problem is still current (version 8.2 CE), and I was unable to find any help (other than the workaround to delete the .lock files, but this only solves it for a few minutes, possibly even less).
I had exactly the same problem, it basically rendered Spoon useless. In my case, the culprit was the antivirus program. I noticed it only because I installed the AV after I used Spoon for some time. I just removed the AV (and installed another one) - no more problems.
It seems that your repository is having some issue in connecting.
Try checking the repo. connection and also check for the permission of accessing the repo.
I faced a similar issue and was able to resolve it by deleting the lock file under
D:\Pentaho-ce\file-repository\ETL\.meta\metastore\.lock
(local-repository root)\.meta\metastore\.lock
Kettle - Spoon version 5.4.0.1-130
I was also facing a similar issue and was able to resolve it by deleting the lock.
Pentaho tool creates .pentaho directory in the home directory.
inside .pentaho delete .lock from
.pentaho/metastore/.lock
and also delete .lock file
/home/pdi-ce-9.1.0.0-324/data-integration
restart your pentaho tool.
hope above solution works for you.
I faced a similar issue and was able to resolve it by deleting the lock file under C:\Users\myuser.pentaho\metastore
Strange event is happening in a Mule project. I have the application xml which is JPC.xml. This normally appears in the mule-deploy.properties as follows
redeployment.enabled=true
encoding=UTF-8
config.resources=JPC.xml
domain=default
When I choose Run As, Mule Application Which kicks off the build in the background prior to the deploy and run. During that time the mule-deploy.properties becomes:
redeployment.enabled=true
encoding=UTF-8
config.resources=
domain=default
And when the application runs it says it is missing the mule-config.xml
What is erasing it?
I think I may have found the root of this issue.
It seems to be a bug related to jdk_1.7.0_45 having to do with xml parsing. see: What's causing these ParseError exceptions when reading off an AWS SQS queue in my Storm cluster
I noticed several errors logged in eclipse/anypoint as:
!ENTRY org.mule.tooling.core 4 0 2014-11-19 14:16:41.081
!MESSAGE Error opening resource measurement_scheduler.xml
!STACK 0
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.
I also noticed that after restarting Anypoint, I would be able to build with maven successfully and my mule-deploy.properties file would again have content. Until...at some point after several edits to things in Anypoint, I would again get mvn build that wiped out the contents of mule-deploy.properties.
I further noticed that once this problem started to happen in one project in Anypoint, it would ALSO start happening in ANY project I built in Anypoint...until restart of Anypoint.
It seems this bug in jdk 1.7.0_45 mistakenly applies this limit in the xml parser to all opened files cumulatively, instead of per file. I suspect this causes Anypoint to not finish parsing all of the xml docs that make up my app and therefore couldnt re-create the mule-deploy.properties...leaving it blank.
Upgrading to newer jdk would fix this.
Another way to work around it is to override this limit for xml parser by adding the following to ${JAVA_HOME}/jre/lib/jaxp.properties:
jdk.xml.entityExpansionLimit=0
jdk.xml.maxGeneralEntitySizeLimit=0
I am not certain that both limits need set to work-around this. Possibly only entityExpansionLimit is needed.
After making this change I am now happily able to use Anypoint again. Beware that using this work-around possibly opens you up to a denial-of-service attack through the xml parser if your same jre is used for other not-so-trusted processes.