> The layout in repository was intentionally fixed. There are good reasons for > that. > I think that support for other protocols than file:// and http:// can be > considered > if there will be more users demanding it. > If you want to use ftp:// you can rise an issue in JIRA. > > I personally think that it is easier to set up own web server then ftp > server. > And FTP protocol is much more limited that HTTP/WebDav and etc. So I don't > see a reason > to use it.
No doubt there is a good reason for fixing the repository layout and for using http and file protocols, but what about company policies? Should developers that are obliged to use a proprietary repository structure not be able to benefit from Maven? If they can use Maven by providing another ArtifactDownloader implementation, why would that be a bad thing to do? It is not breaking the structure, it does not interfere with the rest of Maven. If it is a bad idea to have a custom implementation for those components, what is the reason then for having interfaces for those components? > I don't think that one project should produce more than one "heavy" artifact > like jar, war ejb etc. > But it's/ will be completely perfect for the project to publish multiple > artifacts like: jar, javadoc, src, pom > Usage patterns for both scenarios were frequently discussed on this list and > are supported > by Maven old. I agree that in most cases, one heavy jar is enough. But take Log4J as an example. Isn't there a log4j-core.jar and a log4j.jar? How would you handle that? Gino. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
