Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

Post reply on HN
Print view View original

161–168 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#161

Post by eeperson »

spullara wrote: post #155
eeperson wrote: post #154

Earlier quoted context omitted.

Does this already exist? Based on the top result I get from a Google search for 'maven copy file' [1] this seems to be not very well solved. The top response in that Stack Overflow page recommends calling out to a completely different build tool. It seems like part of the problem is that frequently you will have several plugins that each solve part of a problem but it is difficult to combine the plugins so they solve…

The stack overflow question is about copying files to a remote server during a build, not just copying a file to a directory. Use http://maven.apache.org/plugins/maven-resources-plugin/examp... — if your build copies files to a remote server you have other problems.

As far as I can tell, that question doesn't say anything about about a remote (as in on another machine) server. It sounds like the question is just about copy files to a directory outside of the Maven project.

I know that Maven is ultimately capable of being used to copy a file. However, there are multiple ways to do this because all of the options have limitations and are somewhat awkward to use. For instance, I don't think resource plugin you linked to supports renaming as part of the copy.

Why is using your build to push files to a remote server a problem? A common use would be to deploy local code to an environment that simulates production. If that cannot be done as part of the build then it will exist as scripts that exist outside of the build. This means that there will probably be a lot more 'reinventing the wheel'.

Re: Why Everyone Eventually Hates or Leaves Maven

#162

Post by mathattack »

chii wrote: post #76
mathattack wrote: post #35

I love the Access analogy. It burned me quite a few times in prior lives, when every project started with, "Let's build an access database." Ultimately it's a tradeoff in abstraction and usability.

i actually doubt the problems with access are really that bad - sure you outgrow it eventually, but you'd be surprised at what its capable of. Often the real underlying cause is that a business owner with little to no programming knowledge makes something which works ok, but is architectually wrong. For example, bad table structure/relationships. Or after a while, they want to 'put their app online', and asks a poor…

This is true too. Sometimes screens are designed by people who don't think in terms of relational tables, and then the data eventually gets messed up.

Re: Why Everyone Eventually Hates or Leaves Maven

#163

Post by spullara »

eeperson wrote: post #161
spullara wrote: post #155

Earlier quoted context omitted.

The stack overflow question is about copying files to a remote server during a build, not just copying a file to a directory. Use http://maven.apache.org/plugins/maven-resources-plugin/examp... — if your build copies files to a remote server you have other problems.

As far as I can tell, that question doesn't say anything about about a remote (as in on another machine) server. It sounds like the question is just about copy files to a directory outside of the Maven project. I know that Maven is ultimately capable of being used to copy a file. However, there are multiple ways to do this because all of the options have limitations and are somewhat awkward to use. For instance, I do…

Ah, like some of the commenters, I interpreted this line:

"I have config files and various documents that I want to copy from the dev environment to the dev-server directory using Maven2."

To mean a remote dev-server and then maven-upload was mentioned in the list of solutions. Let me step back a bit.

Maven is primarily interested in the process of building. There are functions that allow deployment but generally that is not Maven's domain. Using Maven as part of your deployment process is definitely going to be at odds with a smooth experience. I think of it like making non-default choices in Ruby on Rails, you are asking for pain.

As to your point about "reinventing the wheel" for deployment using maven, I would suggest that there are many tools designed for deployment and would use those instead, like cap.

Re: Why Everyone Eventually Hates or Leaves Maven

#164

Post by eeperson »

spullara wrote: post #163
eeperson wrote: post #161

Earlier quoted context omitted.

As far as I can tell, that question doesn't say anything about about a remote (as in on another machine) server. It sounds like the question is just about copy files to a directory outside of the Maven project. I know that Maven is ultimately capable of being used to copy a file. However, there are multiple ways to do this because all of the options have limitations and are somewhat awkward to use. For instance, I do…

Ah, like some of the commenters, I interpreted this line: "I have config files and various documents that I want to copy from the dev environment to the dev-server directory using Maven2." To mean a remote dev-server and then maven-upload was mentioned in the list of solutions. Let me step back a bit. Maven is primarily interested in the process of building. There are functions that allow deployment but generally tha…

I can understand making that interpretation at first glance.

I agree that the process of building should be the primary focus of a build tool. I also, think that the secondary purpose is to make development easier. That is why you do 'rake rails' instead of having to use cap to deploy your changes locally. It's not that hard to come across a scenario that falls in to one of these goals that requires custom logic (like copying a file, or something similar). Some of this should go in custom plugins so it can be reused. However, some of it is small and non-generic and makes no sense as a plugin. The solution you pointed to for copying a file involves substantially more code to include and configure the plugin than it would take in other JVM build tools (such as SBT or Gradle) to simply specify that you want to copy a file.

I agree that doing deployment for final builds or to shared environments are better served by a different tool.

Re: Why Everyone Eventually Hates or Leaves Maven

#165

Post by frugalmail »

meaty wrote: post #149
frugalmail wrote: post #102

Earlier quoted context omitted.

As part of your build were you wiping out your local repo ( ~/.m2 ) for some reason? It would only need to check if you don't already have the version specified in your pom in your local repo.

Yes - all our builds are done from zero state i.e. and empty directory. We even deploy a new JVM each time (as we have to test against 3 different JVMs).

Either make your 3rd party librariers part of an OS snapshot, or make it part of your source repository. The flaw seems like it's in your build as opposed to the build system. I'm all for wiping away intermediate work products, but you don't need to test the ability to download 3rd party librariers each time. You could use the md5 or sha1 files that get published to the standard maven repo. and that would be a miniscule download, and once you have it, you could just compare it to the existing files.

Re: Why Everyone Eventually Hates or Leaves Maven

#166

Post by andrewmccall »

chii wrote: post #73
spullara wrote: post #63

Earlier quoted context omitted.

That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.

agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter. The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your o…

I thought that, then I installed nexus and let it proxy the remote repositories and really haven't looked back. Takes some time to setup (few hours). But makes life so much easier that it's well worth the effort, especially that with Java you WILL have a dependency on a 3rd party jar from Oracle that for whatever reason won't ever show up in maven central or want to include some other 3rd party repository.

Re: Why Everyone Eventually Hates or Leaves Maven

#167

Post by eru »

gizmo686 wrote: post #88
laureny wrote: post #55

Earlier quoted context omitted.

> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwd…

My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like: Collections.sort(myList, new new Comparator () { public int compare(E o1, E o2) { return 01.val-02.val } } (You cou…

I used to be in the same camp about not using languages that require an IDE. But I have recently started using something akin to a Haskell IDE, and I have to say, things like displaying the inferred types of expressions in a tooltip and jump-to-definition are nice to have.

Re: Why Everyone Eventually Hates or Leaves Maven

#168

Post by jebblue »

frugalmail wrote: post #107
jebblue wrote: post #70

Good article. I like the idea of what Maven tries to achieve but I prefer monkeying with ant because I can get things done. If Maven or its successor ever gets to where things can't get into a mucked up state; I'm in.

strange, by default maven is much more strict about things, so it's hard to muck up. Perhaps you weren't creating the maven project in the format it wants you to create it in (which IMO, is a good one). Have you tried creating new projects with mvn archetype:generate ?

>> Generates a new project from an archetype, or updated the actual project if using a partial archetype. If the project is fully generated, it is generated in a directory corresponding to its artifactId. If the project is updated with a partial archetype, it is done in the current directory.

I don't recall trying that however, sorry that whole description from the link you provided, it just doesn't make sense to me. In general, when I try to use Maven, Eclipse ends up complaining. Then I fix it so Eclipse is happy then Maven complains.

Maybe the answer for me would really just be get the Maven and the Eclipse people to agree on how to create and manage projects with the Eclipse wizards.

Post reply on HN