Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, | Heh, so you are willing to trade build reproducibility (for all | projects linked to central repo) for care about the community? o.O | | Hrm, please put that on a vote before you do it! | | IF you are talking about putting up dummy (depsless, only GAV) POMs: | IMHO, by putting dummy poms (without dependency to not screw | existing builds), only ones with GAV, you do not provide any value to | community: OSS projects usually move fast, and will quickly switch to | newer (hopefully fixed) artifacts from central with correct POMs. And | the companies will... heh, they will use some advanced repo manager | to solve it ;D The content of such poms is no real value but it stops millions of totally useless requests towards ibiblio and produces longer builds and stupid warnings. So it is more a denial-of-service attack that should be stopped. Look at axis2 with all its dependencies! There is no newer version out and I have about 50-100 useless requests to missing poms per day. My project team has 10 developers so multiply this by ten. I am also using maven for my open-source project. Same result. As ibiblio if you can get a 404 statistic. When you change the version of one of your dependencies you always have to face the fact that transitive dependencies change. That has nothing to do wheter the earlier version had just a stupid GAV pom or not. Adding a pom with additional dependencies afterwards causes a change of transitive dependencies in projects that did not change anything. Please note that business projects need a config-management where deployment is audit-proof and rebuilding a release on an old tag should still have the same result as it had when the tag was created. As people describe there is a workaround to solve this issue for enterprises but if they dont why should we cause such trouble if there is no need to do so. Ahh - I read your posting again. You were not talking about dependencies in the later added poms but in the next version. So my last paragraph was not directly related to what you were saying... | | IF not, how would you be able to get authoritative data to fill in the | missing POMs? | | Thanks, | ~t~ | | On Jan 28, 2008 7:51 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: | if there's no pom uploaded then you can take 5 minutes of your time | and provide one. I try to do it for all the ones I use. It can be | because you care about the community or because you are selfish and | want your project to be reproducible ;) either way providing a pom | doesnt take that long | | Regards ~ Jörg | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoOyLmPuec2Dcv/8RAjbqAJ4m22dFzvlNd248uJNICYhc7eUVNQCfWkO1 ZNrRQwYYbbD439sTOJahMM0= =4TsK -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned fix layers for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix something that is _obviously_ wrong. But, heh, deps are not those sort of things. ~t~ On Jan 27, 2008 6:58 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 25-Jan-08, at 5:22 PM, Carlos Sanchez wrote: great, but - who is going to enforce it? - who is going to say what the right pom is for a project that doesnt build with Maven? If someone from a project submits a POM then we should take that. If projects don't then we take a submission from the community. The base requirement should be that the complete transitive closure be available publicly and preferably in central. The new artifact resolution code will be able to do this but right now if we required correct SCM information then we could have a process grab the code and try to build it for Maven projects. Oleg can speak to some of the work in the new artifact code that can help ensure the integrity of deployments. there's still people saying that poms should be modifiable! For a release it cannot be modifiable, period. The graph cannot be mutable after a release. That has to be written in stone. If someone doesn't see something and made a mistake then they have to release again. It boils down to we get strict or this body of information we have will grow less useful over time and
Re: Fix missing POM files
Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned fix layers for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix something that is _obviously_ wrong. But, heh, deps are not those sort of things. ~t~ On Jan 27, 2008 6:58 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 25-Jan-08, at 5:22 PM, Carlos Sanchez wrote: great, but - who is going to enforce it? - who is going to say what the right pom is for a project that doesnt build with Maven? If someone from a project submits a POM then we should take that. If projects don't then we take a submission from the community. The base requirement should be that the complete transitive closure be available publicly and preferably in central. The new artifact resolution code will be able to do this but right now if we required correct SCM information then we could have a process grab the code and try to build it for Maven projects. Oleg can speak to some of the work in the new artifact code that can help ensure the integrity of deployments. there's still people saying that poms should be modifiable! For a release it cannot be modifiable, period. The graph cannot be mutable after a release. That has to be written in stone. If someone doesn't see something and made a mistake then they have to release again. It boils down to we get strict or this body of information we have will grow less useful over time and that's all there is to it. -- Thanks, ~t~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned fix layers for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix
RE: Fix missing POM files
I think it's simple and is what we've been doing. Once it hits the central repo, it's done...no changes to anything period. The advanced repo manager thing is a workaround for sure, but in an enterprise a very valid and frequently used one. It obviously doesn't help OOS projects, but changing the things in the repos breaks stuff for everyone.
Re: Fix missing POM files
from m1 syncing partners that didnt have poms On Jan 28, 2008 11:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote- resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions),
Re: Fix missing POM files
I still don't see what's wrong with that. I know it can break your build, but people don't think those [WARN] messages in the cmdline and the fact that maven is hitting the internet trying to download the missing pom everytime, are the sign of a problem ??? On Jan 28, 2008 11:48 AM, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Jason van Zyl wrote: On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote: What's worse is if someone reports a missing pom, they then go and add a FULL pom with deps which then gets synced to central. That could cause issues as we all know. Are you serious? Yep. They did it for neethi just last week. Look at the time stamps at: http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0.2/ Dan Dan On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if
Re: Fix missing POM files
On Monday 28 January 2008, Jason van Zyl wrote: On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote: What's worse is if someone reports a missing pom, they then go and add a FULL pom with deps which then gets synced to central. That could cause issues as we all know. Are you serious? Yep. They did it for neethi just last week. Look at the time stamps at: http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0.2/ Dan Dan On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote- resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention
Re: Fix missing POM files
There's still around 5 releases every month only at apache that go to the m1 repo (most of them with poms). I'd rather have the official jars being deployed without poms than do it manually, and accept anybody's upload request for let's say Tomcat, with all the problems that it could cause. . On Jan 28, 2008 11:39 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 28-Jan-08, at 11:33 AM, Carlos Sanchez wrote: from m1 syncing partners that didnt have poms We should just shut off the m1 conversion. Happy to support the m1 repository mapping, but that process is broken not to mention it pegs the machine when it runs. On Jan 28, 2008 11:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata.
Re: Fix missing POM files
On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote: On Monday 28 January 2008, Jason van Zyl wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? Definitely from syncing partners is a huge one. I know the ws commons group at apache is REALLY bad about getting poms into their stuff on a consistent basis. Some releases do, but then the very next release might not. Then they get moved to submitting via JIRA. Carlos if they truly suck and they are abusing the direct access to the repository then we should turn off syncing from all the WS-* projects until they sort their shit out. They can potentially screw everyone. What's worse is if someone reports a missing pom, they then go and add a FULL pom with deps which then gets synced to central. That could cause issues as we all know. Are you serious? Dan On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote- resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should
Re: Fix missing POM files
given these premises - pom is not in the repo - project is not willing to put it then authoritative data can come from project users, after all this is a community. As i said before my opinion is that we can still put poms in projects that didnt have them On Jan 28, 2008 11:27 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Heh, so you are willing to trade build reproducibility (for all projects linked to central repo) for care about the community? o.O Hrm, please put that on a vote before you do it! IF you are talking about putting up dummy (depsless, only GAV) POMs: IMHO, by putting dummy poms (without dependency to not screw existing builds), only ones with GAV, you do not provide any value to community: OSS projects usually move fast, and will quickly switch to newer (hopefully fixed) artifacts from central with correct POMs. And the companies will... heh, they will use some advanced repo manager to solve it ;D IF not, how would you be able to get authoritative data to fill in the missing POMs? Thanks, ~t~ On Jan 28, 2008 7:51 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
On Monday 28 January 2008, Jason van Zyl wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? Definitely from syncing partners is a huge one. I know the ws commons group at apache is REALLY bad about getting poms into their stuff on a consistent basis. Some releases do, but then the very next release might not. What's worse is if someone reports a missing pom, they then go and add a FULL pom with deps which then gets synced to central. That could cause issues as we all know. Dan On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote- resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move
Re: Fix missing POM files
Heh, so you are willing to trade build reproducibility (for all projects linked to central repo) for care about the community? o.O Hrm, please put that on a vote before you do it! IF you are talking about putting up dummy (depsless, only GAV) POMs: IMHO, by putting dummy poms (without dependency to not screw existing builds), only ones with GAV, you do not provide any value to community: OSS projects usually move fast, and will quickly switch to newer (hopefully fixed) artifacts from central with correct POMs. And the companies will... heh, they will use some advanced repo manager to solve it ;D IF not, how would you be able to get authoritative data to fill in the missing POMs? Thanks, ~t~ On Jan 28, 2008 7:51 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote- resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could
Re: Fix missing POM files
i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could
Re: Fix missing POM files
If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced
Re: Fix missing POM files
On 25-Jan-08, at 5:22 PM, Carlos Sanchez wrote: great, but - who is going to enforce it? - who is going to say what the right pom is for a project that doesnt build with Maven? If someone from a project submits a POM then we should take that. If projects don't then we take a submission from the community. The base requirement should be that the complete transitive closure be available publicly and preferably in central. The new artifact resolution code will be able to do this but right now if we required correct SCM information then we could have a process grab the code and try to build it for Maven projects. Oleg can speak to some of the work in the new artifact code that can help ensure the integrity of deployments. there's still people saying that poms should be modifiable! For a release it cannot be modifiable, period. The graph cannot be mutable after a release. That has to be written in stone. If someone doesn't see something and made a mistake then they have to release again. It boils down to we get strict or this body of information we have will grow less useful over time and that's all there is to it. and the fact that maven is ready for business doesnt mean taht you can use anything however you want, you should enforce policies on what plugin versions you want, what third party libraries,... because we may take decisions here that will affect the decisions at some companies, while not at others. Many times there's not black or white On Jan 25, 2008 4:16 PM, Joerg Hohwiller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am sometimes late on threads but anyways... | i don't agree, the point of not having a pom there is to be able to | add one later with the right info. If you work against something | without pom, hey, it's your decision, but you are aware that it's a | problem, as all the warnings tell you I do NOT agree. Adding a jar and later some pom with dependencies is odd. You should enforce that no artifacts can go to central repro if they do not come with a proper pom. To fix the actual problem default poms should be added to the repository. Further versions of these artifacts can add the correct dependencies. Please consider that maven is not just used by open-source users for fun but also by brute business. If some company is running a deployment that comes to a wrong result because of dependencies in a pom that was just added to the repository (e.g. because then a different version than before was chosen for a dependent artifact), they will flame maven. Don't we say that maven is also ready for business? Do you have an idea how much harm the maven community has done to enterprise (and other) users by releasing buggy plugins? I do not want to blame anybody! Giving your spare time for open- source is worth some honor and humans make mistakes. But we should be aware of the sensibility of our decisions. Best regards ~ Jörg | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | Isn't the goal here to stop incessant warnings during a build about | trying to downalod a missing POM? | | The way to do that is to that is to upload a POM for that artifact to | the repository. | | But Nico is right is that the uploaded POM should not break existing | builds. Which means that the POM just needs to be bare bones and list no | dependencies as the missing POM introduces no deps. | | So Nico, I'd suggest you create a simple POM with just groupId, | artifactId and version and get it uploaded to the repository. | | Can I also suggest that it is a worthy task to auto generate and upload | such POMs for all artifacts in central with a missing POM. | | William | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | Sanchez | Sent: Tuesday, 16 October 2007 2:01 AM | To: Maven Developers List | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | different SMTP TO: and MIME TO: fields in the email addresses | | sorry, but that's not the case currently. If it has no metadata it can | be added, that's why you get warnings when the metadata is missing. | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I fully agree about collaborating and submitting more artifacts to the | repo with good meta-datas. The only issue I can see is about | reproductible builds if those meta-datas change. | | The established rule NOT to change meta-datas after publication | applies IMHO also to artifacts without meta-datas. Anyone providing | metadatas for an artifact that is allready in repo, so that can be | used by many people, will potentialy break there builds, with no way | in maven2 to quickly fix this issue by stopping the transitive | dependencies. | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I'm not the guy who uploaded castor 1.0
Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Carlos, | great, but | - who is going to enforce it? Sorry, I can not tell. Of course this is not easy to do. But you do have policies for your repository. It seems that they are not enforced or not strong enough. The best thing for a formal rule is to have a technical solution that prevents the rule to be violated. I just wanted to make sensible for the impact of changing the repository. | - who is going to say what the right pom is for a project that doesnt | build with Maven? Another good question. However, in our case we were talking about artifacts that have no pom. Then maven assumes a default pom with no dependencies. All that was suggested was to add this default pom explicitly. If this is wrong, it was wrong from the time the artifact was added. The policy is not to change artifacts after they have been deployed. So the project has to deploy a new version if the pom is wrong! A technical answer for your question is that you can use things like classpath helper to answer this. Anyhow you are right, that only to project owners should decide how there pom should be like. IMHO this is not the question here for the version that is already released. | | there's still people saying that poms should be modifiable! The chaos is already big enough. Please do not make it worse! Poms are modifyable but they should not be for releases in repositories like our central repo. | | and the fact that maven is ready for business doesnt mean taht you can | use anything however you want, you should enforce policies on what | plugin versions you want, what third party libraries,... because we | may take decisions here that will affect the decisions at some | companies, while not at others. Many times there's not black or white You are right. But again I just want to say be as sensible about changes as possible. Therefore my oppinion is: yes add these poms but without dependencies. If dependencies should be added, new versions have to be created. Take care ~ Jörg | | | On Jan 25, 2008 4:16 PM, Joerg Hohwiller [EMAIL PROTECTED] wrote: | Hi there, | | I am sometimes late on threads but anyways... | | | i don't agree, the point of not having a pom there is to be able to | | add one later with the right info. If you work against something | | without pom, hey, it's your decision, but you are aware that it's a | | problem, as all the warnings tell you | I do NOT agree. Adding a jar and later some pom with dependencies is | odd. You should enforce that no artifacts can go to central repro | if they do not come with a proper pom. | To fix the actual problem default poms should be added to | the repository. Further versions of these artifacts can add the | correct dependencies. | Please consider that maven is not just used by open-source users for fun but | also by brute business. If some company is running a deployment | that comes to a wrong result because of dependencies in a | pom that was just added to the repository (e.g. because then a different version | than before was chosen for a dependent artifact), they will flame maven. | Don't we say that maven is also ready for business? | Do you have an idea how much harm the maven community has done to enterprise | (and other) users by releasing buggy plugins? | I do not want to blame anybody! Giving your spare time for open-source is | worth some honor and humans make mistakes. But we should be aware of the | sensibility of our decisions. | | Best regards | ~ Jörg | | | | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | | Isn't the goal here to stop incessant warnings during a build about | | trying to downalod a missing POM? | | | | The way to do that is to that is to upload a POM for that artifact to | | the repository. | | | | But Nico is right is that the uploaded POM should not break existing | | builds. Which means that the POM just needs to be bare bones and list no | | dependencies as the missing POM introduces no deps. | | | | So Nico, I'd suggest you create a simple POM with just groupId, | | artifactId and version and get it uploaded to the repository. | | | | Can I also suggest that it is a worthy task to auto generate and upload | | such POMs for all artifacts in central with a missing POM. | | | | William | | | | | | -Original Message- | | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | | Sanchez | | Sent: Tuesday, 16 October 2007 2:01 AM | | To: Maven Developers List | | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | | different SMTP TO: and MIME TO: fields in the email addresses | | | | sorry, but that's not the case currently. If it has no metadata it can | | be added, that's why you get warnings when the metadata is missing. | | | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | | I fully agree about collaborating and submitting more artifacts to the | | repo with good meta-datas. The only issue I can see is about
Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am sometimes late on threads but anyways... | i don't agree, the point of not having a pom there is to be able to | add one later with the right info. If you work against something | without pom, hey, it's your decision, but you are aware that it's a | problem, as all the warnings tell you I do NOT agree. Adding a jar and later some pom with dependencies is odd. You should enforce that no artifacts can go to central repro if they do not come with a proper pom. To fix the actual problem default poms should be added to the repository. Further versions of these artifacts can add the correct dependencies. Please consider that maven is not just used by open-source users for fun but also by brute business. If some company is running a deployment that comes to a wrong result because of dependencies in a pom that was just added to the repository (e.g. because then a different version than before was chosen for a dependent artifact), they will flame maven. Don't we say that maven is also ready for business? Do you have an idea how much harm the maven community has done to enterprise (and other) users by releasing buggy plugins? I do not want to blame anybody! Giving your spare time for open-source is worth some honor and humans make mistakes. But we should be aware of the sensibility of our decisions. Best regards ~ Jörg | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | Isn't the goal here to stop incessant warnings during a build about | trying to downalod a missing POM? | | The way to do that is to that is to upload a POM for that artifact to | the repository. | | But Nico is right is that the uploaded POM should not break existing | builds. Which means that the POM just needs to be bare bones and list no | dependencies as the missing POM introduces no deps. | | So Nico, I'd suggest you create a simple POM with just groupId, | artifactId and version and get it uploaded to the repository. | | Can I also suggest that it is a worthy task to auto generate and upload | such POMs for all artifacts in central with a missing POM. | | William | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | Sanchez | Sent: Tuesday, 16 October 2007 2:01 AM | To: Maven Developers List | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | different SMTP TO: and MIME TO: fields in the email addresses | | sorry, but that's not the case currently. If it has no metadata it can | be added, that's why you get warnings when the metadata is missing. | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I fully agree about collaborating and submitting more artifacts to the | repo with good meta-datas. The only issue I can see is about | reproductible builds if those meta-datas change. | | The established rule NOT to change meta-datas after publication | applies IMHO also to artifacts without meta-datas. Anyone providing | metadatas for an artifact that is allready in repo, so that can be | used by many people, will potentialy break there builds, with no way | in maven2 to quickly fix this issue by stopping the transitive | dependencies. | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm | also | not | the guy who used it in the project. I came later and have to | maintain | the | project now. | that's collaboration ;) if you want to use something that uses | castor and want to do it the right way, yes you should contribute a | pom | | Do you think I should contribute an empty POM just to ensure | no-one can latter contribute one with some (maybe) unexpected | dependencies ? | not an empty pom, but it shouldn't take more than 10 min to figure | out what the dependencies are | | A better solution IMHO should be to have an option for a | dependency in | my | POM to excludes all transitive dependencies. The current | exclusion elements require to list dependencies. With such a | feature, a project | that | has legacy reference on a dependency with no POM can simply set | no-transitivity to be reproductible in any case. | that's already filled in jira | | Many artifacts in the repo don't have POMs (from m1 - m2 | migration ?) | not lately but old ones, yes | | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: | Warning : This could break existing projects ! | | My project has a dependency on castor-1.0. This one has no | POM. | If you povide one, rebuilding my app will introduce new | transitive dependencies that were not expected, and my build | will become non-reproductible. | | Only new release of an artifact can come with a POM. | | mmm, that's not the case, you shouldn't made releases of things | without poms, you should have contributed one already | | | Nico. | | 2007/10/11, Jochen Wiedmann [EMAIL
Re: Fix missing POM files
great, but - who is going to enforce it? - who is going to say what the right pom is for a project that doesnt build with Maven? there's still people saying that poms should be modifiable! and the fact that maven is ready for business doesnt mean taht you can use anything however you want, you should enforce policies on what plugin versions you want, what third party libraries,... because we may take decisions here that will affect the decisions at some companies, while not at others. Many times there's not black or white On Jan 25, 2008 4:16 PM, Joerg Hohwiller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am sometimes late on threads but anyways... | i don't agree, the point of not having a pom there is to be able to | add one later with the right info. If you work against something | without pom, hey, it's your decision, but you are aware that it's a | problem, as all the warnings tell you I do NOT agree. Adding a jar and later some pom with dependencies is odd. You should enforce that no artifacts can go to central repro if they do not come with a proper pom. To fix the actual problem default poms should be added to the repository. Further versions of these artifacts can add the correct dependencies. Please consider that maven is not just used by open-source users for fun but also by brute business. If some company is running a deployment that comes to a wrong result because of dependencies in a pom that was just added to the repository (e.g. because then a different version than before was chosen for a dependent artifact), they will flame maven. Don't we say that maven is also ready for business? Do you have an idea how much harm the maven community has done to enterprise (and other) users by releasing buggy plugins? I do not want to blame anybody! Giving your spare time for open-source is worth some honor and humans make mistakes. But we should be aware of the sensibility of our decisions. Best regards ~ Jörg | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | Isn't the goal here to stop incessant warnings during a build about | trying to downalod a missing POM? | | The way to do that is to that is to upload a POM for that artifact to | the repository. | | But Nico is right is that the uploaded POM should not break existing | builds. Which means that the POM just needs to be bare bones and list no | dependencies as the missing POM introduces no deps. | | So Nico, I'd suggest you create a simple POM with just groupId, | artifactId and version and get it uploaded to the repository. | | Can I also suggest that it is a worthy task to auto generate and upload | such POMs for all artifacts in central with a missing POM. | | William | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | Sanchez | Sent: Tuesday, 16 October 2007 2:01 AM | To: Maven Developers List | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | different SMTP TO: and MIME TO: fields in the email addresses | | sorry, but that's not the case currently. If it has no metadata it can | be added, that's why you get warnings when the metadata is missing. | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I fully agree about collaborating and submitting more artifacts to the | repo with good meta-datas. The only issue I can see is about | reproductible builds if those meta-datas change. | | The established rule NOT to change meta-datas after publication | applies IMHO also to artifacts without meta-datas. Anyone providing | metadatas for an artifact that is allready in repo, so that can be | used by many people, will potentialy break there builds, with no way | in maven2 to quickly fix this issue by stopping the transitive | dependencies. | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm | also | not | the guy who used it in the project. I came later and have to | maintain | the | project now. | that's collaboration ;) if you want to use something that uses | castor and want to do it the right way, yes you should contribute a | pom | | Do you think I should contribute an empty POM just to ensure | no-one can latter contribute one with some (maybe) unexpected | dependencies ? | not an empty pom, but it shouldn't take more than 10 min to figure | out what the dependencies are | | A better solution IMHO should be to have an option for a | dependency in | my | POM to excludes all transitive dependencies. The current | exclusion elements require to list dependencies. With such a | feature, a project | that | has legacy reference on a dependency with no POM can simply set | no-transitivity to be reproductible in any case. | that's already filled in jira | | Many artifacts
Re: Fix missing POM files
On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. that's collaboration ;) if you want to use something that uses castor and want to do it the right way, yes you should contribute a pom Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? not an empty pom, but it shouldn't take more than 10 min to figure out what the dependencies are A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. that's already filled in jira Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) not lately but old ones, yes Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
I fully agree about collaborating and submitting more artifacts to the repo with good meta-datas. The only issue I can see is about reproductible builds if those meta-datas change. The established rule NOT to change meta-datas after publication applies IMHO also to artifacts without meta-datas. Anyone providing metadatas for an artifact that is allready in repo, so that can be used by many people, will potentialy break there builds, with no way in maven2 to quickly fix this issue by stopping the transitive dependencies. Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. that's collaboration ;) if you want to use something that uses castor and want to do it the right way, yes you should contribute a pom Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? not an empty pom, but it shouldn't take more than 10 min to figure out what the dependencies are A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. that's already filled in jira Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) not lately but old ones, yes Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
sorry, but that's not the case currently. If it has no metadata it can be added, that's why you get warnings when the metadata is missing. On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I fully agree about collaborating and submitting more artifacts to the repo with good meta-datas. The only issue I can see is about reproductible builds if those meta-datas change. The established rule NOT to change meta-datas after publication applies IMHO also to artifacts without meta-datas. Anyone providing metadatas for an artifact that is allready in repo, so that can be used by many people, will potentialy break there builds, with no way in maven2 to quickly fix this issue by stopping the transitive dependencies. Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. that's collaboration ;) if you want to use something that uses castor and want to do it the right way, yes you should contribute a pom Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? not an empty pom, but it shouldn't take more than 10 min to figure out what the dependencies are A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. that's already filled in jira Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) not lately but old ones, yes Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
Isn't the goal here to stop incessant warnings during a build about trying to downalod a missing POM? The way to do that is to that is to upload a POM for that artifact to the repository. But Nico is right is that the uploaded POM should not break existing builds. Which means that the POM just needs to be bare bones and list no dependencies as the missing POM introduces no deps. So Nico, I'd suggest you create a simple POM with just groupId, artifactId and version and get it uploaded to the repository. Can I also suggest that it is a worthy task to auto generate and upload such POMs for all artifacts in central with a missing POM. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, 16 October 2007 2:01 AM To: Maven Developers List Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has different SMTP TO: and MIME TO: fields in the email addresses sorry, but that's not the case currently. If it has no metadata it can be added, that's why you get warnings when the metadata is missing. On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I fully agree about collaborating and submitting more artifacts to the repo with good meta-datas. The only issue I can see is about reproductible builds if those meta-datas change. The established rule NOT to change meta-datas after publication applies IMHO also to artifacts without meta-datas. Anyone providing metadatas for an artifact that is allready in repo, so that can be used by many people, will potentialy break there builds, with no way in maven2 to quickly fix this issue by stopping the transitive dependencies. Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. that's collaboration ;) if you want to use something that uses castor and want to do it the right way, yes you should contribute a pom Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? not an empty pom, but it shouldn't take more than 10 min to figure out what the dependencies are A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. that's already filled in jira Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) not lately but old ones, yes Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism .html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
i don't agree, the point of not having a pom there is to be able to add one later with the right info. If you work against something without pom, hey, it's your decision, but you are aware that it's a problem, as all the warnings tell you On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: Isn't the goal here to stop incessant warnings during a build about trying to downalod a missing POM? The way to do that is to that is to upload a POM for that artifact to the repository. But Nico is right is that the uploaded POM should not break existing builds. Which means that the POM just needs to be bare bones and list no dependencies as the missing POM introduces no deps. So Nico, I'd suggest you create a simple POM with just groupId, artifactId and version and get it uploaded to the repository. Can I also suggest that it is a worthy task to auto generate and upload such POMs for all artifacts in central with a missing POM. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, 16 October 2007 2:01 AM To: Maven Developers List Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has different SMTP TO: and MIME TO: fields in the email addresses sorry, but that's not the case currently. If it has no metadata it can be added, that's why you get warnings when the metadata is missing. On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I fully agree about collaborating and submitting more artifacts to the repo with good meta-datas. The only issue I can see is about reproductible builds if those meta-datas change. The established rule NOT to change meta-datas after publication applies IMHO also to artifacts without meta-datas. Anyone providing metadatas for an artifact that is allready in repo, so that can be used by many people, will potentialy break there builds, with no way in maven2 to quickly fix this issue by stopping the transitive dependencies. Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not the guy who used it in the project. I came later and have to maintain the project now. that's collaboration ;) if you want to use something that uses castor and want to do it the right way, yes you should contribute a pom Do you think I should contribute an empty POM just to ensure no-one can latter contribute one with some (maybe) unexpected dependencies ? not an empty pom, but it shouldn't take more than 10 min to figure out what the dependencies are A better solution IMHO should be to have an option for a dependency in my POM to excludes all transitive dependencies. The current exclusion elements require to list dependencies. With such a feature, a project that has legacy reference on a dependency with no POM can simply set no-transitivity to be reproductible in any case. that's already filled in jira Many artifacts in the repo don't have POMs (from m1 - m2 migration ?) not lately but old ones, yes Nico. 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. mmm, that's not the case, you shouldn't made releases of things without poms, you should have contributed one already Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism .html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? quoteopen an issue at JIRA MEV with the relevant information /quote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
In that case I think the warning about a missing POM needs to be stronger and make people aware of the implications of someone suddenly uploading one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, 16 October 2007 8:22 AM To: Maven Developers List Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has different SMTP TO: and MIME TO: fields in the email addresses i don't agree, the point of not having a pom there is to be able to add one later with the right info. If you work against something without pom, hey, it's your decision, but you are aware that it's a problem, as all the warnings tell you On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: Isn't the goal here to stop incessant warnings during a build about trying to downalod a missing POM? The way to do that is to that is to upload a POM for that artifact to the repository. But Nico is right is that the uploaded POM should not break existing builds. Which means that the POM just needs to be bare bones and list no dependencies as the missing POM introduces no deps. So Nico, I'd suggest you create a simple POM with just groupId, artifactId and version and get it uploaded to the repository. Can I also suggest that it is a worthy task to auto generate and upload such POMs for all artifacts in central with a missing POM. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
http://maven.apache.org/guides/mini/guide-maven-evangelism.html On 10/4/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, repo1.maven.org contains a number of jar files without POM. Examples include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are quite a pain in the development by causing unnecessary and failed download requests every time, I'd like to fix this, at least for those where I note it. Question is how. Suggestion: Create new upload bundles under com.ctc (woodstox), or org.exolab (Castor)? Other ideas? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. Nico. 2007/10/11, Jochen Wiedmann [EMAIL PROTECTED]: On 10/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: http://maven.apache.org/guides/mini/guide-maven-evangelism.html Quoting from that text: ... unless you provide a pom for it ... I am ready to do that, at least in the cases that harm me. But how? Through the standard upload procedure? Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
On 10/11/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: Warning : This could break existing projects ! My project has a dependency on castor-1.0. This one has no POM. If you povide one, rebuilding my app will introduce new transitive dependencies that were not expected, and my build will become non-reproductible. Only new release of an artifact can come with a POM. There is no reason to omit dependencies in these cases, for the sake of compatibility. Sorry for my bad english. What I meant to say: There is no reason *not* to omit dependencies. The intention is not to fix the lack of transitive dependencies but to avoid unnecessary slow down of the build scripts. -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nag: Fix missing POM files
Ping! Jochen Wiedmann wrote: Hi, repo1.maven.org contains a number of jar files without POM. Examples include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are quite a pain in the development by causing unnecessary and failed download requests every time, I'd like to fix this, at least for those where I note it. Question is how. Suggestion: Create new upload bundles under com.ctc (woodstox), or org.exolab (Castor)? Other ideas? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Fix-missing-POM-files-tf4569446s177.html#a13143712 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fix missing POM files
Hi, repo1.maven.org contains a number of jar files without POM. Examples include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are quite a pain in the development by causing unnecessary and failed download requests every time, I'd like to fix this, at least for those where I note it. Question is how. Suggestion: Create new upload bundles under com.ctc (woodstox), or org.exolab (Castor)? Other ideas? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
