I was thinking of building a tool through which we can have Named Parameters in Java 8+. I am looking for approaches on how to move forward with this. Here's what I have thought of so far,
Writing a compiler plugin which rewrites the method arranging and matching the parameters. In case it is not able to do so, it will throw a well defined exception. Caveat is I would also need to write extensions for IDEs so it does not show as a compile error in IDE.
Writing a buildscript which does the same as above, but does it pre-compilation. We still have the same problem as above and on top, I would have to write for multiple build systems.
Use AOP and use #Named annotations to specify names. IntelliJ and Eclipse both support aop compilers so IDE support should not be an issue. However this adds an extra overhead of adding AOP framework as a dependency.
There might also be some way to leverage Kotlin over here, but I am still exploring that.Looking forward to some ideas that I am completely unaware of as well as feasibility of what I have suggested.
I am not sure if opening a JEP would help as a proposal in 2015 was shot down.
FYI, I am not looking for answers/comments like why not switch to Kotlin. The point of this question is to know how feasible it is to implement this in Java, without changing the JDK itself.
I'm creating some rules to SonarQube where it will analyze a Android Project and raise some Security vulnerabilityes points on code.
I've already created a custom rule by Sonar Tutorial to create my own rules following the same structure, but I had some complications. For instance, when I tryed to run the test classes, I've found some problems to identify Android Classes and validate my rule, and after some research, I solved the problem, but seems like when I put my plugin on SonarQube and run it, the problem remains with the tool not identifying Android Classes (I coudn't comprove this because coudn't find a way to debug the web tool and see why the Rule is not checking).
By this, I need to know if I'm really doing this of the right way. Analyze with custom rules a Android Project directly by SonarQube can be done just following the Sonar Tutorial? Do I need of custom configurations inside my template or any other step to do it?
If beyond the answer or the instruction, someone could provide some documentation to help me, I would be deeply grateful.
Since now, thanks for your attention!
I am sure this is a very basic but important question, answer to which i dont know.
I want to know the answer because i spent several days and nights trying to fix the problems arising in my projects due to version problems in Maven artifacts. First i had problem integrating struts + hibernate. Now with SPRING+HIBERNATE. When i take a sample working project as base, it works fine.
But when in a zealous attempt, i updated the pom.xml with all the latest versions of dependencies, i get plenty of errors, and i try to fix them one by one and end up adding more dependencies/jars in the process which i think leads to the problem. But why it leads to problem, i am not sure. But for now, i have reverted to the original working (but older) versions of dependencies in pom.xml and everything has started working fine.
My question is In Maven project will adding the latest versions of dependencies guarantee a trouble free project??
My experience in Maven is not much. I have only experience in importing projects/changing dependencies.
Or is creating projects through Maven from scratch a panacea to my problems?(in which i dont have much experience)
Simply using the most recent versions of dependencies will not necessarily guarantee a trouble free project. If you are going to include a dependency that requires integration with another dependency, you will usually need to do some research before you determine what version to include. For example, if you had a Spring 3.0+ dependency in your pom.xml and you were going to add a version of Hibernate that works correctly with Spring, you could go to the Spring documentation (http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/orm.html#orm-hibernate) and read about what versions of Hibernate will work with that version of Spring. Typically if a framework like Spring takes the time to provide integration with another framework like Hibernate, they will include documentation detailing what versions of the framework will correctly interact with the other framework.
I was wondering about this. I'm planning to employ jackrabbit in a ECM project and it seems that OCM is dying or what, it is a different fork that the rest of the project. In maven repos there are old jackrabbit-ocm-nodemanagement jackrabbit-ocm versions, otherwise the project itself is downloadable via a referenced zip archive in reference documentation.
org.springmodules.jcr didn't make it to the official spring source base. It got abandoned. Even though it was a great glue for jackrabbit OCM and the project looks great. I absolutely don't understand why they decided to leave such an important specification !?!?!?
It currently resides here as some sort of conservation.
Also there is a jcr spring extension that the same thing I suppose. It has its Jira section, but everything seems abandoned to me. If I got into problems with some nasty bug, any support wouldn't get to me.
Please if you have brighter information than I do, let me know.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What are the main benefits of using maven compared to let's say ant ?
It seems to be more of a annoyance than a helpful tool.
I use maven 2, with plain Eclipse Java EE (no m2eclipse), and tomcat.
Supporters of maven believe that
Maven lets you get your package dependencies easily
Maven forces you to have a standard directory structure
In my experience
Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.
Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.
Or am I just doing it wrong ? Please point me to the right direction, I'm all ears.
Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.
Not that hard... for toy projects. But the projects I work on have many, really many, of them, and I'm very glad to get them transitively, to have a standardized naming scheme for them. Managing all this manually by hand would be a nightmare.
And yes, sometimes you have to work on the convergence of dependencies. But think about it twice, this is not inherent to Maven, this is inherent to any system using dependencies (and I am talking about Java dependencies in general here).
So with Ant, you have to do the same work except that you have to do everything manually: grabbing some version of project A and its dependencies, grabbing some version of project B and its dependencies, figuring out yourself what exact versions they use, checking that they don't overlap, checking that they are not incompatible, etc. Welcome to hell.
On the other hand, Maven supports dependency management and will retrieve them transitively for me and gives me the tooling I need to manage the complexity inherent to dependency management: I can analyze a dependency tree, control the versions used in transitive dependencies, exclude some of them if required, control the converge across modules, etc. There is no magic. But at least you have support.
And don't forget that dependency management is only a small part of what Maven offers, there is much more (not even mentioning the other tools that integrates nicely with Maven, e.g. Sonar).
Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.
First, why do you use Maven like this? I don't. I use my IDE to write tests, code until they pass, refactor, deploy, hot deploy and run a local Maven build when I'm done, before to commit, to make sure I will not break the continuous build.
Second, I'm not sure using Ant would make things much better. And to my experience, modular Maven builds using binary dependencies gives me faster build time than typical monolithic Ant builds. Anyway, have a look at Maven Shell for a ready to (re)use Maven environment (which is awesome by the way).
So at end, and I'm sorry to say so, it's not really Maven that is killing your productivity, it's you misusing your tools. And if you're not happy with it, well, what can I say, don't use it. Personally, I'm using Maven since 2003 and I never looked back.
Maven can be considered as complete project development tool not just build tool like Ant.
You should use Eclipse IDE with maven plugin to fix all your problems.
Here are few advantages of Maven, quoted from the Benefits of using Maven page:
Henning
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to
centralized POM.
getting a number of reports and metrics for a project "for free"
reduce the size of source distributions, because jars can be
pulled from a central location
Emmanuel Venisse
a lot of goals are available so it isn't necessary to develop some
specific build process part contrary
to ANT we can reuse existing ANT tasks
in build process with antrun plugin
Jesse Mcconnell
Promotes modular design of code. by making it simple to manage mulitple
projects it allows the design to be
laid out into muliple logical parts,
weaving these parts together through
the use of dependency tracking in pom
files.
Enforces modular design of code. it is easy to pay lipservice to modular
code, but when the code is in seperate
compiling projects it is impossible to
cross pollinate references between
modules of code unless you
specifically allow for it in your
dependency management... there is no
'I'll just do this now and fix it
later' implementations.
Dependency Management is clearly declared. with the dependency
management mechanism you have to try
to screw up your jar
versioning...there is none of the
classic problem of 'which version of
this vendor jar is this?' And setting
it up on an existing project rips the
top off of the existing mess if it
exists when you are forced to make
'unknown' versions in your repository
to get things up and running...that or
lie to yourself that you know the
actual version of ABC.jar.
strong typed life cycle there is a strong defined lifecycle that a
software system goes thru from the
initiation of a build to the end...
and the users are allowed to mix and
match their system to the lifecycle
instead of cobble together their own
lifecycle.. this has the additional
benefit of allowing people to move
from one project to another and speak
using the same vocabulary in terms of
software building
Vincent Massol
Greater momentum: Ant is now legacy and not moving fast ahead. Maven is
forging ahead fast and there's a
potential of having lots of high-value
tools around Maven (CI, Dashboard
project, IDE integration, etc).
Figuring out dependencies for small projects is not hard. But once you start dealing with a dependency tree with hundreds of dependencies, things can easily get out of hand. (I'm speaking from experience here ...)
The other point is that if you use an IDE with incremental compilation and Maven support (like Eclipse + m2eclipse), then you should be able to set up edit/compile/hot deploy and test.
I personally don't do this because I've come to distrust this mode of development due to bad experiences in the past (pre Maven). Perhaps someone can comment on whether this actually works with Eclipse + m2eclipse.
Maven is one of the tools where you need to actually decide up front that you like it and want to use it, since you will spend quite some time learning it, and having made said decision once and for all will allow you to skip all kinds of doubt while learning (because you like it and want to use it)!
The strong conventions help in many places - like Hudson that can do wonders with Maven projects - but it may be hard to see initially.
edit: As of 2016 Maven is the only Java build tool where all three major IDEs can use the sources out of the box. In other words, using maven makes your build IDE-agnostic. This allows for e.g. using Netbeans profiling even if you normally work In eclipse
Maven advantages over ant are quite a few. I try to summarize them here.
Convention over Configuration
Maven uses a distinctive approach for the project layout and startup, that makes easy to just jump in a project. Usually it only takes the checkount and the maven command to get the artifacts of the project.
Project Modularization
Project conventions suggest (or better, force) the developer to modularize the project. Instead of a monolithic project you are often forced to divide your project in smaller sub components, which make it easier debug and manage the overall project structure
Dependency Management and Project Lifecycle
Overall, with a good SCM configuration and an internal repository, the dependency management is quite easy, and you are again forced to think in terms of Project Lifecycle - component versions, release management and so on. A little more complex than the ant something, but again, an improvement in quality of the project.
What is wrong with maven?
Maven is not easy. The build cycle (what gets done and when) is not so clear within the POM. Also, some issue arise with the quality of components and missing dependencies in public repositories.
The best approach (to me) is to have an internal repository for caching (and keeping) dependencies around, and to apply to release management of components. For projects bigger than the sample projects in a book, you will thank maven before or after
Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success. For a more detailed look at how Maven can help you with your development process please refer to The Benefits of Using Maven.
Maven is a powerful project management tool that is based on POM (project object model). It is used for projects build, dependency and documentation.
It simplifies the build process like ANT. But it is too much advanced than ANT.
Maven helps to manage-
Builds,Documentation,Reporing,SCMs,Releases,Distribution.
- maven repository is a directory of packaged JAR file with pom.xml file. Maven searches for dependencies in the repositories.
I've never come across point 2? Can you explain why you think this affects deployment in any way. If anything maven allows you to structure your projects in a modularised way that actually allows hot fixes for bugs in a particular tier, and allows independent development of an API from the remainder of the project for example.
It is possible that you are trying to cram everything into a single module, in which case the problem isn't really maven at all, but the way you are using it.
This should have been a comment, but it wasn't fitting in a comment length, so I posted it as an answer.
All the benefits mentioned in other answers are achievable by simpler means than using maven. If, for-example, you are new to a project, you'll anyway spend more time creating project architecture, joining components, coding than downloading jars and copying them to lib folder. If you are experienced in your domain, then you already know how to start off the project with what libraries. I don't see any benefit of using maven, especially when it poses a lot of problems while automatically doing the "dependency management".
I only have intermediate level knowledge of maven, but I tell you, I have done large projects(like ERPs) without using maven.