RE: Why I hate Maven :-)
take a look at geronimo for a LARGE project using maven. -Original Message- From: Anil Arora [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 7:03 PM To: Maven Users List; Brett Porter Subject: RE: Why I hate Maven :-) Your counter point of having multiple artifacts per project is still a little troubling. I think the example of ejb, taglib, etc. is good when you're thinking about that level of granularity. In our application, we have quite a few files which can be customized by a customer. So, it doesn't make sense to archive these in a jar file. But with the number of artifacts that needs to be in the final distribution, this method does not scale. To me, it seems that maven tends to be more suited for applications that result in few artifacts. I still would like to see how an application like Tomcat can be built using maven. Anil -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 1:18 AM To: Maven Users List Subject: Re: Why I hate Maven :-) On 6/14/05, Jim Mochel [EMAIL PROTECTED] wrote: Brett Porter recently posted a BLOG entry asking why some people hate Maven. Hmmm.. unless I'm mistaken that was last year! Maybe the blog software decided to send out a refresh :) Regardless, you make some good points here - thanks for taking the time to do so. I've spent some time putting together a response, and have also put it up on the blog as I think it would be of general interest to people who have read the original post. http://blogs.codehaus.org/people/brett/archives/001110_re_why_do_you_hat e_maven.html Im happy to discuss any of these points further, or examine your SOA use case in more detail WRT Maven2 if you'd like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Why I hate Maven :-)
On 6/15/05, Ryan Sonnek [EMAIL PROTECTED] wrote: take a look at geronimo for a LARGE project using maven. I haven't looked at geronimo's code, but sometimes large may not mean representative. For example I have a client who has a typical J2EE webapp + some webstart thick clients. One of these thick clients has two configurations. It's packaged as the same jar, but depending on the parameters in the JNLP file, it will trigger a different internal module. Following maven's rule of one artifact per project, I've created 3 projects, one for the jar file, one for each of the 2 JNLP. The JNLP plugin makes us put the properties in the project.properties which cannot be inherited. So I end up with 2 very similar projects, with the same dependencies, and almost the same project.properties. Then I've got to merge these resulting artifacts inside the same directory for deployment. In that particular case, I find that maven (or the JNLP plugin) gets in my way. It was much cleaner with Ant. Sometimes best practise and productivity don't go hand in hand. Cheers, Jerome PS: if someone knows a clean solution to my issue... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why I hate Maven :-)
not sure why geronimo isn't representitive of what maven can do. they have an extremely modular codebase, and are building a J2EE server, so it seems perfectly logical that J2EE applications could follow the same model. project.properties are inherited. I'm doing a very similar thing with my project. want a real world example? see https://shard.dev.java.net/source/browse/shard/ for my open source project. I'll gladly talk with you more about how I got around the problems you describe. -Original Message- From: jerome lacoste [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 10:16 AM To: Maven Users List Subject: Re: Why I hate Maven :-) On 6/15/05, Ryan Sonnek [EMAIL PROTECTED] wrote: take a look at geronimo for a LARGE project using maven. I haven't looked at geronimo's code, but sometimes large may not mean representative. For example I have a client who has a typical J2EE webapp + some webstart thick clients. One of these thick clients has two configurations. It's packaged as the same jar, but depending on the parameters in the JNLP file, it will trigger a different internal module. Following maven's rule of one artifact per project, I've created 3 projects, one for the jar file, one for each of the 2 JNLP. The JNLP plugin makes us put the properties in the project.properties which cannot be inherited. So I end up with 2 very similar projects, with the same dependencies, and almost the same project.properties. Then I've got to merge these resulting artifacts inside the same directory for deployment. In that particular case, I find that maven (or the JNLP plugin) gets in my way. It was much cleaner with Ant. Sometimes best practise and productivity don't go hand in hand. Cheers, Jerome PS: if someone knows a clean solution to my issue... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
RE: Why I hate Maven :-)
Heck, I'm interested even if Jerome isnt! Let's have it... -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 11:20 AM To: Maven Users List; jerome lacoste Subject: RE: Why I hate Maven :-) not sure why geronimo isn't representitive of what maven can do. they have an extremely modular codebase, and are building a J2EE server, so it seems perfectly logical that J2EE applications could follow the same model. project.properties are inherited. I'm doing a very similar thing with my project. want a real world example? see https://shard.dev.java.net/source/browse/shard/ for my open source project. I'll gladly talk with you more about how I got around the problems you describe. -Original Message- From: jerome lacoste [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 10:16 AM To: Maven Users List Subject: Re: Why I hate Maven :-) On 6/15/05, Ryan Sonnek [EMAIL PROTECTED] wrote: take a look at geronimo for a LARGE project using maven. I haven't looked at geronimo's code, but sometimes large may not mean representative. For example I have a client who has a typical J2EE webapp + some webstart thick clients. One of these thick clients has two configurations. It's packaged as the same jar, but depending on the parameters in the JNLP file, it will trigger a different internal module. Following maven's rule of one artifact per project, I've created 3 projects, one for the jar file, one for each of the 2 JNLP. The JNLP plugin makes us put the properties in the project.properties which cannot be inherited. So I end up with 2 very similar projects, with the same dependencies, and almost the same project.properties. Then I've got to merge these resulting artifacts inside the same directory for deployment. In that particular case, I find that maven (or the JNLP plugin) gets in my way. It was much cleaner with Ant. Sometimes best practise and productivity don't go hand in hand. Cheers, Jerome PS: if someone knows a clean solution to my issue... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why I hate Maven :-)
On 6/15/05, Poppe, Troy [EMAIL PROTECTED] wrote: Heck, I'm interested even if Jerome isnt! Let's have it... -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 11:20 AM To: Maven Users List; jerome lacoste Subject: RE: Why I hate Maven :-) not sure why geronimo isn't representitive of what maven can do. they have an extremely modular codebase, and are building a J2EE server, so it seems perfectly logical that J2EE applications could follow the same model. I don't say that is it not representative, I mean that it won't exercise all things one may want to do. project.properties are inherited. I'm doing a very similar thing with my project. want a real world example? see https://shard.dev.java.net/source/browse/shard/ for my open source project. I'll gladly talk with you more about how I got around the problems you describe. Then my bad. The documentation I came upon was wrong or I misunderstood it. But if I want to inherit it propertly, I will have to do something like client/core client/jnlpcommon/project.properties client/jnlp_1/ client/jnlp_2/ with jnlp_1 and jnlp_2 inheriting from jnlpcommon. I don't say that I don't want to use maven. It's sometimes a little bit verbose to me. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why I hate Maven :-)
On 6/14/05, Jim Mochel [EMAIL PROTECTED] wrote: Brett Porter recently posted a BLOG entry asking why some people hate Maven. Hmmm.. unless I'm mistaken that was last year! Maybe the blog software decided to send out a refresh :) Regardless, you make some good points here - thanks for taking the time to do so. I've spent some time putting together a response, and have also put it up on the blog as I think it would be of general interest to people who have read the original post. http://blogs.codehaus.org/people/brett/archives/001110_re_why_do_you_hate_maven.html Im happy to discuss any of these points further, or examine your SOA use case in more detail WRT Maven2 if you'd like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why I hate Maven :-)
Brett, Thank you for taking the time to put out a very concise and thoughtful response. As for the blog putting it out again, I think I trusted the search engines to much. I have searches that run each morning and one of them brought that blog entry up for the first time so I treated it as relatively recent. Jim Brett Porter [EMAIL PROTECTED] 06/14/2005 04:17 AM Please respond to Maven Users List To Maven Users List users@maven.apache.org cc Subject Re: Why I hate Maven :-) On 6/14/05, Jim Mochel [EMAIL PROTECTED] wrote: Brett Porter recently posted a BLOG entry asking why some people hate Maven. Hmmm.. unless I'm mistaken that was last year! Maybe the blog software decided to send out a refresh :) Regardless, you make some good points here - thanks for taking the time to do so. I've spent some time putting together a response, and have also put it up on the blog as I think it would be of general interest to people who have read the original post. http://blogs.codehaus.org/people/brett/archives/001110_re_why_do_you_hate_maven.html Im happy to discuss any of these points further, or examine your SOA use case in more detail WRT Maven2 if you'd like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why I hate Maven :-)
Your counter point of having multiple artifacts per project is still a little troubling. I think the example of ejb, taglib, etc. is good when you're thinking about that level of granularity. In our application, we have quite a few files which can be customized by a customer. So, it doesn't make sense to archive these in a jar file. But with the number of artifacts that needs to be in the final distribution, this method does not scale. To me, it seems that maven tends to be more suited for applications that result in few artifacts. I still would like to see how an application like Tomcat can be built using maven. Anil -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 1:18 AM To: Maven Users List Subject: Re: Why I hate Maven :-) On 6/14/05, Jim Mochel [EMAIL PROTECTED] wrote: Brett Porter recently posted a BLOG entry asking why some people hate Maven. Hmmm.. unless I'm mistaken that was last year! Maybe the blog software decided to send out a refresh :) Regardless, you make some good points here - thanks for taking the time to do so. I've spent some time putting together a response, and have also put it up on the blog as I think it would be of general interest to people who have read the original post. http://blogs.codehaus.org/people/brett/archives/001110_re_why_do_you_hat e_maven.html Im happy to discuss any of these points further, or examine your SOA use case in more detail WRT Maven2 if you'd like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why I hate Maven :-)
Jim, On your point about SOA and Maven. We have the same problem at my company. But you have to remember that the unit tests are to test the unit of deployment and its code. It sounds like what you're doing is integration testing (proxy code - server code) which is a different kettle of fish. We are thinking of getting around this using mock objects to actually test the proxy code and creating a custom project of integration tests which will be built separately when all the code has been deployed. Chris -Original Message- From: Jim Mochel [mailto:[EMAIL PROTECTED] Sent: 13 June 2005 16:15 To: Maven Users List Subject: Why I hate Maven :-) Brett Porter recently posted a BLOG entry asking why some people hate Maven. I couldn't get the blog entry dialog to take more than two sentences so I figured I would post it here. Please read this without assuming that I am attacking Maven 1x. I clearly like something about Maven since I am still using it. Keeping in mind that much of this looks like it is being solved by M2 here are some of my all time greats hassles: ISSUE: Multiproject handling is a tacked on option whose interaction with other goals becomes problematic. M2: Appears to have been addressed in M2. ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion. M2: Appears to have been addressed in M2. ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals. M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation. Ideology - More often than not, If Maven's best practices doesn't fit my real world issues I am screwed. The workarounds take much more time than they might (aggravated by lack of documentation issues) and almost always cause bad side effects.. Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets. ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment. There are circumstances here at my site with an SOA deployment which means that EVERYDAY we deal with the negative impact of those features. We can have all unit testing OR none AND we have to write all of our own code to manage the issues many of which could have been avoided if we had a way to run the tests as a process after we had successfully built, installed, and did a deploy to the app servers. Yes, we have workarounds and they are not ideal. M2: I am not yet clear that this is resolved in M2. ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. At one point I was giving developers a process that had them creating 8 projects for each service to be deployed even though the actual source code was 3-11 files per service. This was necessary so we could manage the generation of key elements and unit tests. In effect, the source code was the same but it had several expressions in the world at large and each one required a separate project. Now we currently put it all in one project and I have created a group of rules to generate ALL the artifacts for a single service from the one project. It doesn't fit perfectly with the existing other practices inside Maven but it gives my fellow developers a lot less complexity to manage and thus there are a lot fewer mistakes along the way. The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference. M2: I have seen no sign that this is simpler in M2. ISSUE: The versioning of artifacts is VERY much a one size fits rarely UNLESS you are in total control of all of your codebase. If there is any place where a specific artifact name doesn't work or cannot contain a version at deployment time (.NET strongly named assemblies come to mind - painfully) then there are rarely workarounds that don't take many hours to implement and integrate into the process. M2: I have seen no sign that this is simpler in M2. ISSUE: Repositories assume WORA semantics for the artifacts.
Re: Why I hate Maven :-)
ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. SNIP The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference. I find this especially true once you try to build dll's in Maven. You really have a header file, a lib file and a dll file as an output. We are also building installshield installers with it. This can also give multiple artifacts like a client installer, a web installer, ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why I hate Maven :-)
We follow a similar method here. Any system testing that is to be done at a unit level must use mocks. Each project's test directory contains unit and system dirs, with the unitTestSourceDirectory pointing to the desired test type at build/post-deploy time. cheers, Justin Stevenson, Chris Chris.Stevenson@ To DrKW.com 'Maven Users List' users@maven.apache.org 14/06/2005 01:28 cc AM Subject RE: Why I hate Maven :-) Please respond to Maven Users List [EMAIL PROTECTED] he.org Jim, On your point about SOA and Maven. We have the same problem at my company. But you have to remember that the unit tests are to test the unit of deployment and its code. It sounds like what you're doing is integration testing (proxy code - server code) which is a different kettle of fish. We are thinking of getting around this using mock objects to actually test the proxy code and creating a custom project of integration tests which will be built separately when all the code has been deployed. Chris -Original Message- From: Jim Mochel [mailto:[EMAIL PROTECTED] Sent: 13 June 2005 16:15 To: Maven Users List Subject: Why I hate Maven :-) Brett Porter recently posted a BLOG entry asking why some people hate Maven. I couldn't get the blog entry dialog to take more than two sentences so I figured I would post it here. Please read this without assuming that I am attacking Maven 1x. I clearly like something about Maven since I am still using it. Keeping in mind that much of this looks like it is being solved by M2 here are some of my all time greats hassles: ISSUE: Multiproject handling is a tacked on option whose interaction with other goals becomes problematic. M2: Appears to have been addressed in M2. ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion. M2: Appears to have been addressed in M2. ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals. M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation. Ideology - More often than not, If Maven's best practices doesn't fit my real world issues I am screwed. The workarounds take much more time than they might (aggravated by lack of documentation issues) and almost always cause bad side effects.. Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets. ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment. There are circumstances here at my site with an SOA deployment which means that EVERYDAY we deal with the negative impact of those features. We can have all unit testing OR none AND we have to write all of our own code to manage the issues many of which could have been avoided if we had a way to run the tests as a process after we had successfully built, installed, and did a deploy to the app servers. Yes, we have workarounds and they are not ideal. M2: I am not yet clear that this is resolved in M2. ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. At one point I was giving developers a process that had them
RE: Why I hate Maven :-)
Chris, Thank you for the comment. Integration is indeed another issue. Unfortunately , even our base services need to be deployed into a container before testing. The proxy generation has to occur at the same time for reasons specific to the way another group choose to design the SOA. LOL. Jim Stevenson, Chris [EMAIL PROTECTED] 06/13/2005 11:28 AM Please respond to Maven Users List To 'Maven Users List' users@maven.apache.org cc Subject RE: Why I hate Maven :-) Jim, On your point about SOA and Maven. We have the same problem at my company. But you have to remember that the unit tests are to test the unit of deployment and its code. It sounds like what you're doing is integration testing (proxy code - server code) which is a different kettle of fish. We are thinking of getting around this using mock objects to actually test the proxy code and creating a custom project of integration tests which will be built separately when all the code has been deployed. Chris -Original Message- From: Jim Mochel [mailto:[EMAIL PROTECTED] Sent: 13 June 2005 16:15 To: Maven Users List Subject: Why I hate Maven :-) Brett Porter recently posted a BLOG entry asking why some people hate Maven. I couldn't get the blog entry dialog to take more than two sentences so I figured I would post it here. Please read this without assuming that I am attacking Maven 1x. I clearly like something about Maven since I am still using it. Keeping in mind that much of this looks like it is being solved by M2 here are some of my all time greats hassles: ISSUE: Multiproject handling is a tacked on option whose interaction with other goals becomes problematic. M2: Appears to have been addressed in M2. ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion. M2: Appears to have been addressed in M2. ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals. M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation. Ideology - More often than not, If Maven's best practices doesn't fit my real world issues I am screwed. The workarounds take much more time than they might (aggravated by lack of documentation issues) and almost always cause bad side effects.. Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets. ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment. There are circumstances here at my site with an SOA deployment which means that EVERYDAY we deal with the negative impact of those features. We can have all unit testing OR none AND we have to write all of our own code to manage the issues many of which could have been avoided if we had a way to run the tests as a process after we had successfully built, installed, and did a deploy to the app servers. Yes, we have workarounds and they are not ideal. M2: I am not yet clear that this is resolved in M2. ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. At one point I was giving developers a process that had them creating 8 projects for each service to be deployed even though the actual source code was 3-11 files per service. This was necessary so we could manage the generation of key elements and unit tests. In effect, the source code was the same but it had several expressions in the world at large and each one required a separate project. Now we currently put it all in one project and I have created a group of rules to generate ALL the artifacts for a single service from the one project. It doesn't fit perfectly with the existing other practices inside Maven but it gives my fellow developers a lot less complexity to manage and thus there are a lot fewer mistakes along the way. The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference. M2: I have seen no sign that this is simpler in M2. ISSUE: The versioning of artifacts
