Closed Bug 349870 Opened 14 years ago Closed 13 years ago
Build Thunderbird with preinstalled Lightning
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20060821 Firefox/18.104.22.168pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060823 Thunderbird/2.0a1 ID:2006082303 This is a bug similar to Bugzilla Bug 306324 Build/run Tbird on top of XULRunner, bug 299986, etc. Its intention is to gather up what is required to build a working Thunderbird with Lightning integrated. Reproducible: Always Add your bugs here.
Component: Build Config → Lightning Only
Product: Thunderbird → Calendar
Should actually be quite simple, as it works for suiterunner with the patch in bug 313822 - Thunderbird should be very similar (probably just making the ifdef I use in my patch include both suite and thunderbird).
Assignee: mscott → build
Component: Lightning Only → Build & Release
Product: Calendar → mozilla.org
QA Contact: build → preed
Version: unspecified → other
Can someone confirm this bug? Thank you.
Maybe this bug should be moved to Product "Calendar" and Component "Build Config".
(In reply to comment #3) > Maybe this bug should be moved to Product "Calendar" and Component "Build > Config". > I had both of those turned on in the past, and it found its way here for whatever reasons.
13 years ago
Assignee: build → nobody
Component: Build & Release → Build Config
Product: mozilla.org → Calendar
QA Contact: preed → build
Version: other → Trunk
Noe that step 1 of bug 313822 has landed, you probably just need to make the ifdef MOZ_SUITE in the Lightning Makefile to include Thunderbird. I guess there's no var set that tells if we are building Lightning together with some normal host application? If there is such a var, it would probably be the best choice for this ifdef, actually.
I vote for wontfix. The reason is this: building thunderbird with lightning integrated means that those who build lightning themselves no longer need to install lightning. Those people include the developers. The result is that developers never test the installing phase of using lightning. But for users, that step is pretty important. If it fails, the can not use the product. So, I suggest that we don't automatically install lightning. Those who know what they are doing can apply the patch themselves.
I don't use Thunderbird anyways, so I don't care a lot, but I don't completely understand this reasoning, as there's not any Lightning-specific stuff tested in that installation process. If we were in old install.js-based installation times, I'd understand, but all the installation process is done by EM, which gets enough testing elsewhere. And even with that patch, EM still checks install.rdf and (de)activates the extension based on the info in there, so I don't see any part of Lightning code that is not tested this way that would be tested with the current variant.
The reasoning is simple: "test what you ship". Don't assume that things will work. test it!
As I understand it, our long-term goal is still the inclusion of Lightning into Thunderbird (and probably SeaMonkey too). Therefore I don't think that this bug should be WONTFIX'ed.
@mvl: IMO we won't miss the installation tests; I assume that most people use a regular release thunderbird installation for testing (that's at least my production environment, I only switch occasionally to my debug thunderbird build, and even for that case we could offer a build option to not install globally). Regarding long term, I think it's not only a matter of build config here, but whether thunderbird ships with lightning or not, or has a prominent setup option to install it or whatever. I think that's the interesting part.
Comment 9 and comment 10 are in line with the reason I opened this bug. The install of Lightning is not the issue, but rather the problem. I want it to be included in one download with no additional install required. If anything, there could be a checkbox at install time whether to activate (or install) the Lightning part of it, but that can be some other bug. Thanks.
The makefile magic introduced for Seamonkey *allows* to build Lightning by specifying |ac_add_options --enable-extensions=default,lightning| and have it show up in the Add-ons manager. http://mxr.mozilla.org/seamonkey/source/calendar/lightning/Makefile.in#49 It also builds the chrome.manifest automatically, so you don't need to maintain it manually: http://developer.mozilla.org/en/docs/JAR_Manifests http://mxr.mozilla.org/seamonkey/source/calendar/lightning/chrome.manifest This doesn't mean that Lightning is built *by default*, but it is a prerequisite.
OK, I guess what I am looking for is for this to not just allow it to be built, but also to ship that way. Changing the title to reflect this.
Summary: Build Thunderbird with integrated Lightning → Ship Thunderbird with integrated Lightning
Not going to happen within the 0.7 timeframe. If we do this, we will coordinate that properly with the Thunderbird folks.
I think it makes sense if Lightning would be automatically installed in Thunderbird if Thunderbird was build with --enable-extensions=lightning. This would be the same behavior as it is with DOM Inspector now. But shipping an official Thunderbird release with Lightning included is a different topic. In my opinion this doesn't make much sense because many user don't need this functionality. If they need this functionality the can install Lightning. Shipping by default would also mean that the release schedule of both projects needs to be synced. Maybe Thunderbird could include a link to the latest Lightning release instead allowing easier installation of Lightning - as already suggested in Comment #10
I think the same ssitter in that regard. The --enable-extensions part is quite easy, as I said earlier you just need to change the MOZ_SUITE ifdef (pointed out in comment #12) to include Thunderbird as well. Actually, I think it would be a good idea to either remove the ifdef completely or rewrite it so that it's only not installed by default when the build project is something where it doesn't make sense. After all, install.rdf is still there and only activating it in certain apps/configurations, even when the build process might "install" it. For the "ship by default" case, I think this is not even a decision the calendar team can make, but only the team shipping Thunderbird can make, and so a bug directed at that might even be invalid for the calendar product.
OK, ship by default may be the wrong wording. What I'd like to see is a checkbox giving the option at install time (like the ability to install desktop shortcut, the ability to install talkback, etc.). This is the trunk we're talking about here, not the branch; and it seems that is the proper place for this sort of thing. Why hold off on doing it when it is going to be inevitable eventually anyhow? Might as well have it right right from the start.
What you mean is indeed ship by default, and the calendar product on bugzilla is probably indeed the wrong place for requesting this as you need to request it from the thunderbird team instead of the calendar team. Not sure if any of those two teams even wants to ship the two products together, but that's surely I cannot know, I'm in neither of those teams. But I as an outsider on both of them are not convince this is "inevitable" as you called it and not even convinced if it's "right" as you call it. Remember that Thunderbird is not the "everything but the kitchensink" app, it's not even a suite, it's just a mail (and newsgroups) client. Still, as I said, if they even want it is for the Thunderbird folks to figure out, not for me and probably not even for the calender team this bug report is addressed to.
If you look back at the bug history, you'll see it was originally against Thunderbird. I think if they want to compete at all with Outlook, they will have to add a calendar/schedule component and everybody knows it but won't discuss the 350 pound gorilla in the room. This bug just brings it to the table for discussion.
If you look back at the bug history, you'll see it was originally against Thunderbird. I think if they want to compete at all with Outlook, they will have to add a calendar/schedule component and everybody knows it but won't discuss the 350 pound gorilla in the room. This bug just brings it to the table for discussion and can become the driving force to make Thunderbird something decent "out of the box" without the extra painful steps of finding and installing an extension to make it happen.
The key is the INSTALL_EXTENSION_ID. It extracts the contents of dist/xpi-stage/lightning.xpi to dist/bin/extensions: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/config/rules.mk&rev=3.570&mark=1764,1769-1774#1764 So this *allows* you (but doesn't change anything unless you do) to build Thunderbird with integrated Lightning by adding |mk_add_options MOZ_CO_PROJECT=mail,calendar| and |ac_add_options --enable-extensions=default,lightning| to your mozconfig. This is the same as e.g. DOM Inspector does. I'm simply removing the ifdefs since this should happen for all apps which want Lightning, e.g. Firefox as well - unless I'm missing something. Tested with Thunderbird on the 1.8 branch on Linux and works just fine.
Assignee: nobody → steffen.wilberg
Status: NEW → ASSIGNED
Attachment #281251 - Flags: review?(daniel.boelzle)
It wouldn't make sense (and the Add-ons manager would prevent it anyway) to install Lightning inside Sunbird, so I've added ifndef MOZ_SUNBIRD around the INSTALL_EXTENSION_ID line. The other options (USE_EXTENSION_MANIFEST and NO_JAR_AUTO_REG) are about extension packaging and can be used in any case. They are documented here: http://developer.mozilla.org/en/docs/JAR_Manifests#Register_Chrome
Comment on attachment 283620 [details] [diff] [review] better patch r=dbo, thanks for the patch.
Attachment #283620 - Flags: review?(daniel.boelzle) → review+
(In reply to comment #16) > For the "ship by default" case, I think this is not even a decision the > calendar team can make, but only the team shipping Thunderbird can make, and so > a bug directed at that might even be invalid for the calendar product. Right, whether lightning will or will not be part of thunderbird's installation in the future has to be discussed with the thunderbird team resp. David Ascher. I am changing the title of this bug to reflect that.
Summary: Ship Thunderbird with integrated Lightning → Build Thunderbird with preinstalled Lightning
Whiteboard: [checkin-needed after 0.7]
Thanks everyone for your hard work on this bug. The original bug title was "Ship Thunderbird with integrated Lightning", and that is still the intent. I may just let this bug finish up with its lifespan, and open a new one for the actual shipping product.
Checked in on HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [checkin-needed after 0.7]
Target Milestone: --- → 0.8
(In reply to comment #25) > Thanks everyone for your hard work on this bug. The original bug title was > "Ship Thunderbird with integrated Lightning", and that is still the intent. I > may just let this bug finish up with its lifespan, and open a new one for the > actual shipping product. > Done! Bug 401779 – Ship Thunderbird with integrated Lightning
Bug 406441 attachment 297853 [details] [diff] [review] regressed this by putting it inside an ifdef INSTALL_LIGHTNING.
(In reply to comment #28) > Bug 406441 attachment 297853 [details] [diff] [review] regressed this by putting it inside an ifdef > INSTALL_LIGHTNING. Could you elaborate on this? Does this bug need to get reopened?
No. If the builds instructions are still correct, you just need to add ac_add_options --enable-calendar to your Thunderbird mozconfig: https://developer.mozilla.org/en/Comm-central_source_code_%28Mercurial%29#Sunbird_and_Lightning
Since there are so many problems with Thunderbird and calendar now, it may be a good chance to think about integrating the calendar into Thunderbird completely and directly, and do away with the addon part of it entirely. This would greatly simplify the installations, and hopefully make less bugs overall.
Product: Calendar → Thunderbird
Target Milestone: 0.8 → ---
Please don't mess with bugs that were marked fixed long ago, even if you reported it. (TM 0.8 is no longer available)
Product: Thunderbird → Calendar
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.