Introducing Lift Modules

[Peter Robinett]

After some good discussion, both at Scala LiftOff London and here on the mailing list (see Creating a module system for Lift and Locating Templates in Modules), we've got everything we need to create nice reusable modules. Please check out the wiki page for more information. I have created a Hello World module and a Lift app that uses it. Of course, the conventions aren't set in stone (they're just that, conventions), so please suggest rooms for improvement.

I look forward to the modules you create and perhaps we can soon start thinking about a community site to host them!

Peter

[Heiko Seeberger]

Hi,

Very good initiative!

Do we really have to use the ugly underscore in the package name lift_module?

Heiko

On Saturday, 8 January 2011, Peter Robinett <pe...@bubblefoundry.com> wrote:
> After some good discussion, both at Scala LiftOff London and here on the mailing list (see Creating a module system for Lift <https://groups.google.com/d/topic/liftweb/GfVqg7hHmYA/discussion> and Locating Templates in Modules <https://groups.google.com/d/topic/liftweb/gIjjKvg4bsI/discussion>), we've got everything we need to create nice reusable modules. Please check out the wiki page <http://www.assembla.com/wiki/show/liftweb/Modules> for more information. I have created a Hello World module <https://github.com/pr1001/HelloWorld> and a Lift app that uses it <https://github.com/pr1001/HelloWorldExampleApp>. Of course, the conventions aren't set in stone (they're just that, conventions), so please suggest rooms for improvement.

> I look forward to the modules you create and perhaps we can soon start thinking about a community site to host them!
> Peter
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>

--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through
Actors: akka.io

[TylerWeir]

Congrats Pete.  I look forward to checking this out.

[Peter Robinett]

Yes, it is rather ugly, isn't it? First, you can name your package anything you want, the convention only cares about the last part. There isn't any sort of module validator or creator (though I think  that would be a great addition to something like Lifty or Giter8), so it really is just for humans to check, not computers. I seem to remember having problems with a domain name with a dash in Maven so I used an underscore instead, which I believe is the suggested approach. David already has lift-tools.org and lift-modules.org (Oops, .org, not .net! I guess I should change my example!), so that is why I chose the package name I did for my Hello World example.

Peter

[David Pollak]

Peter,

Very nifty stuff!

I look forward to seeing how Lift Modules grows and helps the Lift community!

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Marius Danciu]

I have the same question. Don't really like _ in package names.

[Indrajit Raychaudhuri]

Great start, Peter :)

Peter Robinett wrote:
> Yes, it is rather ugly, isn't it? First, you can name your package
> anything you want, the convention only cares about the last part.

How important is it to have the convention of last part of the package
same as the module name?

> There isn't any sort of module validator or creator (though I think that would
> be a great addition to something like Lifty or Giter8), so it really is
> just for humans to check, not computers.

Lifty could be a nice candidate I hope. Once we have an existing project
(i.e., project/build.properties exists) giter8's role is pretty much
over. Further, just for safety/convenience do you consider some trait,
say LiftModule, could be useful?

> I seem to remember having
> problems with a domain name with a dash in Maven so I used an underscore
> instead, which I believe is the suggested approach.

I think it's more of Java problem than Maven (java package name cannot
have a dash).

David already has
> lift-tools.org and lift-modules.org (Oops, .org, not .net! I guess I
> should change my example!), so that is why I chose the package name I
> did for my Hello World example.
>
> Peter
>
> On Saturday, January 8, 2011 4:16:19 PM UTC+1, Heiko Seeberger wrote:
>
> Hi,
>
> Very good initiative!
>
> Do we really have to use the ugly underscore in the package name
> lift_module?
>
> Heiko
>

[Peter Robinett]

Thanks, Indrajit. To answer your questions:

On Saturday, January 8, 2011 7:00:44 PM UTC+1, Indrajit Raychaudhuri wrote:

How important is it to have the convention of last part of the package
same as the module name?

It's not. However, if you know the package name then you know the name of the object to import and call in Boot, which I think is useful. 

Lifty could be a nice candidate I hope. Once we have an existing project 

(i.e., project/build.properties exists) giter8's role is pretty much
over. Further, just for safety/convenience do you consider some trait,
say LiftModule, could be useful?

Sounds reasonable. A trait could be used but my goal was to put forward the module system with a minimum of changes to Lift. I believe that Lift modules, including their convention, should be managed by the community at large, as the general goal is the lower the barrier to entry. At the same time, I believe structural types could be used to verify a Lift module object is 'valid' (ie has an init method), yes?

I think it's more of Java problem than Maven (java package name cannot
have a dash).

Ahh, ok. So are we stuck with the underscore then?

Cheers,

Peter

[Indrajit Raychaudhuri]

On Saturday 8 January 2011 at 11:49 PM, Peter Robinett wrote:

Thanks, Indrajit. To answer your questions:

On Saturday, January 8, 2011 7:00:44 PM UTC+1, Indrajit Raychaudhuri wrote:

How important is it to have the convention of last part of the package
same as the module name?

It's not. However, if you know the package name then you know the name of the object to import and call in Boot, which I think is useful. 

My brain is working slower I think :(

The way I understand is you still need to know the package name (the whole of it) to do an import as thus:

import net.lift_modules.HelloWorld.HelloWorld

so that you can call:

HelloWorld.init

How would have it been different if it was:

import net.lift_modules.Universe.HelloWorld

Lifty could be a nice candidate I hope. Once we have an existing project 

(i.e., project/build.properties exists) giter8's role is pretty much
over. Further, just for safety/convenience do you consider some trait,
say LiftModule, could be useful?

Sounds reasonable. A trait could be used but my goal was to put forward the module system with a minimum of changes to Lift. I believe that Lift modules, including their convention, should be managed by the community at large, as the general goal is the lower the barrier to entry. At the same time, I believe structural types could be used to verify a Lift module object is 'valid' (ie has an init method), yes?

Totally! Would be interesting to see how community convention evolves. Related to this, maybe we could consider aligning Lift's distributed modules along the same convention (in case any divergence shows up, that is). 

I think it's more of Java problem than Maven (java package name cannot
have a dash).

Ahh, ok. So are we stuck with the underscore then?

I think, but like you said, package names could be arbitrary so long as the compiler doesn't complain ;) 

Cheers,

Peter

[Peter Robinett]

On Saturday, January 8, 2011 8:19:24 PM UTC+1, Indrajit Raychaudhuri wrote:

My brain is working slower I think :(

The way I understand is you still need to know the package name (the whole of it) to do an import as thus:

import net.lift_modules.HelloWorld.HelloWorld

so that you can call:

HelloWorld.init

How would have it been different if it was:

import net.lift_modules.Universe.HelloWorld

Because you only need to know the module's package is net.lift_modules.HelloWorld and you can guess that the object is HelloWorld. If you looked for Universe in net.lift_modules.Universe you'd be disappointed and so the module writer would need to alert module users that, hey, actually the module object is called HelloWorld. My goal, basically, is to reduce the amount of per-module documentation required. This also, I believe, makes future tools easier to write.

This is really a very minor thing, so don't worry if the benefits aren't immediately apparent! And frankly, maybe they just aren't that great.

 

Totally! Would be interesting to see how community convention evolves. Related to this, maybe we could consider aligning Lift's distributed modules along the same convention (in case any divergence shows up, that is). 

I think that eventually, as people are willing to maintain them, it makes sense to move the existing modules out of Lift proper. Or, if not move out, at least supersede. For instance, I've been thinking about rewriting the Flot module from scratch as a stand-alone Lift Module. 

Peter

[Indrajit Raychaudhuri]

On Sunday 9 January 2011 at 12:55 AM, Peter Robinett wrote:

On Saturday, January 8, 2011 8:19:24 PM UTC+1, Indrajit Raychaudhuri wrote:

My brain is working slower I think :(

The way I understand is you still need to know the package name (the whole of it) to do an import as thus:

import net.lift_modules.HelloWorld.HelloWorld

so that you can call:

HelloWorld.init

How would have it been different if it was:

import net.lift_modules.Universe.HelloWorld

Because you only need to know the module's package is net.lift_modules.HelloWorld and you can guess that the object is HelloWorld. If you looked for Universe in net.lift_modules.Universe you'd be disappointed and so the module writer would need to alert module users that, hey, actually the module object is called HelloWorld. My goal, basically, is to reduce the amount of per-module documentation required. This also, I believe, makes future tools easier to write.

Hmm, that means I am not supposed to have all related features show up as individual modules under same package hierarchy. So the following aren't legal by convention:

net.lift_modules.Universe.Feature1.init

net.lift_modules.Universe.Feature2.init

net.lift_modules.Universe.Feature3.init

This is really a very minor thing, so don't worry if the benefits aren't immediately apparent! And frankly, maybe they just aren't that great.

Agreed, let's not bother much though. 

 

Totally! Would be interesting to see how community convention evolves. Related to this, maybe we could consider aligning Lift's distributed modules along the same convention (in case any divergence shows up, that is). 

I think that eventually, as people are willing to maintain them, it makes sense to move the existing modules out of Lift proper. Or, if not move out, at least supersede. For instance, I've been thinking about rewriting the Flot module from scratch as a stand-alone Lift Module. 

Fantastic! My thoughts behind segregating modules into separate repo (in the other thread) was quite along the lines. Separate repo would mean less impediment to separate governance for modules moving in or out (after IP legalities being taken care of). FWIW, Drupal follows a similar approach I think (core modules vs contrib modules).

[Peter Robinett]

On Saturday, January 8, 2011 9:16:25 PM UTC+1, Indrajit Raychaudhuri wrote:

Hmm, that means I am not supposed to have all related features show up as individual modules under same package hierarchy. So the following aren't legal by convention:

net.lift_modules.Universe.Feature1.init

net.lift_modules.Universe.Feature2.init

net.lift_modules.Universe.Feature3.init

I'm afraid I hadn't thought of submodules/features at all. I guess you could have something like:

net.lift_modules.Universe.Universe.init(Feature1 :: Feature2 :: Nil) // initialize some or all features

Or, individually:

net.lift_modules.Universe.Universe.init

net.lift_modules.Universe.Feature1.init

net.lift_modules.Universe.Feature2.init

net.lift_modules.Universe.Feature3.init

Or even, if it's some sort of massive module and you want subpackages:

net.lift_modules.Universe.Universe.init

net.lift_modules.Universe.Feature1.Feature1.init

net.lift_modules.Universe.Feature2.Feature2.init

net.lift_modules.Universe.Feature3.Feature3.init

Though, at that point you might want to just consider making each feature a stand-alone module in itself. There's nothing saying that modules can't depend upon other modules and in fact I hope they do. For instance, I can think of a generic login module which would use one or more of OpenId, Facebook, Twitter, LDAP and other modules to authenticate a user.

Fantastic! My thoughts behind segregating modules into separate repo (in the other thread) was quite along the lines. Separate repo would mean less impediment to separate governance for modules moving in or out (after IP legalities being taken care of). FWIW, Drupal follows a similar approach I think (core modules vs contrib modules).

 

Yes, I think that makes a lot of sense. And, what's nice is that we can do that without affecting the examples at demo.liftweb.net and the testing that David and others use them for. (Though it would be nice to have the various sample apps for the existing lift-modules public somewhere.)

Peter

[Indrajit Raychaudhuri]

-- 
Indrajit Raychaudhuri
Sent with Sparrow

On Sunday 9 January 2011 at 3:20 AM, Peter Robinett wrote:

On Saturday, January 8, 2011 9:16:25 PM UTC+1, Indrajit Raychaudhuri wrote:

Hmm, that means I am not supposed to have all related features show up as individual modules under same package hierarchy. So the following aren't legal by convention:

net.lift_modules.Universe.Feature1.init

net.lift_modules.Universe.Feature2.init

net.lift_modules.Universe.Feature3.init

I'm afraid I hadn't thought of submodules/features at all. I guess you could have something like:

net.lift_modules.Universe.Universe.init(Feature1 :: Feature2 :: Nil) // initialize some or all features

This looks neat! 

Or, individually:

net.lift_modules.Universe.Universe.init

net.lift_modules.Universe.Feature1.init

net.lift_modules.Universe.Feature2.init

net.lift_modules.Universe.Feature3.init

Or even, if it's some sort of massive module and you want subpackages:

net.lift_modules.Universe.Universe.init

net.lift_modules.Universe.Feature1.Feature1.init

net.lift_modules.Universe.Feature2.Feature2.init

net.lift_modules.Universe.Feature3.Feature3.init

Though, at that point you might want to just consider making each feature a stand-alone module in itself. There's nothing saying that modules can't depend upon other modules and in fact I hope they do. For instance, I can think of a generic login module which would use one or more of OpenId, Facebook, Twitter, LDAP and other modules to authenticate a user.

Indeed, and stitching  dependencies together can be well handled via (transitive) dependency resolution at build time by maven/sbt/gradle etc. The inits can be chained/nested however. So this is covered imho :)

Fantastic! My thoughts behind segregating modules into separate repo (in the other thread) was quite along the lines. Separate repo would mean less impediment to separate governance for modules moving in or out (after IP legalities being taken care of). FWIW, Drupal follows a similar approach I think (core modules vs contrib modules).

 

Yes, I think that makes a lot of sense. And, what's nice is that we can do that without affecting the examples at demo.liftweb.net and the testing that David and others use them for. (Though it would be nice to have the various sample apps for the existing lift-modules public somewhere.)

+1 

[David Pollak]

On Sat, Jan 8, 2011 at 7:46 AM, Peter Robinett <pe...@bubblefoundry.com> wrote:

Yes, it is rather ugly, isn't it? First, you can name your package anything you want, the convention only cares about the last part. There isn't any sort of module validator or creator (though I think  that would be a great addition to something like Lifty or Giter8), so it really is just for humans to check, not computers. I seem to remember having problems with a domain name with a dash in Maven so I used an underscore instead, which I believe is the suggested approach. David already has lift-tools.org and lift-modules.org (Oops, .org, not .net! I guess I should change my example!), so that is why I chose the package name I did for my Hello World example.

Okay... I got lift-modules.net.  Please feel encouraged to use the domains in any way you want in furtherance of the lift-modules project.
 

Peter

On Saturday, January 8, 2011 4:16:19 PM UTC+1, Heiko Seeberger wrote:

Hi,

Very good initiative!

Do we really have to use the ugly underscore in the package name lift_module?

Heiko

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

[ghostM]

Awesome! Good work Peter.
Time to get working on taking the omniauth functionality I started
last fall and turning it into an actual module.

-Matt

[Peter Robinett]

Thanks, Matt, I look forward to it.

Peter

[Naftoli Gugenheim]

A few thoughts:

1) Since we're for the most part post-2.7, why not define the convention that the init method should be a member of the package object? No need for a singleton with the same name as the package. Just call net.liftmodules.helloworld.init.

2) Why not recommend that the package name be the name of the module *except in lowercase*, as is the standard in Java and Scala?

3) Minor point -- the wiki page says the init method should return nothing. Perhaps it would be better to say "Unit" explicitly. Even though it's obvious, there is another type called Nothing.

4) Is it possible that it should matter at what point in Boot init is called?

Also, re the "lift_modules" name: Why not host the modules at a subdomain of the main lift domain, e.g., modules.liftweb.net?

Peter

--

[David Pollak]

On Sat, Jan 8, 2011 at 4:12 AM, Peter Robinett <pe...@bubblefoundry.com> wrote:

After some good discussion, both at Scala LiftOff London and here on the mailing list (see Creating a module system for Lift and Locating Templates in Modules), we've got everything we need to create nice reusable modules. Please check out the wiki page for more information. I have created a Hello World module and a Lift app that uses it. Of course, the conventions aren't set in stone (they're just that, conventions), so please suggest rooms for improvement.

I look forward to the modules you create and perhaps we can soon start thinking about a community site to host them!

Peter,

For package naming, please use liftmodules (not lift_modules or lift-modules).  I've just registered liftmodules.net and liftmodules.org for this purpose.

The reason for this change will be obvious in about a week.

Thanks,

David

 

Peter

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Peter Robinett]

On Monday, January 10, 2011 3:49:56 PM UTC+1, ngug wrote:

A few thoughts:

1) Since we're for the most part post-2.7, why not define the convention that the init method should be a member of the package object? No need for a singleton with the same name as the package. Just call net.liftmodules.helloworld.init.

I hadn't thought about package objects (I didn't know anything about them), but after reading a little bit on them right now they sound like the right tool for the job. What do others think? 

2) Why not recommend that the package name be the name of the module *except in lowercase*, as is the standard in Java and Scala?

Another good suggestion. Any objections?

 

3) Minor point -- the wiki page says the init method should return nothing. Perhaps it would be better to say "Unit" explicitly. Even though it's obvious, there is another type called Nothing.

You're right. Fixed.

 

4) Is it possible that it should matter at what point in Boot init is called?

Also, re the "lift_modules" name: Why not host the modules at a subdomain of the main lift domain, e.g., modules.liftweb.net?

My goal is to have a community site like how the Ruby on Rails community has http://www.railsplugins.org/ and http://agilewebdevelopment.com/plugins/ (among others). This both frees us of Lift's (good!) committer rules and provides a little bit of separation for the main Lift project if something less than ideal happens in the wild west of the module world.

Peter

[Peter Robinett]

Great, done. I updated the two GitHub files and the module jar on my server.

Peter

[Indrajit Raychaudhuri]

On Tuesday 11 January 2011 at 7:15 PM, Peter Robinett wrote:

On Monday, January 10, 2011 3:49:56 PM UTC+1, ngug wrote:

A few thoughts:

1) Since we're for the most part post-2.7, why not define the convention that the init method should be a member of the package object? No need for a singleton with the same name as the package. Just call net.liftmodules.helloworld.init.

I hadn't thought about package objects (I didn't know anything about them), but after reading a little bit on them right now they sound like the right tool for the job. What do others think? 

Good idea.

2) Why not recommend that the package name be the name of the module *except in lowercase*, as is the standard in Java and Scala?

Another good suggestion. Any objections?

Except multi-word module names start looking out of the place after a while. And then people start having widgetlib, widgetlibhtml5, widgetlibhtml5foriphone etc. I am not opposed to this, just that a set of guidelines would help ;)

- Indrajit

 

3) Minor point -- the wiki page says the init method should return nothing. Perhaps it would be better to say "Unit" explicitly. Even though it's obvious, there is another type called Nothing.

You're right. Fixed.

 

4) Is it possible that it should matter at what point in Boot init is called?

Also, re the "lift_modules" name: Why not host the modules at a subdomain of the main lift domain, e.g., modules.liftweb.net?

My goal is to have a community site like how the Ruby on Rails community has http://www.railsplugins.org/ and http://agilewebdevelopment.com/plugins/ (among others). This both frees us of Lift's (good!) committer rules and provides a little bit of separation for the main Lift project if something less than ideal happens in the wild west of the module world.

Peter

--

[Derek Chen-Becker]

IIRC, hyphens aren't allowed in package names because package names follow the rules for Java identifiers (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8). Interestingly, the DNS spec (http://www.freesoft.org/CIE/RFC/1035/6.htm) disallows underscores and allows hyphens. As a network engineer (and DNS pedant) this little quirk provides no end of frustration/bemusement depending on how my day is going ;)

Derek

--

[Indrajit Raychaudhuri]

On Tuesday 11 January 2011 at 11:13 PM, Derek Chen-Becker wrote:

IIRC, hyphens aren't allowed in package names because package names follow the rules for Java identifiers (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8). Interestingly, the DNS spec (http://www.freesoft.org/CIE/RFC/1035/6.htm) disallows underscores and allows hyphens. As a network engineer (and DNS pedant) this little quirk provides no end of frustration/bemusement depending on how my day is going ;)

Oh yeah, reminds me of my circus as network newbie when I delightfully set up BIND config with underscore in DNS names only to encounter most un-delightful outcome ;)

- Indrajit

[Christopher Taylor]

On 11.01.2011, at 17:46, Indrajit Raychaudhuri wrote:

>> 2) Why not recommend that the package name be the name of the module *except in lowercase*, as is the standard in Java and Scala?
>>
>> Another good suggestion. Any objections?
> Except multi-word module names start looking out of the place after a while. And then people start having widgetlib, widgetlibhtml5, widgetlibhtml5foriphone etc. I am not opposed to this, just that a set of guidelines would help ;)

I haven't been following the discussion closely, but couldn't there be widgetlib, widgetlib.html5 and widgetlib.html5.iphone?

Regards,
--Chris

[Peter Petersson]

Hi Lift devs/users if you want a good source (for inspiration/ideas ) of modular design and how it can be accomplished successfully in a big project take a look at the open source proj.

Apache Geronimo http://geronimo.apache.org/

They have (among other things) developed user friendly module packaging tools (command line and gui). Behind the scene maven and osgi are used. In fact everything in the project is build as modules resulting in a highly modular Java EE application server.

best regards
  Peter Petersson

[Richard Dallaway]

On Sat, Jan 8, 2011 at 12:12 PM, Peter Robinett <pe...@bubblefoundry.com> wrote:

After some good discussion, both at Scala LiftOff London and here on the mailing list (see Creating a module system for Lift and Locating Templates in Modules), we've got everything we need to create nice reusable modules.

Thank you Peter.  Here's a stab at My First Module.

https://github.com/d6y/liftmodules-googleanalytics

It adds the Google Analytics tracking code JavaScript to the head of pages.   Three things:

1.  I'm not sure if LiftSession.onBeginServicing is the right place to attach S.putInHead, but it seems to work.  Publishing this source will probably get me the answer pretty quickly :-)

2. I need to publish to a repository, which will mean figuring out how to create an S3 backed repo.

3. I need to check this code actually does result in hits appearing over at Google :-/

Cheers

Richard

[Peter Robinett]

Thanks, Richard, and congratulations on writing the first Lift Module!

As Richard mentioned, it'd be great to have a repository to publish modules to. Once I have some more time I'll try to sit down a see what I can do about a common Lift Modules repository and web site. Even better, of course, is if someone else wants to pitch in and take up that task! ;-)

Peter

[S?ren Bramer Schmidt]

Github supports webhooks which would allow the modules site to automatically download and compile the source whenever a change is pushed. I think that would be pretty neat.

rubygems uses a terminal comand to perform the publish. Which approach would be best?

[Peter Petersson]

Maven:ized modules would also be great as maven is already used by many enterprise IT departments.
A lift maven repository for modules maybe ?
best regards
   Peter Petersson

On 2011-01-14 00:45, =?ANSI_X3.4-1968?Q?S=3Fren_Bramer_Schmidt?= wrote:

Github supports webhooks which would allow the modules site to automatically download and compile the source whenever a change is pushed. I think that would be pretty neat.

rubygems uses a terminal comand to perform the publish. Which approach would be best?

[Jeppe Nejsum Madsen]

On Fri, Jan 14, 2011 at 11:11 AM, Peter Petersson
<peterss...@gmail.com> wrote:
> Maven:ized modules would also be great as maven is already used by many
> enterprise IT departments.
> A lift maven repository for modules maybe ?

Agreed. I think a Maven repo is a must for Lift modules (I'll even
say any lib on the JVM), not just for enterprise IT departments. All
the build tools in use for Scala are able to read a maven a repo (at
least SBT, Maven & Gradle are :-)

/Jeppe

[Richard Dallaway]

On Thu, Jan 13, 2011 at 10:34 PM, Peter Robinett <pe...@bubblefoundry.com> wrote:

As Richard mentioned, it'd be great to have a repository to publish modules to.

I was going to publish what I have to a free maven repo somewhere (sonatype, github...), but on reflection I think that's a bad idea.  it would be good to co-ordinate on this, otherwise it's going to be ugly and dull for users to have to specify a different repository for each module they want to use.

Richard

[David Pollak]

Part of the Lift modules program is the offer of hosting on a Lift-modules.org maven repo (housed on the same machines that house scala-tools.org).  It should be the central clearing house for all Lift modules.

 

Richard

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[David Bernard]

May be a dedicated repo under http://nexus.scala-tools.org

Personnaly, I now used sonatype repo (with replication on central, constraint : every dependencies should be on central repo).

my 2c

/davidB