How did MyEclipse get their Maven Integration So Wrong?

Discussions

News: How did MyEclipse get their Maven Integration So Wrong?

  1. Eugene and I have been watching with amazement how vocal MyEclipse users have been about their great disappointment with Genuitec's attempt at Maven integration, which amounts to complete mutilation of m2eclipse and the way Maven itself works. Genuitec decided to work in their standard fashion, which is unfortunately not a very collaborative mode of operation, and it's apparent that MyEclipse customers are not happy. MyEclipse Breaks Maven Maven has a very opinionated way of doing things, there is a very strong structure that is encouraged and users have come to like the convention over configuration approach. I warned Wayne Parrot from Genuitec that changing the way Maven worked by default, or at least the attempt to, would result in unhappy Maven users. None of our documentation would apply, users could not use conventional modes of support like the Maven users lists, or the m2eclipse users lists, and they couldn't benefit from standard books, or the Maven website. I really wasn't very pleased with some of the initial reactions but it was this quote that drove me to write something about the unequivocally abysmal Maven4MyEclipse integration: Read the rest at http://blogs.sonatype.com/jvanzyl/2008/09/05/1220595900181.html .

    Threaded Messages (61)

  2. My response below was orignally posted here on the MyEclipse blog. Let me start my response to your harsh criticism by stating that the sky is not falling and the issues you raise are only a short lived situation. You asked "How did MyEclipse get their Maven integration so wrong?" without sharing the whole truth of the strategy I shared with Jason prior to the release of Maven4MyEclipse in MyEclipse 6.5. Let me share with everyone that the issues you outlines are already resolved and will be released as part of MyEclipse 7.0M2 in two weeks. If Jason would have reached out to us he would be informed and could have avoided this little rant of a temporary issue. Let's step back and I'll share with everyone the big picture that I shared with Jason on two prior occasions before the initial release of Maven4MyEclipse. The first is that we are very excited about the growing enterprise adoption rate of Maven technology among MyEclipse corporate customers. So, we listened to them and their complaints about Maven as it is today. Our initial release strategy for rolling out Maven4MyEclipse to the community has been a two-phase rapid release process. The first release was to get Maven in the hands of thousands of previously non-Maven users (well over 300,000 users in the last 6 weeks). The second release was to focus on the concerns of existing Maven/m2e users. Again, your issues are concentrated towards the existing m2e user of which the upcoming second release of Maven4MyEclipse will address at the full level of m2e with additional enhancements. When you talk about MyEclipse getting Maven wrong you have to step back and see the forest rather than trees. But you knew this per our early discussion and have elected to omit that fact. As I stated earlier, we are excited about Maven and our initial concern that led us to focus on new users over the m2e user is the opportunity for the half million MyEclipse users who have never used Maven, or worse yet, have used it and discarded it due to the usual Maven challenges. So we fixed those problems first. Unfortunately, we left a gap for m2eclipse user until this next release, MyEclipse 7.0M2 release. I shared with Jason that this would be the case for a very short period. Counter to your claim that we should listen to our users, I should point out we did just that. Unlike you MyEclipse has a very broad customer base with many varied perspectives of love-hate towards Maven. Specifically, our first releases focused on the "Maven Haters" who have always bumped into Maven's shortcomings and rejected it outright. With MyEclipse, there is no "first day off" to figure out how to get your jars into your repository and project. Maven4MyEclipse just does it for the user, behind the scenes. That's a half million MyEclipse users that don't have to fight that battle, something we're pleased about. We also introduced wizards for the sometimes-confused Maven novice who had never installed their own legacy jars into a repository; we even focused on making it a bit easier to point to the JDK. Most importantly of course, we made sure that Maven was seamless for as many of the existing MyEclipse project structures as possible. "Seamless" is a word not historically used by Maven users, so we are pretty proud of that as well. To your narrow view of the "right way" to do Maven, it might not appear that we are an interested part of the Maven community because we took our first Maven releases to address so many issues that were important to the "other" community; that community of people who were not interested in Maven but rather just need tools to get their job done. We believe, as you do, that the Java community can benefit greatly through expanding the adoption of Maven. But our customers always vote with their feet, so we took care of the "other" community first, and are now circling back to attend to our closer Maven friends in a couple of weeks. In summary, had you bothered to contact the MyEclipse team instead of spending hours researching this issue for the sole purpose of spreading FUD, you would have found that MyEclipse 7.0 has already addressed all of your quoted gripes - but you knew that. So, stay tuned. I encourage you reach out to us when you discover any issues (as we have done with your team with the intent to collaborate and serve our combined user bases). No one wins by forcing their will on others. It is only through true collaboration and compromise that we achieve an enduring standard and satisfy the spirit of the open source model. Best regards, Wayne Parrott VP, Product Development
  3. That's one reason why I hate maven[ Go to top ]

    My response below was orignally posted here on the MyEclipse blog.

    Let me start my response to your harsh criticism by stating that the sky is not falling and the issues you raise are only a short lived situation.

    You asked "How did MyEclipse get their Maven integration so wrong?" without sharing the whole truth of the strategy I shared with Jason prior to the release of Maven4MyEclipse in MyEclipse 6.5. Let me share with everyone that the issues you outlines are already resolved and will be released as part of MyEclipse 7.0M2 in two weeks. If Jason would have reached out to us he would be informed and could have avoided this little rant of a temporary issue.

    Let's step back and I'll share with everyone the big picture that I shared with Jason on two prior occasions before the initial release of Maven4MyEclipse. The first is that we are very excited about the growing enterprise adoption rate of Maven technology among MyEclipse corporate customers. So, we listened to them and their complaints about Maven as it is today. Our initial release strategy for rolling out Maven4MyEclipse to the community has been a two-phase rapid release process. The first release was to get Maven in the hands of thousands of previously non-Maven users (well over 300,000 users in the last 6 weeks). The second release was to focus on the concerns of existing Maven/m2e users.

    Again, your issues are concentrated towards the existing m2e user of which the upcoming second release of Maven4MyEclipse will address at the full level of m2e with additional enhancements.

    When you talk about MyEclipse getting Maven wrong you have to step back and see the forest rather than trees. But you knew this per our early discussion and have elected to omit that fact. As I stated earlier, we are excited about Maven and our initial concern that led us to focus on new users over the m2e user is the opportunity for the half million MyEclipse users who have never used Maven, or worse yet, have used it and discarded it due to the usual Maven challenges. So we fixed those problems first. Unfortunately, we left a gap for m2eclipse user until this next release, MyEclipse 7.0M2 release. I shared with Jason that this would be the case for a very short period.

    Counter to your claim that we should listen to our users, I should point out we did just that. Unlike you MyEclipse has a very broad customer base with many varied perspectives of love-hate towards Maven. Specifically, our first releases focused on the "Maven Haters" who have always bumped into Maven's shortcomings and rejected it outright. With MyEclipse, there is no "first day off" to figure out how to get your jars into your repository and project. Maven4MyEclipse just does it for the user, behind the scenes. That's a half million MyEclipse users that don't have to fight that battle, something we're pleased about. We also introduced wizards for the sometimes-confused Maven novice who had never installed their own legacy jars into a repository; we even focused on making it a bit easier to point to the JDK. Most importantly of course, we made sure that Maven was seamless for as many of the existing MyEclipse project structures as possible. "Seamless" is a word not historically used by Maven users, so we are pretty proud of that as well.

    To your narrow view of the "right way" to do Maven, it might not appear that we are an interested part of the Maven community because we took our first Maven releases to address so many issues that were important to the "other" community; that community of people who were not interested in Maven but rather just need tools to get their job done. We believe, as you do, that the Java community can benefit greatly through expanding the adoption of Maven. But our customers always vote with their feet, so we took care of the "other" community first, and are now circling back to attend to our closer Maven friends in a couple of weeks.

    In summary, had you bothered to contact the MyEclipse team instead of spending hours researching this issue for the sole purpose of spreading FUD, you would have found that MyEclipse 7.0 has already addressed all of your quoted gripes - but you knew that. So, stay tuned. I encourage you reach out to us when you discover any issues (as we have done with your team with the intent to collaborate and serve our combined user bases). No one wins by forcing their will on others. It is only through true collaboration and compromise that we achieve an enduring standard and satisfy the spirit of the open source model.

    Best regards,
    Wayne Parrott
    VP, Product Development
    To hear that MyEclipse has made using maven better is welcome news to me. I've had to suffer the crapiness of maven in the past and ended up hating it. I find the maven developers arrogant and full of themselves. I've been known to flame maven on TSS in the past :) I just might give MyEclipse a try just to see how it improves on maven. Often I wish someone aborted the maven fetus before it was birthed. flame on! peter
  4. Re: That's one reason why I hate maven[ Go to top ]

    I just might give MyEclipse a try just to see how it improves on maven. Often I wish someone aborted the maven fetus before it was birthed. flame on! heh, i just may go back to MyEclipse too, maven is a mess and i'd rather chew my left foot off than use that thing on a project.
  5. Re: That's one reason why I hate maven[ Go to top ]

    The standoffish attitude of the people supporting the projects is one of the reasons that I've never had an interest in using MyEclipse or JBoss. Instead of providing a well-reasoned and rational response, which was totally within their reach, here we see a member of MyEclipse once again take a holier-than-thou stance. You don't have to be nice, but you have to be civil. It's a fair criticism that your only production product has broken maven integration. That your next version will be better is surely welcome news to your customers that are also avid maven users, but it's not a GA product.
  6. Re: That's one reason why I hate maven[ Go to top ]

    The standoffish attitude of the people supporting the projects is one of the reasons that I've never had an interest in using MyEclipse or JBoss.

    Instead of providing a well-reasoned and rational response, which was totally within their reach, here we see a member of MyEclipse once again take a holier-than-thou stance.

    You don't have to be nice, but you have to be civil. It's a fair criticism that your only production product has broken maven integration. That your next version will be better is surely welcome news to your customers that are also avid maven users, but it's not a GA product.
    You are a bit mistaken in this. We are speaking of MyEclipse 7.0M1, a milestone release, also known as public beta. It is NOT a production release. Best regards, Robert
  7. Re: That's one reason why I hate maven[ Go to top ]

    You are a bit mistaken in this. We are speaking of MyEclipse 7.0M1, a milestone release, also known as public beta. It is NOT a production release.
    I debated whether I should turn this into a lesson about the difference between a constructive and standoffish response to someone who makes a mistake, but I decided to take the high road instead and just be constructive.
    I'm sorry, I should have been clearer. I was referring to MyEclipse 6.5, which is the latest production release and has the broken Maven support. The fact that 7.0M1 will fix it is surely welcome news, but it won't help many of them until 7.0 reaches GA.
  8. Re: That's one reason why I hate maven[ Go to top ]

    You are a bit mistaken in this. We are speaking of MyEclipse 7.0M1, a milestone release, also known as public beta. It is NOT a production release.

    I debated whether I should turn this into a lesson about the difference between a constructive and standoffish response to someone who makes a mistake, but I decided to take the high road instead and just be constructive.

    I'm sorry, I should have been clearer. I was referring to MyEclipse 6.5, which is the latest production release and has the broken Maven support. The fact that 7.0M1 will fix it is surely welcome news, but it won't help many of them until 7.0 reaches GA.
    Sorry, it was my error. To be honest, I did not notice Maven4MyEclipse in 6.5, therefore I assumed that 7.0M1 was the version which had broken the Maven2 support, and actually the 7.0M1 release was what I referred to as not being a production release and that you should consider only 7.0GA. As it was 6.5 which brought out Maven4MyEclipse, and it if really broke Maven[12], then you are right, it is really an unwelcome thing. The reply was not intended to be standoffish, it was intended to be fair, only a bit lacking in background facts. Sorry again and best regards, Robert
  9. When I heard Maven4Myeclipse,I got a try,but I found i could't a Web app using it,so I gone back to user Maven Plugin itself,It's so strong and convenient,I also like ,I think Myeclipse must put more effort into support formal use of maven,but not make it so strange
  10. Re: That's one reason why I hate maven[ Go to top ]

    Yes, many people criticize maven, but their criticisms mostly do not make sense to anyone who has learned, used, and benefited from maven. Peter, is your hate of maven mostly due to the fact that it does have somewhat of a steep learning curve? I have the same issue with ant. Ant is very straight forward and coming from makefile environment, one might say, wow, tasks let me cut down on the amount of manual configuration/build code I have to write. But to me, once I switched to maven, every time I go to ant, I find myself saying, shit, why do I have to write these 20 lines of xml when this is done out of the box with maven. Maven is convention over configuration. Most flexibility is fulfilled by plugins. In the last 3 years for over 30 or so projects that I chose to use maven for, there was only one time I remember going to ant due to the a bizarre, flexible build requirement and the lack of motivation to spend a week writing a maven plugin. I wish maven could be more easily extended with built in dynamic scripting. There are some facilities for that, but they are pretty limited. Ilya
  11. Biggest problem in maven[ Go to top ]

    I use maven intensively for my project and most requirements can be fulfilled really easily once you know how to do it. The problem with maven in my opinion is that it does many things by convention but does not make it easy to understand what it does by default and how to change that. So a beginner with maven will try the craziest workarounds till he learns that maven can do what he wants by just using the right small config or command. The other problem with maven people often face is that they know what maven does and want it to do something slightly different. Then it is extremly difficult to understannd where to extend maven to do what you want.
  12. Re: That's one reason why I hate maven[ Go to top ]

    Peter, I doubt you know any of the Maven developers. Many of us certainly have opinions -- who doesn't -- but we just surpassed the HTTPD project, and Tomcat in total number of commits. We have one of the most active lists at Apache, and one of strongest Open Source communities period. It's because many of the Maven developers are committed to the users so I would say the general statement that Maven developers are arrogant is unfair. It's also highly unlikely that a third party is going to improve Maven where the Maven community doesn't do this first. If you actually tried m2eclipse, which it doesn't seem like you have, you would be able to compare the differences yourself instead dishing out speculation. I base this on you stating yourself that your encounters with Maven were in the past. Last month was an all time record and the Maven Central Repository got close to 250M hits so I don't think the general populace shares your opinion about Maven. If it doesn't suit your needs don't use it. It's unfortunate, it seems to me, that someone forced Maven on you prematurely and you dislike it to the point where you feel the need to talk about fetuses. Such is life, but many users express opinions counter to yours.
  13. Re: That's one reason why I hate maven[ Go to top ]

    Peter,

    I doubt you know any of the Maven developers. Many of us certainly have opinions -- who doesn't -- but we just surpassed the HTTPD project, and Tomcat in total number of commits. We have one of the most active lists at Apache, and one of strongest Open Source communities period. It's because many of the Maven developers are committed to the users so I would say the general statement that Maven developers are arrogant is unfair. It's also highly unlikely that a third party is going to improve Maven where the Maven community doesn't do this first. If you actually tried m2eclipse, which it doesn't seem like you have, you would be able to compare the differences yourself instead dishing out speculation. I base this on you stating yourself that your encounters with Maven were in the past.

    Last month was an all time record and the Maven Central Repository got close to 250M hits so I don't think the general populace shares your opinion about Maven. If it doesn't suit your needs don't use it. It's unfortunate, it seems to me, that someone forced Maven on you prematurely and you dislike it to the point where you feel the need to talk about fetuses. Such is life, but many users express opinions counter to yours.
    I'm an apache committer and I read a lot of apache mailing lists. You're right. I don't know any of the maven developers personally. Then again, if I did, I'd probably end up cursing them. I had to use maven on a gigantic project. We ran into all sorts of build issues every single week because of lame architecture of maven. to get around it, we wrote quite a few plugins for maven to get it to work properly. ultimately the effort was a complete waste of time. after I left that job, the project decided maven2 just wasn't worth it and they moved off. Originally, that project used maven 1. I've also had to use maven2 with other open source projects and frankly, I always end up wasting time. I'd much rather use ANT and be done. It's far simpler to use ANT than maven. There are many apache committer that hate maven. Let the flames continue.
  14. Re: That's one reason why I hate maven[ Go to top ]

    Check Maven integration in Netbeans and check in the Intellij IDEA, They both work great, That are well architected solutions, I was also a user of MyEclipse, I left because they have lots of problems with integrations, bugs and also I do Swing development but their solution also doesn't work well, It is pointless this thread.
  15. Re: That's one reason why I hate maven[ Go to top ]

    There aren't any flames to continue to honest. It's a pretty simple choice. Don't use it if it doesn't suit your style, or needs. It's no skin of any Maven developer's back if you choose to use something else. Maven 1.x admittedly had lots of flaws like many first generation tools have. I think that's pretty normal. Look at anyone's experience with the first versions of Ant, if you look at arguments people had they are almost the exact same as yours. If you've read many of the Apache mailing lists you know that I've never tried to jam Maven down any project's throat, and I've in fact argued to not make any tool mandatory. Users are smart enough to decide what they want to use. Lots of people dislike Maven, lots of people dislike Ant as they find Ant overly complex. I'm sure many choices will continue to exist including the new scripting options like Gradle, Gant, and BuildR. But it is generally the case that large projects where the first experience with Maven is a conversion almost 100% of the time results in failure. Without some experience trying out smaller projects with Maven, attempting to wedge a large, complex and completely ad-hoc structure to the Maven equivalent is extremely painful. If you attempt to use Maven simply as a replacement of one tool for another you won't succeed. Sounds like that's what happened to you but I can only guess because you generally present rants devoid of any clear argument or presentation.
  16. Re: That's one reason why I hate maven[ Go to top ]

    Jason, your message reeks with petty and hypocrisy. This elitist mentality when everyone is wrong unless its done your way just makes my blood boil. That is one of the key reasons why IMHO Maven is loathed by many on this thread. But you really have no idea how self-centered your logic sounds to the rest of world. So let me see if I can make my response as crass as possible so you might just get it: First, You don't like the way myeclipse implemented Maven in their first release after digging up a few complaints on their forums. Yet in your own defense for Maven 1.x,
    Maven 1.x admittedly had lots of flaws like many first generation tools have. I think that's pretty normal. Look at anyone's experience with the first versions of Ant, if you look at arguments people had they are almost the exact same as yours.
    But its the end of the world with myeclipse first Maven generation despite the fact that I could find more complaints on this thread alone against maven today than what you managed to dig up from the myeclipse support site. Smell the hypocrisy! Second, the myeclipse guys told you they shipped maven targeting early adopters as a way to get past the big problems non-experts have when trying Maven for the first time. But the key message is that they shipped several hundred thousand copies and should make you grin ear-to-ear with excitement having reached this large base of happy users [other than the few you pulled out of their website]. I would be jumping up and down with joy if my project had a fraction of that population. But instead of finding ways to work through the issues as most adults would, you chose to air your frustrations in public. An that is petty. Lastly, the myeclipse guys assured you that they worked through all the concerns you brought up in their upcoming release. Yet, you chose to continue your rants instead of trying to listen and find the win for your project and your users. And that's the hight of arrogance. It is possible that maven has reached past the point where you and your small company can take it. Particularly when its clear that you are unwilling to listen to anyone other than the guy in the mirror.
  17. still missing the point[ Go to top ]

    Second, the myeclipse guys told you they shipped maven targeting early adopters as a way to get past the big problems non-experts have when trying Maven for the first time. But the key message is that they shipped several hundred thousand copies and should make you grin ear-to-ear with excitement having reached this large base of happy users [other than the few you pulled out of their website].
    No one has an issue with targeting early adopters. The fact is that existing users where totally locked out...even those that didn't pay to upgrade to the version that included Maven4Eclipse. All users where effectively blocked from using M2e as they where previously.
  18. Re: That's one reason why I hate maven[ Go to top ]

    Often I wish someone aborted the maven fetus before it was birthed
    +10000
  19. Re: That's one reason why I hate maven[ Go to top ]

    Often I wish someone aborted the maven fetus before it was birthed


    +10000
    Ok, I hate to sound like a maven zealot, but shit like this annoys me. +10000 for what? What is your issue with maven? And mind there are a few, but there are also that many more with ant and all the other build systems. If you can't get your mind around declarative builds and haven't yet gone through the maven learning curve, please don't post stupid crap like this. At least peter's original post had some opinionated content, with which I disagree. Ilya
  20. Re: That's one reason why I hate maven[ Go to top ]

    Often I wish someone aborted the maven fetus before it was birthed


    +10000


    Ok, I hate to sound like a maven zealot, but shit like this annoys me. +10000 for what? What is your issue with maven? And mind there are a few, but there are also that many more with ant and all the other build systems. If you can't get your mind around declarative builds and haven't yet gone through the maven learning curve, please don't post stupid crap like this. At least peter's original post had some opinionated content, with which I disagree.

    Ilya
    I'll give you an example. This is from first hand experience and not out of thin air. Say you support a product which has 40+ components. That in itself isn't really the problem. Say the depedency between the components is quite complex, which makes building the components tricky. To make things worse, say you're force to use Clearcase with it's recommended structure. Now we have a serious conflict between what IBM Rational recommends for convention and what maven recommends. If you use the Rational recommended conventions and setup, things work fairly well after a big setup cost. On the otherhand, if you use maven conventions, you run into issues and Rational tells you "we can't help you if you don't use our conventions." Of course, someone might say "why use clearcase, just use SVN and maven conventions." Say we figure out a happy medium between clearcase conventions and maven conventions. by the way, we did manage to figure out an acceptable medium, but it was expensive to maintain. Say we have to run a full regression test every night with the following matrix for os, and database: windows, solaris, linux, aix, hpux, zos, sql server, oracle and db2. The thing is, maven makes the assumption there's only 1 configuration, which is totally unrealistic for a large complex multi-platform product. With maven 1.x, you couldn't run with different build files, so it meant doing a combination of ANT + Maven. Basically, we had 1 build script for each OS platform and use ant to rename the appropriate scripts before running maven. The other huge flaw with maven is the repository. It assumes 1 repository. In some cases, you might want to use some files from one repository and files from a second repository. In other words, multiple repositories. I don't know if maven 2 can support multiple repositories, but that is a real requirement for real products.
  21. Re: That's one reason why I hate maven[ Go to top ]

    Peter, if you're still using maven 1, then I can see your issues. Maven 2 resolved most maven 1 issues. Yes, you can use as many repos as you'd like. Things are definitely better and cleaner. I started using maven 1 right before 2 came out and almost lost hope, but then gave 2 a try and never looked back. Also, I can see your issue with clearcase conventions. I don't know why a version control system would have conventions. I used clearcase when I still used to work for large corporations. I'm not sure about your opinion, but I never used a less intuitive, ridiculously engineered product before. I'm sure I didn't use it to it's full capability, but just the lack of being able to commit directories recursively (not sure, they might of added that feature lately), was it for me. Either way, your clearcase/maven issue is a chicken/egg problem.
  22. Re: That's one reason why I hate maven[ Go to top ]

    Peter, if you're still using maven 1, then I can see your issues. Maven 2 resolved most maven 1 issues. Yes, you can use as many repos as you'd like. Things are definitely better and cleaner. I started using maven 1 right before 2 came out and almost lost hope, but then gave 2 a try and never looked back.

    Also, I can see your issue with clearcase conventions. I don't know why a version control system would have conventions. I used clearcase when I still used to work for large corporations. I'm not sure about your opinion, but I never used a less intuitive, ridiculously engineered product before. I'm sure I didn't use it to it's full capability, but just the lack of being able to commit directories recursively (not sure, they might of added that feature lately), was it for me.

    Either way, your clearcase/maven issue is a chicken/egg problem.
    I don't use maven anymore, but I have used maven2 with various open source projects. maven 2 is nicer than 1, but it still has warts. in a perfect world, the developers would get to pick the version control tool, but that's not reality. I've seen different ways of using clearcase. some people use the recommended "approach" while others use it just for version control and nothing else. I agree clearcase sucks, but if you're in a project that is using multiple streams with the recommended layout, it definitely conflicts with maven regardless of the version.
  23. Re: That's one reason why I hate maven[ Go to top ]

    But why do you think it's OK for clearcase/Rational to recommend layouts and not OK for maven to do the same?
  24. Re: That's one reason why I hate maven[ Go to top ]

    But why do you think it's OK for clearcase/Rational to recommend layouts and not OK for maven to do the same?
    it's perfectly fine for each to recommend a specific set of conventions. My point is when conventions conflict and give developers grief. I understand that maven 2 isn't as strict with directory structure, but often that's just the tip of the iceberg. The situation gets worse if you are forced to use Websphere and rational tools for pushing builds. Instead of just 1 build tool, there's 2 tools and they often don't work well with each other. An example would be using rational tools to push builds to a mainframe environment. Depending on how close a company follows rational guidelines, it could mean maintaining 2 separate build systems. A "good" build system in my mind should integrate with existing tools with minimal "reworking". For me ANT serves that purpose much better than Maven.
  25. Re: That's one reason why I hate maven[ Go to top ]

    I just might give MyEclipse a try just to see how it improves on maven. Often I wish someone aborted the maven fetus before it was birthed. flame on!

    peter
    This is one of the most pathetic post i have ever seen. The world is full of tools, frameworks, platforms, ... that i dislike but i never hoped to kill them: i simply do not care of them. Probably your anger against maven is caused by your comprehension of your inability in using tools that require high level skills.
  26. Ok, you seriously didn't have to write a 5 page essay and outline your evidently poorly architected/executed strategy for integrating maven. This is not rocket science and you did not invent anything innovative here. If you needed an example, you should of just took a good look at how IntelliJ integrates with maven, it provides seamless integration without getting in your way and without locking the customer into using intellij. The whole point of using a 3rd party build system, is so that we're not tied to proprietary ways of building and have our build dependent on MyEclipse. I used MyEclipse extensively a year or so ago, just as a way to give eclipse a try. Eclipse really doesn't stand a good chance of attracting someone coming from IDEA world. But that bias aside, I gave it a try and liked it. But eventually realized that there are so many proprietary integrations, etc... For some reason you guys insist on locking people into your product. Although a good long term strategy for the "strategy" folks, it's really unattractive to anyone who's ever been bitten by such a strategy, and that pretty much covers anyone with some experience. Ilya
  27. So if we are ranting here[ Go to top ]

    The main issue in Eclipse is that the basic WTP is so rotten and barely unusable that MyEclipse basically is the only solution to have something working in the JEE world which is okish. Unfortunately there is no real alternative to MyEclipse (well maybe the jboss tooling I have to revisit it again) In my experience, Intellij can be used out of the box without too much hazzles but you pay the price for it. Eclipse itself is a good core and the compile save incremental system complements itself perfectly with tools like javarebel, for simple java editing the comfort of eclipse has not been surpassed. But things get ugly as soon as you hit the WTP world, half finished buggy plugins, third party extensions you have to shop for on myriads of sites on the net, and simply being close to unusable without a commercial package or distro, that is the WTP world. I am somewhat thankful for tools like MyEclipse which make JEE programming in the Eclipse world bearable. Although ME is not perfect and has a load of bugs, but it is working out of the box (well most features) As for Maven, many people use but, but I have yet to find a single person actually liking it. The problems in maven are numerous. Byzantine exection hierarchy which makes it hard to know what is going on if you are not knee deep into it. The xml is verbose, due to not using attributes just only tags. No real central repo which covers all unlike the perl world has definitely hard to gain fine gained control over your build process which still some people like and enforcing conventions even if you dont want then instead of just showing a way. Maven is the tool of choice for many, but I assume as soon as something better hits the scene people will move away rather swiftly instead of sticking to it. There is no love towards it, it is just used but no one really likes it! Just my 2c although not really on topic ;-)
    Ok, you seriously didn't have to write a 5 page essay and outline your evidently poorly architected/executed strategy for integrating maven. This is not rocket science and you did not invent anything innovative here. If you needed an example, you should of just took a good look at how IntelliJ integrates with maven, it provides seamless integration without getting in your way and without locking the customer into using intellij. The whole point of using a 3rd party build system, is so that we're not tied to proprietary ways of building and have our build dependent on MyEclipse. I used MyEclipse extensively a year or so ago, just as a way to give eclipse a try. Eclipse really doesn't stand a good chance of attracting someone coming from IDEA world. But that bias aside, I gave it a try and liked it. But eventually realized that there are so many proprietary integrations, etc... For some reason you guys insist on locking people into your product. Although a good long term strategy for the "strategy" folks, it's really unattractive to anyone who's ever been bitten by such a strategy, and that pretty much covers anyone with some experience.

    Ilya
  28. Re: So if we are ranting here[ Go to top ]

    In my experience, Intellij can be used out of the box without too much hazzles but you pay the price for it.
    I seriously don't understand when people complain about the price of IntelliJ. I wouldn't care if it was twice it's price. It's making me productive, I enjoy using it, and as a full time developer, I'm fine with dishing out 250-500 dollars for a product that I'll use every single day and which will make my day a lot more productive and enjoyable. One of my prerequisites of working at any company is to see how much money they are willing to spend on good tooling. If they push back, I definitely wouldn't want to work there.
    As for Maven, many people use but, but I have yet to find a single person actually liking it.
    I used it and besides a few hassles, I love it. Yes, there was definitely a steep learning curve, but at this point I'm much more productive with it as I ever was using any other build environment that's not declarative. Can maven be improved, absolutely. I think there are many ways to improve it and maybe another system will provide declarative builds that give us the benefits of maven without its drawbacks, but for now, maven is it. Ilya
  29. Re: So if we are ranting here[ Go to top ]

    The price of Intellij hurts you? haha, that is really funny for a professional software developer, Sometimes we have to spend little bit for our tools as you do with MyEclipse. Intellij IDEA new license for personal programmer is about $254.00US and upgrade $129.00US check on their website for the exactly price. But with that low price you get a Great Java IDE with all the integrations that with MyEclipse you are paying little bit more less but the integrations sucks. Maybe as someone said the problem is not MyEclipse, It is Eclipse?. I love Intellij IDEA, It gets my job done without a problem, It have all integrated and it is well architected. If you want something also good, not the level of Intellij but it get the things done try Netbeans and it is free. This is not about Maven it is about the tools they dont behave well with the technology. As I said this thread is pointless. Regards.
  30. Re: So if we are ranting here[ Go to top ]

    As for Maven, many people use but, but I have yet to find a single person actually liking it.
    Count me in as a someone who really, really likes Maven. When the IDE does get it right, like in NetBeans, then Maven projects are a breeze to use. Think about what it takes to start working with someone's open source probject. If they use Maven, I just point my IDE at the pom and everything works. There is no extra configuration whatsoever. I'm immediately productive. With ant, the first thing I have to do is figure out how the build works. Then I have to go find all the dependencies myself. Then if I'm lucky I can figure out how to work with it in my IDE. But the ant script was probably written in such a way that makes it very hard to do this. It might take as much as two days to be productive. If you intend to be the sole programmer on your project, go ahead and use ant. If you want to share it with someone, Maven is the smart choice. Stan
  31. Re: So if we are ranting here[ Go to top ]

    >
    As for Maven, many people use but, but I have yet to find a single person actually liking it.
    you found one.
  32. Wayne, The sky is hardly falling. I was pointing out the reaction of your users. It's not a situation that can't be improved. It's just a situation that got off on the wrong foot. Everything is correctable and we certainly don't have a fait accompli on our hands. The harsh criticism is from your own users, I only echo their concerns. I looked at the situation purely from the perspective of your users and I wouldn't consider the collection of complaints I gathered FUD. That was entirely unedited material from your own forums and the perspective in my blog post is that of your users. If your users were pleased with your integration I would have no place to say anything. If they preferred altering Maven's structure to yours and preferred your projection of m2eclipse and not the default m2eclipse behavior I would also not have a right to say anything. So this is not my perspective, it is the perspective of your users and they are MyEclipse users and Maven users.
  33. Wayne, you missed the point.[ Go to top ]

    Wayne, I don't think anyone has issues with MyEclipse focusing on non-Maven users as a first rollout. The issue is that existing Maven users are effectively locked out of using M2e as they where before. This definitely does not serve our combined user base. Further, introducing new users to a customized Maven experience doesn't really help them become true Maven users in a portable sense, since they are effectively locked in to the MyEclipse version. Using M2e as a base and extending _and committing it back_ is definitely welcome behavior. Taking it and modifying it is your licensed right...but blocking users from using other Maven integrations is not exactly in the right spirit of things.
  34. As I posted in the past, Maven is totally wrong from root. It forgot the most important principle of a build system: easy to use and flexible to do the build tasks. Maven, on the contrary, blames users instead of itself. ;-) Hank
  35. As I posted in the past, Maven is totally wrong from root. It forgot the most important principle of a build system: easy to use and flexible to do the build tasks.

    Maven, on the contrary, blames users instead of itself.

    ;-)

    Hank
    No, I think you've got it wrong. Maven is about convention over configuration. Yes, configuration is sometimes not as straightforward as one might wish, but I don't really care. Honestly for most of my builds, even the complex multiproject ones, maven does everything I need and is set up in less than 30 minutes, as opposed to writing ant scripts and perfecting them for many days. I know some don't like the convention, but why? Who gives a crap if your src and resource files go into the directories you're accustomed to, get unaccustomed and put them into maven standard dir. Now, I did face some issues with maven when it comes to some 3rd party products, with funky requirements. Maven doesn't make it very easy to integrate those without having to write a mojo, but in most cases you can accomplish it with custom goal attachments and ant tasks. Ilya
  36. As I posted in the past, Maven is totally wrong from root. It forgot the most important principle of a build system: easy to use and flexible to do the build tasks.

    Maven, on the contrary, blames users instead of itself.

    ;-)

    Hank


    No, I think you've got it wrong. Maven is about convention over configuration. Yes, configuration is sometimes not as straightforward as one might wish, but I don't really care. Honestly for most of my builds, even the complex multiproject ones, maven does everything I need and is set up in less than 30 minutes, as opposed to writing ant scripts and perfecting them for many days. I know some don't like the convention, but why? Who gives a crap if your src and resource files go into the directories you're accustomed to, get unaccustomed and put them into maven standard dir.

    Now, I did face some issues with maven when it comes to some 3rd party products, with funky requirements. Maven doesn't make it very easy to integrate those without having to write a mojo, but in most cases you can accomplish it with custom goal attachments and ant tasks.

    Ilya
    See, that's the problem. *I* do give a crap where my resource and source files go. Why should I have to get "unaccustomed" to accomodate a tool that may very well be superseded by another tool in a shortwhile. For all its shortcomings, Ant met my needs pretty well. Still does. And I was able to adjust it to fit how I worked which to me is a superior paradigm. That's the problem I personally have with converntion over configuration. I don't get to pick the convention. Maven gives you all the inflexiblity of having to do it Maven's way with all the difficulty of pure configuration. This was the appeal, to me, of Idea. It seems to allow me to do it my way instead of the way the vendor thinks it should be. I believe that the best tools conform to the user, not vice-versa.
  37. And David's message, I believe, hits upon the biggest obstacle to Maven adoption. Ego. The feeling that your project's build is a special little snowflake, and that somehow your choice of source paths is distinct and ought to be different from the millions of other java projects out there. If you're wise enough to let such feelings go, and just accept the fact that your project's build needn't differ from everyone else's, then Maven is for you, and you can enjoy the benefits of a standardized build. Maven is not without its warts, but after maintaining hundreds of builds with the exact same boilerplate Ant code, I welcomed its conventions. ~kc
  38. And David's message, I believe, hits upon the biggest obstacle to Maven adoption. Ego. The feeling that your project's build is a special little snowflake, and that somehow your choice of source paths is distinct and ought to be different from the millions of other java projects out there.

    If you're wise enough to let such feelings go, and just accept the fact that your project's build needn't differ from everyone else's, then Maven is for you, and you can enjoy the benefits of a standardized build.

    Maven is not without its warts, but after maintaining hundreds of builds with the exact same boilerplate Ant code, I welcomed its conventions.

    ~kc
    I used the same basic Ant file from 2002 to 2007. Only minor changes as I adopted things like Spring, annotations, or GWT. This can be done without Maven. In addition, it is not about one thinking that their structure is unique. It is about the necessity of having the tool dictate the structure. When "Ultimate BuildTool" comes out, are we supposed to dump the existing Maven conventions for that? Will we hear the same reasoning? "Just let it go, nd Utimate BT will solve your problems." My structure has survived for years and is independent of any tool.
  39. The directory structure used by Maven project has never been fixed. There are defaults, yes, but they can all be overridden. I have had many clients over the years that have had existing structures that needed to be preserved for various policy reasons, or projects that had lives spanning many branches into the past where changing the directory structure would have made merging a nightmare. The defaults are easy to change at a project, or organizational level. That the structure is fixed in Maven is a myth. Many organizations choose to start new projects using the standard structure and/or migrate to the standard where possible as standard Maven documentation, training, and idioms then apply. Maven's defaults were chosen to allow for growth but are, in fact, as arbitrary as the defaults in any other system. The advantage is that our defaults are used by a few hundred thousand people and there are undeniable benefits in a collective understanding of a project structure. I'm not trying to say this alone mitigates any of the implementation defects in Maven (of which no one is more acutely aware then myself) or that a default structure alone is a good reason to use Maven. But it lends itself toward building a level of social capital (a measure of how well groups can work together) because there is some common structure from which to work from and communicate. Maven does not dictate a structure, contrary to popular opinion, but we definitely promote one. You have used your same Ant build files since 2002 which works for you. If you deliver using this tool set who can argue with that. But I have seen the argument many times over and it goes something like "my structure is pretty simple because I stick to the basics and it does what I need." This is perfectly fine in isolated cases but try to onboard new developers, find resources for your build and release team, attract developers to your open source project, reach a standard in your department, or your organization, integrate with disparate parts of your organization, incorporate third party libraries, integrate open source and you will rapidly find N pivot points against which you must learn something different to make the overall system work. This is simply an untenable proposition for a community of people trying to efficiently. Maven has many flaws, but it is very usable by a large number of groups. Maven is also not static. Not many people know that .NET and C toolchains have been created for Maven, or that with a few new implementations of internal components that Maven can build OSGi components directly from manifest information (look Mom, no POM!), or that you can write Maven plugins in Groovy, Ruby, or Ant script. Many of these things are unknown because the Maven project has admittedly been terrible at documenting these attributes and features. This is a failure at the Maven community level that we are trying address. Ultimately it's your decision as a user. If Maven doesn't work for you don't use it. But Maven was not meant to cater to personal biases, it was meant to work for groups and as such compromises need to be made in order to use Maven effectively. Maven is not for anyone in particular, it was intended for a large number of users who have made a conscious decision to work in more or less in the same way to achieve results in what they are making, not in how they make it.
  40. You have used your same Ant build files since 2002 which works for you. If you deliver using this tool set who can argue with that. But I have seen the argument many times over and it goes something like "my structure is pretty simple because I stick to the basics and it does what I need." This is perfectly fine in isolated cases but try to onboard new developers, find resources for your build and release team, attract developers to your open source project, reach a standard in your department, or your organization, integrate with disparate parts of your organization, incorporate third party libraries, integrate open source and you will rapidly find N pivot points against which you must learn something different to make the overall system work. This is simply an untenable proposition for a community of people trying to efficiently.
    I appologize for not be clear. By "me" I don't mean "just me." I mean my team. We had, at my last job, multiple teams, multiple projects with multiple dependencies. The projects used the same codebase, but dependencies shifted as one project introduced Spring to the framework, or another Hibernate, or another GWT. We had from 2002-2007 developers come and go, projects that came and the codebase that evolved as new OSS code was incorportaed in. No where did I say "It's simple and does what I need." My point was actually that Maven doesn't have a lock on such issues. We standardized quite successful during my tenure and attracted developers because of how agile we were with respect to using a variety of open source in our projects. Ultimately, I don't care if people use Maven or not. My point is that it isn't reasonble to attack(not saying you did) people who don't prefer tools that attempt to impose the tools point of view on the world. The best tools, IMO, adapt to the user, as opposed to forcing the user to adapt to it. Again, I ask: Whap happens when, not if, another buildtool arrives that addresses whatever weakness are supposed to be in Maven, but has its own conventions? IMO, the tools should slide right into the existing process. That's what tools like Idea, Spring, Hibernate, Quartz, and Ant, to name a few, all did. They didn't seem impose their world view on me. Instead, they adapted to my use.


  41. I appologize for not be clear. By "me" I don't mean "just me." I mean my team. We had, at my last job, multiple teams, multiple projects with multiple dependencies. The projects used the same codebase, but dependencies shifted as one project introduced Spring to the framework, or another Hibernate, or another GWT.

    We had from 2002-2007 developers come and go, projects that came and the codebase that evolved as new OSS code was incorportaed in. No where did I say "It's simple and does what I need."

    My point was actually that Maven doesn't have a lock on such issues. We standardized quite successful during my tenure and attracted developers because of how agile we were with respect to using a variety of open source in our projects.

    Ultimately, I don't care if people use Maven or not. My point is that it isn't reasonble to attack(not saying you did) people who don't prefer tools that attempt to impose the tools point of view on the world.

    The best tools, IMO, adapt to the user, as opposed to forcing the user to adapt to it. Again, I ask: Whap happens when, not if, another buildtool arrives that addresses whatever weakness are supposed to be in Maven, but has its own conventions?

    IMO, the tools should slide right into the existing process. That's what tools like Idea, Spring, Hibernate, Quartz, and Ant, to name a few, all did.

    They didn't seem impose their world view on me. Instead, they adapted to my use.
    thats fine, one of the fundamental goals of maven is to capture a default convention for locations and processes for all the resources and bits and pieces you so successfully captured in your long lived ant files. Problem is that your setup has no convention backing it that lets any other ant project benefit from it without some build guy to read and understand your custom build and tease out the important elements that have worked for you over the years. Maven tries to address this by gathering a wide smattering of concepts and tease out a common lifecycle that can be applied to all projects using maven, allowing people to instantly benefit from the pain and suffering of others. that people have some pain and suffering associated with maven is generally because they are like you, seemingly very attached to the way you have done it for years...which is totally fine so long as you realize that specifically choosing to not adopt the conventions of maven means your libel to suffer in your configuration of maven
  42. Well, I suppose that one way of seeing it. You say I'm "seemingly very attached." I say, I don't need the tool to make my decisions for me. As I said, I changed items as the projects dictated, and simply feel that I'm better qualified to determine my project structures than Maven. You, on the other hand, feel that Maven is better qualified than you and should impose its own world view on you. In essence, "Do it my way or suffer!" Your(or perhaps Maven's) reasoning smacks to me of unnecessary rigidity disguising itself as standardization. Considering the general split on Maven, I guess we won't solve this today. Who knows? I selected C++ over Java as my main focus back in the late '90s and now look at me! Take care...
  43. thats fine, one of the fundamental goals of maven is to capture a default convention for locations and processes for all the resources and bits and pieces you so successfully captured in your long lived ant files. Problem is that your setup has no convention backing it that lets any other ant project benefit from it without some build guy to read and understand your custom build and tease out the important elements that have worked for you over the years. Maven tries to address this by gathering a wide smattering of concepts and tease out a common lifecycle that can be applied to all projects using maven, allowing people to instantly benefit from the pain and suffering of others.

    that people have some pain and suffering associated with maven is generally because they are like you, seemingly very attached to the way you have done it for years...which is totally fine so long as you realize that specifically choosing to not adopt the conventions of maven means your libel to suffer in your configuration of maven
    You're assuming the setup has no convention backing it. Why is it that pro-maven people always assume failed attempts are due to "no convention". When I say maven developers have ego issues, this is what I mean. To assume the user failed because they are clueless or disorganized it wrong and stupid. Look at the example I gave. There are times when a project has a predefined set of conventions, which are not compatible with maven. Since I work on open source projects, I have to admit I've made the same mistake and assumed it was looser error. In my case, I usually come to my senses and apologize for being a retard.


  44. You're assuming the setup has no convention backing it. Why is it that pro-maven people always assume failed attempts are due to "no convention". When I say maven developers have ego issues, this is what I mean. To assume the user failed because they are clueless or disorganized it wrong and stupid. Look at the example I gave. There are times when a project has a predefined set of conventions, which are not compatible with maven. Since I work on open source projects, I have to admit I've made the same mistake and assumed it was looser error. In my case, I usually come to my senses and apologize for being a retard.
    I make no such assumption, pls to be not putting words in my mouth. If you adopt a set of conventions for your project, that is perfectly fine, and if you have lots of projects that you work with and your responsible for making sure all of the builds follow your conventions, then more power to you. And if they are mutually exclusive to the way maven does something, no biggy. Maven adopts conventions so that a wider group of people can benefit from the trials and tribulations of others. The maven conventions and lifecycle are a good attempt at standardization. Are they they only standard? Not at all..and i doubt you'll find any maven developer that claims otherwise. Point being with maven, providing the user follows the basic conventions laid out then any other user that understands maven can pick up that project and immediately be productive with it, without having to troll through a mess of build scripts and associated files, or read documentation on how to use the build system, or sit down with you and have you explain your set of conventions. People seem to toss a lot of stones at maven throwing claims of ego and arrogance around because OMG someone actually tried to establish some basic conventions for building software.
  45. A useful reminder: http://en.wikipedia.org/wiki/Convention_over_Configuration No-one blasts Hibernate or Rails for applying conventions so why Maven? Bringing some design paradigms to build automation is not of itself a *bad thing*. Plus, if you want (need) to go deeper, define your own packaging types and custom lifecycle. Its no biggie. How about I just wire each custom lifecycle phase to a ruby/groovy script runner via a single custom plugin? Not sure why you'd want to, but its possible if you want total flexibility. You just need to dig a little when you need Configuration rather than Convention. Would'nt it be great though if you could wrap some conventions around plain old Ant, like re-usable plugins and a lifecycle.... ;-) Adam
  46. When the next build tool comes along[ Go to top ]

    Again, I ask: Whap happens when, not if, another buildtool arrives that addresses whatever weakness are supposed to be in Maven, but has its own conventions?
    If you use Maven, I bet there will be a simple maven2newbuildtool conversion program. That is a benefit with using conventions. Btw, I guess you have the same feeling for Rails and Grails and their extensive use of convention over configuration?
  47. ... Again, I ask: Whap happens when, not if, another buildtool arrives that addresses whatever weakness are supposed to be in Maven, but has its own conventions?...
    Java history is based on conventions that led to a solid community. Would you like to be free to avoid using camel naming conventions ? Or do you want to start naming the classes lowercase ? Or do you want to start readXXX(), writeXXX() trueFalseXXX() instead of getXXX(), setXXX(), isXXX() ?
  48. Agree, that's it. I'd rather start writing code than spend my time customizing builds for hours and hours. Also, the dependency management of maven is really nice and for the most part transparent. Ivy brings that to ant, but it doesn't remove ant's headaches outside of dependency management. I wonder why people that are so against declarative/convention based builds, are using ant? A shell script would do the same and you can customize it above and beyond all the ant capabilities you'll ever have. You can take the next 3 weeks to write such a script and then reuse it for all your projects. No thanks, I'd rather generate a maven project and start coding 5 minutes later. Ilya
  49. Agree, that's it. I'd rather start writing code than spend my time customizing builds for hours and hours. Also, the dependency management of maven is really nice and for the most part transparent. Ivy brings that to ant, but it doesn't remove ant's headaches outside of dependency management.

    I wonder why people that are so against declarative/convention based builds, are using ant? A shell script would do the same and you can customize it above and beyond all the ant capabilities you'll ever have. You can take the next 3 weeks to write such a script and then reuse it for all your projects.

    No thanks, I'd rather generate a maven project and start coding 5 minutes later.

    Ilya
    First of all sorry for my rant, it was not against intellij and its pricing it is just you get what you pay for in both worlds, Intellij and Eclipse. And after having used both I have to say from a plug and start to work perspective Intellij is way better and Eclipse seems to become worse every release (the update center nowadays is a huge mess) Anyway back to the topic. Convention is not a problem per se, but maven itself is rather inflexible if you have to break out of the convention or if you have to add something to the convention it is. Go the maven way or it hurts, add something to maven via a plugin or it hurts. Well there still is the ant fallback. This makes the integration or migration of existing maven projects rather hard and in the past has been a huge problem when the list of plugins was way smaller than it now is. But maven2 made several critical choices which in the end are dead ends in my experience. A the choice of almost attribute less xml which makes the config files more verbose than they really should be (I am almost sure going away from xml should reduce the typical maven file by 90% and introducing attributes should at least reduce it by 50%) Also the choice it is either plugins or nothing to extend maven with a build like functionality is hard for many. Probably it would have been better to extend ant with default build tools and add the repository mechanism than doing it vice versa, then people could slowly move away from ant instead of trying to shoehorn ant into a rather byzantine build lifecycle which is hard to grasp. Dont get me wrong, maven is an excellent tool, and many things were done right, but there are some design considerations many feel uneasy about, and the reports of many of having moved away from maven because they ran constantly against roadblocks which they could resolve in classical build systems by a few lines of script should give the maven developers to think about. And yes I too love the eclipse:eclipse facilities and many other things, but also I see the problems of maven in its day to day usage basically every day. As for myeclipse to get back entirely ontopic. This was a problem, I also ran into, but I never really used that stuff anyway (eclipse:myeclipse was always fine for me), but it still was a bad choice. But the main problem itself lies also in the structuring of eclipse projects, eclipse allows multi projects, but not deeply nested projects, so maven itself does some tricks to be rather compatible to the eclipse world. Genuintec has its own tooling which follows WTP conventions (even with eclipse:myeclipse I usually have to readjust some minor settings) so there is definitely a mismatch of the conventions both tools assume in the eclipse world and generally in the world of JEE which has to resolved as well on the maven and on the JEE side of things (the wtp basically follows the implicit layout which has been used before maven2 hit the scene)
  50. Agree about extensibility. Every time you want to extend maven, you basically have to write a mojo, which for some people is out of grasp of their current knowledge and/or time. It would be nice if maven allows lifecycle hooks that allowed for arbitrary scripts. With JDK 6 dynamic language extension, you should be basically able to plug in any/all scripting languages into maven. I think that would resolve majority of the issues. Ilya
  51. I sort of agree with the attribute statement, except that attributes can't later become complex types, which means, although right now an element accepts just a string value, later that can turn into a more complex object/expression, though sticking it in the attribute would later require POM refactoring or having to support attribute and elements at the same time.
  52. I sort of agree with the attribute statement, except that attributes can't later become complex types, which means, although right now an element accepts just a string value, later that can turn into a more complex object/expression, though sticking it in the attribute would later require POM refactoring or having to support attribute and elements at the same time.
    On the other hand attributes later can use the EL... just like spring will do it for spring 3.0, while nodes cannot really be el dynamized! As for your scripting hookpoint I agree fully. The biggest issue I had with maven so far was that everything you need extra basically causes an extension to be written some extension points which you can mix with scripting are heavily needed and probably would resolve around 90% of all gripes people have with maven.
  53. Wayne, Convention over configuration can be a big PITA if the convention is not to your liking. One of the reasons some developers hate maven (other than echos from 1.x) is that the conventions it supports are not to their liking. But the power of convention over configuration, is that the most benefit is gained from the tool by adopting those conventions rather than fighting against them. I for one was a bit resistant to the maven conventions and it required a bit of a mind shift for us to move jetty to those conventions. But having done so, I'm more than pleased with the results and the benefits that we have gained. Jetty is a much better project for making the switch. But what to do if you really can't accept those conventions? Jason offered one solution - don't use maven. This is a totally acceptable solution. Alternately, you can engage with the maven community and see if the conventions can be extended, enhanced or changed to include your vision. Or you can take the maven code base and apply it to your own new conventions. But if much of the value of the maven is in it's conventions, then using the code base for new conventions is almost like a fork of the project. So you can't really expect the maven community to reach out to you and embrace the new conventions. Convention is important and for many projects changing convention is just like changing the code. It like introducing a new rail gauge to Ruby on Rails or Grails and wondering why some developers get derailed. So while there may be lots of value in what you have done, show a little understanding about how maven developers might view it.
  54. Unhappy suibscriber[ Go to top ]

    Dear Mr Parrot: As a myEclipse subscriber after learning that my frustration with myEclipse handling of maven integration could have been avoided i formally announce i will not be renewing my subscription. The sky is not falling, but I have better things to do with my time that work around your decisions. Yours truly Gil Lindsay
  55. Happy Subscriber[ Go to top ]

    As a corporate and personal user who has had a hellish time with eclipse, RAD, and RSA, I will continue to evangelize MyEclipse and renew our dozens of subscriptions regardless of Maven. As long as it works, we'll keep using!
  56. MyEclipse is sooooo goood![ Go to top ]

    that I wouldn't even care to be honest. From the very beginning, it's saved me countless hours of config hell, so no biggie to me.
  57. I am happy for the existence of this topic, because i have been struggling with maven on myeclipse 6.5. First of all, i have to say that i love myeclipse; i have been using it for years and, in my opinion, it simply make eclipse a much better product. But, after i tried maven4myeclipse, i was quite astonished by the fact that, for the first time, genuitec simply included in a full release a totally unusable product. I did not know anything about the users complains shown above and i contacted genuitec trying to give them my personal feedbacks and suggestions on maven4myeclipse, concluding simply saying that their maven implementation could not be a usable product for me. And i have to admit that genuitec told me exactly what Wayne wrote here: - it was a first tentative of maven integration - they know that they are going to break existing maven projects - they will enhance it in the 7.0 version And, to be honest, they also told it during the maven4myeclipse webinar, being very open and clear about the maven4myeclipse limitations and future plans. In my opinion, genuitec simply was too eager to deploy maven4myeclipse and their only mistake is that they did it too early; maven4eclipse, from the functional point of view, is an project in alpha state.
  58. Eclipse Plug-in Friends?[ Go to top ]

    http://www.jroller.com/eu/entry/on_maven_support_in_myeclipse
    In a mean time, to allow MyEclipse users to continue using full power of m2eclipse, we created special update site that will disable Maven4MyEclipse and replace it with stock m2eclipse.
  59. Best of both worlds[ Go to top ]

    I'm a happy coder who managed to use best of both tools: ant and maven. I use ant's 1.6 modular build features to create reusable modular build system which uses defaults where possible and retrieves explicit settings (like build directory) from pom, if used in maven mode (its possible to use it without maven too). Maven pom is used to describe project dependencies and configuration. Maven ant tasks project is used to take dependency information from pom into ant filesets and paths. mvn eclipse:eclipse is used to create or update eclipse project from pom - no other tools are ever needed. Maven repository infrastructure (local, proxy and central) is used to store and share artifacts within team. There are few minor problems so far which I hope will be solved in next version of maven ant tasks, mostly related to multiproject setups, profiles and offline mode, though for now I'm much more satisfied than when used ant or maven alone.
  60. Maven is a bit of a pain to learn. I think this is where most gripes from Ant fans come from. For *most* Ant users, who very likely have no idea about the value-add that Maven brings over Ant. My favourite bits of Maven are, - simply updating the pom with whatever dependencies I want, and doing a mvn package. Maven finds the jars and installs them. No more manual downloading of jars (mostly, unless due to licensing like some SUN jars). This is worth the price of admission alone. - mvn cobertura:cobertura. Runs my tests and produces a line-by-line coverage analysis report. Makes doing TDD useful since I can see what code i'm testing. Awesome and simple. - mvn eclipse:eclipse. Updates my eclipse project classpath to match my pom - mvn jetty:run. Start up my app in Jetty. Easy. - mvn package. Builds my project according to whatever packaging i've chosen. No more putting together ant scripts, etc, to create .war files or whatever. I know its still simple in Ant but it doesn't get any simpler than 'mvn package'. On top of that, I don't think I could really go back to using unversioned jars, i.e. without the jar version no. appended to the jar file name. Makes it so much easier to stay on top of versioning issues. I've not looked at the MyEclipse plugin but can't really see why I'd need or want another layer on top of that. I've only used Maven2. Maven1 did seem like a dog. I think people need to state their Maven credentials before bitching about it, or at least honestly acknowledge how far up the steepish learning curve they are.
  61. ...but wait, there's more[ Go to top ]

    and who can forget... - mvn eclipse:eclipse -DdownloadSources to download and install source while updating the eclipse classpath. No more manual downloading and installing of source files, followed by more mucking about more in Eclipse configuring which source belongs to which jars. It honestly seems like too much hard work to go back to Ant.
  62. MyEclipse/Maven updates[ Go to top ]

    Please see the new thread regarding the Milestone (beta) 2 release if MyEclipse 7.0 and learn about the new choices users have with MyEclipse and Maven.