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]
