 Well, I think we will just get started. Yeah. Yeah. Welcome to my talk on building FlexJ applications, FlexJS applications with Maven. Well, if you sort of looked through the history of talks I did, you will probably see sort of this name quite often. But the strange thing is, every time I hold the talk, it was something completely different because it was such a moving target. Last year, I had this talk and I was building with FlexMojo's. Well, I was going to talk about that. That was sort of a just in situation. Things stopped working the day before I held the talk. But today we're talking about something that's working. Hopefully. Yeah, well, yeah, they got it. A little about me. Well, I really feel sort of strange introducing myself. I think you all know me. But well, my name is Christopher Dutz. I'm a senior IT consultant and work for a company called Cotentric. I get one day per week, usually, to work on open source stuff. I had a little luck with some projects. I did the last few years, so I was able to actually do quite a lot more work on open source. As my time there, I'm an Apache member. I'm part of the Flex PMC and committed there. I had been the FlexMojo's lead developer. Well, I still am, but I'm not very active there. Because due to recent changes in the Maven project, it started getting harder and harder to support that. So that's sort of a dead end for me. I'm a total open source enthusiast. So all my free time sort of goes into open source projects. And they're all my Twitter handle, if you want to see what I'm up to. So what am I going to talk about? Well, first of all, why Maven? After that, I'll just fly through a five minute Maven introduction, sort of just get the interesting parts and point out what they are. A teeny weeny little introduction into the Maven Flex.js build life cycle. So who here knows Maven? OK, so everyone? Yeah, well, maybe I'll just do it for the recording. Then I'm going to show you how easy it is to get started with building a Flex.js application with Maven using one of our archetypes. We've recently started creating quite a lot of little archetypes for different scenarios. So I'll just show you how easy it is. And then we'll have a little deep dive into the POM XML, the configuration, to show you how you achieve different things. Yeah, after that's done, well, I'm going to talk a little about the current development, what I'm currently working on, and what is to come. And hopefully, you have some questions that I'll answer then. But you can always interrupt me if there is something you don't understand. So why Maven? Well, Maven is a well-established standard. It works everywhere and sort of works at every customer I came across. It has a great IDE support, well, except Eclipse, that sort of has issues. It has an even better CI server support. So running unit tests on Jenkins is really easy. And it has a well-established standard for accessing dependencies. In the last few years, I've noticed that with upcoming of SBT or NPM, a lot of problems at my customers were related to, well, they have their closed environments, and it's problematic to get dependencies using these other not so established build tools. But Maven worked in every place. So I really like that. The super-duper-mini five-minute Maven introduction, I think it might even be less than five minutes. Well, the main thing is, in Maven, you describe your build in one file, the POM XML. It's the project object model. You describe how things are built, what dependencies you need, and, well, as I said, everything you need to build the project goes into that file. Maven is built up around the concept of inversion of control. So if you're used to and, you usually say tell and do this, then do that. And before you can do this, make sure you have done something else. And you describe every step of the way. With Maven, that's a different approach. Maven sort of says, yeah, well, I'm in phase X. What do I have to do? I'm in phase Y. What do I have to do? And it has a very fixed lifecycle. The main concept is that the default use case should work with almost no configuration at all. So an ideal approach would be for a FlexJS application that I just specify the type, SWIC, or SWIF, and off I go. Configuration can be used to sort of change the defaults and adjust it to your needs. Well, same as if you're building a JAR file, well, you will probably have use cases where you have to fine-tune the build. Same applies here. But Maven allows to do that really easily. One thing that's really great is its dependency management. I remember we had a lot of issues with the ant build with dependencies that sort of had to be downloaded and sort of verifying checksums, getting transitive dependencies, servers that sort of move, have different URLs, or there were a lot of issues in getting stuff. With Maven, it's really easy. Well, as long as you sort of use well-established stuff and, well, we are using almost just standard stuff. So I think that's a really, really great benefit of Maven. So I think a lot of questions on the mailing list I've come across and answered in the past were sort of related to, where does Maven put stuff to and where does Maven get stuff from? Well, let's say this is sort of the default setup. You can see at the bottom you have the project. It sort of consumes, let's say, artifacts and it produces an artifact. Maven takes care of sort of storing that in the local repository. That's just a directory on your hard drive somewhere. Or it gets stuff that's missing from a place called Maven Central. That's sort of from a Maven point of view that's home. If it doesn't find anything, it asks home, do you have it? If it has that artifact, it downloads it, stores it in the local repository, and passes that on to the project. So that's the default case. In case of FlexJS, our ecosystem is a little more complex. So we had to solve quite some problems and that's sort of how it looks for FlexJS. So everyone who is currently working on the development versions or working on snapshots, you need to tell Maven about the Apache snapshot repository. This is usually done. Anyone who had checked out our source code before, you'll find a file called settings-template.xml. So that's a little example file that you can use to tell Maven about the Apache Maven repository. And as soon as you specify that, a lot of problems go away. But not all. Well, that's a good question and I'm just going to come to that right away because not everything we need is available in a Maven repository. As FlexJS is able to compile JavaScript, well, we're safe on that side, but also for Flash and Air, we have dependencies to stuff Adobe provides us with, stuff in the Air SDK or the player global resources. They aren't available as Maven artifacts. So times prior to Apache Flex, the guy who maintained FlexMojos, he sort of had to deal with Adobe to manually convert an Air or a Flash, Flex SDK, into Maven artifacts and publish that. But we didn't get that permit, so we had to find a different way. And we're using Maven extension. It's sort of a really low level extension of Maven itself that intercepts requests sort of like an adapter sitting between Maven and Maven Central. So we check if Maven tries to resolve an Adobe artifact. And if it doesn't work, it intervenes and asks the user if he accepts a license and if he does, it automatically downloads from Adobe's web servers, unpacks that in the temporary directory, and locally does this conversion automatically. And that is the reason why we have to put the repository in the Settings XML because the Mavenizer sort of has to be found before Maven even starts parsing the POM. So without this, Maven would just say, yeah, well, I can't find it and just dies. With a Mavenizer, it does find it. As soon as we release the Mavenizer, or the, well, let's call it, the official name is the Flex SDK converter, I think. As soon as we release that, a lot of that hassle goes away because then it will be found in Maven Central and we no longer have a need for that. But I still have to put a lot of work into that, especially in handling DMG files. But we're on a good way. So that was the five-minute introduction. I hope it was sort of five-minute-ish. Anyone who wants a more detailed one, we did a recording last year in Vancouver and thanks to Justin, who sort of spent 100 hours in cutting all my irms and urrs out of it. It's even relatively short. I think the talk was about three hours and the final version is two hours and 50 minutes. So that was a lot of irms and urrs in there. So feel free to have a look at that. We put it online just to educate the project to get a little more comfortable with Maven. So assuming I said that Maven has a fixed life cycle, it does look rather complex and anyone who had a look at the video will probably recognize the picture. I doubt. I have no idea, eventually. I don't know. Well, as I said, every project has a fixed life cycle. So it does look rather bad if you look at it that way. Can you read it? Yeah, so you can see that. If I, for example, say I'd like to run test, I know that it's gonna go through validate, initialize, generate sources, processors, and all these steps up to test, including test. But it doesn't mean these are offers Maven provides. So it sort of starts, okay, I'm in the validate phase. Does anybody have anything to do now? No, okay, then how about initialize? Are there any things we have to do initialize? And exactly what has to be done in which phase is defined by the packaging. So I think you might have seen one of these POM files. We're gonna look at one in a few minutes. It has a packaging type. And if you set that to SWIC or SWIF, Maven automatically knows what to do in which of these phases. I summed them up a little, and I think this isn't even gonna fit on the screen, but I think you're gonna get quite a good idea of what's gonna happen. For example, for a SWIC, a flex library, we only operate, for example, in the generate sources. For those of you familiar with FlexJS and these, we call them type defs. And when creating the slides, I found out that I should eventually change the name of that goal to generate type defs. It's a part of our build in which we parse JavaScript files and from the JS doc annotations, we create AS doc files that will be used to tell the IDE about types of non-flex libraries. So we can use normal JavaScript libraries, put them into our project. If they are equipped with these JS doc annotations, this phase will produce the action script code that will be used as interfaces. Then we're using the default Maven resources plugin to simply copy static resources. In the compiler, if you're using the ant version, we did have problems in the past that if you had static resources that were not JPG, but JPEG, things didn't get copied. That was because the compiler handled things manually. In the Maven world, we simply rely on the Maven resources plugin and whatever we put in a resource directory, that's copied to the output. Then come the fun parts, the compilation. So we have the compile AS thing that deals with compiling the flash version. We have the part that deals with compiling the JavaScript version, and we have a part that compiles the type diffs. They have to be sort of compiled slightly different, and I think I might be able to reduce these to JS and AS plug-ins into one after the last changes. But right now, it's sort of three executions, but Maven sort of decides on, well, there's no JavaScript in here, so I haven't generated anything, so I'm not gonna compile the type diffs. Yeah, we already got, I got everything set up to be able to start compiling, generating, and running unit tests, but I haven't filled these plug-ins with life yet because I'm still waiting on getting some time to finish FlexUnit to compile. When I look, well, this is the life cycle for a library, so if I say type SWIC, that's what's gonna happen. If I put SWIFN there, that's when we wanna build an application that we can actually run. So life cycle looks a little different there. You can see there is no extern generation because type diffs are always libraries, never applications. So you can see in that case, in the compile phase, we're running compile app. I think I could have left away the test things, but in the end, for example, the package phase is quite interesting in this case because if we compile for Flash, the output is one file, but if we compile for JavaScript, we get a directory full of multiple files and Maven doesn't like that. Maven only likes one single file to be deployed because it sort of uploads that to remote servers and it only uploads one file and no directories, and that's why in the package.js plugin, we sort of pack up everything that the compiler produced and create a bar file from that. That file is then sort of uploaded or locally deployed and it gives us the chance to use who of you has built a web application with Maven? So, oh cool. So let me explain a little. So assuming you're building a server side web application and you want to bundle a Flex.js front end with that, you can easily now use the overlay mechanism to simply take the content of one of those Flex.js vars and simply unpack it in the output of your application. So all you have to do is sort of finish your server application, add a dependency to your Flex.js var file and you're ready to go. You get a var file that has the Flex.js application included. Maybe it's better to have everything in the same project because if you make a change to the back end, a front end as well, but if you have separate projects, you have to release the front end at first or put it in the server when you want to change the back end API. Yeah, well, the thing is, I never have my code in my web application module. I usually have my code and my API in separate modules and then I sort of have the var plugin or var project is simply a wrapper that sort of packs everything together. So yes, I do have the Flex.js application and the server and the API in one multimodule build, but not inside the same module because I usually, I have my model and that's built and then I have my action script model generated from the Java model and sort of then that's built and then everything's packed together. So yeah, I think you would get into real big trouble if you sort of started having one Maven project with Flex and Java and that. So I think that would be a pack with the devil probably. Yeah, okay. So I said, are there any questions to the general way Maven builds? So okay, yeah. Yeah, well, usually you're not allowed to deploy anything at Maven Central, but it's sort of, there are other Maven repositories hosted by other people. For example, the company Sonatype who sort of created the software Maven Central runs on, they have their own repositories. It's the Sonatype OSS repository or so. So you could sign up there and so you have to do a little paperwork, but as soon as you get that done, you can release stuff to their repository and that gets synced to Maven Central. The other way is we have our own Nexus installation at the Apache Software Foundation. So that's the repository you have to tell Maven about to find the Mavenizer. So that's where that is. And as soon as we release something, it sort of disappears from the snapshot repository and goes to the official Apache release repository and that is again, synced with Maven Central. So when doing a Maven release, I just did a Blaze.js release a few weeks ago. All I have to do is sort of close repository, except and yeah, I think a few minutes after that, things pop up at the Maven Central. Yeah, okay. So one thing I put most of my time into is making it easy for people to get started in developing with FlexJS or easy to contribute to FlexJS. And after cleaning up the build greatly by adding the Maven build, we started providing little so-called archetypes. Maven has this archetype mechanism that allows projects to sort of create little templates for different use cases. And for example, we now have five archetypes. Well, one is a simple application archetype. It's an archetype that produces a Hello World application that you can compile to Flash or JavaScript. Then we have a pure JS archetype that might be interesting for people that want to get started with, that only want to target the browser and don't care about Flash, or they want to use some libraries that will not be available to Flash. So the pure JS archetype will help you get set up there. On the other side, we have the same with a Swift archetype. So that is a project that just builds Flash. That could be interesting if you're planning on building a mobile application that sort of uses some features of your mobile phone or so, you will never compile that to JavaScript. So that's a good starting point for pure Flash development. The last two, a simple library archetype. So if you want to sort, you don't want to build everything into one big application, but you want to apply some separation of concerns and split up your project into multiple parts, the simple library archetype will help you set up a simple library. Last, not least, we have the type def archetype. I think this is a really interesting thing because with this you can set up, assuming you found this fascinating JavaScript library and you would love to write a Flex application that uses that. So by using the simple type def archetype, you'll get a project which you can sort of drop in some JavaScript and it will produce a Flex library that you can start writing code for this fascinating new library you found. Okay, so don't want to be just talking, okay? It's not even doing some line breaks. So now we're going to have a little demo and I'll just show you how fast and easy you can get your first Flex.js application running with Maven. There was a trick, I think, because that's full screen, isn't it? Can you see that? There, where's the full screen mode? I hate that. So let's make it a little easier. I already typed that. So what happens here is, it's not recorded if I go there. What happens here is we call a Maven plugin called the archetype plugin to generate a project. If we just left it there, it would sort of look in Maven Central and look at all the archetypes there are. If you started using archetypes about 10 years ago, that was cool, but right now, I think there are several thousand archetypes you sort of would have to scroll through. So what I'm doing here is I'm providing the group ID, the artifact ID and the version of the archetype I want to use. It looks a little lengthy, but there is no real magic to it. Any questions? You sort of, or it's just too hard to read. Oh well. Okay, so off we go. And fingers crossed. Okay, so it's asking me for a group ID I want to give the thing. So I'll just call it Org Apache Flex Demo. Give it a name. It already suggests a version, a package name. Asks me if I mistyped anything and it's generated. So you can see there's a POM and a source directory. So if we want to build it, you can see the, did you saw the ASCII Art logo? So that's the little thing I built into the mavenizer to that you can see that it's actually working because we did have problems in the past that people said, yeah, well, I did it and it still doesn't work. If you see that, you're safe. I hope it says build successful. That's good, but it doesn't have to mean it works. So now I'll just go into that directory. So now you can see in the target directory, we have JavaScript bin debug and there's the index HTML. And as soon as I open this, I really hope I'll see this hello world. That's awesome. It's the coolest hello world in the world. But we could also see that there was also a Swift. Here it had the, on this side it said hello, hello world. It's a shy hello world. Yeah, well, so you can see it was really, really easy to get started. Well, it's getting a little, it will probably get a little more complicated if you wanna do more than just this little hello world. Yeah, I'll just open that here and push it over and use the cool presentation mode. Ah, I can see it here, okay. Never quite used that. So there it is. Where's the palm there? Okay, so as you can see up here. There were the coordinates, the archetype asked me. So the group ID, artifact ID and version, the Swift packaging is coming from the template. Also, I'm defining a variable there called compiler.debug. I use that to sort of set the compiler to produce debug versions and optimized versions. The optimized version still builds the debug version, but it sort of processes the debug version to become a final version that does all this minifying and stripping away of the code. The important parts here are this extensions tag because if you leave that away, Maven will complain that it doesn't know what to do with the Swift packaging on top. So by defining the flex JS Maven plugin and telling Maven that this is an extension, you will be able to build flex JS applications. I did create the plugin that it's completely separated from the compiler itself. So it should be possible to use the flex JS Maven plugin with the original flex compiler. It's completely separate. So you have to provide the compiler you want to use. We were also thinking of moving the Maven plugin into a separate project so we could release them separately. So that's just something you have to keep in mind. You have to provide a reference to the compiler. Here all we have to do is tell the compiler what's my main class and what type of output do we want. So in this case we're creating the Swift and the JavaScript version. Our code does depend on some other libraries and these are defined down here. And here comes one specialty. Well, we need core where we got some of the core functionality. So we got a normal Swift dependency on a core but for example when compiling the flash version we need a reference to player global or error global. That's sort of the core library for everything built with flash. And the JavaScript version in contrast needs the other two libraries defined down there. So if you just build a flash application you can leave the lower dependencies away. If you're just building a JavaScript one you can omit the error global reference. Yeah? Yeah, well, I, oh, I think I have to adjust my archetype because there should be a debug that references the variable. So if I tell Maven to use the release profile that it sets this variable to false. A good point. So any questions to that? Oh, yeah. Yeah, just let me, so that's not the right one. Is it now? It says it's the FlexJS version. Is it? I'm just gonna close that. It must have sort of magically disappeared. It's still telling me it's there but I can't see it. Where's it behind everything? I'll show you after. Yeah, it's quite easy. It's sort of these archetypes are sort of simple Maven modules in which everything you need is sort of put into the resources of source main resources of the archetype module. But inside the archetype you replace things you want dynamically updated with some escaped values. It's sort of a templating thing. It's quite easy to understand. No, not at all. It's just text editor. So let me get back. I hope I'll find my way back to my presentation. Oh, that's looking good. Okay, so. Okay, I already did the dive into the palm. So, not all is good right now. Not all dependencies are available as Maven artifacts. Well, if we go down the JavaScript path, it's great because we have the opportunity to work on that. But on the flash side, Adobe will never release their stuff in Maven Central. So we will always have this problem of providing these resources. The Mavenizer, I'm currently working on the last pieces I need to release that. I didn't want to release it before being able to process content in DMG files. I know on the mailing list there were some discussions about using system calls to execute that. But I'm no big friend of that because right now the Maven converter is able to even produce Mac libraries on a Windows machine. So I wouldn't want to give up on that. And these executions would simply miserably fail on a Windows machine. So I'm currently implementing the DMG decompression code. I'll probably put that to Apache Commons. Unfortunately, the Apache Common guy just left. Yeah, so that's what I'm currently working on. And as soon as the Mavenizer is released, we are getting rid of quite a lot of problems. Right now we are using simple compile scopes in Flex. So we don't have big problems at the moment, but everyone who worked with the old Flex SDK, you know, we had scopes like RSLs or the signed RSLs. Or yeah, we had different scopes that Java just doesn't know about. And with Flex Mojos, we sort of worked around that because there was a bug in Maven that sort of, as soon as there was a scope, it didn't know. It sort of defaulted to compile. That was cool because we could do whatever we wanted this way, but they fixed that bug. And now, transitive dependencies of non-compiled scopes aren't resolved anymore. So if I had a library that, if I had a library A that requires B and I would include it as a normal SWIC, that would be okay. But if I sort of said, yeah, well, that should be an RSL, then we wouldn't get B. So we would have to start and try figuring out, sort of declaring dependencies multiple times. I'm no big friend of that, but the good thing is, I've been talking quite intensively with the Maven guys, and they just recently got a part of code we needed, donated from the Eclipse Foundation. I don't know if you followed that discussion, the Ether project, the Eclipse Ether project is now part of Maven. And now we have control over the code we need to be finally able to provide an extensible mechanism for providing non-default Java scopes. So I'm currently waiting on these extension points to be established, and as soon as that's gonna happen, I'll be doing some really deep Maven extension stuff. So we can finally use all our good stuff with Maven without any problems. Another thing that's currently bugging me quite a lot is a few months ago, SourceForge updated their SSL encryption. And that's sort of, people from the US will probably not have noticed that, but everyone outside will, because Java simply isn't able to support that deep level of encryption. And this level of encryption is sort of, I think there are some US export restrictions that sort of prevent that from being shipped with a GDK. There seems to be a way to manually install Java cryptography extension to make Java download that, but I haven't seen that work reliably. So it sometimes works and sometimes doesn't. Yes, Justin? Yeah, okay. Yeah, well, it's one thing. I think it might probably be the easiest way that I simply re-implement the libraries we needed from there, because it's simply the font kit stuff to do the font encoding that we are still using from, I think it's still version one and I think it hasn't changed for, feels like 10 years or so. So as soon as I re-implement that library, those problems go way too. But I have to implement that and I'm not looking forward to doing font encoding stuff, but, no, look at that. But I think we need a special encoding. It's not the decoding of fonts. I'm worried about there are cool libraries for that, but I have to encode stuff in a way the Flash player knows about it. And I would be surprised if Adobe chose a format that is standardized and, yeah, I don't know. Well, one thing that I would like to finish really soon is simplifying the dependencies. One thing you didn't see, but I can show you later on, that we are building two versions of libraries, one that was compiled for JavaScript and one that was compiled for Flash. So we do need to reference both libraries if we want to be able to build both types and I think that's just too complicated for most users and with the changes in the dual branch, it should be the first step on a way to produce swigs that contain, has any one of you had a look into a swig? So inside a swig there is a catalog XML and a swith file that contains the bytecode for the Flash version. So what I'm proposing is that we sort of have a catalog JS XML file in there and the corresponding swith file, the Flash site would simply treat that as binary garbage in the file and it wouldn't mess up anything there and we could make our compiler sort of look into that catalog file. So we wouldn't have to do this distinction. We would just have I need library X and version Z and we wouldn't have to do define multiple dependencies. Now it's still producing two files and you still need to, if you have a look at the examples that it usually says, well, you depend on core and core internally has, well, I depend on something else and something else JS. So this morning that was the first thing I checked when I woke up this morning because sort of was lying in bed was awake and thought I didn't see any JavaScript dependencies in my archetype. Holy crap, does that work? So I just did check and yeah, okay, it's just one level beneath. So an end user doesn't explicitly see it but we do require two versions. Okay, you do probably. Okay, yeah. Well, talked about the past and the current situation. What is to come? Well, the top thing on my list is the mavenizer. I don't know if anybody still remembers that but that code was the thing that got me involved with the Flex project. I donated it shortly after going to ApacheCon in Zinsheim and it's still in the 1.0 snapshot. So I should probably finally finish it, release it, ship it. Next thing on my list is FlexJS unit support. The old FlexMojos did some really nice job sort of scanning through the project like the JUnit integration does. It scans for test cases and automatically creates a runnable test suite and runs that and sort of instantly starts a listener that the browser then connects to and passes back information. So you can get a full unit test coverage reports that maven understands right outside your maven build. So that's one thing I'm gonna be working on. Another thing I started and sort of had to delay just as a lack of time is AS stock generation. Currently the project is focusing on creating a flex or an AS stock viewer that's created in FlexJS. But I think it would be good that we had a classical AS stock generation in maven that we are able to produce static HTML documentation pages. So IDEs and Google and everything that is used to handling HTML files for documentation will be able to provide direct documentation for FlexJS. Yeah, as I said, as soon as the maven guys fire out their extension points, I'm gonna definitely do the extension mechanism for dependencies. And if I still have any life left in me, I'll probably re-implement the Adobe FontKit libraries. What? Oh yeah, forget it. So yeah, I'm right at the end, 51 minutes, cool. So any questions? Has anybody? I was wondering, one of the things keeping me from, I'm not so sure how well it integrates with the instance. I don't remember I had this workflow in my introduction showing how I change a framework class and I can actually use it in the test application. Suppose I wanted to use maven on the framework. Would that be a problem? I mean, I know mixing and in maven doesn't work very well. Would that be a problem with the IDEs? I have no real idea because I was working on fixing IntelliJ's integration, but I didn't get that good support from the JetBrains guys. I think it should be possible because it isn't that difficult to extend IntelliJ. Justin, do you have anything to- Yeah, I tried that. Yeah, so that's the way I usually do it. I edit in IntelliJ and then I just hit the button and a few seconds after that, it's finished. Especially you don't have to rebuild the whole application every time you change something. So it is enough that if you work on HTML, for example, or a core that you just build that module, that's a few seconds and then you build your application. So yeah, that's one thing. In Seville, there were some guys from the Maven project sitting here and you could sort of really see them. He said clean install, oh, damn it. Yeah, well, in the Java world, it's usually not treated as good or best practice to do a clean install, but here we're producing a lot of different files and especially the state the compiler is currently in, I wouldn't trust it on working on things like incremental builds or recompiling stuff. So I would suggest to stick to the clean install for now. No, no. Well, the first time it does, first time you download the internet and after that it's there. As soon as you change a version number, then it tries to download the new version number, but it stores it locally in the Maven local repository and uses it from there. Yeah, yeah. Unless you tell it not to. Yeah, so we currently set up several builds on the ASF Jenkins machines and they produce on every commit, the snapshots are updated and your Maven will call back and check if something changed once a day. So usually, as soon as midnight, I know it's time to go to bed when it's this one build where it starts contacting Maven central again, so oh, damn, it's 12 again. Have to go to bed. Yeah. There's some font forge. Well, if it's GP, I think we'll have a problem, huh? Well, it depends. Okay. Okay. We'll definitely have a look at that because I don't really. Mm-hmm, yeah. Well then, thank you. Let's grab some lunch.