-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments are inline. Please bear with me, I think my responses are as lengthy as your original email! :(
Cheers, John Ashley Williams wrote: | Sincere apologies to the dev team if this email seems like a troll, I | absolutely don't mean it to be. I'm aware that they continue to do | outstanding work and are few in number. | | The more I use Maven the more I get a feel for the size and shape of it | and find myself looking for features that aren't there. Since I joined | the community I've posted questions on what I consider to be the most | important aspects of a build system namely (yes in this order): | | 1. Usability from Ant - there are hundreds of Ant targets out there | that are useful for me today. I can't justify waiting for them to be | rewritten as Maven equivalents not only because I need functionality | today, but also because I don't see why I have to abandon my experience | with ant. I've already addressed this with you and others on this list. I've mentioned that I'm fully in favor of this sort of integration, and I have some starting points from Chris that I'll be putting in to allow this sort of thing. You don't have to wait for all of Ant's API to be replicated; you only have to wait for me to get this one change in place. :) | | 2. Usability from Eclipse - when will I be able to ditch the command | line and create and manage projects entirely from eclipse This depends on people with Eclipse development experience (not experience using Eclipse) picking up the task and running with it. We're trying to get something together in the way of a more concerted effort, but I'm sure you'll agree that getting a stable API was the first thing to do, since otherwise the Eclipse integration project would have to track a moving target. Now that we've got a beta-1 release, we can start thinking about this. | | 3. Need to do a myriad of simple things such as automatically run java | command or deploy to tomcat. I used to do this all the time in my ant | scripts, ie run my build.xml script and at the end it would run my app | on completion. It's a credit to those on this list who reply with ideas | and workarounds - however this is kind of related to 2 above, where | there are lots of ant tasks out there that are tested to death and that | I should be able to use today. The funny thing about Maven 2 is that it facilitates external plugin development. You can load a plugin from a repository hosted anywhere. Personally, I feel strongly that executing random commands from within the build process is a Bad Thing, and a thing that is bad and common with Ant. Maven - and also Ant, to a lesser extent - is a build tool. It's not a launching platform, and it's not a tool to be used to run your coffee maker. Executing random commands from a configuration in a POM is: a. unscaleable, since that runtime config is not encapsulated for reuse b. bound to partition your build logic into multiple pieces, which now have to be maintained from multiple sources. In Ant, you can do anything you please, including things that don't relate to the process of building software. It's important to keep a clear idea of the problem domain we're trying to address here. Having said that, there's nothing stopping you from hosting your own maven-foo-plugin on Sourceforge or somesuch. If you find what you perceive to be a hole in our plugin offering, and cannot convince us to fill it, there's nothing stopping you from scratching your own itch. We currently have maven-execute-plugin on the mojos project, but I'd really like to see it deprecated and eliminated eventually. | | 4. Online documentation. Simple example was trying to get the assembly | plugin to work which Daniel Shomer had to look into the source code to | advise me of what to do. This is just one example of many. You're not the first to point this out, and properly so. Just this week, one of the devs started fulltime on fixing this. Documentation has lagged for a few reasons, which I don't offer as excuses. First, the devs have been trying to stabilize the featureset and functionality before we try to document it. This is sort of a chicken-egg scenario, because (as was pointed out) its easier to maintain a clear design between multiple devs when you have documentation, but documentation of an evolving API gets stale quickly. Now that you've read the source code for the assembly plugin, will you contribute some documentation? | | 5. Other project structures. Sometimes I will encounter a project where | all the source code is in one tree (beginning with com/). I'm not | saying its any better than one directory per artifact, but I am saying | I encounter such projects in my career and as such I know I wouldn't be | able to use maven. This project can get a little preachy, and I'm no exception. We tend to believe that we've seen a lot of use cases (many on this list), and that our standard layout is the most elegant solution THAT WE'VE FOUND SO FAR. I emphasize that, because it's important to acknowledge that today's gospel is tomorrow's quaint idea. We're focusing on providing support for that standard layout/model right now, but we will be adding support for other project layouts when we learn of deficiencies. What we most need is use cases. If you have a specific one, can you share it? Where, specifically, are you having trouble with meshing your layout and the POM? | | 6. Contribute to the code. I have tried to get a foot in the door in | order to fix some of my own critisisms, but the lack of javadocs mean | that I really can't do this other than for some simple plugins. That is | unless I had lots of time to spare which I don't. In turn that makes me | concerned how the project will attract other developers to move things | along quickly. I addressed this a little bit above, but I believe Maven 2 is still climbing that maturity curve. We're climbing fast, but there are bound to be places that need attention. Javadocs may help, but an architectural overview and set of mini HOW-TOs may go a lot further. There are very few methods in the code that aren't self-explanatory, at least at a high level. However, I still agree that javadocs would be a good thing. Unfortunately, as you've so eloquently pointed out, there is a long line of Good Things waiting for attention...this is where we have to prioritize, and choose which ones we will attend to first. We've chosen code/feature stability, and API stability heretofore, but we're starting to focus on POM usability, additional plugin languages, and documentation now that we're in bugfix mode. If you've spent any time in the sources, and found that you understood even a small portion when you were done, would you be willing to write some of these javadocs and submit a patch? Every contribution, however small, will push us closer to the level of maturity you desire. | | I realize there may be workarounds for some of the above, but I | couldn't stick my neck on the line for a dev team and recommend sharing | of eclipse hack scripts etc as a way of working. I'm also putting my | selfish hat on and say that I'd like to do the above without defending | it - there are a few threads on this list already that deal with the | pros and cons. | | *************************************** | | Now I'll turn my attention to Ivy. I've began to look at this product | and it seems to offer many of the features of Maven including | | 1. transitive dependencies If I understand correctly, Ivy depends on profile name consistency for transitivity to function properly... | 2. compatibility with the ibiblio repository Maven 2 has this compat as well, and can probably supply the same level of functionality as Ivy given the quality of metadata in the m1 repository. You can specify a repository with <layout>legacy</layout> and it should work. But we're hoping for much more than this. | | and in addition | | 1. the online docs are excellent even if they are in broken english Ivy is an overlay for Ant, meant only to provide transitive dependency resolution and compat with the m1 repository. This means it's a relatively small project, and therefore have the ability to climb that maturity curve faster. As a side note, Ant 1.7 will be using Maven 2.0's artifact-handling API. This, after Ivy has been out there available for integration for some time now. Why is that, do you think? | 2. Can manage projects from with eclipse, since they are just ant | projects (with simple projects, haven't tried anything tricky) What level of integration do you need here? Would it be feasible, for example, to create a set of command-line execution profiles in Eclipse, to call various m2 targets? I've done this successfully with svn, when I found subclipse to be far too sluggish and flaky. | 3. Can manage maven style module directory structures or single source | trees. Obviously being Ant, it can manage any structure you like, but | these are the only two sane ones I know. If I understand correctly, the m2 eclipse plugin does have some support for this, although I'm not the best person to speak about it. To some extent, solutions to this will be compromised by Eclipse's lack of nested project support...which in some cases can lead to set-semantics when collecting dependencies for a hierarchy of projects...which can in turn lead to sources compiling in Eclipse but not in Maven, since the dependency declarations are not the same. The eclipse integration has been escalated as a priority recently, but we're not likelly to have anything for at least a few weeks. We understand the market share that Eclipse commands, and its value for integration...unfortunately, we haven't had the time to devote to external m2 integations up to now. | | Yes there is stuff that it doesn't have such as a built in lifecycle, | but with what I've learnt from the maven layout, I feel I could quite | easily replicate that in ant in a reusable way. That said I would | prefer not to have to. I suppose I'm looking for reassurance as to why | Maven is the way to go because there seems to be considerable overlap | with Ivy. 'Considerable' is a tad exaggerated, IMHO. Maven gives you reusability, not only of plugin functionality, but also of project information (the POM specifies most of what plugins need, so project configuration scales better than Ant for the marginal plugin). It also provides a single, simple lifecycle that ensures a sane progression from task to task in order. This lifecycle is the same for everything you will build, since plugins bind to the lifecycle behind the scenes. If you attempted to build a lifecycle on top of Ant, I think you'd find ~ a couple of things to be true: 1. it's not as simple as it seems, particularly if you build multiple types of projects (EJB, EAR, WAR, JAR, DLL, RPM, ...) 2. unless you attempt to open source your own solution - which means it will have to have general applicability, which itself is not a trivial goal - you will have to maintain your lifecycle layer in addition to your actual build scripts. Tracking something like this against updates in Ant and Ivy is not trivial...I tried something similar before Maven came along. The problem is that maintaining this lifecycle layer will not directly impact your company's bottom line, so they will be reluctant to give you much slack time to maintain it. | | **************************************** | | I realize that I am being very selfish here, but I have to think very | carefully about what I invest my time in. Maven has all the hallmarks | of being that software that I felt was missing during my career, which | is why I care enough about it to spare the time for these critisisms. I | just want to be sure it has a chance of gaining critical mass. | | Maybe the gatekeeper/guardian of this project needs to write some sort | of Jerry Maguire style memo that says what Maven's purpose is and plans | are so that we can all keep focused on that. | | Maybe my views aren't representative of a large enough demographic in | which case this email will just slip away into obscurity, but either | way thanks for reading and please don't take it as a troll I appreciate you taking the time to articulate your concerns. There is no doubt in my mind that many of the points you raise will resound with users, both current and potential. However, I have a question for you: How long did you spend on this email? It's fairly involved, and judging by the time I've spent responding, it took some effort. Did you do this in the course of your workday? If so, can you afford this amount of time a couple times a week? I'd like to encourage you to spend this amount of time exploring our APIs, writing javadocs (or whatever doco, etc. you see fit) and submitting patches. This much effort from a few users like you would really make a difference fast, IMO. Just something to think about. Even small patches will eventually add up. - -john | | -AW | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDMCeJK3h2CZwO/4URAhfPAKCD1iOtdPe2NO0j8KY6vg0L7oUW4ACgnZpk 7bbtGsKkiZKm8o/wOqY4Sjo= =JcXf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
