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 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.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
~t~
--
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
