I've found the "Beginner's Guide to Setup Xuggler" article from here. I was trying to follow the best chosen answer. While going through the steps, I got stuck # "Run ivy from command-line as follows:" I didn't had Ivy at first, so I headed to Ivy's download page, and downloaded from the Snapshot Build section of the site. Then, I tested with both jar files, but while running the command stated in the Beginner's Guide, I'm getting this message: "ivy configuration file not found: ivysettings.xml". So, what did I do wrong, need I follow the "Building from source" section from the site? If so, can you please give me a detailed description of how to do it, I'm kinda new in these things. Long story short, I need to know how o get a legit "ivy.jar" file as stated in the command line of the Guide.
Ok, so I've solved the problem my own way, kind of. So, I'm gonna share it here so that other fellows like me may profit from it. So, what I did was that I (obviously) downloaded Xuggler 5.4. Then, I downloaded its dependencies manually as listed here. Then, on my IDE, I just had to import Xuggler and all of its dependencies which I previously downloaded and BAM, it worked like a charm. So, if any of you are having problem finding those dependencies or have any queries concerning this "unofficial" method of mine, you can contact me via email. I'll gladly help. :)
I don't know from Xuggler, but... the error message said you're missing ivysettings.xml. The message is probably from ivy.jar, so you definitely have that. ivysettings.xml is a required Ivy config file that tells what repositories you want to pull jars from. There may be a default one in the Xuggler distro, but probably not. You need to look at the ivy documentation to get farther. Or, use Maven instead. While I'm not a fan of Maven, for this kind of situation it may be easier.
Related
Hi everyone I am new to IntelliJ in general and especially to Gradle and I feel like a total noob. :D
Im not sure if this is a Kotlin DSL thing or if I just do it the wrong way and it wouldn't work in Groovey either.
After hours of trial and error and reading other SO posts I'm still not able to install a simple dependency... it can't be that hard...
Currently I am playing around with Jetpack Compose for Desktop even though it's still in alpha and it works but for the love of god I am not able to add a dependency.
So here is my Problem:
I try to install the dependency like they say I should in
https://developer.android.com/jetpack/compose/navigation#kts
and yes I know it's an android package so it may not compile or it may crash during runtime but shouldn't it at least find and download the dependency???
So... if I add
implementation("androidx.navigation:navigation-compose:2.4.0-alpha10")
to my build.gradle.kts
And try to compile it I get an exception during the build process:
What I tried so far:
I checked if the repository maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
who is configured in my build.gradle.kts repositories-section and in my settings.gradle.kts pluginManagement-section contains the package that I want.
The site https://mvnrepository.com/artifact/androidx.navigation/navigation-compose?repo=space-public-compose-dev tells me, that the repository contains the package that I need.
I checked the error log itself.
But I don't relly know what it tries to say.
I use Java SDK16, since I expect downward compatibility and the fact that the dependency is still in alpha I assume it should be compatible.
I use Kotlin 1.5....
that's it.
Thanks for reading all that :) I really appreciate your time... If I forgot some crucial information let me know and I will add it as soon as I can.
the problem which I feel is, is you are basically opening the wrong file. (I don't use jetpack compose so the answer might differ)
on the top left corner in the image, where there is project dropdown, open it and select android.
now there will be a different set of files in the Gradle folder, in fact, there will be 2 different files in that folder.
build.gradle (project: <project_name>)
build.gradle (Module: <project_name>.app)
open the second file and there will be dependencies copy + paste implementation code there.
the file which you have opened is actually the first file.
Well... here I am back again answering my own question.
After I switched to the terminal in IntelliJ Idea (which to be honest I could have thought of that prior to posting my question) there was highlighted text that gave me the necessary insight, why it wasn't working.
And after some searching the web in order to find out what an "aar" file is and why I didn't get a jar file like I expected it turns out that android has it's own little file format for android applications and that those cannot be used in regular java/kotlin projects.
I read somewhere, that 'aar' files contain a jar file and some other stuff and extracting the jar file from the aar file may be a way to get it working, but it didn't fix anything, maybe because the dependencies of the navigation package are aar files as well and therefor I'd need those packages as well and extract the jar file from those as well and it all seems like this isn't the right way...
So I guess I have to wait until Jetpack Compose for desktop somehow is able to use aar files or until the repositories deliver the packages in a regular jar file.
I've dug a lot and learned how to share the run configurations in IntelliJ IDEA CE (presently using 2019.3.4) via the in .idea/runConfigurations/*.xml files. When we check those file into VCS (Git) others get them and all works as expected.
The question is related to sharing the templates for JUnit and Application configurations. When created manually they end up in .idea/workspace.xml which is not meant for or suitable for sharing (often modified, has personal preferences and even screen locations, ...).
I could not find any mention of how to do this so I tried extracting the relevant <component ...>...</component> fragments into standalone files inside .idea/runConfigurations/. This seemed to work but weird things started happening - IDEA renamed the files from my original names (whatever they were, forgot), to:
.idea/_template__of_JUnit.xml and
.idea/_template__of_Application.xml
I was happy with that and submitted those to Git but then other people commented how IDEA keeps renaming those files further.
What is the proper way to accomplish this?
Thanks!
IntelliJ IDEA doesn't support sharing run/debug configuration defaults at the moment.
I am new to rest, so I followed this tutorial exactly the way its mentioned here:
However, I get a requested resource not found error when I hit the URI mentioned there, that is,
http://localhost:8080/RestletDemo/service/helloWorld
My build was successful.
This is the first time I am posting a question, my apologies for any ambiguity. Do let me know if you need more information.
It's difficult to figure out your problem like that. I have a look at your link and the problem of the provided code is that there are a lot of plumbing. Things could be much more simpler leveraging for example bean converters (Jackson one for example).
However, I didn't see anything strange in this code. Perhaps it's a configuration problem within your servlet container. For example, when using Tomcat with WTP in Eclipse, I need to check the item "Publish module contexts to separate XML files" to make things work.
I just submitted a very simple Restlet project targetting servlet and without all these plumbing. I made it work under Eclipse with WTP 2 (Tomcat7). You can reach it here:
https://github.com/templth/restlet-stackoverflow/tree/master/restlet/test-restlet-servlet
Since it use Maven, to use it, you can simply :
mvn eclipse:eclipse and then import it into Eclipse. You can then create a server (WTP) and add the project
mvn package and deploy the corresponding war into a servlet container (Tomcat or something else)
Hope it helps you,
Thierry
I am trying to get the run-exploded goal of the jetty-maven-plugin to work correctly. I find the documentation somewhat lacking on what I need to do to set this up.
I believe I have a standard WAR-file setup. (The reason I wrote "believe" is that I find the maven-war-plugin documentation lacking as well.) When I build my webapp using maven package, I get the following in my target folder:
classes
maven-archiver
surefire-reports
test-classes
tmp
mywebapp-version
mywebapp-version.war
where mywebapp-version is the exploded war and mywebapp-version.war is the packaged one. So far so good (I think?).
Now, running mvn jetty:run-exploded, it seems the default deploy folder is target/tmp/webapp/mywebapp-version.war/. This folder exists, but contains no files except for a webapp-cache.xml. This seems wrong to me.
I also tried to actively set the webApp configuration element to ${project.build.directory}/mywebapp-version/, but run-exploded seems to ignore it (despite the documentation stating otherwise).
What am I doing wrong? It looks as if I am missing something simple since no one else appears to be running into the same problem.
Now, running mvn jetty:run-exploded, it seems the default deploy folder is target/tmp/webapp/mywebapp-version.war/. This folder exists, but contains no files except for a webapp-cache.xml. This seems wrong to me.
According to the documentation of the jetty:run-exploded mojo, the default value for the tmpDirectory is target/jetty-tmp.
I also tried to actively set the webApp configuration element to ${project.build.directory}/mywebapp-version/, but run-exploded seems to ignore it (despite the documentation stating otherwise).
The webApp defaults to ${project.build.directory}/${project.build.finalName} so I'm not sure your "active" configuration changed anything.
What am I doing wrong? It looks as if I am missing something simple since no one else appears to be running into the same problem.
Well, what is the problem actually? :) What are you expecting exactly (I'm suspecting a misunderstanding of what is supposed to happen).
By the way, I find the Maven Jetty Plugin Configuration Guide and the documentation of Jetty's mojos pretty decent.
I've asked a similar question in which part of this was addressed, but I'd like to expand in more detail.
When configuring maven to look at internal repositories, is it best to put that information in the project pom or in a user's settings.xml? An explanation on why would be really helpful here.
thanks,
Jeff
You should always try to make the maven project so that it compiles from a clean checkout from source control in your local environment; without a settings.xml. In my opinion this means that you place any overrides to sensible default values in the user's settings.xml file. But the pom should contain sensible values that will work for everyone.
I encourage you to put the repository definition in the POM, this way any developer just grab a copy of the code and run Maven to get it compiled, without having to change things in his settings file.
I find the setting.xml file useful just for hacking Maven's behaviour in special situations, for example when one repository is not accessible due to a firewall and you need to use a mirror. But that's my personal opinion. Maven documentation gives you more freedom:
The settings element in the
settings.xml file contains elements
used to define values which configure
Maven execution in various ways, like
the pom.xml, but should not be bundled
to any specific project, or
distributed to an audience. These
include values such as the local
repository location, alternate remote
repository servers, and authentication
information.
If you have a local repository which is used in every single project you may add that at the settings.xml, just be sure that configuration is well documented, in my current project it's not and new developers struggle at the beginning when they try to compile something.
We use the user's settings.xml and include info in the README about what possible other repos may be needed.
In theory a given group-artifact-version is the same no matter which repo it comes from. It works pretty well for us. If you find yourself with two different assets that have the same group-artifact-version identifier, then that indicates you're doing something really bad.