Re: [Lift] The future of lift-core

2009-12-22 Thread Indrajit Raychaudhuri 


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 framework http://liftweb.net
> Beginning Scala http://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.

Re: [Lift] The future of lift-core

2009-12-21 Thread David Pollak 
On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri  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.

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.


> 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 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, the simply functional web framework http://liftweb.net
Beginning Scala http://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.

Re: [Lift] The future of lift-core

2009-12-20 Thread Heiko Seeberger 
2009/12/20 Indrajit Raychaudhuri 

> 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.
>

>From a modularity standpoint pulling in all the numerous Lift modules - some
of them very special - is a bad idea.

Further, the name is a misnomer now!
>

Yes, it is totally misleading.


> The question, therefore is:
> Should we consider deprecating this?


Yes!


> If yes, what should be the time frame for making the move?
>

Perfect fit for 2.0.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

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] The future of lift-core

2009-12-20 Thread Indrajit Raychaudhuri 
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, 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 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.