Maven Upload Requests

Carlos Sanchez added a comment - 12/Nov/06 12:37 PM The script is missing what subfolders you want to sync. We can't let you sync to /

Ben Fortuna added a comment - 14/Nov/06 6:37 AM Here is a second version of the mavensync script, which narrows the sync to the "net" directory

Ben Fortuna added a comment - 14/Nov/06 6:43 AM Just to explain a bit further, the goal here is to automatically upload releases of multiple open source projects, namely ical4j (ical4j.sf.net) and mstor (mstor.sf.net). The documentation on how to achieve this is very minimal, but I'm assuming this is the correct way. The reason I has originally specified the root directory (/) is that I don't have a lot in my maven repository right now, just the first release of ical4j and the parent pom. Note that the parent pom is under a different group id, which is why I have know specified to sync the 'net' directory. If you require me to be more specific I will need to provide two scripts: one to sync 'net.modularity' and one to sync 'net.fortuna' (I read somewhere that parent poms must also be uploaded to the repository, which is why I need both group ids synced). Let me know if there are further issues here. regards, ben

Carlos Sanchez added a comment - 16/Nov/06 2:58 AM you need one script for each group you own. We can't give you access to all / or to all net/

Ben Fortuna added a comment - 16/Nov/06 5:47 AM Updated maven sync script for the 'net.modularity' group id

Ben Fortuna added a comment - 16/Nov/06 5:48 AM Added maven sync script for the 'net.fortuna' group id

Carlos Sanchez added a comment - 16/Nov/06 8:28 PM After all this time you still don't understand that you can't upload thing in places that are not yours?? are you the owner of fortuna.net and modularity.net ??

Ben Fortuna added a comment - 16/Nov/06 9:28 PM Carlos, Are you talking about domain names now? Since when has Maven required you to actually own a domain name to use it's reversed form as a group id? Java most certainly does not have this restriction with package names, and if it did I can assure you the language would have failed long ago. This is obviously a departure from Maven 1.x, as I am almost certain that does not require you to own a domain name to publish under a group id. In fact the projects in question are in the maven repository right now and I have never had to prove association with a domain name. I surely hope I have misunderstood you, as up until now I have been on the maven bandwagon as a necessary part of a modern development environment. If you are going to start suggesting some kind of totalitarian rule over what goes in your repository then I think I'll be getting off this ride right now! regards, ben ps. Every single extra "restriction" you have highlighted on this issue are NOT documented anywhere. Don't expect me to read your mind to figure this stuff out. I have tried to be extremely patient with you resolving this issue, but I take offence and insult with your last comment. I can only suggest to you that it's not professional and/or acceptable in my books.

Carlos Sanchez added a comment - 16/Nov/06 10:08 PM From http://maven.apache.org/guides/mini/guide-ibiblio-upload.html "IMPORTANT considerations about the groupId: it will identify your project uniquely across all projects, so we need to enforce a naming schema. For projects with artifacts already uploaded to ibiblio it can be equal to the previous used, but for new projects it has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. There are a lot of poorly defined package names so you must provide proof that you control the domain that matches the groupId. Provide proof means that the project is hosted at that domain or it's owned by a member, in that case you must give the link to the registrar database (whois) where the owner is listed and the page in the project web where the owner is associated with the project. eg. If you use a com.sun.xyz package name we expect that the project is hosted at http://xyz.sun.com."

Ben Fortuna added a comment - 16/Nov/06 10:14 PM Fine. I'll just have to distribute the traditional way via sourceforge.net. I'm not sure who came up with that policy, but you must realise that you are discriminating against the small hobbyist developers that produce the libraries you guys depend on, but don't necessarily have a domain name to go with it (if we all had domains there would be no need for Sourceforge would there!). Sometimes I think you guys really lose sight of the bigger picture - just remember that not everyone is an Apache/Codehaus.. regards, ben

Carlos Sanchez added a comment - 17/Nov/06 10:56 PM I think you are misunderstanding things, you can use net.sf.ical4j or whatever sf project name you have, there are already a good number of them there http://repo1.maven.org/maven2/net/sf/

Ben Fortuna added a comment - 17/Nov/06 11:12 PM No I understand completely. What I don't understand is what the real benefit is of imposing such tight restrictions on Group Ids. It isn't going to help developers to locate dependencies more easily, as even the Java package naming convention states that there is no guarantee that the reversal of a package name corresponds to a domain on which it is hosted (it is purely /suggested/ as a mechanism to maintain uniqueness). The only reasoning I can see behind this is that you somehow believe the current structure is a bit disorganised. The real problem I have with this is that it imposes on my creative freedoms to manage and distribute my project using whatever Group Id I choose, as long as it is guaranteed to be unique. That is all that Java package naming aims to address, and I believe the same should apply to Maven Group Ids. regards, ben

Carlos Sanchez added a comment - 17/Nov/06 11:15 PM Nice, so you want to be able lets say to distribute things under "com.sun.ben" and we should let you, just because you like it and its possible with package names.

Ben Fortuna added a comment - 17/Nov/06 11:34 PM Not at all. Have you seen anyone use that kind of package convention apart from Sun? No one is stopping them, but you don't see it happen do you. Your suggestion of using net.sf.ical4j implies a direct connection between sourceforge and my project. What if I want to change to use objectweb, or even host it myself in the future? A group id of net.sf.ical4j would no longer make sense, and to change it means everyone using it will need to change there references. I'm sure you are aware that the aim of group ids is to guarantee a unique identifier. By the very definition of a single repository uniqueness is enforced, and as long as those group ids are reasonable there is no reason whatsoever to enforce a link between group ids and domain names. And might I say that *you* don't "let" me do anything when it come to *my* project. If you want my participation with your project then you will address my needs, and not the other way around. There are plenty of competing dependency management tools available that I'm sure won't try to impose such authoritarian rule. regards, ben

Carlos Sanchez added a comment - 18/Nov/06 12:24 AM maybe you haven't thought that somebody may buy fortuna.net and decide to deploy under that groupid, will you both deploy to the same place? if you move to other groupid you can copy all your previous artifacts, nobody will have to change their previous builds. {quote} And might I say that *you* don't "let" me do anything when it come to *my* project. If you want my participation with your project then you will address my needs, and not the other way around. There are plenty of competing dependency management tools available that I'm sure won't try to impose such authoritarian rule. {quote} Nice. You are the one that wants your stuff to be used by maven users. I'm spending my free time helping people get their stuff in maven repo, but for that there are some rules. If you don't like them you can argue in repository@maven.org, but right now the rules are the ones i told you. Even the most popular projects had adhered to these rules.

Ben Fortuna added a comment - 18/Nov/06 1:05 AM Well struts, wicket, and even maven saw fit to name their project without securing a domain name first. I'm sure such names were decided upon by a quick check that there weren't any existing projects using that name. How is a Maven group id any different? And if I take a quick look at the current repository as you suggested, I find the project 'ezwizard-rt' under the struts group id: http://repo1.maven.org/maven2/net/sf/struts/ From what I can tell, this project is not a part of struts, and after failing to find it on sourceforge I managed to discover that it is hosted here: http://www.superinterface.com/easywizard.htm So how have your rules helped in this case? It seems to me that it has made the repository structure more confusing, as you imply that there is a direct link between domain and group id where obviously, for this project at least, there isn't! And it is the Maven users that initially requested that I add my stuff to your repository. I am spending *my* free time helping to fulfull those users needs. Regardless of whether the "most popular projects" adhere to your rules, I am not comfortable with such rules that serve no obvious purpose. regards, ben