 We are here to talk about how we actually killed our sleepless nights from PD build, moving to Maven and then to Maven Tyco. So, this is actually an experience that we went through about a year and a half ago and we thought we would just do a quick talk on it. So, our topic is sleepless, sleep peacefully with Maven Tyco builds your product. So, I'm from a company called Ancet Consulting and Subhu is from a company called Everteam. So, Ancet is an Eclipse Foundation member and we typically do Eclipse Consulting services in India. And Everteam is a BPM-based company, basically kick starters of the BPM project in the Eclipse projects. So, how many of you use the Maven Tyco on their projects already? How many of you have done PD builds the Antway? How many of you have done a mixed mode where you have PD builds that run on Maven with POMP first approach? Okay, so, good, right, like I always say in all my talks, you know, the advantage of less people raising their hands is whatever we talk is right. If too many people raise hands, then you have to be more careful. Yeah, so, what's, yeah, so PD builds, so what was wrong with PD builds? It was ant-based, right. I've spent long hours trying to set up the build machines with the right dependencies in the right path, right, and then somebody would check in a code with a new dependency which the build machine doesn't have, and I would be actually sleeping and the code gets checked in from Germany, and then the build fails, and we have emails shooting all sides, I think the build failed because the dependencies are missing, right. So, finally, I said, I was so frustrated that I decided not to do automation of the build. At one point, I said I will click the export button every time myself, right. So, yeah, so we all know what is the pain in PD build, you know, we really don't want to spend too much time on, yeah, that's kind of a Dilbert which says my build system is connected to a massage chair. The number of times build fails, I have to be up without sleep, so it vibrates me, right. So, yeah, so just on a, then ant improvised, right, so ant moved ahead and went into Maven build where the dependency management was a lot more easier, right. It would find what it wanted as long as we pointed to the right repositories, right. So that was good about it. But the problem with Maven, when Eclipse wanted to adopt it was that Maven worked very well for non OSGI bundles, right, but couldn't work with OSGI bundles. Then we did our own part of the code where we do the Maven Eclipse stuff around it and then package full Maven to actually make OSGI bundle instead of a non OSGI bundle and all sort of things, right, again not required. But the idea was that ant moved on to Maven which made dependency management a lot more easier, right. And then came in the next phase where, yeah, so Tycho came in to make life really easy, right. So with Maven dependency management was taken care, but through Palm dot XML, right, which Eclipse did not understand. And as Eclipse developers we add all our dependencies into the manifest file, right. So every time it was the responsibility that you add into manifest file and you also add into the Palm dot XML file and then check in everything, right. And this was a big headache because I always test on my local machine if it's working and I just commit the code. I don't really worry about does the build system work. I always forget to write into the Palm file. Then came in the Tycho build, which is really awesome. It worked like the PD build on the manifest file, but giving me the goodies of not having to add it to the Palm file and the dependency management was automated because it could take from my P2 repository. So I really didn't have to set up my build machine with the right Eclipse downloaded with the right set of plugins. I just pointed to the various repositories that I'm interested in and the build would happen, right. So that's where the Tycho build came in. So our idea of this 45 minutes talk is give you a quick beginner level introductory demo of what you could do with Maven Tycho. How do you build the different artifacts? So normally with Maven we build jars, wires, EARs, right. But with the Eclipse world we build plugins, features, repositories of P2 sites or products, right. So the artifact change happens and that's what Tycho brings in, right. So the idea of this talk is to show you how to build these artifacts using Maven Tycho and how do you actually manage some extra stuff that you are interested in. So step one, right, so which we are not going to demonstrate is you first need the Maven plugins downloaded for Eclipse, right. Installing the M2E plugins, right. Then on top of it you need to install the now with the latest version M2E plugins come by default in Eclipse. So you really don't have to do the installation, right. Then on top of it you need to install the Tycho configurator which is responsible for the various artifacts and all of this understanding of these artifacts. So the idea now is how do I use this Maven Tycho to build these artifacts? How do I build my plugin? How do I build my feature? How do I build my site? How do I build my product? So demo time, right. And demos are always like an examination, right. Sometimes they work on stage. Sometimes they don't work on stage. So we're always cross-fingered saying let's hope that it works, right. So yeah, so he's, so Subu will walk us through the demo. I would do, I'm more like a, he's the real man behind the Maven scripts. I'm more like his orator. I just talk, right. Probably his protector. Yeah. So like any other Eclipse plugin developer, we start developing some plugins. So we're just going to build a few plugins and then Mavenize it for you. So he's just taking some template projects that he has. So we're building a simple Eclipse plugin. So having had the Eclipse plugin, the two important files for us are the manifest file and the builder properties file, right. Which decide what goes into the jar and what are our dependencies, right. So we're going to Mavenize this now. So there's actually a menu here under the screen, which is called as configure and configure it to a Maven project convert to Maven project. It's going to Mavenize it. So if you look at this, the first change that really happens is, okay, we haven't spoken about Maven. So leaving out that part of the story. So this is an M2E plugin, which opens up and the packaging styles are what Maven supports. So it has jar, var and EAR, but we're not building a jar here. We're trying to build an Eclipse plugin here. So we need to change that. So he first changes the group ID. Then the version numbers should always be in sync with your manifest file. So it's 1.0.0 for us. It's dot qualifier in the Eclipse plugins in manifest file. It's hyphen snapshot. So it's 1.0.0 hyphen snapshot. And then the name of the plugin that you're building and the packaging style is manually typed as Eclipse hyphen plugin. So we're going to show you. Yeah, so he does not understand what is Eclipse hyphen plugin because because Maven is not meant for that. So he will now include the required dependency from Maven that understands Eclipse hyphen plugin. So we are adding a Tyco plugin. So this plugin is from Maven and not from Eclipse. So it's a Maven extension that supports. Yeah, we can increase the font size or zoom on back. Yeah, you can increase the font size on the Tyco editor. We can also zoom in. And then you can just run your add the deposit. So the first step is to make Eclipse plugin understandable by Maven. So this is the addition. Then you need to add your repository from where he would find his dependencies. So he's added the repository here, pointing it to a P2 layout and the URL from where he would find his dependencies. So you can point it to any P2 repository online so that the downloads happen. And having done that, you just run your Maven install command and step one is make your plugins. Step two is Mavenize the plugin. It would actually create the POM file. When you create the POM file, the packaging style should be Eclipse hyphen plugin. And then once you have your first form, you need to add in the Tyco plugin, Tyco Maven plugin to it and then add the repository. Trying to connect your repository is trying to see if there's an update that he has to take. So we've just built an Eclipse plugin. So if you go back to the Explorer and repress your package Explorer, you would find a target folder which contains the jar of your plugin. So you did not really have to manage any dependencies, even if I had. I would just make a plugin, Mavenize it, set the type to Eclipse hyphen plugin. Go ahead and add the required repositories and the extension plugins to it in my POM file and then run. So that's a simple plugin deployment. So how to bundle a plugin. So now we're going to bundle the second plugin and show you how to actually bundle multiple plugins at the same time using the parent form. Because you typically don't have one plugin to build. You have multiple plugins to build. You run your test suite, it runs all the test cases. So here you run your parent form and it runs all the modules which are attached to the parent form. So we've got the second plugin up. You still need to Mavenize it. The same stuff appears. You have to configure it, convert it to a Maven project. The same stuff again, you have to replace its group ID, the version number and type Eclipse hyphen plugin here. So having done that, you have this error. So you could again add the plugin here and the repo here but doesn't make sense to keep duplicating the information. So we create a parent project which has all the common configurations in the parent form and the child form just use it from there because it's declarative. So he's creating a general project which acts as the parent project. He Mavenizes the parent project also. But this time the group IDs have to be same because that's how they get associated. But this time he's going to build the packaging type as form. So he just takes a parent form. So whenever you have to create a parent form, the packaging type has to be set to form which is a default type from Maven. Nothing to do with Eclipse or Tyco. And then he creates the form file for that. And then having created the form file, he would copy the general configurations from the previous form that we already had to build plugins and the repository. So whichever is common across all your forms, you can move them to the parent form. And then now you need to tell the parent that you have two children. So he has to add modules to this. He goes to the overview in the module section, adds two parents. And then you need to select this update form. So the parent knows the child. The child knows the parent. It's bidirectional. So having done that, so now my parent knows the child and you just have to do an update to get rid of the error. The errors are gone. The two childs are being build. Now you can run your parent form and then it would just build the two plugins for you. So you make a parent form. You just make a general project. Mavenize it with the packaging type as form. And then add the two modules or the two children that you want to build along with the parent form. Move the common configuration into the parent form and then run the build. And it's successful. My parent project in turn invokes the two builds for the plugin one and plugin two and build. And now you would have your target folders in the corresponding projects where the two plugins are built. The two jars are present. So typically we don't only build plugins. So the next step is to build a feature which consolidates the two plugins and then gives you an update site or P2 site that you could upload it into your P2 site. The next step is creating a feature. So it's just a normal process of creating a feature project. So you're just creating a feature project. Having done the feature project, it has to also be mavenized. You undergo the same step convert to Maven project. Same rules, the group ID, the artifact, the version number, but this time the packaging type would be eclipse hyphen feature. When you build plugins, you build eclipse hyphen plugins. When you build features, you build eclipse hyphen feature, right? So again, eclipse hyphen feature is not understood, but this time you just have to go add it to your parent because the parent has the required common configuration. You go to your parent, include that bidirectionally and update your feature project once and the error is gone. And now if you run your parent form, it also builds your feature along with it. It builds your plugins in respective plugins inside the target folder. It builds the feature inside the feature inside the target folder of the feature. The first warning that you see which says build is platform dependent because I'm only building currently for my platform. I haven't included the other platforms. It's like when you export your product and it asks you do you want to you include the delta pack and then you say export for multi platform. So yeah, so that's my parent form, my feature and my two plugins built with the target folder there showing you the feature. The next step for delivering this to someone would be your repository because that's the final deliverable that you typically give. So you can build a repository or a product, both use nearly the same mavenizing technique. He's just creating an update site. The update site has to be just a general project because there's nothing called as an update site anymore. So we just make a general project and may have a nice, the general project. And yeah, so he's adding all the required things for the update site that we normally do. So he's got a category dot XML where he includes which features to download. So that's your typical. Then he mavenizes this again with the group ID. But this time he's going to use the packaging type as Eclipse hyphen repository. So there's Eclipse hyphen plugin. There's Eclipse hyphen feature. Then there's Eclipse hyphen repository repository is for your final deliverables. It is meant for your update sites and your products. And again, you need to come and add that to your parent. So if you see here, we tick the parent and we say update the child also, right? And then finish update. So the error on the palm file is gone. Now to remove the marker symbol is update the project once. No more errors. You can run your parent form and it would give you your update site as well to give you an update site. And if you look at your update site with the target, it basically has your repository there with the features plugins, artifacts and the content dot jar, which can be copied onto or just shipped as an update site. And you can install this now using your windows or help install your software in Eclipse. The next one is to build an RCP product out of this plugin, right? Which also follows the similar technique with the product configuration file and the P2 director. Sorry. The director plugin which is responsible for generating the application. This was always there in the PD build. It is just that it's gotten Maven feature. So it's just added on here. We're just taking a template project. The only difference that we see from our regular development and here is that for all your bundling projects like feature or for the product, you have to create a separate general project and keep your configuration files inside that. Normally what we do as a normal developer is I keep my product file also within the same application. I don't keep it separated out. But in this case, you have to keep it in a general project outside. The same happens with the feature. The feature contains your category dot XML. Sorry, your update site has to be a general project separated out containing the category dot XML. So if you saw here, the application plugin is still an Eclipse hyphen plugin, right? Because that also has to be shipped like a plugin. Final EXE that I generate is off type Eclipse hyphen repository. So your normal application plugin also is an Eclipse hyphen plugin. He is adding it to the parent form. Updating the child. The same steps again and again. So it becomes quite easy. We're now creating the general project, which will have your product dot configuration file, which would basically help you create your executing already created the dot product file. He's just going to place it there. The only extra step that happens here, which I would want to show you, but after the mavenizing is done. So it's Eclipse hyphen repository again. So for anything that you want to be a feature or a product, the packaging style is still Eclipse hyphen repository. So that doesn't change. You're going to add that to the parent form to get rid of that error in the profile. We're just going to have the multi target support, the multi platform support and the director plugin. So we've got code templates. So we just use the code. So he's added the multi target support here for all the operating systems. And then he goes to the product form file. This is the only difference between the update site and the actual product, including the director. So we give him the steps of converting that into any. So we basically saying use the P2 director product, make a product out of it and then zip it up three steps over here. And then including the target platform in the palm. The two extra steps from feature to product include the multi target stuff if you're interested. So whichever targets you want to generate for you include only those targets. If you're not interested in any other target, you don't have to do that step. And then go to your, the palm, which has the product configuration, right? And then add your P2 director plugin to it and then tell him how to materialize the product and archive the product is running all of that. The first time you run Maven Tyco, it's slow because it has to duplicate the complete repository on the local machine into your M2 folder into your P2 repositories. But once it is done and you're not changing the version, it's quite fast. So it's doing OS by OS, successful build. So now if you go into the product folder and then repress the target, you would see the products, all the zip files, all the EXE is generated, all Linux for Windows for all the platforms that we had included. There's no issue of setting up the delta pack and exporting it and all that stuff. So we take care of downloading what you want. The first time he's heavy because he downloads the whole world, but I still find it more comfortable than me downloading that word because I make mistakes. So that's typically a complete life cycle of the small project. So we develop plugins, we develop features, we sometimes make update sites, sometimes make the, put that into an RCP, make a product out of it. We do not have too much experience on the E4 side of it. I've never done that on the E4 project, but it really definitely works for an E3 project and it's quite successful. And we actually managed to convert a 7-hour build that we used to run on PDE with Maven mixed mode to probably a 2-hour build. And the chances of the build to fail is way more or less where the 7-hour build, if it breaks, we spend at least two to three days trying to figure out what happened because the scripts were written in 2005. And then we're just managing those scripts. And we really convinced our clients saying you have to migrate. We took the effort, we migrated it and we really had fun doing that. We learned a lot of stuff which we haven't showcased here. Handling non-OSGI jars, what happens to them because Tyco is not very friendly with non-OSGI jars. So basically what I mean is any jar that you include in your lips, your exodus jars or SQL connectors or whatever. So there we have a successful build. So I've taken that from somebody's blog. So the next part is, so what we've done is as part of this experience that we were going through, we used to always go to the Maven Tyco ref card and copy the blocks. If I want for the repository or if I want for the director part or if I want for adding the plugins. So what we did was we actually went ahead and contributed a Maven Tyco utility project which took us like about 20 minutes to create just a template. You do control space, you get all your templates. You just change the version numbers and you don't have to buy hearted or copy it from anywhere else. So that's available on Marketplace as Maven Tyco utilities. And most of the code snippet that you require for building your Eclipse products or plugins are available on control space. And we invite more people to add as many as templates to that, which you think is useful for Maven Tyco build. And the next thing is handling non-OSGI jars. Right. So we actually, when we were doing the migration, we had lots of Java jars in our projects and we were reaching out to everybody that we knew was using Maven Tyco. You know, we walked into every other company that was into Maven Tyco and we were trying to figure out how do you do this? I mean, what do you do for the jar? If I have a MySQL connector, how do I tell my Tyco plugin or the Maven Tyco plugin to download it? Right. And then the only answer that we started getting was just commit the jar. That's the easiest way. Don't worry about it because Tyco doesn't support a mixed mode M2P2 repo. Nor does it support a POM based dependency handling. So then they said, just commit the jar. We actually went ahead. We did that first time and then we were still continuously working on how to figure it out. And then we found some workarounds documented by multiple people. We took the best of all of that and try to create our own Maven script which could do it for us. And now we have a script which we will soon put it into the Maven Tyco plugin. So when you do a control space, you get that script where you just change your IDs of the jar that you want to download and it takes care of it. So what we do is we tweak a little bit. I mean, we haven't done any magic here. We just do what Maven typically would do. We download the plugin using some Maven extensions onto the machine and then we do a copy of that into a fixed folder which is already there in my project, which is already added to the build path. So I create a lib folder in my project and just add the lib to my runtime tab in the manifest file and it's empty. But during the build, we copy the jars into it and then we make them available at runtime. And it works. So we really don't know how we made it work. We kept trying many things. It started working. We froze it at that point and it said it works. And we have a script that runs. So that's typically how we handle non-OSGI jars. The first approach is check in the jar itself. But if the jar versions upgrade, then your source control system is going to get heavier because you're going to check in a lot of jars. So the other way around was download and copy them into a specific folder where the folder is already added into your build path in the manifest file. And yeah, the last part. So when we were walking through all the demo, what were we doing? We were mavenizing every artifact that you created. Could be a plugin. Could be a feature. Could be a product. We kept mavenizing it. And then we had to every time go add it to the parent form. Then the maven type of guys came up with the solution of formless build. So they started questioning the system saying, anyways, the manifest file is present in all the projects. It knows all the dependencies. If you claim that he can resolve all the dependencies, then why do you need a palm file in every project that you create? You just need a parent form, which knows which all plugins to build or which all features to build, which all repositories to build. You just run the parent form and it internally takes care of reading through the manifest files, resolving the dependencies and making a build, right? Because the advantage of doing this is if you have a huge project and you want to mavenize it, right? You have to go to every plugin and create a palm file, which is a lot of step, right? And then add it to the parent form, right? But with this, you can actually mavenize your existing projects in a lot more easier manner just by creating a general project, which becomes your root project. And then just adding a palm file there and adding all of these. You don't even need to add, right? The dot maven extension file with the list and then it just runs. We don't have a demo at the moment configured. But yeah, so it's easy and it's very well documented online to at least try it out. So the next things for you to actually go back and look at is how to handle non-OSDI jars and then how to actually use a palm list build for mavenizing your existing projects, so that the effort is less. How much time are we doing? You have? Okay, he's got a palm list, right? Yeah, we have time, yeah. So he has a working set for palm list build. So he can actually show you that, right? So what he's done is he's got a plugin, which is oh, he answered Eclipse demo or plugin one. And then he's got a general project for creating the parent form. And then, okay, in this, yeah, the only step is that the child project should be present inside the parent. Unlike in the other case where you just have to reference them here. The parent project has to contain all your child projects. So he only works on those. And then you have to add them in here and then you just run the form file. So yeah, the major step is to migrate your flat workspace projects into a parent project. So you will have to basically change your locations probably when you create your projects. And then the parent project does not, the child project does not have a form inside it. See, that's the real plug in there. Doesn't have a form. We have all of this documented on our site. All of that we've shown here are available as tutorials. You can have a look at them. The code is also available. So yeah, so this is what we finally understood. Just a last slide to add to this. We did all the hard work, migrated everything. And then finally someone says, maybe Tycho is outdated. Let's move to cradle now. And the managers are always fascinated with terms. They always want to keep migrating to the latest. So yeah, we haven't worked with cradle too much yet. The next thing for you to look at from the build angle is cradle. So we just put a slide on that. So that when you go back, you know, the next stuff that's really picking up in the eclipse world. So we've got some important links here. So all this is available on our GitHub account. The code is there. You can just take the code and this code really works there. All the tutorials are there on our site as whatever screens we've shown here. Right. Then then yeah, the ref card from the Tycho wiki. And then yeah, our Maven Tycho utility is available on the eclipse market place. We've we've got about we've got about close to anywhere between 7500 10,000 downloads for that plugin so far. Right. So and then we've got some more GitHub projects that run. You can actually look at our GitHub account. We've got small utility plugins that we build up for our day to day work. So we've got a pull request plugin for GitHub that you can raise a pull request from your eclipse itself. You don't have to actually go to github.com and raise the pull request. We've got a pull request plugin. Then you've got some Java utilities and things like that. Yeah. And we always invite people to fork it and use it and stuff like that. And you can also contribute to it. Good. So thank you. You have questions. You can ask us questions. We don't have a slide for questions because we are scared of questions. Right. So you can ask us whatever you want. We just go with the connector. We don't manually install it. No. Each like what we saw was each each plugin had its own form. Right. And the parent form had reference to each of them. It had for plugins and for features. So it's more like a test suit that runs all the test cases. It just goes to all the. So building the feature doesn't mean it'll build the plugins also. We don't have to mention it in the because that has nothing to do here. Right. Feature and plugin is more of an eclipse thing for installing. But for the build, they're just independent jobs. You can build the feature separately and build that separately. So it really doesn't require anything in the bomb file. Only the parent needs to know what all you want to build because the basic rule is for Maven actually for him, feature and plugin are all jarred. He doesn't differentiate between them. He doesn't try to understand. He just picks that and tries to do a bit. So he just knows he has to build plugin one plugin to a feature. To build, you need the plugins to be built already. So you already have to build. It's the order that you want to be. You mean convert extract them into a plugin and then include them into. Right. Without extracting them is what we did with the non OS GI jar bundling. Actually. So we have scripts, which is, you know, we keep the jars in one location. We copy it into the plugins. And we don't put them into a rep or anything. We download them through an M2 stuff onto a local machine. Right. And then we move them into the lip folders of whatever project you're interested in. But these lip folders are empty. Okay. You have OS GI jars and we can treat them as the same. Right. Right. He wants OS GI. I have to. I have to. Are different from. They go into people. Or they can use the command line. Reposit. But you don't want to do that. He doesn't want to do that. Yeah. So he just wants to actually create a P2 repo. Right. We actually didn't have that use case, but when we were reading to be actually realize that there are command line utilities, which can generate a P2 repo for you. With all the P2 artifacts that you have. So probably that could be one of the way you'll have to at least do that part to actually generate a repository out of it and include that repository here. But the second question that I always. Does the latest type include the local? Okay. We something that we don't have an answer also is that I don't know if Tyco now supports local repositories. Right. So it always has to point to a server based repository. It doesn't really have support for target platforms or local repository. They've support for target platform. Yeah. Yeah. Now it supports target platform. Correct. That's a successful build from his company. Yeah. Yeah. It's like, it's like, you know, a report. Like what we do in GitHub, right? You create the repository and you keep all your plugins inside it. Right. So the same thing you'll have to do here. Okay. Same plugin. Right. Okay. Basically it should be in the folder where the parent form is. Right. So no, no, he wants to know, should you copy that into the parent? Also, do you have duplicates? Okay. Okay. We've not tried that on formulas, but what we do is we build them independently and then put them onto a P2 site. And then we download it into a third build system which takes it from there and then does the build. So we run two different builds for two, because we have like multiple projects which share the plugin. So we run their independent builds, put them onto a P2 site, which is a local site for us within our organization. And we download that onto a third build actually. Good. So how to integrate with Jenkins. Okay. We actually have a tutorial on how to run Jenkins, but here we actually didn't plan that demo. So we actually didn't start the Jenkins. But yeah, if that, yeah, if we are not running off time, then, you know, I can take this offline also show you this step actually on how it has to be done with Jenkins. Yeah. A 13 step tutorial, which actually tells you how to install and actually configure your parent form in that and then just run the Jenkins. But we also have tutorials on that for what we've not shown on testing your plugin on including a jre version. Right. Sometimes when you make a product, you want to include the jre into it. Right. If it's Windows, some other jre, if it's Linux, some other jre. So we've got tutorials on how to include that. And we've got tutorials on how to include a drop-ins folder. Right. Sometimes you want a drop-ins folder to be part of your product. Right. So how do you do that? It'll always be the same. A free text project. Yeah. Use a Maven build project. And yeah, before that you need to configure your Maven here. And then mention your root form. Yeah. Where is the project? Where is the root? Yeah. But yeah, we can actually show you this. Yeah. All right. So you can, you can, you can. Actually, we've not demonstrated it here, but we have a tutorial which also talks about how to run your unit test cases on it. You can do a multiple stuff on top of it. So thank you very much.