Mave

mave

Getting Started With Maven - A Beginner's Guide to Efficient Java Build Management

Building a CI/CD Pipeline with AWS, K8S, Docker, Ansible, Git, Github, Apache Maven, and Jenkins

AWS, K8S, Docker, Ansible, Git, Github, Apache Maven এবং Jenkins এর সাথে একটি CI/CD পাইপলাইন তৈরি করা

Aufbau einer CI/CD-Pipeline mit AWS, K8S, Docker, Ansible, Git, Github, Apache Maven und Jenkins

Creación de una canalización de CI/CD con AWS, K8S, Docker, Ansible, Git, Github, Apache Maven y Jenkins

Création d'un pipeline CI/CD avec AWS, K8S, Docker, Ansible, Git, Github, Apache Maven et Jenkins

AWS, K8S, Docker, Ansible, Git, Github, Apache Maven और जेनकिंस के साथ CI/CD पाइपलाइन का निर्माण

AWS、K8S、Docker、Ansible、Git、Github、Apache Maven、Jenkins を使用した CI/CD パイプラインの構築

AWS, K8S, Docker, Ansible, Git, Github, Apache Maven 및 Jenkins를 사용하여 CI/CD 파이프라인 구축

Construindo um pipeline de CI/CD com AWS, K8S, Docker, Ansible, Git, Github, Apache Maven e Jenkins

Создание конвейера CI/CD с помощью AWS, K8S, Docker, Ansible, Git, Github, Apache Maven и Jenkins

AWS, K8S, Docker, Ansible, Git, Github, Apache Maven ve Jenkins ile CI/CD İşlem Hattı Oluşturma

Xây dựng quy trình CI/CD với AWS, K8S, Docker, Ansible, Git, Github, Apache Maven và Jenkins

使用 AWS、K8S、Docker、Ansible、Git、Github、Apache Maven 和 Jenkins 构建 CI/CD 管道

I tweet technical content that I consider interesting, but the funny tweets are the ones that get the most engagement. I attended the JavaLand conference in March, stumbled upon the Gradle booth, and found this gem: Of course, at some point, a fanboy hijacked the thread and claimed the In this post, I'd like to shed some light on my stance, so I can direct people to it instead of debunking the same "reasoning" repeatedly. so-called superiority of Gradle. To manage this, I need to get back in time. Software development is a fast-changing field, and much of our understanding is based on personal experience. So here's mine. My first build tool: Ant I started in 2002. At the time, there were no build tools: we compiled and built through the IDE. For the record, I first used Visual Age for Java; then, I moved to Borland JBuilder. developing in Java Building with an IDE has a huge issue: each developer has dedicated settings, so artifact generation depends on the developer-machine combination. Non-repeatable builds are an age-old problem. My first experience with repeatable builds is Apache Ant: Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications. Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications. Ant can also be used effectively to build non Java applications, for instance C or C++ applications. More generally, Ant can be used to pilot any type of process which can be described in terms of targets and tasks. -- https://ant.apache.org/ Ant is based on three main abstractions: A is an atomic unit of work, , to compile Java files, to assemble a Web Archive, etc. Ant provides lots of tasks out-of-the-box but allows adding custom ones. task e.g. javac war A is a list of tasks. target You can define dependencies between tasks, such as depending on . In this regard, you can see Ant as a workflow execution engine. package compile I soon became "fluent" in Ant. As a consultant, I went from company to company, project to project. Initially, I mostly set up Ant, but Ant became more widespread as time passed, and I encountered existing Ant setups. I was consistent in my projects, but other projects were very different from each other. Every time, when arriving at a new project, you had to carefully read the Ant set up to understand the custom build. Moreover, each project's structure was different. Some put their sources in , some in , some in a nested structure, etc. src sources I remember once a generic build file that tried accommodating the whole of an organization's project needs. It defined over 80 targets in over 2,000 lines of XML. It took me a non-trivial amount of time to understand how to use it with help and even more time to be able to tweak it without breaking projects. My second build tool: Maven The above project got me thinking a lot. I wanted to improve the situation as the maintainers had already pushed Ant's limits. At the time, I was working with my friend (of Sonar fame). We talked, and he pointed me to Maven. I had once but had no other prior experience. I studied the documentation for hours, and through trial-and-error attempts, under the tutelage of Freddy, migrated the whole Ant build file to a simple parent POM. Freddy Mallet built a project with Maven In Ant, you'd need to define everything in each project. For example, Ant requires configuring the Java files location for compilation; Maven assumes they are under , though it's possible to override it. Maven did revolutionize the Java build field with its approach. Nowadays, lots of software offer sensible configuration by default. src/main/java Convention over Configuration For developers who go from project to project, as I did, it means there's much less cognitive load when joining a new project. I expect Java sources to be located under . Maven conventions continue beyond the project's structure. They also define the project's lifecycle, from compilation to uploading the artifact in a remote registry, via unit and integration testing. src/main/java Finally, junior developers tend to be oblivious to it, but Maven defined the term . It introduced the idea of artifact registries, where one can download immutable dependencies from and push artifacts to. Before that time, each project had to store dependencies in its dedicated repository. dependency management For the record, there were a couple of stored dependencies on the abovementioned project. When I migrated from Ant to Maven, I had to find the exact dependency version. For most, it was straightforward, as it was in the filename or the JAR's manifest. One, however, had been updated with additional classes. So much for immutability. Maven had a profound influence on all later build tools: they defined themselves in reference to Maven. No build tool of mine: Gradle Gradle's primary claim was to fix Maven's shortcomings, or at least what it perceived as such. While Maven is not exempt from reproach, Gradle assumed the most significant issue was its lack of flexibility. It's a surprising assumption because that was precisely what Maven improved over Ant. Maven projects have similar structures and use the same lifecycle: the in effect. Conversely, Gradle allows customizing nearly every build aspect, including the lifecycle. principle of least surprise Before going to confront the flexibility argument, let me acknowledge two great original Gradle features that Maven implemented afterward: the Gradle daemon and the Gradle wrapper. Maven and Gradle are both Java applications that run on the JVM. Starting a JVM is expensive in terms of time and resources. The benefit is that long-running JVM will optimize the JIT-ed code over time. For short-term tasks, the benefit is zero and even harmful if you take the JVM startup time into account. Gradle came up with the Gradle daemon. When you run Gradle, it will look for a running daemon. If not, it will start a new one. The command-line app will delegate everything to the daemon. As its name implies, the daemon doesn't stop when the command line has finished. The daemon leverages the benefits of the JVM. Chances are that your application will outlive your current build tools. What happens when you need to fix a bug five years from now, only to notice that the project's build tool isn't available online? The idea behind Gradle's wrapper is to keep the exact Gradle version along with the project and just enough code to download the full version over the Internet. As a side-effect, developers don't need to install Gradle locally; all use the same version, avoiding any discrepancy. Debunking Gradle's flexibility Gradle brought the two above great features that Maven integrated, proving that competition is good. Despite this, I still find no benefit of Gradle. I'll try to push the emotional side away. At its beginning, Gradle marketing tried to put down Maven on every possible occasion, published crazy comparison charts, and generally was aggressive in its communication. Let's say this phase lasted far more than would be acceptable for a young company trying to find its place in the market. You could say that Gradle was very Oedipian in its approach: trying to kill its Maven "father.” Finally, after all those years, it seems it has wised up and now "loves Maven.” very Remember that before Maven took over, every Ant project was ad hoc. Maven did put an end to that. It brought law to the World Wild West of custom projects. You can disagree with the law, but it's the law anyway, and everybody needs to stand by it. Maven standards are so entrenched that even though it's possible to override some parameters, , source location, nobody ever does it. e.g. I did experience two symptoms of Gradle's flexibility. I suspect far more exist. Custom lifecycle phases Maven manages integration testing in four phases, run in order: : set up anything the tests need pre-integration-test : execute the tests integration-test : clean up the resources, if any post-integration-test : act upon the results of the tests verify I never used the pre- and post-phases, as each test had a dedicated setup and teardown logic. On the other side, whatsoever. Yet, Gradle fanboys will happily explain that you can add the phases you want. Indeed, Gradle allows lifecycle "customization": you can add as many extra phases into the regular lifecycle as you want. Gradle has no notion of integration tests It's a mess, for each project will need to come up with both the number of phases required and their name: , , , (for the lazy), etc. The options are endless. integration-test integration-tests integration-testing it The snowflake syndrome Maven treats every project as a regular standard project. And if you have specific needs, it's possible to write a plugin for that. Writing a Maven plugin is definitely not fun; hence, you only write one when it's necessary, not just because you have decided that the law doesn't apply to you. Gradle claims that lack of flexibility is an issue; hence, it wants to fix it. I stand by the opposite: lack of flexibility for my build tool is a feature, not a bug. Gradle makes it easy to hack the build. Hence, anybody who thinks their project is a special snowflake and deserves customization will happily do so. Reality check: it's rarely the case; when it is, it's for frameworks, not regular projects. Gradle proponents say that it still offers standards while allowing easy configuration. The heart of the matter is that it's not a standard if it can be changed at anybody's whim. Gradle is the build tool for . In one of the companies I worked for, somebody wrote custom Groovy code in the Gradle build to run Sonar and send the metrics to the internal Sonar instance. There was no out-of-the-box Sonar plugin at the time, or I assume it didn't cut it. So far, so good. de facto Android projects When another team created the company's second Android project, they copy-pasted the first project's structure and the build file. The intelligent thing to do would have been, at this time to make an internal Gradle plugin out of the Sonar-specific code. But they didn't do it because Gradle made it so easy to hack the build. And I, the Gradle-hater, took it upon myself to create the plugin. It could have been a better developer experience, to say the least. Lacking quality documentation and using an untyped language (Groovy), I used the console to print out the objects' structure to progress. Conclusion Competition is good, and Gradle has brought new ideas that Maven integrated, the wrapper and the daemon. However, Gradle is built on the premise that flexibility is good, while my experience has shown me the opposite. Ant was very flexible, and the cognitive load to go from one project to the next was high. We, developers, are human beings: we like to think our projects are different from others. Most of the time, they are not. Customization is only a way to satisfy our ego. Flexible build tools allow us to implement such customization, whether warranted or not. Irrelevant customizations bring no benefit and are easy to develop but expensive to maintain. If managing software assets is part of my responsibilities, I'll always choose stability over flexibility for my build tool. Originally published at on August 6th, 2023 A Java Geek

Is Gradle Really Better Than Maven? - My Final Verdict

গ্রেডল কি সত্যিই মাভেনের চেয়ে ভাল? - আমার চূড়ান্ত রায়

Ist Gradle wirklich besser als Maven? - Mein endgültiges Urteil

¿Es Gradle realmente mejor que Maven? - Mi veredicto final

Gradle est-il vraiment meilleur que Maven ? - Mon verdict final

क्या ग्रैडल वास्तव में मावेन से बेहतर है? - मेरा अंतिम फैसला

Gradle は本当に Maven よりも優れているのでしょうか? - 私の最終判断

Gradle이 Maven보다 정말 나은가요? - 나의 최종 평결

O Gradle é realmente melhor que o Maven? - Meu veredicto final

Gradle Gerçekten Maven'den Daha mı İyi? - Son Kararım

Gradle có thực sự tốt hơn Maven không? - Bản án cuối cùng của tôi

Gradle 真的比 Maven 更好吗？ - 我的最终判决

Build automation is an important aspect of software development. In this article, we will compare the two most popular build tools for Java development: and . Maven Gradle Make and Apache Ant Previously, developers used the Make tool for building Java projects, and the build process was not much different from building applications in any other language. Then in 2000, the (Another Neat Tool) build system was released. Ant Ant, like Make, uses an imperative style, but build scripts have XML syntax. Ant was developed as a build system specialized for Java projects. Ant is a Java-based build automation system and therefore it is much easier for a Java developer to extend its functionality. Maven However, already in 2004, a new Maven build system was proposed, which took a fresh look at the process of building Java applications. Previously, developers themselves organized the folder structure for storing source codes, resources, classpath directories, and output directories. And therefore, the build scripts for Ant for two different applications could be very different: compilation, assembly, copying files to the output directory, etc. were prescribed separately. In Maven, a Java project always has a deliberately defined structure. For example, the source codes should be in src/main/java, the resources for tests in src/test/resources. Maven allows you to create a file structure of a typical project with a single command. Maven also introduces the concept of "build lifecycle" with successive phases: ➞ ➞ ➞ ➞ ➞ ➞ validate compile test package verify install deploy Now, thanks to a fixed folder structure and a set of goals, there is no need to write and maintain a large build script and build scripts have become declarative. It has become more convenient for developers to work not only with their own code but also with third-party projects because it is clear how the source code is organized and how to build it. There are quite a lot of libraries in the Java world, and a serious application uses hundreds of them. When using Ant, you need to add the necessary jar files to the project yourself. You also need to take care of the necessary transitive dependencies. Maven provides dependency manager functionality and Maven Central Repository. Now, when specifying a new dependency in the build script, Maven will automatically find the necessary jar of the appropriate version and all its transitive dependencies, download them, and make sure that they get into the classpath of the project. You can also raise your own closed internal repository, in which you can store your own or patched libraries, or standard libraries built manually. It should be noted that Ant can be used in conjunction with the project, which also allows you to manage dependencies and work with Maven repositories. Apache Ivy Despite all the advantages of Maven, its declarative approach can be a disadvantage in some situations. For example, when you need to change the build lifecycle and add new goals to the build process. Maven allows you to extend its functionality with plugins. There are many ready-made Maven plugins that solve various typical tasks, and these plugins are also available from the central repository. However, if for some reason it is necessary to slightly change the standard lifecycle, and there is no suitable plugin, the developer will have to create his own plugin on his own. Gradle In 2008, the first release of the Gradle build system was released, and version 1.0 was released in 2012. The goal of the Gradle project is to preserve all the advantages of Maven, but also to give the developer more opportunities to customize the build process. That is why Gradle build scripts are written in Groovy DSL. Gradle provides the ability to write declarative build scripts and more compact than Maven because XML is quite cumbersome. It's also easy to add non-standard logic to the build process in Gradle, it's enough to write a Groovy script, and you don't need to develop plugins. At the same time, you can easily debug the execution of build scripts, as they are regular Groovy files. Thus, Gradle combines declarative and imperative approaches. Since version 5.0, Gradle also supports Kotlin DSL. Gradle also supports plugins, which allows developers to exchange ready-made customizations. Also, one of the significant advantages of Gradle is an incremental build. When the assembly is restarted, Gradle determines whether the files that are the input data for the target have changed and if not, the execution of the target is skipped, because its output artifacts have already been collected. This gives a significant increase in build speed compared to Maven, especially on large multi-module projects. Gradle can also run Gradle daemon, a background process that avoids the cost of resources and initialization time each time the build is started. Gradle has a convenient Gradle wrapper feature – it is an opportunity to generate shell and Windows batch scripts that automatically download the Gradle distribution of the specified version and use it to build the project. This means that to build a Gradle project, you do not need to install Gradle separately, just installing Java is enough. And it is also quite easy to switch the project to another version of Gradle. Choosing between Maven and Gradle Despite the advantages of Gradle, quite a lot of projects use the Maven build system. The choice depends on the type of project and team. Maven has been in use since 2004, so more developers are familiar with it. In addition, Maven is stable, the last major version 3 was released in 2010. Gradle has already changed significantly several times without backward compatibility, and developers had to migrate their build scripts to new versions. In addition, not everyone is familiar with Groovy or Kotlin, so using Gradle requires additional knowledge, while Maven uses understandable XML. Therefore, the question arises, if the project began to be developed before Gradle became popular, does it make sense to migrate build scripts to Gradle. On the other hand, more and more developers are choosing Gradle. Spring, Hibernate, and LinkedIn use Gradle. Also, the Android assembly system is Gradle, and it is popular with Android application developers. All popular IDEs have integration with both build systems and support auto-completion when editing build scripts. A huge number of plugins have been developed for both Maven and Gradle, which allow you to add frequently used functions to the project build process. Conclusion From the pros and cons of each of the build systems described above, the following conclusion can be drawn. Maven is more suitable for small projects that do not require customization of the build process, and the build time of the project is not so critical. Gradle is more suitable for large-scale projects with a large number of modules, as well as for Android apps.

Maven vs Gradle: How to Choose the Right Build Tool

Maverick Protocol raises $8 million in funding has raised $8 million in a strategic round of funding. It will use the money to launch its mainnet later this year, bringing its Automated Liquidity Placement mechanism and open asset listing model to market in the process. Maverick Protocol Maverick is being funded by a veritable who’s who of the crypto industry’s biggest VC names, including Pantera Capital, which established the first-ever crypto fund in the U.S. back in 2013, which led the round. Other participants include Altonomy, Circle Ventures, CMT Digital, Coral Ventures, Gemini Frontier Fund, GoldenTree Asset Management, Jump Crypto, LedgerPrime, Spartan Group, Taureon, and Tron Foundation. Maverick is a permissionless derivatives protocol previously operating in stealth mode, which says it’s aiming to revolutionize derivatives trading in DeFi. No serious derivatives trader can do so outside of centralized exchanges such as Binance because the options don’t exist. Whereas most centralized exchanges can offer over 100 derivative trading pairs, most DEXs provide less than 20, focusing exclusively on top tier coins. So it’s impossible to trade mid-cap tokens on perpetual markets. It means DeFi is missing a big opportunity, Maverick says, as more than 50% of the daily trading volume in crypto comes from the derivatives markets. Joey Krug, Co-CIO of Pantera Capital, said: DeFi needs someone to answer the demand for derivatives built on the mid-cap and long-tail assets that are underserved by existing exchanges. Pantera believes Maverick is the protocol to accomplish this. Its innovative market structure is poised to capture a significant chunk of the market by offering low slippage to traders and low-maintenance, capital-efficient staking to LPs. Maverick  will expand derivatives trading to DEXs with the aid of its Gaussian Automated Liquidity Placement vAMM, which is an entirely new mechanism that automates liquidity placement in markets more effectively than other methods. Not only does this mean more capital efficiency for liquidity providers, removing the need to manage their collateral, it also translates to less slippage for traders. ** ** The ALP protocol is based around the idea of capital-efficient, passive staking with high yield for LPs, Maverick says. It will enable open-asset listing, with traders able to stake any ERC20 token as collateral. ** ** Alxin Xu, the co-founder and CEO of Maverick, in an interview with Hackernoon, said: ALP makes it possible for new derivatives markets to be created entirely by the trading community. Up until now, he said perpetual markets have been unable to list most crypto assets due to the intense work need to create sustainable markets. Being a veteran in the crypto industry, you get to see many trends come and go. One thing that still holds true is a trading platform’s value comes from giving people access to the latest and greatest crypto assets. Maverick said the funding comes ahead of the planned launch of its mainnet later this year and that it will now build out its core business and machine learning teams to scale its protocol. It believes there’s a much bigger opportunity than just decentralized derivatives trading, saying its passive staking mechanism could potentially serve as the ideal composable model for dozens of other DeFi use cases. Crypto record-breaking month with nearly $5 billion in investments In January, venture capital funds continued to pour into the crypto business. The roughly $5 billion in additional funds set a new monthly high. Almost 200 crypto businesses received funding in January despite the overall crypto market slump. Bitcoin’s price has fallen from approximately $60,000 in early December to roughly $40,000 now. Despite this, fundraising rounds have continued to grow in size, particularly for later-stage startups. There were 15 mega-rounds of at least $100 million, with Fireblocks raising the most money at $550 million. Pantera Capital’s latest fund has garnered over $1 billion in total commitments. The fund’s initial target of $600 million has almost doubled to over $1 billion. The crypto trading, custody, and financial services sectors garnered the highest money overall. The NFT and gaming verticals also received a lot of money, although they have slowed down recently. VCs were also interested in the crypto infrastructure area. ** ** . Catch all the breaking news, and Don’t forget to like the story! Image credits: and Dylan Tan Hans Eiskonen

Maverick Protocol raises $8 Million from Pantera Capital, Circle Ventures and Altonomy 

NFT Platform Raises Funding to Expand Operations in Asia , a celebrity NFT platform that offers various additional services and experiences, has acquired over $5 million in funding, allowing the team to construct the infrastructure needed to push the NFT world into the mainstream. A customized virtual museum, numerous play-to-earn games, virtual competitions, and the metaverse are available via the authorized celebrity NFT platform. Colexion The global NFT market generated over $23 billion in trading volume in 2021, according to crypto-data analysis platform DappRadar. NFTs quickly bridge the gap between our physical reality and the widely anticipated metaverse. With NFTs becoming more mainstream worldwide, several brands have forayed into the space. Adidas, Nike, Taco Bell, Coca-Cola, and Campbell are some international brands that have entered the industry. Colexion has  become Asia’s biggest NFT platform, drawing the interest of a number of private investors and supporters. The seed round brought in $1.8 million, while a private round brought in $3.2 million. Polygon, Jump Trading Investments, Alan Howard of Brevan Howard, HyperEdge Capital, C2 Ventures, GSR, Oracles Investment Group (OIG), Gains Associate, and a number of other notable names such as ZBS Capital, ICO Pantera, Titan Ventures, Good Games Lab, Maven Capital, and others contributed to both rounds. Several launchpads, including Redkite, Prostarter, Scaleswap, Firestarter, and others, will support the native $CLXN utility coin. The token will be traded on a number of major exchanges. The token and NFTs will also be traded on the built-in marketplace as well as other Tier A exchanges. The platform’s major goal is to license famous NFTs while keeping them accessible to the general public. Major Indian movie stars, international cricket players, and other worldwide sports and movie stars are among the celebrities, with each NFT being unique. The platform has also secured exclusive rights to a number of international cricket teams, Bollywood and Tollywood stars, TV personalities, different global and Indian sports leagues, and other great athletes. The Future of Digital Art and NFTs NFTs have gained widespread awareness due to large art transactions, which now account for about a quarter of all NFT sales. For example, an American artist known as Beeple sold his digital artwork for $69.3 million at Christie’s earlier this month, putting him among the “top three most valuable living painters.” Every time the owner of the NFT changes, he will earn a ten percent royalty. Winkelmann’s success in the digital world is undoubtedly not unique. CryptoPunk #7804, one of the 24x24 pixel art pieces, sold for $7.5 million in March, while TrevorJones” Bitcoin Angel sold for $3.2 million. In 2022, the NFT market is expected to grow even further. Like any other sector, it has its own set of hazards that purchasers should be aware of before investing. However, when it comes to art, it’s necessary to look at the item first – and then at its properties – because possessing something you don’t like has little value. Catch all the breaking news, and Don’t forget to like the story!

Colexion a Celebrity NFT Platform Raises $5 Million from Polygon, Titan Ventures and Maven Capital

Normally, when you start a project, you set your required dependencies up with the latest stable versions of all libraries and plugins. Then time goes by, the project grows, and new features and libraries are added. But the versions of the 3rd-party dependencies and the plugins remain the same; the team never updates them. Now, that’s all fine and dandy until… there׳s a conflict. If each team has its own repository, how can dependencies be managed and conflict frequency reduced? What is dependency conflict The dependency issue arises when libraries have same dependencies (internal / 3rd-party) with different versions, the library can only be installed with a single version, thus causing version conflict. Conflicting versions of 3rd-party libraries known as well as our own- appearing in production as ‘NoSuchMethodError’ or ‘ClassNotFoundError’. Repository Structure Some time back at Outbrain, we had made a transition from one big mono-repo to a multi-repo approach that required all teams to manage their dependencies by themselves, reducing visibility and control of the dependencies among multi-repos. Unfortunately, this gave rise to dependency conflicts caused by conflicting versions of 3rd-party libraries. (To read more about Outbrain’s approach to repository structures and version conflicts, check out “ Mono-repo vs Multi-repo vs Hybrid: What’s the Right Approach? ’’ After some deliberation on how to proceed, we decided on a hybrid approach: We have that is responsible for keeping internal shared libraries, versions of 3rd-party dependencies, and APIs among teams and that can be released and managed by a specific version. The teams, however, each use their own for a service code that uses library API’s, which are managed by a property version that was part of the mono-repo release process. one mono-repo multi-repos So, to use the latest internal API, we just need to upgrade specific property versions in the multi-repos. Can 3rd-party dependencies be upgraded just as easily? Yes! Centralized Dependency Management The mono-repos should reduce the frequency of dependency conflicts since we have one place with a repo that manages all dependencies. All the internal shared libraries are compiled and released with the same dependencies because they are all defined under the same pom.xml (the parent pom.xml). How is Conflict Frequency Reduced? The mono-repo has a module called “service-pom” with only one pom.xml file that contains the common plugin definitions and all the 3rd-party versions for all the deployable services. The service repos (multi-repos) must be inherited from the service-pom. In other words, the entire service-repo gets all the relevant properties from one place- the . This service-pom is released with a specific version as part of the mono-repo release process. centralized dependency management Pom Hierarchy in the Mono-repo This repo contains all our shared libraries. As part of this repository, we have modules with a structured pom hierarchy for pom’s that are part of the mono-repo release process. A Drill Down into the POM Hierarchy The service-pom This service-pom module contains only one pom.xml and is meant to be used as a parent pom for all service repos. In the image below, we can see how a service pom looks. <project>
  <parent>
    <groupId>com.outbrain</groupId>
    <artifactId>version-pom</artifactId>
    <relativePath>../version-pom</relativePath>
    <version>${revision}</version>
  </parent>
  <groupId>com.outbrain</groupId>
  <artifactId>service-pom</artifactId>
  <name>Common to all services</name>
  <version>${revision}</version>
  
 <build>
        <pluginManagement>
          <plugins>
            ...more...
          </plugins>
         </pluginManagement>
 </build>
</project> The version-pom This pom aggregates all the 3rd-party versions that we use. Below, we can see how the 3rd-party definitions are organized. <project>
  <groupId>com.outbrain</groupId>
  <artifactId>version-pom</artifactId>
  <version>${revision}</version>
  
  <properties>
    <revision>5.0.0</revision>
    <libs.version>${revision}</libs.version>
    <log4j2.version>2.17.0</log4j2.version>
    ...more...
    ...more...
  </properties>

    <dependencyManagement>
    <dependencies>
      
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>${log4j2.version}</version>
      </dependency>
     ...more...
     ...more...
    </dependencyManagement>
    </dependencies>  
</project> The module-pom This pom aggregates all the needs of mono-repo modules and is used as a . ּּּּּּּBelow is a layout of the internal-library definitions. bom pom <project>
  <parent>
    <groupId>com.outbrain</groupId>
    <artifactId>version-pom</artifactId>
    <relativePath>../version-pom</relativePath>
    <version>${revision}</version>
  </parent>
  <groupId>com.outbrain</groupId>
  <artifactId>modules-pom</artifactId>
  <version>${revision}</version>
  
 <dependencyManagement>
    <dependencies>
      
      <dependency>
        <groupId>com.outbrain</groupId>
        <artifactId>mono-repo-lib1</artifactId>
        <version>${libs.version}</version>
      </dependency>
      <dependency>
        <groupId>com.outbrain</groupId>
        <artifactId>mono-repo-lib2</artifactId>
        <version>${libs.version}</version>
      </dependency>
     ...more...
     ...more...
    </dependencyManagement>
    </dependencies>  
</project> Service-repos All service repositories' repo projects must: inherit from the service-pom, and add modules-pom as a bom dependency In the code block below, we have service-repo pom.xml definitions. <project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.outbrain</groupId>
    <artifactId>service-pom</artifactId>
    <version>2.0.0</version>
  </parent>
  <artifactId>service-repo-one</artifactId>
   ...
  <dependencies>
    <dependency>
        <groupId>com.outbrain</groupId>
        <artifactId>modules-pom</artifactId>
        <version>${bom.revision}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    .....
  </dependencies>
</project> As mentioned earlier, the service-pom that was released and managed by the version contains all the 3rd-party dependencies with the specific versions, since all our service-repos inherit from the service-pom Now, to upgrade 3rd-party dependencies, we can work in the mono-repo (simultaneously upgrading multiple dependencies, which will be released and managed by only one version as part of the mono-repo release process). Consequently, we can upgrade the service-pom across all the multiple repos at once. (as is shown in the image above). Upgrade Multiple Dependencies, by Managing One Version As mentioned earlier, the mono-repo can be released multiple times a day and contain the code changes of shared libraries and/or multiple 3rd-party upgrades, with all these changes being released into one version. So, all we need to update is the service-pom version across all our multi-repos. Manual Upgrades? Who Needs Them? We have an automatic tool called “Bumper” that, at a fixed frequency, upgrades and creates pull requests across all service repos with the latest version of the released version, and then merges them. Afterward, the services are automatically deployed with CI/CD pipelines. When we needed to tackle the for example, the centralized dependency management and the bumper tool took care of everything. Log4j Vulnerabilities, Got 200 repositories to update? Just head to the break room while the maven-centralized dependency management and bumper tool does it all for you.

Keeping Dependencies Up To Date with Maven-Centralized Dependency Management

What is Maven? Maven is a platform that enables instructors to launch and run their cohort-based classes successfully. Cohort Based Classes are virtual versions of regular classes in real life. The last decade of learning on the internet was auto-didactic. Anyone who wanted to learn something went through a series of noninteractive blogs and videos. Cohort Based Courses are 4-8 Weeks courses where instructors teach to a live set of students . Its virtualization of the real-world classes. virtually The simplest way to think about Maven is its Shopify for Cohort Based Courses. Currently, Maven is enabling the courses taught by , Anthony Pompliano, Sahil Bloom & Others. Li Jin Business Model: Maven earns revenue by charging a percentage from the income a course generates. This percentage is not well defined yet. It is most probably course to course basis for now as the product and the company are at a very early stage. In the future, the model could evolve to something like a Shopify subscription where the initial basic version of platform tools are priced at a monthly subscription cost with richer features at a premium offering. The course runners can choose which one they need based on the scale and requirements of the course they are launching and overtime scale appropriately as we have seen in the case of Shopify merchants. Positives: Maven has been smart about its go-to-market strategy. Their first 4 instructors have all built an authority and following on subjects that are not taught in any university class. By bringing these four instructors onboard gave Maven the advantage to reach more consumers (who are audiences of instructors) and at the same time learn from the courses themselves to what the platform will look like. It also proved the thesis that there are subjects in 2021 that people want to learn but have no good ways to go about it. Go To Market Strategy: ( , Li Jin, & Lenny Rachitsky) Anthony Pompliano Sahil Lavingia Having the ability to raise from well-known angel investors like , Maven did a crowdfunding raise for ~700k USD. This was interesting because crowdfunding is increasingly making more sense for certain types of companies. Maven by doing a crowdfunding campaign acquires a new consumer & supporter base who can contribute to the early product evolution. Crowdfunding: Not a lot of Startups who have access to capital from the traditional VC ecosystem do crowdfunding, especially if the founding team has built successful companies before. Naval Ravikant & Jason Calacanis This is the reason Crowdfunding can be called “negative customer acquisition”. Not only does the company not have to pay for this user base, it actually receives investment from this pool of user base making them more invested in the success of the product and the company. I have previously written about crowdfunding here, while Maven was actively fundraising. Check it out if you are interested in crowdfunding. Challenges: The Internet increases the distribution ability of any creator. Ideally, if anyone is looking to learn a new subject they must be able to learn it from the best teacher of that subject in the world irrespective of their location. Internet theoretically allows for this possibility. This is definitely an expanding market as skills in the new economy are more specialized and more people are getting access to the Internet leverage. It will be interesting to see how large this market can become. Market Size: The question is if there are in theory enough course, subject & instructor combinations to make Maven a platform where these best courses are launched, a $1B business? There are interesting players that are already helping Cohort Based Courses. Competition: (Acquired by HotMart) has already created a Thinkific, LearnWorlds, G2 Deals, TalentLMS, Kajabi & Udemy Business are attempting to create similar products. Teachable “Shopify for teachers of all kinds”. which recently raised $25M at a $250M valuation has scaled its courses very effectively by using a couple of different tools and not building any proprietary platform. They have mainly used Zoom & Slack to effectively create and scale the largest Cohort-based company. is another example of the same. What level of efficiency will the platform achieve for the course creators? Will it be 5x, 10x, or 100x better than the combination of different tools? These are the questions that the Maven product has to overcome and would be interesting to see as their product becomes public. That is all for this edition of BMB, don’t forget to share this post on Twitter, Facebook, and elsewhere. If you have suggestions for a BMB post, you can reach out to me on Twitter. Technology: OnDeck Product School Another yet-to-be-proven idea with maven is what would a platform exclusively built keeping Cohort-based courses in mind can do that current combination of tools cant do? 🚀 That is all for this edition of business model breakdowns. If you have suggestions for a business model breakdown post, you can reach out to me on For more such breakdowns follow my newsletter. Twitter. Also published on: https://www.getrevue.co/profile/bmb/issues/2-bmb-snackable-business-model-breakdowns-maven-com-747083

Snackable Business Model Breakdowns - Maven.com

Indian Startup ecosystems are growing exponentially. The demand for IT services is increasing year after year. India is the leading sourcing destination of the world capturing approximately 55 percent market share of the global services sourcing business in 2019-20. US$ 200-250 billion IT industry’s revenue is estimated to be around in FY20, growing at y-o-y and it is estimated to reach by 2025. But the grass is not as green as it looks like. US$ 191 billion 7.7 percent US$ 350 billion Most of the IT companies are not able to deliver the latest technology-driven services, enhancing the customer experience. Delivering the projects on time and meeting the expectation of the client is still the biggest challenge for a number of IT companies. That is where Maven Cluster comes into play Maven Cluster is constantly working to meet the technical requirements of international standards focusing on enhancing the experience of the clients across the globe. Who are you? I am Faheem Hasan, a hardcore Techie. I started my journey as a 15-year-old kid who was curious and fascinated by the world of technology. I started reading about designing and building websites from a young age. I had my first experience of working on live projects along with meeting the expectation of clients during my third year of engineering. By delivering Final Year projects to college students, I made my first source of income. Trying hands on a couple of things in college time, I joined as an unpaid intern in an IT company after college, along with working part-time on a few projects to fill up my pocket. After 6 months, I joined a small IT company in the night shift to understand the market of the USA. But after some time the company closed, as the founder joined some other venture. At this point, I had a decent amount of money in my savings and I requested the founder to sell the Computer PC’s to me. Then I hired a few people and set up my own venture; it was the start of my custom software development company in India. After a journey full of ups and downs and almost having no projects a number of times, the struggle of more than 10 years paid off and Maven Cluster became a bootstrapped profitable and a leading IT firm in the Indian ecosystem. What motivated you to start Maven Cluster? When I was in college, I saw the potential of the Coders. They are extremely talented and hardworking, yet most of them were not able to get a decent job. Such incidents triggered me to start my own venture because there is a lot of untapped and underappreciated talent that lies in the Tier II and Tier III cities. It's always a great feeling when, in a country like India where the unemployment rate is so high, you are someone who is helping people and their families to get a secure future. Also throughout my experience of working in various IT firms, I have realized that firms are not able to meet the client’s expectations. Though having a country of such talented people, we are not making a good name in the international market by ruining a client’s experience. It also became a major reason for me to take a bold step towards my path of entrepreneurship How did you get the initial Clients? I got my first client from my network. I think it is a big lesson for budding entrepreneurs to build up a strong network by attending various networking events and startup communities. I had built a good relationship with my networking professionals who had the same level of connections. People around you shape your ideology and approach towards things. My network helped me in team building, acquiring new clients, and much more. Working in various firms and places was an added advantage for me as it helped me to add various people in my domain making my network even stronger. And most of the time it's a matter of the first few clients. After that, your business starts flourishing through referrals if you and your team are dedicated to deliver a good experience to your clients and meet their expectations. What is your business model? Maven Cluster is a full-fledged IT Company and the business model is similar to any IT Company. We majorly work with enterprises, startups, and small business owners who are looking towards technology with hope. Our team ensures that we stand unique as a custom software development company. We started with fewer projects and average monthly revenue of around $10,000 but as we focused on team building and quality of products, we were able to deliver world-class products. Within 3 years of our startup, we were achieving revenue of . $60,000 monthly So, What’s the difference between Maven Cluster to other Software Development Companies? So, first of all, you can see us as a Software Development Solutions Provider. We have comprehensive services in Software Development, Web Development, or Web Solutions. We have a very strong point as a Customer Retention percentage. It’s more than and that is just because of our dedication and commitment to our values. We serve our customers with a result-oriented vision and that makes us different from others as a Software Development Services Provider. 95% How did you go about building your team? A good team is not like a family, it's like a sports team, always ready for challenges and winning the game at any cost. Initially, I have started by roping in some of the Techies in my network by convincing them to work with me. We started working initially on some small budget projects. We were working day and night delivering the projects on time to meet our clients' expectations without thinking much about business expansion. The reason is to achieve stability in this small company. The technical team was strong but the business side was still something to work upon. After making a part of the company stable which was probing in regular profits, I thought it's time to scale. I wanted someone on the IT sales side who can help me in handling the sales side. Then I met , who was an ace in IT sales. After a couple of meetings with him, I realized I met the CEO of my company. I convinced Shawez to join Maven Cluster and as we shared the same vision, he agreed to join as the CEO. Shawez Sheikh After Shawez joined the company, we saw exponential growth and now I don’t have to worry about the sales side. As a Software Development Company, now we are eyeing global expansion of our teams. Recently, a year before we opened our office in Melbourne, Australia. That made us a globally operating company. We don’t want to stop our-self at any moment and very soon, there will be another office opening in Chicago. It feels very good. What are your future goals and how do you plan to achieve them? As I said, we are constantly growing and exploring new domains, new verticals in every new quarter. That means we are also evolving into something big and new every day. We started providing software development services but now we have much more to offer in our bucket of services. In the future, we are eyeing to be a leader in hot technologies like Artificial Intelligence and Machine Learnings. Also, the field of Big Data is also very exciting. So, it depends on which vertical our clients take us and which product excites the team. We are quite open and ready for any change. What is your advice to Pushstarters starting out? - Start experimenting from a young age and don't be afraid to fail. You never know what can work for you and when. - Your team is the reason for the growth or decline of your organization. Be true to them and build a team that is ready to take challenges with you. This is the secret of sure growth. Always build the team with the same vision and mindset as your organization. - Life is too short to have a secure future, believe in yourselves, and take bold decisions. Those who eye a safe future often end up inside in the zone of average people. - Never lose hope, every other day you will have setbacks but don’t give up, come back stronger and conquer. - Patience is your ultimate shield in this battlefield of a startup. Don’t ever lose the shield if you don't want to die on the battlefield. How can we get in touch with you? Well, I am all accessible from top social media platforms and emails too. Preferably, I am active on . Linkedin

An Interview With The Founder of Maven Cluster: How Faheem Hasan Turned The Business Profitable

A central aspect of Java's philosophy is that . names matter Brian Goetz, Java Language Architect and author of Java Concurrency in Practice Packages If you work for "acme.com" and you're working on a project called "foo" then is for your root package to be . the convention com.acme.foo Being a , we tend to add lots of "grouping" packages. Our foo project is a utility library, and we might make other ones, so we put it into , to make sure there is space for other utility projects. If we're really forward-looking, we'll take into account that foo is a utility library for manipulating text, so we better put it into . On the other hand, . forward-looking bunch com.acme.util.foo com.acme.util.text.foo YAGNI In the javascript world, there are no packages, you just get one name - - and that's it. I'm glad that I do most of my work on the JVM rather than a runtime which was , but whenever I start nesting my root package deeper than , I try to remember that all those gobs of software being written in Node.js are getting by without any nesting at all, so maybe I can get by with 3 or 4 levels of nesting for my root package, rather than 5 or 6. foo designed and built in 10 days com.acme.foo Maven groupId:artifactId One nice thing about files is that you don't have to pick names for them - they get their name automatically from a 1:1 mapping on the file they came from. Unfortunately, maven asks you to pick names, so it can't be that simple. Luckily, maven also provides not only , but slightly different conventions for how to pick these names! .class .java two one two Accordingly, if you ask , you'll see two popular answers. And when a major library like RxJava ships a new version, you'll need a to figure out what the names ought to be. StackOverflow 12-screen-long debate Luckily, there is a mechanistic answer out there! JitPack turns any git commit into a maven artifact at , which I've found to be huge improvement over for integration testing. The naming convention that it uses is: https://jitpack.io -SNAPSHOT (also , , and ) com.github.{user}:{repo} com.gitlab org.bitbucket com.gitee for multi-module builds com.github.{user}.{repo}:{subproject} If you use JitPack's integration, then you can replace with com.acme for a professional touch. Even if you don't use JitPack, using this convention will mean that you , and it lays down a simple rule that works well enough for . custom domain com.github.{user} could all these people Gradle plugin id In Gradle-land, you can apply a plugin like this: . plugins { id 'any.plugin.id.you.want' } Gradle provides an excellent : guideline As a convention, we recommend you use an ID based on the reverse-domain pattern used for Java packages, for example org.example.greeting. The trouble is, a huge number of the plugins which have been published so far are named... . It seems reasonable while you're the plugin, and you don't realize how silly it is until you it from a distance: gradle-plugin writing use plugins {
    id id id } 'com.acme.gradle.foo' 'org.nonprofit.bar.bar-gradle-plugin' 'beetlejuice.beetlejuice.gradle' What kind of car is that? That's the Chevy Corvette Car. What kind of phone is that? It's an iPhone XS Phone. Wouldn't this be better? plugins {
    id id id } 'com.acme.foo' 'org.nonprofit.bar' 'beetlejuice' It's interesting, because the guidelines that Gradle gives are very good - no excessive nesting, no unnecessary , just the bare minimum. And yet, a lot of the people who it feel like they should add a or two, just in case. Probably the only way to save us from ourselves would be for the gradle tooling to search for in the id and throw a warning, to help us think about it a little before we publish. gradle.gradle use gradle gradle Lessons Designing namespaces is a rare opportunity. Most of us never do it even once in our entire career. And since nobody has experience in it, we're still making lots of beginner mistakes, even in the quarter-century-old world of java. It's hard! Typosquatting, , there are so many pitfalls. If I ever end up defining a namespace, I'm gonna try to remember these lessons: IDN homograph attacks namespaces are helpful for identifying the author/maintainer: com.acme.foo 👍 namespaces are overkill for fine-grained categories: com.acme.util.text.foo 👎 defining the name to be a tuple of two other names is 👎 if the names are all plugins to foobar, people are just gonna name them my-foobar-plugin, and it might be good to warn them ¯\_(ツ)_/¯ Previously published at https://dev.to/nedtwigg/names-in-java-maven-and-gradle-2fm2

Naming Conventions in Java, Maven and Gradle

Stories, News & Mentions about MAVE

Mave’s Stories on HackerNoon