create a working gradle plugin with adept

Progress indicator goes crazy for SBT projects with multiple sub projects.

When i try to run sbt in the adept repo, i get the following error:

java.lang.IllegalArgumentException: Illegal pattern character 'Y'
at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:768)
at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:575)
at java.text.SimpleDateFormat.(SimpleDateFormat.java:500)
at java.text.SimpleDateFormat.(SimpleDateFormat.java:475)
at AdeptBuild$$anonfun$3.apply(Build.scala:11)
at AdeptBuild$$anonfun$3.apply(Build.scala:10)
at sbt.Init$Value$$anonfun$apply$6.apply(Settings.scala:329)
at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$constant$1.apply(INode.scala:158)
at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$constant$1.apply(INode.scala:158)
at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:177)
at sbt.EvaluateSettings$INode.evaluate(INode.scala:132)
at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:64)
at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:73)
at sbt.EvaluateSettings$$anon$3.run(INode.scala:69)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

I think it would be useful to test adept against openjdk6 aswell as openjdk7

Lockfile tests are pending, but we should add a simple test for it.

Currently you can search for a module in a universe. If it fails, it should tell you about other universes where it can find the module

Example: search for scala-version 2.10 for a module, and nothing is found. If there exists a module matching the coordinates for 2.9.2 adept should notify the user somehow

Hi,

Is it possible to support Hg and Bazaar also. If not Bazaar at least Hg.

Suminda

If you have a dependency in libraryDependency and the same one appears somewhere in the adeptDependencies you risk having a broken classpath

The term ResolutionResult should be replaced with Context. Specifically a "ResolutionResult" is a ContextValue and "ResolutionResults" (plural) is a Context.

The reason for the name change is that it makes it easier to sell the reliability:
The definition of context is as follows:
the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.
VS the definition of state:
the particular condition that someone or something is in at a specific time.

The difference here is time. Ivy and Maven has state (changes over time), but Adept has uses a context which is immutable over time. Ivy/Maven: dependencies X state(time) = result(time), Adept: dependencies X context = result.

The Jvm target in the build.sbt does not seem to do what it is supposed to: make adept-core and adept-lockfile compatible with JVM target 1.6.

I think adept would be a perfect fit for a dep mgr cli that resolves and generates the lockfiles. This way it can be used by more people.

In http://adepthub.com/blog/2014/02/19/resolution-engine-0, you write that:

because the actual matching in Adept is redonkulously simple and only does equality. If you want binary version 2.2, that is what you're getting. In the same way, you can get libraries with "license" equal to "apache2" or have only the ones with "QA department seal of approval" equal to "approved".

The "seal of approval" part got me wondering about cryptographic signatures on packages. Since those would be a function of the package contents, it wouldn't be a pure equality check, but would rather be a signature verification against some list of approved public keys (or some PKI hierarchy). Is that a planned feature or do you have thoughts on it?

If there is a dependency that is missing and not evicted adept should fail with a easy-to-understand error message and not continue to compile task

Documentation must be improved and updated - it is not possible to get a good understanding of Adept the way it is now without a better doc.

Security updates should be visible as soon as possible. Preferably within minutes after they are published people should have all the information needed to start upgrading.

I think getting information about security updates should be the major driver in Adapt's target of discovering new artifacts.

One way to do this is by clearly printing the security updates during each 'build'.

There are marks to do performance tests, but they just write to system out. I want these to write to a json file, which can be displayed in a static html (on GitHub). These tests should note which type of disk (SSD/HD), CPU and memory. I want there to be integration tests that are bigger than the tests we have today and have perf marks on them as well.
This way we can agregate the perf benchmarks from all committers.
There is no point in talking about perf improvements before this is online.

This is more of a documentation issue than a functionality one. I was skimming the readme and whatever readings I could find, and was unable to figure out an answer to "if I were to start using this today, would I be signing up for a world of pain?"

It seems like a question worth answering prominently. I don't see much activity on the issue tracker or the mailing list, so it's hard to tell.

Hi,

Is it possible to have tighter and seamless IDE integration. Also perhaps package with Scala IDE also.

Suminda

Hi,

Say if I have project A in SBT, project B on Maven, C on Gradle, D on Buildr, ... I while the projects are hosted on GIT, Hg, Bazaar, etc. It will be nice to be able to create a projects say SuperProject which uses all this by pointing to the relevant repos' hash / tag / etc. then get the build script evoke the build tool and cache the artifacts without having to build separately or use output builds of the subprojects.

Also generate build scripts for SuperProject to integrated as a sub project into other build systems by generating the Maven, Gradle, SBT files and plugins.

Suminda

Progress on the lockfiles seems to be broken in the adept build. My assumption is that if there are multiple downloads going on at the same time, we will have issues.

Need a thread safe way to handle this.

Sometimes builds hang when trying to download artifacts

snippet:

[warn]     fromCallback(() => {
[warn]     ^
[info] Done updating.
10/11 - 92% - 43.26 kb/s - total: 4.61 mb34/46 - 39% - 176.57 kb/s - total: 32.62 m3410/11 - 92% - 43.22 kb/s - total: 4.61 mb[info] Packaging /s/playframework/framework/src/anorm/target/scala-2.10/anorm_2.10-2.0-unknown.jar ...
34/46 - 39% - 176.54 kb/s - total: 32.62 mb[info] Done packaging.
736/46 - 43% - 177.07 kb/s - total: 32.62 36/46 - 44% - 177.72 kb/s - total: 32.62 mb[warn] 6 warnings found
370/72 - 83% - 89.00 kb/s - total: 45.62 mb[info] Packaging /s/playframework/framework/src/iteratees/target/scala-2.10/play-iteratees_2.10-2.0-unknown.jar ...
36/46 - 44% - 177.90 kb/s - total: 32.62 mb[info] Done packaging.
36/46 - 44% - 178.03 kb/s - total: 32.62 m36/46 - 44% - 178.14 kb/s - total: 32.62 mb[info] Packaging /s/playframework/framework/src/routes-compiler/target/scala-2.9.2/routes-compiler_2.9.2-2.0-unknown.jar ...
36/46 - 44% - 178.16 kb/s - total: 32.62 mb[info] Done packaging.
36/46 - 46% - 178.98 kb/s - total: 32.62 mb311/11 - 100% - 41.88 kb/s - total: 4.61 mb
43/46 - 94% - 180.99 kb/s - total: 32.62 mb72/72 - 100% - 88.35 kb/s - total: 45.62 mb
45/46 - 100% - 183.66 kb/s - total: 32.62 mb

Right now now there are 2 different ways of reading json files. Adept-lockfile uses json-smart, because it is only 1 small jar. Adept-core uses play-json because I knew it better. We should probably replace play-json with json-smart because it will be more standardized and it will reduce the jar footprint. Must verify that performance is good though.

Currently it is not possible to search adept for coordinates.

A regex based search would be great where you could do something like: adept search akka and get all coordinates for akka would be great

Failing to download an artifact should say which artifact is missing and not continue to compile task

Tentative API call:

repository.pull()
val gitFiles = adept.localPublish(variants, repository, artifacts = Set(new File("/Users/awesomeperson/Projects/myproject")))
repository.add(gitFiles)
repository.commit("A new release of my awesome project!")

Currently the progress and logger in the lockfile is not used in adept-core. Also there should be a bridge so that logging using slf4j or logback with the lockfile and adept-core works seemlessly.

Check whether both versions work correctly.

For now only 7 is checked.