search

foundweekends / conscript

Scala at your command
https://www.foundweekends.org/conscript/
478 stars 65 forks source link

force update #2

Closed eed3si9n closed 13 years ago

eed3si9n commented 13 years ago

steps

cs -f eed3si9n/scalaxb or some other way.

expectations

  1. conscript grabs jars from the repo even if I have already for the particular version.
  2. it doesn't break other apps installed by conscript.

    why?

not sure if it's a good practice, but I publish multiple snapshot builds between releases using the same x.x.x-SNAPSHOT version number. currently, I need go to ~/.conscript/boot/scala-2.8/, ~/.ivy2/cache/, ~/.ivy2/local/ to clean out the stuff.

please feel free to reject this usage as abnormal.

n8han commented 13 years ago

(omg, markdown formatted bug report!)

I know what you're talking about and it's a great annoyance when developing for the sbt launcher. conscript 0.2.0 runs programs nicely but it is not so helpful on the development side.

I've thought of a couple of ways of dealing with it.

1) From within an sbt-plugin that helps you make conscripts, similar to the one that helps you make giter8 templates. It might simulate the invocation of conscript using its own boot directory which it rebuilds on each run.

2) From a processor that does the above, as much as possible. (I find it harder to do a lot of things from a processor.) @softprops has already started on this and is going to add it to this repo.

3) A cs --clean (is this a good name?) command that erases the boot directory. This is not as destructive as it sounds, since you still generally have everything in ~/.ivy/cache, so each of your conscripts will refetch its jars in less that a second, the next time you run it.

It shouldn't be necessary to clear out the local ivy cache and repo; in my experience republishing will reliably replace artifacts stored there if the project has -SNAPSHOT in the name. It's the boot directory that causes a problem.

eed3si9n commented 13 years ago

I would prefer an option that a cs user can run to refresh the app, though a dev helper plugin would be a nice addition.

As per --clean, it has make clean ring to it. --clear-cache may be a closer analogy, but neither would probably make sense to a user who is unaware of the sbt innards.

n8han commented 13 years ago

Well, the thing is... jar refreshing is really up to the sbt launcher. All conscript does is create the launch config, which it does update that any time you run cs against the repository. But if sbt launcher doesn't see new artifact versions, it won't update those in the boot directory. And since conscript uses one shared boot directory for all programs (as I think it should), all it can do is delete that one directory to force an update of the jars. Which should maybe be --clear-boot.

The best way to insulate users from all of this is to have the launchconfig depend on a released version rather than a snapshot. Then, when you change the launchconfig to refer to a new version it will always update.

eed3si9n commented 13 years ago

all it can do is delete that one directory to force an update of the jars.

I'll take what I can get. --clear-boot sounds good.

The best way to insulate users from all of this is to have the launchconfig depend on a released version rather than a snapshot.

Good point.

n8han commented 13 years ago

Between the conscript.Harness sbt project trait and --clean-boot command I think this is fixed.