> > MAVEN REPOSITORY AS ONLY SOURCE OF DEPENDENCIES
I don't see the big issue here , as others have pointed out you can solve this with a system scope. On the other hand, setting up your own repository is actually very simple and gives a lot of advantages (like proper version tracking of the dependencies etc) > ORDER OF TASKS > I do agree that the logic of maven is sometimes unclear in this regard (and others), however this is a type of problem common to many tools. Also, as others have said, a simple antun task solves your example problem quite nicely. > TOO SLOW Yes, if you use it in the way you described then I agree that it will be slow. On the other hand, if you use a sensible IDE like Eclipse or Netbeans, the test cycle you describe will be MUCH shorter than ANY build tool! (you never have to build just to test run) If you don't want to use these nice IDE:s, then you really want to do it in your specific way and then I definitely think maven is a bad pick for you. We use Eclipse and then maven is simply the build tool when we run a FULL build, either manually or in the build server. > SECURITY CONCERNS > > for every artifact Maven wants to download or update. So a malicious > repository could introduce malicious artifacts into my local repository, > affecting all my other projects as well. Well, if you use the public repositories directly then you decide to trust them and then I guess you have to accept that. One option I guess is to set up your own repository as the ONLY repository and them set it to mirror the central repositories selectively. Nexus has a lot of configuration options regarding this at least. Naturally this would require some work, but if you want to use open-source components in your code, then you will have this problem anyway and either have to accept it or manually manage and validate your repository . > JNI ISSUES > > In some cases I use libraries which employ JNI, or write JNI code > myself. Mavens lack of cross-compiler support severely limits the > development of JNI builds. Installing third party JNI artifacts in the > repository in such a way that they can be loaded seems difficult work at > best, if possible at all. Probably native libs would have to be copied > to some library dir from where they could be loaded. The fact that the > install:install-file mojo doesn't seem able to attach additional > artifacts further complicates issues, as I would need one POM per > os/arch combination, instead of a classifier. It is interesting that noone here has commented this so far? I am no expert in this area (but we will need to look more at non-java compilation soon), however I get the feeling that the non-java support in maven is a bit less "mature" than the java side (for natural reasons maybe). However AFAIK this should not be a problem with the maven architecture, but more likely lack of plugins(mature) for the different aspects? The dependencies and compilation should be solvable using classifiers and profiles quite nicely? anyone more experienced care to comment on this? it is an interesting problem... > > > DOM STRUCTURE Again interesting that this has not been commented by others yet. I personally don't see the huge contradiction/ambiguity that you describe, yes the POM IS wide, but that is something that is pretty obvious from the scope of maven. > > plugins. Foremost among these I would count file encoding. Why do I need I definitely see a point here, but this is a detail that should be fairly easy and sensible to fix in future versions of maven? > > EXTENDING MAVEN > > Many things in maven can be solved by writing your own plugins. I don't > like the plugin interface at all, though, especially the way I have to say I like that it is VERY easy to get started writing your own plugin, something that is not true for many other frameworks... I do agree to your points regarding configuration and I hope your points regarding this are taken as feedback for future versions as they are very specific and constructive. > > DOCUMENTATION > Maven documentation is difficult to find and to read. Help pages for > mojos consist mostly of machine-generated text, with often only a single > sentence of less about the role of each parameter. Most maven generated > project pages provide little information distributed over many pages. Amen to this! I like maven a lot and have a lot of gratitute for the people writing plugins etc but if it is one thing that is constantly frustrating is that the documentation many times is lacking/confusing/hard to find etc etc Granted, this IS a very common for many open-source projects, but given the talent in the maven community and the efforts that have been attempted in standardizing plugin documentation etc it is a pity. It is particularly frustrating when you find a nice and relatively mature plugin that HAS some documentation but it is very hard to find without searching forums for links to it etc (eg docbkx plugin here)
