On 22/12/09 12:23 AM, David Pollak wrote: > > > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri > <[email protected] <mailto:[email protected]>> 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 [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:liftweb%[email protected]>. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
