where are we at

[Doug Tangren]

It's been a while since I started an initial prototype, posted a few messages here and didn't get much feed back. I noticed there's been some discussion since then on the list. Is this a canonical repo for this. The one hosted under sbt looks pretty bare. It sounds like some people have gone a bit further but in a different direction than the git based one. Is this the case? If so I'll stop thinking about it in the back of my head. There's a million other things that can be built and I'd hate to be building the same thing in parallel. I'm still a fan of git idea, if others have gone in a different direction I'd be happy see whats going on there. It wasn't that clear periodically checking the sbt/adept repo on github.

[Mark Harrah]

Fredrik has a branch with his work:
https://github.com/sbt/adept/tree/freekh

I'm pretty sure it is based on git these days. He'd have to elaborate on the current status.

-Mark

[Fredrik Ekholdt]

Hey Doug!
Sorry it took this long to answer.
My fork (https://github.com/freekh/adept) is also now based on git. I did some perf testing and it seemed to come out ok.
I considered basing it off yours, but since it was mostely de/serialization of the files and the format I had was slightly different I felt it was quicker for me to built it from scratch.
I try to push it to the sbt/adept when I remember.

I was hoping to get an alpha of the fork I am working on out in May, but I am a bit behind schedule.
The alpha will be the bare minimum of what adept needs to be to replace Ivy in Sbt.
Therefore it will consist of:
- an adept-sbt plugin which based on ModuleIDs ("foo" % "bar" % "1.0" in SBT): fetches metadata (when needed), downloads jars (when needed), resolves conflicts and creates a valid classpath and adds it to the managed-classpath in SBT
- a simple CLI
- some Ivy helpers, that makes it possible to import data easily from Ivy. Most of my time has ironically been on trying to get Ivy to play along, but i feel this is important to be able to create a good migration path.
- basic publish functionality, which another contributor, Tomas Herman, has been implementing
- For it to be usable there also has to be some modules in an adept repository that can be used for testing. My strategy here is to gather ivy modules from the community. I have a script that lists all modules in the ivy cache and creates a report that can be sent to me. The plan is then to add every module that can be resolved in the common public repositories (maven central, typesafe, ...). If anybody is interested in trying it out you can do so by running: 'curl http://freekh.github.io/adept/files/adept-ivy-cache.sh | sh' and sending the output to me. I do not have a Windows version of this unfortunately. In the longer run, there has to be a simpler way to do this, but this is a simple and easy to implement way of doing it.


What is left to be done is full configuration support and the adept repository. I also want to make a pass on the sbt plugin to add the resolve.adept file back to the sbt plugin (there is another thread on this).

There is still lots of functionality and issues to be solved for adept to be what I/we want it to be, but I want to get something out as soon as possible to get more feedback. People tend to give more feedback once they can try it out themselves...

Cheers,
F

[Doug Tangren]

On Wednesday, June 5, 2013 9:30:29 AM UTC-4, Fredrik Ekholdt wrote:

Hey Doug!
Sorry it took this long to answer.
My fork (https://github.com/freekh/adept) is also now  based on git. I did some perf testing and it seemed to come out ok.
I considered basing it off yours, but since it was mostely de/serialization of the files and the format I had was slightly different I felt it was quicker for me to built it from scratch.
I try to push it to the sbt/adept when I remember.

I was hoping to get an alpha of the fork I am working on out in May, but I am a bit behind schedule.
The alpha will be the bare minimum of what adept needs to be to replace Ivy in Sbt.
Therefore it will consist of:
- an adept-sbt plugin which based on ModuleIDs ("foo" % "bar" % "1.0" in SBT):  fetches metadata (when needed), downloads jars (when needed), resolves conflicts and creates a valid classpath and adds it to the managed-classpath in SBT
- a simple CLI
- some Ivy helpers, that makes it possible to import data easily from Ivy. Most of my time has ironically been on trying to get Ivy to play along, but i feel this is important to be able to create a good migration path.
- basic publish functionality, which another contributor, Tomas Herman, has been implementing
- For it to be usable there also has to be some modules in an adept repository that can be used for testing. My strategy here is to gather ivy modules from the community. I have a script that lists all modules in the ivy cache and creates a report that can be sent to me. The plan is then to add every module that can be resolved in the common public repositories (maven central, typesafe, ...). If anybody is interested in trying it out you can do so by running:  'curl http://freekh.github.io/adept/files/adept-ivy-cache.sh | sh' and sending the output to me. I do not have a Windows version of this unfortunately. In the longer run, there has to be a simpler way to do this, but this is a simple and easy to implement way of doing it.


What is left to be done is full configuration support and the adept repository. I also want to make a pass on the sbt plugin to add the resolve.adept file back to the sbt plugin (there is another thread on this).

There is still lots of functionality and issues to be solved for adept to be what I/we want it to be, but I want to get something out as soon as possible to get more feedback. People tend to give more feedback once they can try it out themselves...

Cheers,
F

Ah cool. I'd love to be a part of this but now I'm not sure where to jump it. Is there a concrete area I can help out with. I'm particularly interested in cli work. 

With respect to where this went, I'm fine with things. I just was't sure there was a page to be on or where that page was. Are you going to be at scaladays. we should talk.

[Fredrik Ekholdt]

On Jun 10, 2013, at 4:38 PM, Doug Tangren wrote:

On Wednesday, June 5, 2013 9:30:29 AM UTC-4, Fredrik Ekholdt wrote:

Hey Doug!
Sorry it took this long to answer.
My fork (https://github.com/freekh/adept) is also now  based on git. I did some perf testing and it seemed to come out ok.
I considered basing it off yours, but since it was mostely de/serialization of the files and the format I had was slightly different I felt it was quicker for me to built it from scratch.
I try to push it to the sbt/adept when I remember.

I was hoping to get an alpha of the fork I am working on out in May, but I am a bit behind schedule.
The alpha will be the bare minimum of what adept needs to be to replace Ivy in Sbt.
Therefore it will consist of:
- an adept-sbt plugin which based on ModuleIDs ("foo" % "bar" % "1.0" in SBT):  fetches metadata (when needed), downloads jars (when needed), resolves conflicts and creates a valid classpath and adds it to the managed-classpath in SBT
- a simple CLI
- some Ivy helpers, that makes it possible to import data easily from Ivy. Most of my time has ironically been on trying to get Ivy to play along, but i feel this is important to be able to create a good migration path.
- basic publish functionality, which another contributor, Tomas Herman, has been implementing
- For it to be usable there also has to be some modules in an adept repository that can be used for testing. My strategy here is to gather ivy modules from the community. I have a script that lists all modules in the ivy cache and creates a report that can be sent to me. The plan is then to add every module that can be resolved in the common public repositories (maven central, typesafe, ...). If anybody is interested in trying it out you can do so by running:  'curl http://freekh.github.io/adept/files/adept-ivy-cache.sh | sh' and sending the output to me. I do not have a Windows version of this unfortunately. In the longer run, there has to be a simpler way to do this, but this is a simple and easy to implement way of doing it.


What is left to be done is full configuration support and the adept repository. I also want to make a pass on the sbt plugin to add the resolve.adept file back to the sbt plugin (there is another thread on this).

There is still lots of functionality and issues to be solved for adept to be what I/we want it to be, but I want to get something out as soon as possible to get more feedback. People tend to give more feedback once they can try it out themselves...

Cheers,
F

Ah cool. I'd love to be a part of this but now I'm not sure where to jump it. Is there a concrete area I can help out with. I'm particularly interested in cli work. 

Hey! It was cool meeting you yesterday! Looking forward to getting out the alpha, then I will do the following things:

- go over the issues and make it possible to start contributing based on it. Since there are still a lot of loose ends, I think they will be more topic based in the beginning then as we figure out what is the best approach we can work on solidifying them

- create an overview of how adept works, and the architecture so it is possible to use for discussions and for learning more about what we have and have not...

Maybe see you later today! :)