Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have downloaded and installed sbt and plugin for gen-idea.
But the built projects can not be run on idea.
Also the "project" folder is not generated when I run gen-idea.
Can someone please tell me how I should install sbt and sbt-idea plugin and configure it, as I think the problem here is configuring.
In all sbt projects you have a project folder (in the root of your project directory). You need to create there a file called - plugins.sbt and place there:
resolvers += "Sonatype snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0-SNAPSHOT")
Notice that i have a blank line between. Then, if you have an opened sbt session call reload command, you can call gen-idea to generate idea files, also i recomend to add sbt-classifiers to download sources.
Otherwise you can make this plugin visible globally to all your sbt project, by placing the same two line in the ~/.sbt/0.13/plugins/build.sbt file.
When you have generated this project, in IDEA choose Open Project and choose your newly generated project. This should work, if not, provide some additional info.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
IDEs produce some config files per project/workspace
IntelliJ has it's .idea/ folder and it's .iml files.
Eclipse has its .classpath and .project files.
Eclipse Maven integration used to need a m2e-lifecycle configuration in the pom.xml (not sure if this is still the case)
I've seen projects in the past,
where Eclipse artifacts (.classpath, .project) have been stored in the SVN and it usually broke every developer's workspace.
where even the m2e-lifecycle configuration was prohibited
where the m2e-lifecycle configuration was allowed but not .classpath or .project
where subsets of the .idea/ folder is checked in because it contains the run-configurations
typically .gitignore files contain IDE specific files.
I tend to leave all IDE artifacts out of the sourcecode, including configuration, except the listing of IDE artifacts in the .gitignore.
But I wonder, what are good reasons for / against checking in
IDE generated artifacts (like .classpath or *.iml)
IDE specific configurations (i.e. in maven poms)
into the SCM?
Or is it a general No-Go?
If you use Maven/Gradle/SBT there is no point to commit *.iml files as they are re-generated from Maven/Gradle/SBT. Artifacts are also automatically generated form these build systems, so unless you creates your own IDE artifacts you should not commit artifacts configuration.
See also How to manage projects under Version Control Systems.
See also similar question: Which files in .idea folder should be tracked by Git?.
Why you should omit them:
you want to be able to build your projects with the build tool of your choice (e.g. maven, gradle, etc.) on any build server you like (that actually supports them)
you want to be able to load the project with any IDE (no quirks in the IDE project settings to get it to work somehow)
Why you should commit them:
all use the same IDE in the project (and maybe also: all have the same directory structure; note: I would never force anyone to use a particular IDE or fixed directory structure, so I actually don't like this particular point ;-) )
OR (probably more valid): you are the only one to use the project and want to (re-)setup everything rather quickly/smoothly
Regarding IDE settings, such as formatting settings, etc. something similar applies. As long as all use the same IDE sharing makes sense. If you use different ones, you may need to use your version-control-tool to actually format the code (formatting commit hook, formatting before comparing different revisions, etc.) or everyone should rather agree on a common formatter.
Regarding IDE specific settings in build-files like m2e-lifecycle:
... it really depends. I would rather try to use plugin configurations that actually work without additional m2e-lifecycle-boilerplate. In the end it doesn't make the build-file any more readable ;-)
Summarizing (my opinion ;-)) I only commit IDE specific files when working alone on a project and in any other case I omitted committing them as did teammates. If they were committed in a project I usually didn't reuse it (or only the formatter via plugins) as I mostly was on another IDE.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
JasperReports 6.2.2 contains only dis folder containing jasper report .jar , dataflow.jar and font.jar while other jars as :
commons-beanutils-*.jar
commons-collections-*.jar
commons-digester-*.jar
commons-logging-*.jar
groovy-all-*.jar
itextpdf-*.jar
itext-pdfa-*.jar
are missing. So should i separately download each jar or not?
Indeed, in recent releases we gave up distributing the third-party jars in the lib folder and instead, we are using the Apache Ivy plugin for Ant to automatically download them from public Maven repositories at source code build time or when running the samples.
So you need to download them on your own from public repositories. In the next release, there will be an Ant target to retrieve them all with a simple command.
Until then, copy this snippet in the build.xml file found in the root folder of your JR 6.2.2 source distro:
<target name="retrievelibs" description="Retrieve dependencies with Apache Ivy">
<ivy:retrieve conf="compile, javaflow, test" pattern="dist/lib/[artifact](-[classifier])-[revision].[ext]"/>
</target>
If you launch >ant retrievelibs from command line, you'll have all libs required to compile JR Lib places in the /dist/lib folder of the project.
Note that depending on which are of functionality you use, you'll need additional JARs. Each sample in our project distro brings additional JARs needed at runtime. You can check which JARs are needed as they are listed in the ivy.xml file of that particular sample. You can use a similar target in the build.xml of the sample to have those JARs downloaded for you.
If you are using Maven, you could launch:
>mvn dependency:copy-dependencies
command and get all dependencies including the transient ones in the target/dependecy folder of the JR project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm new to the sbt and scala. I've installed sbt and sbt-idea. How can I create an idea project now ?
I personally got it work fairly painlessly by following the documentation: add the following lines to your project's ./project/plugins.sbt:
resolvers += "Sonatype snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0-SNAPSHOT")
Reload sbt, the gen-idea command should now be available.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I downloaded the latest ollydbg 2.x version from its official site and some plugins from tuts4you. But how to enable/install the plugins?
either you put the plugin dll inside a dedicated directory (e.g. Plugins) or in the same directory than ollydbg.exe
in the Options / Options... / Directories panel, configure the Plugin directory setting accordingly to the place where you put the dll. If you put the dll in ollydbg.exe directory, you can set .
restart OllyDbg
you should have a plugins menu where the plugins add their menus entry points
This is a general procedure, you might need to adapt for specific plugins : e.g. some may need additional .txt or .ini files. This should be described inside the plugin package.
Also, if you have done this settings and still cannot see your plugin, beware that the plugin API had a recent major upgrade for version 2.01h. Some existing plugins may not be supported anymore.
If you don't have you plugin source code or cannot rebuild it yourself it is possible to try to patch the plugin dll to let it load in Olly. This is tricky because you need to patch the version number, and probably the callbacks in the dll concerned by the plugin api. The procedure is described in a screencast.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am diving into Scala and noticed sbt. I have been quite happy with Gradle in java/groovy projects, and I know there's a scala plugin for Gradle.
What could be good reasons to favour sbt over Gradle in a Scala project?
Note that one key difference between SBT and Gradle is its dependency management:
SBT: Ivy, with a a revision which can be given as a fixed one (1.5.2, for instance) or as latest (or dynamic) one.
See "Ivy Dependency"
That means the "-SNAPSHOT" mechanism support can be problematic, even though Mark Harrah details in this thread:
It is true the cache can get confused, but it is not true that Ivy doesn't understand resolving snapshots. Eugene explained this point in another thread, perhaps on the admin list. There is an issue with sbt's auto-update that was addressed in 0.12.
What Ivy does not support, as far as I know, is publishing snapshots in the manner Maven does. I believe I have stated this elsewhere, but if anyone wants to improve the situation, my opinion is that effort is best spent working with the Gradle team to reuse their dependency management code.
Gradle: This thread mentions (Peter Niederwieser):
Just to let you know, problems with Ivy and Maven snapshot dependencies were one of the reasons why Gradle eventually replaced Ivy with its own dependency management code. It was a big task, but brought us a lot of goodness.
This tweet mentions that the all situation could evolve in the future:
Mark said in the past that he was interested in using Gradle instead of Ivy for SBT.
(both tools can learn from each other)
For me the key features of SBT are:
Fast compilation (faster than fsc).
Continuous compilation/testing: the command ~test will recompile and test you project everytime you save a modification.
Cross-compilation and cross-publishing, across several scala versions.
Automatically retrieving dependencies with the correct scala version compatibility.
The downsides are:
A hieroglyphic syntax that tends to discourage new users (especially if they come from Java)
No easy way to define a "task": if you need a special build procedure, you will need to either find a plugin, or write a plugin yourself.
sbt is a Scala DSL and for it Scala is a first class citizen, so in principal it seems to be a good fit.
But sbt suffers from major incompatible changes between versions, which makes it hard to find the correct working plugin for a task and get it to work.
I personally gave up on sbt, since it was causing more problems than it solved. I actually switched to gradle.
Go figure.
I'm fairly new to gradle, and very new to sbt - what I really like about sbt so far is the interactive console. It allows me to use commands like 'inspect' to get a better idea of what's going on. AFAIK gradle does not provide something like this atm.
Sbt and gradle, both are based on statically typed languages....but sbt has few advantages:
better plugin support, specially autoplugins
task creation and dependency management between tasks
sbt specially suits scala projects in the sense that it supports incremental builds and most of the sbt itself is written in scala and sbt build definitions is written in scala
sbt has interative shell support with many useful built-in tasks
sbt default lifecycle is pretty useful and can get novice started with pretty less effort