[2.0] Preferred way to work with standard SBT projects and Play 2?

[Manuel Bernhardt]

Hi,

I'm working with a few non-play SBT libraries that I am developing
locally, and I am wondering how to accomodate Play's usage of an own
repository. I'm sure there are many good reasons for Play using its
own repository but in the meanwhile I'm getting a headache trying to
get things to work:

- issuing ./play publish-local doesn't seem to publish Play to the
default ~/.ivy2 repository. I worked around this in the past by
copying the produced play artifacts in
PLAY2_HOME/repository/local/play, but since recently, I now get a
"java.lang.NoClassDefFoundError:
com/typesafe/config/ConfigException$Missing"

- the other way around, things that are developed locally sortof seem
to be picked up by Play when adding the local ivy repository by hand
as a dependency, but this stops working when e.g. depending on a
library that is not in one of the default repositories (i.e. where a
resolver has been added in the build definition) - in that case, the
external dependency seems to get lost on the way.

So I'm wondering how to deal with this situation. Is there a way to
tell Play to use the default ivy repository instead of its own thing,
or would that massively screw things up?

Thanks,

Manuel

[Leon Radley]

I think the right way to get play to publish to the ~/.ivy2/ repo is to run ./build build-repository in the framework dir.

What this does is run

update

compile

publish-local

and it copies to the ~/.ivy2/

I hope I'm right :)

[Manuel Bernhardt]

Hi,

thanks Leon, but I think build-repository rebuilds Play's own
repository. Or at least it doesn't publish anything to ~/.ivy2

Now, I remember I managed to run SBT once directly from play/framework
- this seems to break every now and then tough. Right now it can't
resolve a transitive dependency, i.e.:

commons-codec#commons-codec;1.4: configuration not found in
commons-codec#commons-codec;1.4: 'compile'. It was required from
org.apache.httpcomponents#httpclient;4.1.2 compile

As a result only anorm gets published to ~/.ivy2

The interesting bit is that the above will be found with a totally
empty play sbt repository, so things must be configured properly over
there.

Maybe I'll take some time and clean ~/.ivy2 and go through a lot of
downloading - there most likely are some caching issues going on.

Can someone tell me again what was the motivation behind having an own
SBT repository for Play? I take it that downloading half of the
internet the first time you install the framework may not be the
sweetest thing on earth, but I think the additional complexity
introduced by this repository juggling is a too high price to pay for
downloading a few dependencies the first time Play is installed. I
mean, SBT (and dependency management in general) is already
complicated enough in its most default setup.

And yeah, for simple applications with only remote, well-know
dependencies, that custom repository will fare well. But Play 2 wasn't
built solely for building simple applications, I would like to think.

Sorry for the ranting, I know this isn't a simple thing to solve.

Manuel

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/HawBeGai0EgJ.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

[Morten Kjetland]

This is how I told sbt/play2 to look at my local ivy repo, then my custom github repo, then plays own repo.

import sbt._

import Keys._

import PlayProject._




object ApplicationBuild extends Build {




    val appName         = "computer-database-jpa"

    val appVersion      = "1.0"




    val appDependencies = Seq(

      "org.hibernate" % "hibernate-entitymanager" % "3.6.9.Final",

      "kjetland" %% "gt-engine-play" % "0.1.1"

    )




    val main = PlayProject(appName, appVersion, appDependencies, mainLang = JAVA).settings(

      ebeanEnabled := false,

      resolvers ++= Seq(

            Resolver.file("Local ivy Repository", file("/Users/mortenkjetland/.ivy2/local/"))(Resolver.ivyStylePatterns),

            "mbknor github Repository" at "http://mbknor.github.com/m2repo/releases/"

            )   

    )




}

https://github.com/mbknor/gt-engine-play2/blob/master/samples/computer-database-jpa/project/Build.scala 

-Morten

[Ben McCann]

I'll add my vote for having Play use ~/.ivy

The only nice thing that can come from Play 2 having it's own ivy repository is that you can build multiple versions and switch between them without having to "publish-local".  But this is something I've only done very rarely and is something I'd guess the vast majority of users would not do.

[Pascal Voitot Dev]

Hi
Your commons-codec problem is a known one from sbt+ivy2! There is a pb with this dependency! Just delete this specific dep dir from your .ivy2 dir and re-run "sbt update"

Sbt is becoming really great now and progressing! I really find its approach better than maven or ivy alone while providing real deps management compliant to maven or ivy repositories. It's good choice IMHO

Pascal

[Guillaume Bort]

Try to run play with -Dsbt.ivy.home=~/.ivy:

play -Dsbt.ivy.home=~/.ivy

I think it is a better default to have the play binary package use
it's own repository. It's easier for new users that don't care about
SBT. Advanced users could create an alias to the play script, or we
could use an environment variable to override this ivy repository.

--
Guillaume Bort

[Manuel Bernhardt]

Hi,

ok, I went for a "rm -rf ~/.ivy2" and now (well, after some serious
downloading) my cache problems are gone.

> play -Dsbt.ivy.home=~/.ivy

Ok, thanks, I'll work with that. I think that a page with some
introductory words on the way Play interacts with SBT in the "The
Build System" part of the wiki could help with this for advanced SBT
users.

> I think it is a better default to have the play binary package use
> it's own repository. It's easier for new users that don't care about
> SBT. Advanced users could create an alias to the play script, or we
> could use an environment variable to override this ivy repository.

An environment variable for this would be very welcome, then this can
be set-up simply with CI servers as well.

One more question while I am at it: is there a way to get access to
SBT configuration parameters from within a Play application? E.g. to
get to know what other projects are out there (modules, etc.)

Thanks,

Manuel

[Pascal Voitot Dev]

Once again, you don't have to delete all .ivy2 for commons-codec 1.4 problem. 

Just delete this directory precisely from .ivy2 and  you won't have to download all those deps again!

Pascal

[Manuel Bernhardt]

On Thu, Jan 26, 2012 at 11:20 AM, Pascal Voitot Dev
<pascal.v...@gmail.com> wrote:
> Once again, you don't have to delete all .ivy2 for commons-codec 1.4
> problem.
> Just delete this directory precisely from .ivy2 and  you won't have to
> download all those deps again!

Too late :) That is I don't use ivy only for Play projects so it's a
bit hard to tell where a cache corruption comes from.

[Pascal Voitot Dev]

On Thu, Jan 26, 2012 at 11:22 AM, Manuel Bernhardt <bernhard...@gmail.com> wrote:

On Thu, Jan 26, 2012 at 11:20 AM, Pascal Voitot Dev
<pascal.v...@gmail.com> wrote:
> Once again, you don't have to delete all .ivy2 for commons-codec 1.4
> problem.
> Just delete this directory precisely from .ivy2 and  you won't have to
> download all those deps again!

Too late :) That is I don't use ivy only for Play projects so it's a
bit hard to tell where a cache corruption comes from.

yes sure but I encounter this commons-codec pb quite often :D 

[foolshat]

In my plugins.sbt I use the following to reference my local ivy
repository. Works for us.

resolvers ++= Seq(    Resolver.defaultLocal)addSbtPlugin("play" % "sbt-
plugin" % "2.0-RC1-SNAPSHOT")
To publish to my local ivy I find this works:

cd framework
./build build-repository
sbt publish-local



On Jan 26, 10:27 am, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:
> On Thu, Jan 26, 2012 at 11:22 AM, Manuel Bernhardt <

> >https://github.com/mbknor/gt-engine-play2/blob/master/samples/compute...

> > >> >>>> On Thu, Jan 26, 2012 at 8:04 AM, Leon Radley <l...@radley.se>

> ...
>
> read more »

[foolshat]

Sorry, lines concatenated. Should be

resolvers ++= Seq(    Resolver.defaultLocal)
addSbtPlugin("play" % "sbt-plugin" % "2.0-RC1-SNAPSHOT")

> ...
>
> read more »

[Eric Butter]

foolshat (or anyone else!) --

I fixed this issue thanks to you all on this thread, but I am still _very_ confused /why/ this commons-cache#commons-cache (and in my case, also org.slf4j#slf4j-api) dependency issue pops up in sbt. 

Am I wrong that this has to do with bad metadata (declaring dependency errors) in the repo's from which sbt pulls these jars -- in which case, why have these files not been rejected until the maintainers fix the problem? 

Thanks, Cheers,

E

> > > >> >>>> > play-framework@googlegroups.com.

> > > >> >>>> > To unsubscribe from this group, send email to

> > > >> >>>> > play-framework+unsubscribe@googlegroups.com.

> > > >> >>>> > For more options, visit this group at
> > > >> >>>> >http://groups.google.com/group/play-framework?hl=en.
>
> > > >> >>>> --
> > > >> >>>> You received this message because you are subscribed to the Google
> > > >> >>>> Groups
> > > >> >>>> "play-framework" group.
> > > >> >>>> To post to this group, send email to

> > > play-framework@googlegroups.com.

> > > >> >>>> To unsubscribe from this group, send email to

> > > >> >>>> play-framework+unsubscribe@googlegroups.com.

> > > >> >>>> For more options, visit this group at
> > > >> >>>>http://groups.google.com/group/play-framework?hl=en.
>
> > > >> >>> --
> > > >> >>> You received this message because you are subscribed to the Google
> > > >> >>> Groups
> > > >> >>> "play-framework" group.
> > > >> >>> To post to this group, send email to

> > > play-framework@googlegroups.com.

> > > >> >>> To unsubscribe from this group, send email to

> > > >> >>> play-framework+unsubscribe@googlegroups.com.

> > > >> >>> For more options, visit this group at
> > > >> >>>http://groups.google.com/group/play-framework?hl=en.
>
> > > >> >> --
> > > >> >> You received this message because you are subscribed to the Google
> > > >> >> Groups
> > > >> >> "play-framework" group.

> > > >> >> To post to this group, send email to play-framework@googlegroups.com

> > > .
> > > >> >> To unsubscribe from this group, send email to

> > > >> >> play-framework+unsubscribe@googlegroups.com.

> > > >> >> For more options, visit this group at
> > > >> >>http://groups.google.com/group/play-framework?hl=en.
>
> > > >> > --
> > > >> > Guillaume Bort
>
> > > >> > --
> > > >> > You received this message because you are subscribed to the Google
> > > >> > Groups "play-framework" group.

> > > >> > To post to this group, send email to play-framework@googlegroups.com.