I'm using the ceylon copy command of ceylon version 1.2.3 to download a dependency:
./bin/ceylon copy --rep "http://repo.maven.apache.org/maven2/" -out outdir "joda-time:joda-time/2.9.4"
Why is the result that the tools skips downloading it?
Module joda-time:joda-time/2.9.4 [1/1]) Skipped.
The tool looks - among others - for:
http://repo.maven.apache.org/maven2//joda-time:joda-time/2.9.4/joda-time:joda-time-2.9.4.jar
... but it should look for:
http://repo.maven.apache.org/maven2/joda-time/joda-time/2.9.4/joda-time-2.9.4.jar
Logically the following should then work:
./bin/ceylon copy --rep "http://repo.maven.apache.org/maven2/" --out here --verbose --jvm "joda-time/2.9.4"
... but it tells me:
... Module joda-time/2.9.4 not found ...
... similarily with:
./bin/ceylon copy --rep "http://repo.maven.apache.org/maven2/" --out here --verbose --jvm "joda-time-2.9.4.jar"
... and with:
./bin/ceylon copy --rep "http://repo.maven.apache.org/maven2/" --out here --verbose --jvm "joda-time-2.9.4"
How can I make the copy tool construct the url correctly and get the module downloaded to my local repository?
Really the correct answer here is that the copy tool is not meant for copying Maven modules.
The whole idea of the copy tool is that you have an already compiled module, possibly with dependencies, and you want to copy it to some other repository to be able to run it there. Depending on your use-case you might want to include it's dependencies while copying or not.
In this scenario copying the Maven modules doesn't make too much sense because a) they would be somehow converted from being Maven modules into Ceylon modules (this is not always a trivial process, and that's why we have a special tool ceylon import-jar to help you do that). And b) at the same time your importing code would still refer to the Maven imports which means that even if the copy tool would have copied those Maven modules your original module would still use the modules from the Maven repository! You'd have to change the imports and recompile the code to make this work.
So the bug you encountered is Ceylon 1.2.2 even trying to do so. I've just made a change in the 1.2.3 copy tool where it will always skip any modules that don't come from a Ceylon repository. Its documentation has been updated to make that clear.
Thanks for bringing this to our attention!
Modules with : in their names are resolved to be Maven modules in Ceylon 1.2.2+, so the --rep "http://repo.maven.apache.org/maven2/" is superfluous.
However, it does not really work in 1.2.2, because the resulting repository contains outdir/joda-time:joda-time/2.9.4/joda-time:joda-time-2.9.4.jar which is never going to be resolved by Ceylon (because the name contains a : it will only try to resolve it from Maven repos, not Ceylon repos). So that's a bug.
Also, it did not download dependencies or materialised a module.xml to describe them, so that's another bug.
Now, if you try it in Ceylon 1.2.3 (git master) it will say Skipped and it could be due to the fact that we've added namespaces for Maven imports, and so the syntax could be maven:joda-time:joda-time/2.9.4 (it's really in flux ATM). Except if you try that you'll get an exception, so that's a third bug.
Could you report them please? https://github.com/ceylon/ceylon/issues/new
Related
I know it's a very old thing now, but I need it.
I download scala-sources from the link, unpacking on Ubuntu 20.04. Also I download Ant 1.7.0 and install it. Also I download Apache maven 2.2.1 (or I tried maven 3.5.0) and install it.I also use jdk1.8.0.
I am trying to run "ant" or "ant build" from the scala directory, and something happens, but the build failed for the following reasons:
failed to create task or type scalacfork
Build failed
The following messages also appear at the top:
[taskdef] java.util.zip.ZipException: zip file is empty
(several times)
...
[WARNING] POM for 'biz.aQute:bndlib:pom:1.43.0:compile' is invalid.
...
[taskdef] Could not load definitions from resource scala/tools/ant/sabbus/antlib.xml. It could not be found.
I understand that many things are no longer available now and are definitely not supported, but maybe someone will tell me a way to get the result.
Maybe I can download the necessary data and manually build scala? I'm new to this and don't quite understand what and where I can change. And I can't use a newer version of scala because of work.
I hope for any help. Thank you in advance.
Yes, it is possible. Although it requires some patches in the build process and a few workarounds.
Read the README.rst, it contains some information on how builds are structured
Run git init, git add ., git commit as the build uses some git info (commit hash, etc) during build. It may be not needed for release, but I have not tried.
You need either JDK 1.6 or JDK 1.7. It can't be built on the 1.8 JDK (compilation fails if you remove checks from build.xml). And on 1.7 it says it can't build swing library so you won't be able to build distribution.
Fix the tools/binary-repo-lib.sh and change URLs to https otherwise fetching artifacts will fail. Maybe you have to remove some of the curl arguments to see what happens, maybe it won't be required.
Run pull-binary-libs.sh
Fix build.xml to use https protocol. This is based on the Official usage documentation. You have to define repository before the first artifact:dependencies task in the file (I did that in the same block).
<artifact:remoteRepository id="central" url="https://repo1.maven.org/maven2" />
Then you have to tell every artifact:dependency task to use that repo by adding the remoteRepository element, the tasks should look like
<artifact:dependencies pathId="extra.tasks.classpath" filesetId="extra.tasks.fileset">
<dependency groupId="biz.aQute" artifactId="bnd" version="1.50.0"/>
<remoteRepository refid="central"/>
</artifact:dependencies>
I think this was enough for me to build it using ant build on JDK 1.7 (apparently, swing libs were not built).
But probably the easier way would be to just download prebuild Scala version or tell your build tool to use the Scala version you want.
This may or may not be a duplicate of How to use chisel module as package.
Again, for scala/sbt/maven experts this may be obvious, for old school ASIC designers it's not:
I have project PROJ with standard directory structure PROJ/src/main/scala/myproj.scala. How do I use some chisel code from some external library LIB? Eg. from /usr/libs/LIB/src/main/scala/{stuff}.scala?
(Not a full answer, more a warning than an answer)
"Search path" sounds a bit concerning, so I'd just want to make sure that you don't expect something like a C/C++ build that's searching for some files on some file systems.
Before proceeding, it might be helpful to ponder on the thought that the entire scala / java / kotlin / maven / sbt / gradle / ... ecosystem is "internet-centric", not "file-system-centric". It essentially assumes that all packages are available under a globally unique identifier in some online repository (even when they are not, local installation will make them look as if they came from a public repository, see below). Local file systems are used only as temporary local caches (and it is assumed that you as a human will not look into those caches without a good reason). In general, it tries really hard not to depend on the machine on which it's built: everything it needs is specified in the build.sbt, presence or absence of any files in /usr/lib is irrelevant.
If you want to use a package, you have to declare it as a dependency in your build config (SBT documentation definitely does tell how to do this; Maven Central even provides a helpful little textfield from which you can copy the correctly formatted pieces of the config).
If your package does not come from any public repository, you'll first have to install it locally (SBT documentation must also tell how to "install a package locally", it's a short SBT command that will copy the package into the local cache in your file system, so that other projects that depend on it can pretend as if it came from some repository).
If you have just the src/foo/bar/baz/stuff.scala-files, but no build.sbt-file, you'll probably first want to convert it into a proper sbt-project, then build it, then install it locally (you need a JAR, adding .scala files to the CLASSPATH won't buy you anything, they must be compiled first; Doing anything to the CLASSPATH manually is essentially hopeless anyway, the only way to do it is to let SBT take care of everything).
How to initialize a new Scala project in sbt, Eclipse and github, so that it all plays together...
A new Scala project typically requires being set up for sbt, eclipse (if you so choose) and github such that it all works together. After investing some time on this setup, it may help to have this list for aligning these 3 tools/services, for as long as simpler ways are not available. The series of steps that works for me follows. It assumes you have the Scala IDE plugin installed in eclipse.
Create a new repo in Github.
Decide a directory location for the new project
In eclipse, use the Git Repositories View to import the Github repo into that location. Alternatively you can use command line git for that.
Locate to that same location you've chosen for the project and run sbt eclipse. This makes sure eclipse will be able to handle the sbt project structure, so that your project can be built by sbt while also being intelligible for eclipse. If sbt eclipse doesn't work, the sbt eclipse plugin is probably not installed in sbt - install it.
In eclipse, use File --> Import --> General --> Existing Projects into Workspace, selecting that same location, so that eclipse builds its project structure for the file structure having just been prepared by sbt.
Make git ignore all but the core of your new project by updating the .gitignore file to ignore eclipse and sbt files. The following seems to be currently fine.
*.class
*.log
# sbt specific
dist/*
target/
lib_managed/
src_managed/
project/boot/
project/plugins/project/
# Scala-IDE specific
.scala_dependencies
# Eclipse specific
.project
.classpath
.cache
You should now be able to run the project in eclipse, and in sbt, and commit and push code changes through git. To see the empty project run, which may very well make sense at this stage, you can add a scala class in eclipse to it, containing merely the following code. Note that scala sources should typically sit under src/main/scala. If this path doesn't exist yet, create it through e.g. mkdir -p src/main/scala on Unix.
object hello {
def main(args: Array[String]) {
println("Main starting")
}
}
Or alternatively only this code:
object app extends App {
println("Application starting")
}
It should work now.
Need to disclaim that future versions of eclipse, sbt, etc may render this outdated.
If this is dead wrong in your environment, you can add a better answer.
Previous answer/s is/are of high importance as well as the question since these tools are not self explanatory. Based on personal experience with this challenge which seemed impossible but when one acknowledges few key insurance policy reference points things will become reality:
Implementation of development environment may require radical
re-installation as new tool is adopted (if you adopt GIT after you
already had SBT in place you may need to empty SBT's working
directory as GIT require the cloning process to have empty house on
local working directory)
Keep really well updated backups especially when considering
re-setting any of this "domino" environment layers as some of the GUI
or command initiated cleansing operations truly take care of that
sometimes with surprising effectiveness and without any regard to
other tools / layers requirements
Keep really good documentation (including previous pragmatic answer) on key stages to
make things a reality (again)
I've seen that there are quite a few questions regarding this problem, but unfortunately none have solved it for me. Here is a screencap of what's going on:
It is dependent on the android-support-v4 jar file which as you can see is added to my build path. It the exact jar file from the maven library directory's libs folder. I've tried the following:
Restarting Eclipse
Cleaning the project
Right-clicking the project and updating dependencies
Updating project configuration Disabling and re-enabling workspace resolution
Nothing has helped. Is there any other tricks to getting this resolved? All of the answer's I've seen suggest doing these things that I have already tried.
Thanks a lot!
Actual root cause:
The OP JMRboosties reports in this instance having to desactivate Proguard (the tool which shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names)
disabling proguard on the line where the error occurred (the <plugin> item) in pom.xml solved the problem
(See "How to use ProGuard with android-maven-plugin ").
Certain side-effects can result from using Proguard: For example, the Proguard page does mention:
The default proguard.cfg file tries to cover general cases, but you might encounter exceptions such as ClassNotFoundException, which happens when ProGuard strips away an entire class that your application calls.
Original answer:
As mentioned in this GitHub post:
you need to use maven Android SDK Deployer to install it:
I'm going to deploy my own android artifacts to my personal repository to avoid having this problem again.
If you're not explicitly using Maven you can just import it as a regular Android project into eclipse and it'll pick up the .jar from the libs/ directory.
(Note your android-support-v4.jar isn't in libs in your project)
declare it in your pom.xml.
You have to install both Android 1.6 and the compat lib using the maven SDK deployer for now.
cd to platforms/platform-4/ and extras/compatibility-v4/ in the deployer and run mvn install in each.
Hopefully the compat lib makes it into maven central soon so I can avoid this step.
Again, the project is set up to be used as a normal Android project in eclipse too completely separate from maven.
File, New, Project, Android, use existing sources, select library/ folder.
Assuming you're using m2e-android behind the scenes, the reason you're getting compile problems is that the m2e-android plug-in strips out all provided scope dependencies from the Eclipse project classpath.
We do this because, due to changes in ADT 16.0.0, any JAR file in the Eclipse classpath will be packaged into distributable APK file.
I'm having some problem with Maven's scm element and subversion.
I added the following to my pom.xml:
<scm>
<connection>scm:svn:svn+ssh://user#x.y.z/repositorypath</connection
<developerConnection>scm:svn:svn+ssh://user#x.y.z/repositorypath</developerConnection>
<url>scm:svn:svn+ssh://user#x.y.z/repositorypath</url>
</scm>
in order to use svn revision in my JAR files manifest.
But when I run "clean package" on that, I get this:
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: The path 'C:\xxxxxx' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
Still, subversion seems to work great otherwise: I can checkout, update and commit just fine from Eclipse. I also tried running upgrade for my working copy, but it was already upgraded.
Our subversion server is 1.6.11 and my Eclipse uses Subclipse 1.8. Java HL is 1.7.2
So what should I change to get this to work? Also, is there a way to omit the username from the svn+ssh url? So that the pom.xml could be use by all developers?
EDIT:
I should have mentioned that I also added buildnumber-maven-plugin to my pom.xml when I started getting this error. I now looks to me as if that plugin is unable to deal with my subversion version. Oddly it's homepage here claims that the newest is 1.1-SNAPSHOT, while I can't find newer than 1.0 (must I enable using snapshots explicitly somehow?)
You have used the scm element correctly in your pom.xml
One way to avoid having to handle username/password is to configure an anonymous read-only access to your repository to be used for build and similar purposes. Otherwise, the SO references alluded to above gives some directions on how to externalize at least the password, if not the username.
As for the error message, you see this because of difference in the versions of the subversion client used by Eclipse and maven scm plugin.
From the error message, it looks like Eclipse has created (some of) the subversion folders (.svn) in the newer (1.7) format. It looks like maven scm client uses the 1.6 format as per this.
One way to fix the problem is checkout the project using maven scm plugin itself or an older subversion client.
To omit the username, look for the file .ssh/config in your %HOME% directory, add the following two lines to it (leave any existing lines alone):
Host x.y.z
User user