Henning I'm only going to respond to this email, since it is the only one in this thread that actually tries to contribute something to the progress of this project....
> - getting rid of the "SNAPSHOT" concept. This is fundamentally flawed. > Lets check at every build process whether "there is a newer jar in the > repository" is bad. -1 : One of the benefits to Maven is its ability to keep un-related projects in sync. Honestly, since Maven, I've had better success at building Jakarta projects. I contribute this, in part, to the SNAPSHOT concept of benefiting the cross-pollination of open source projects. However - SNAPSHOTS should be replaced with actual versions, when creating a source release. > - Make builds completely offline by default. If a jar is missing, die. -1 : Again, one major benefit to Maven is being able to resolve dependencies for you. Don't change the online behavior to appease the situation that you have a slow connection. Instead create a more robust lookup that distributes the load. AND if your project doesn't require SNAPSHOTS don't use them (most production project don't), but if you are working with a project that is in-development than you want to stay in sync. In the end, it is the developers call, and it should stay that way. Dependencies should (IMHO) be resolved in the following way local repository -> internal repository -> master repository (or mirror) -> domain specific repositories The last one Maven doesn't currently have, the DNS SRV proposal will make that possible. > - Have a switch doing a "closure" which does explicit download of all > missing jars at that point. Then you have a set of jars in your local > repository, which can be used to build. You have a reliable set of > jars to be able to test a local change. If the build breaks, it was your > change and not some developer uploading a newer "snapshot" version while > you were not looking. > > If something needs a "newer" jar, either run this closure switch again > or, > even better, maybe have > > % maven --update <artifact-id>, e.g. maven --update commons-collections > > which then pulls the most current release from the repository. I agree with Jason on this one, this is useful, but doesn't necessarily help development. And it is basically making it harder for a developer - let me explain. Currently, unless SNAPSHOT is specified, dependencies are resolved in your local repository first, therefore a build on hits the remote repository once! Instant "closure" > - get rid of the "symlink" concept on ibiblio. If you need a newer > version of the jar, you're willing to wait. Let maven check all existing > versions of an artifact and "get the newest" What? To me, it sounds like you just described a SNAPSHOT > - add a "manifest" file to each jar directory. This is managed at upload > time and can be downloaded by maven to get md5 sums, current versions > available and other meta information. Get an upload application / tool. Actually, this is similar to an idea I had. Last night I was trying to think of how to provide project-by-project customizable organization of their repository space. Then it hit me - A meta file "repository.xml". In this scenario <domain> specifies the origin of the project <groupID> provides the placement in a repository (restriction groupID must begin with the revers domain, and is required. Domain is optional, if domain is not specified it is considered equal to the reverse of groupID). Each project directory can be organized in a default manner (currently how it is done today, with artifact naming conventions, Jar/Distribtuions/License directories), but if repository.xml exists in the project's top level directory, than it is processed. This provides an extension point that can have artifact - physical location mappings. PROS; - Ultimate extensibility over time (consist extension point) - Very flexible in regards to project specific organization - Still provides default layout for *most* projects, since specific project organization is probably going to be a rare thing CONS: - Need to tread carefully as far as performance is concerned (adding xml processing to artifacts may provide a bottleneck). I do feel though that this is going to be a rare case for most projects. > - finally do a _clear_ definition of the semantics of This is being established. The repository as it stands right now, however, is evolving so there are artifacts that don't necessarily belong. I assume once a future repository layout is agreed on (Jason did mention that it would be the "final" layout change), that their will be a cleanup cycle. Until then developers just need to deal with it. It doesn't interfere with the dependency resolution. > After you get _these_ things nailed down, you can even start to think > about replicating or clustering maven repositories. I'm really scared, > thinking about a _really_ popular project which is used by thousands > of developers starting to use maven. Think Tomcat. Maven has grown fast and will continue to grow fast. Don't be scared, be excited. Maven is evolving, and in my opinion, has the potential of becoming the defacto standard for building projects. It is no secret, that it is not there yet. (and get the facts straight - JBoss knows this, and isn't making any moves. Someone mentioned it on the list, but that's about it. Somewhere along the way the message got misinterpreted. I lurk on that list. However, the fact that someone even mentioned Maven shows that it is making waves outside of the Turbine world. My hat is tipped to you Jason.) Help Maven get there through positive contributions. I think it is apparently clear that no one wants (or has the time) to deal with bullshit. - Mike > > Jason often talks about how he does not like "half-assed" > approaches. I let it to your imagination what my opinion about the > current maven repository structure is... :-) > > Regards > Henning > > Jason: BTW: Do you have any traffic numbers from the ibiblio repo? > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > Java, perl, Solaris, Linux, xSP Consulting, Web Services > freelance consultant -- Jakarta Turbine Development -- hero for hire > > --------------------------------------------------------------------- > 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]
