[Lift] Re: The future of lift-core

[Peter Robinett]

Indrajit, your post made me realize that I've been using lift-core
without realizing it. Thanks.

Unfortunately switching to something simpler is giving me some
trouble. I believe that I should be able to add lift-base, but while
its sub-modules get downloaded (lift-common, lift-util, etc), Maven
says that the lift-base module is missing and needs to be installed.
This is the entry I'm using:

  net.liftweb
  lift-base
  1.1-SNAPSHOT


As the resident Maven expert, do you have any idea what's wrong? My
entire pom.xml is here: http://gist.github.com/262244

Thanks,
Peter

On Dec 22, 8:32 am, Indrajit Raychaudhuri  wrote:
> On 22/12/09 12:23 AM, David Pollak wrote:
>
>
>
>
>
>
>
> > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
> > mailto:indraj...@gmail.com>> wrote:
>
> >     Folks,
>
> >     lift-core is a 'meta' project that can be added as a dependency to a
> >     Lift project to pull in all the Lift modules. This serves as a singular
> >     configuration point in a Lift based application.
>
> >     However, since lift-core downloads all the Lift modules (irrespective of
> >     whether the project needs it), adding this as the dependency slow  down
> >     things for a standard project that doesn't need some additional modules.
>
> >     In a sense, we have moved quite a bit from the initial purpose of having
> >     single dependency on this 'meta' project in a Lift application.
>
> >     Further, the name is a misnomer now!
>
> >     The question, therefore is:
> >     Should we consider deprecating this? If not, we need to document when it
> >     should be preferred and when not. If yes, what should be the time frame
> >     for making the move?
>
> >     With Lift 2.0 coming up,
>
> > Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1 based on
> > the naming rules that Heiko proposed and the Lift community adopted.
> > The fact that the next release of Lift is going to be called 2.0 rather
> > than 1.1 does not change the scope of the release.
>
> Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I meant.
> But yes, it ends up sounding different, sorry.
>
>
>
> > With that being said, deprecating lift-core is fine by me as long as
> > there is an easy to understand deprecation message with clear
> > instructions as to how to replace lift-core with whatever is necessary.
>
> For deprecating dependencies, it's just matter of persuasion
> (Announcement, wiki etc.) for at least two releases, or more (could be
> milestone releases). And eventually, dropping it from the build beyond
> an agreeable release time frame.
>
> I couldn't figure out a clean way of deprecating 'meta' packages since
> it doesn't have any active code (thus doesn't expose any place to code
> in some deprecation warning message).
>
> As such, the package is harmless and there is zero cost of maintenance.
> Just that, it's no more a good practice (longer build time, larger war
> size etc.).
>
>
>
>
>
> >     now might be a good time to make a decision.
> >     Thoughts?
>
> >     Cheers, Indrajit
>
> >     NB: An open question to anybody in the Lift: Who among you are actually
> >     using lift-core in you project and what is the level of impact you
> >     foresee in case you have to move on to have an alternative approach.
>
> >     --
>
> >     You received this message because you are subscribed to the Google
> >     Groups "Lift" group.
> >     To post to this group, send email to liftweb@googlegroups.com
> >     .
> >     To unsubscribe from this group, send email to
> >     liftweb+unsubscr...@googlegroups.com
> >     .
> >     For more options, visit this group at
> >    http://groups.google.com/group/liftweb?hl=en.
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
>
> > --
>
> > You received this message because you are subscribed to the Google
> > Groups "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.

--

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

[Lift] Re: The future of lift-core

[Peter Robinett]

Thanks guys, that helps a lot.

Peter

On Dec 23, 9:05 am, Indrajit Raychaudhuri  wrote:
> Hey Peter,
>
> lift-base is just a parent model for lift-common, lift-actor, lift-util
> and lift-webkit. It's not a real dependency that can be used in a
> project. Since you are using lift-mapper, just using lift-mapper as
> dependency should suffice. Rest of the dependencies would be pulled down
> automatically.
>
> I just updated your gist. See if this works.http://gist.github.com/262613
>
> As davidB mentioned you can also run "mvn dependency:analyze" to filter
> out unnecessary dependencies.
>
> Generally speaking:
>
> 1. If you are using any of the persistence modules (lift-mapper,
> lift-jpa, lift-record) you do not need any of the base modules. They
> would be pulled transitively.
>
> 2. If you are not using the persistence module (possibly because your
> app doesn't need such support). Just including lift-webkit should suffice.
>
> 3. Additionally, if you are using any of the special purpose modules
> (from lift-modules), just add that to the lift of dependencies.
>
> Cheers, Indrajit
>
> On 23/12/09 7:12 PM, David Bernard wrote:
>
>
>
> > Tips :
>
> > in your project call :
> > mvn dependency:analyze
>
> > you should see the list of dependencies useless and used throught
> > transitive path and to list directly in your pom.xml (may be in place of
> > lift-core).
>
> > /davidB
>
> > On Wed, Dec 23, 2009 at 02:31, Peter Robinett  > > wrote:
>
> >     Indrajit, your post made me realize that I've been using lift-core
> >     without realizing it. Thanks.
>
> >     Unfortunately switching to something simpler is giving me some
> >     trouble. I believe that I should be able to add lift-base, but while
> >     its sub-modules get downloaded (lift-common, lift-util, etc), Maven
> >     says that the lift-base module is missing and needs to be installed.
> >     This is the entry I'm using:
> >     
> >     net.liftweb
> >     lift-base
> >     1.1-SNAPSHOT
> >     
>
> >     As the resident Maven expert, do you have any idea what's wrong? My
> >     entire pom.xml is here:http://gist.github.com/262244
>
> >     Thanks,
> >     Peter
>
> >     On Dec 22, 8:32 am, Indrajit Raychaudhuri  >     > wrote:
> >      > On 22/12/09 12:23 AM, David Pollak wrote:
>
> >      > > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
> >      > > mailto:indraj...@gmail.com>
> >     >> wrote:
>
> >      > >     Folks,
>
> >      > >     lift-core is a 'meta' project that can be added as a
> >     dependency to a
> >      > >     Lift project to pull in all the Lift modules. This serves
> >     as a singular
> >      > >     configuration point in a Lift based application.
>
> >      > >     However, since lift-core downloads all the Lift modules
> >     (irrespective of
> >      > >     whether the project needs it), adding this as the
> >     dependency slow  down
> >      > >     things for a standard project that doesn't need some
> >     additional modules.
>
> >      > >     In a sense, we have moved quite a bit from the initial
> >     purpose of having
> >      > >     single dependency on this 'meta' project in a Lift application.
>
> >      > >     Further, the name is a misnomer now!
>
> >      > >     The question, therefore is:
> >      > >     Should we consider deprecating this? If not, we need to
> >     document when it
> >      > >     should be preferred and when not. If yes, what should be
> >     the time frame
> >      > >     for making the move?
>
> >      > >     With Lift 2.0 coming up,
>
> >      > > Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1
> >     based on
> >      > > the naming rules that Heiko proposed and the Lift community
> >     adopted.
> >      > > The fact that the next release of Lift is going to be called
> >     2.0 rather
> >      > > than 1.1 does not change the scope of the release.
>
> >      > Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I
> >     meant.
> >      > But yes, it ends up sounding different, sorry.
>
> >      > > With that being said, deprecating lift-core is fine by me as
> >     long as
> >      > > there is an easy to understand deprecation message with clear
> >      > > instructions as to how to replace lift-core with whatever is
> >     necessary.
>
> >      > For deprecating dependencies, it's just matter of persuasion
> >      > (Announcement, wiki etc.) for at least two releases, or more
> >     (could be
> >      > milestone releases). And eventually, dropping it from the build
> >     beyond
> >      > an agreeable release time frame.
>
> >      > I couldn't figure out a clean way of deprecating 'meta' packages
> >     since
> >      > it doesn't have any active code (thus doesn't expose any place to
> >     code
> >      > in some deprecation warning message).
>
> >      > As such, the package is harmles

Re: [Lift] Re: The future of lift-core

[David Bernard]

Tips :

in your project call :
mvn dependency:analyze

you should see the list of dependencies useless and used throught transitive
path and to list directly in your pom.xml (may be in place of lift-core).

/davidB

On Wed, Dec 23, 2009 at 02:31, Peter Robinett wrote:

> Indrajit, your post made me realize that I've been using lift-core
> without realizing it. Thanks.
>
> Unfortunately switching to something simpler is giving me some
> trouble. I believe that I should be able to add lift-base, but while
> its sub-modules get downloaded (lift-common, lift-util, etc), Maven
> says that the lift-base module is missing and needs to be installed.
> This is the entry I'm using:
> 
>  net.liftweb
>  lift-base
>  1.1-SNAPSHOT
> 
>
> As the resident Maven expert, do you have any idea what's wrong? My
> entire pom.xml is here: http://gist.github.com/262244
>
> Thanks,
> Peter
>
> On Dec 22, 8:32 am, Indrajit Raychaudhuri  wrote:
> > On 22/12/09 12:23 AM, David Pollak wrote:
> >
> >
> >
> >
> >
> >
> >
> > > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
> > > mailto:indraj...@gmail.com>> wrote:
> >
> > > Folks,
> >
> > > lift-core is a 'meta' project that can be added as a dependency to
> a
> > > Lift project to pull in all the Lift modules. This serves as a
> singular
> > > configuration point in a Lift based application.
> >
> > > However, since lift-core downloads all the Lift modules
> (irrespective of
> > > whether the project needs it), adding this as the dependency slow
>  down
> > > things for a standard project that doesn't need some additional
> modules.
> >
> > > In a sense, we have moved quite a bit from the initial purpose of
> having
> > > single dependency on this 'meta' project in a Lift application.
> >
> > > Further, the name is a misnomer now!
> >
> > > The question, therefore is:
> > > Should we consider deprecating this? If not, we need to document
> when it
> > > should be preferred and when not. If yes, what should be the time
> frame
> > > for making the move?
> >
> > > With Lift 2.0 coming up,
> >
> > > Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1 based on
> > > the naming rules that Heiko proposed and the Lift community adopted.
> > > The fact that the next release of Lift is going to be called 2.0 rather
> > > than 1.1 does not change the scope of the release.
> >
> > Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I meant.
> > But yes, it ends up sounding different, sorry.
> >
> >
> >
> > > With that being said, deprecating lift-core is fine by me as long as
> > > there is an easy to understand deprecation message with clear
> > > instructions as to how to replace lift-core with whatever is necessary.
> >
> > For deprecating dependencies, it's just matter of persuasion
> > (Announcement, wiki etc.) for at least two releases, or more (could be
> > milestone releases). And eventually, dropping it from the build beyond
> > an agreeable release time frame.
> >
> > I couldn't figure out a clean way of deprecating 'meta' packages since
> > it doesn't have any active code (thus doesn't expose any place to code
> > in some deprecation warning message).
> >
> > As such, the package is harmless and there is zero cost of maintenance.
> > Just that, it's no more a good practice (longer build time, larger war
> > size etc.).
> >
> >
> >
> >
> >
> > > now might be a good time to make a decision.
> > > Thoughts?
> >
> > > Cheers, Indrajit
> >
> > > NB: An open question to anybody in the Lift: Who among you are
> actually
> > > using lift-core in you project and what is the level of impact you
> > > foresee in case you have to move on to have an alternative
> approach.
> >
> > > --
> >
> > > You received this message because you are subscribed to the Google
> > > Groups "Lift" group.
> > > To post to this group, send email to liftweb@googlegroups.com
> > > .
> > > To unsubscribe from this group, send email to
> > > 
> > > liftweb+unsubscr...@googlegroups.com
> > > 
> > >  >.
> > > For more options, visit this group at
> > >http://groups.google.com/group/liftweb?hl=en.
> >
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
> >
> > > --
> >
> > > You received this message because you are subscribed to the Google
> > > Groups "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > liftweb+unsubscr...@googlegroups.com
> .
> > > For more options, visit this group at
> > >http://groups.google.com/group/liftweb?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this gr

Re: [Lift] Re: The future of lift-core

[Indrajit Raychaudhuri]

Hey Peter,

lift-base is just a parent model for lift-common, lift-actor, lift-util 
and lift-webkit. It's not a real dependency that can be used in a 
project. Since you are using lift-mapper, just using lift-mapper as 
dependency should suffice. Rest of the dependencies would be pulled down 
automatically.

I just updated your gist. See if this works.
http://gist.github.com/262613

As davidB mentioned you can also run "mvn dependency:analyze" to filter 
out unnecessary dependencies.

Generally speaking:

1. If you are using any of the persistence modules (lift-mapper, 
lift-jpa, lift-record) you do not need any of the base modules. They 
would be pulled transitively.

2. If you are not using the persistence module (possibly because your 
app doesn't need such support). Just including lift-webkit should suffice.

3. Additionally, if you are using any of the special purpose modules 
(from lift-modules), just add that to the lift of dependencies.

Cheers, Indrajit


On 23/12/09 7:12 PM, David Bernard wrote:
> Tips :
>
> in your project call :
> mvn dependency:analyze
>
> you should see the list of dependencies useless and used throught
> transitive path and to list directly in your pom.xml (may be in place of
> lift-core).
>
> /davidB
>
> On Wed, Dec 23, 2009 at 02:31, Peter Robinett  > wrote:
>
> Indrajit, your post made me realize that I've been using lift-core
> without realizing it. Thanks.
>
> Unfortunately switching to something simpler is giving me some
> trouble. I believe that I should be able to add lift-base, but while
> its sub-modules get downloaded (lift-common, lift-util, etc), Maven
> says that the lift-base module is missing and needs to be installed.
> This is the entry I'm using:
> 
> net.liftweb
> lift-base
> 1.1-SNAPSHOT
> 
>
> As the resident Maven expert, do you have any idea what's wrong? My
> entire pom.xml is here: http://gist.github.com/262244
>
> Thanks,
> Peter
>
> On Dec 22, 8:32 am, Indrajit Raychaudhuri  > wrote:
>  > On 22/12/09 12:23 AM, David Pollak wrote:
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
>  > > mailto:indraj...@gmail.com>
> >> wrote:
>  >
>  > > Folks,
>  >
>  > > lift-core is a 'meta' project that can be added as a
> dependency to a
>  > > Lift project to pull in all the Lift modules. This serves
> as a singular
>  > > configuration point in a Lift based application.
>  >
>  > > However, since lift-core downloads all the Lift modules
> (irrespective of
>  > > whether the project needs it), adding this as the
> dependency slow  down
>  > > things for a standard project that doesn't need some
> additional modules.
>  >
>  > > In a sense, we have moved quite a bit from the initial
> purpose of having
>  > > single dependency on this 'meta' project in a Lift application.
>  >
>  > > Further, the name is a misnomer now!
>  >
>  > > The question, therefore is:
>  > > Should we consider deprecating this? If not, we need to
> document when it
>  > > should be preferred and when not. If yes, what should be
> the time frame
>  > > for making the move?
>  >
>  > > With Lift 2.0 coming up,
>  >
>  > > Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1
> based on
>  > > the naming rules that Heiko proposed and the Lift community
> adopted.
>  > > The fact that the next release of Lift is going to be called
> 2.0 rather
>  > > than 1.1 does not change the scope of the release.
>  >
>  > Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I
> meant.
>  > But yes, it ends up sounding different, sorry.
>  >
>  >
>  >
>  > > With that being said, deprecating lift-core is fine by me as
> long as
>  > > there is an easy to understand deprecation message with clear
>  > > instructions as to how to replace lift-core with whatever is
> necessary.
>  >
>  > For deprecating dependencies, it's just matter of persuasion
>  > (Announcement, wiki etc.) for at least two releases, or more
> (could be
>  > milestone releases). And eventually, dropping it from the build
> beyond
>  > an agreeable release time frame.
>  >
>  > I couldn't figure out a clean way of deprecating 'meta' packages
> since
>  > it doesn't have any active code (thus doesn't expose any place to
> code
>  > in some deprecation warning message).
>  >
>  > As such, the package is harmless and there is zero cost of
> maintenance.
>  > Just that, it's no more a good practice (longer build time,
>