> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2003 2:34 PM > To: [EMAIL PROTECTED] > Subject: RE: Setting up Maven-New > > > > 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.
Because any company hopeful can profit from "standart"repository layout in several ways: a) standard it is "standard". I think that this is already a good reason... And this standard is based on proven, good practices b) Once maven will be supported by GUI/IDEs like Eclipse etc.. those tools will be able to help you to create your project.xml file and for example let browse Ibiblio repository and let you point at desired artifact c) There are already some efforts to develop more complex tools which are making repositories yet more powerful: like auto discovery of locally available repositories, indexers etc. > 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? > Because it is always good idea to have an interface :D > > 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? > I wanted to say there are lightweight and heavyweight artifacts types (not files) I see any jar, war, ear (doesn't matter how big the file is) as heavy artifact. In case if log4j will be mavenized there should be two subproject core, optional Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
