Torsten Curdt wrote:
Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.
I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that directory in the
checkout area as first repository server in the search list.
So where is the big difference? For every fresh checkout you download
the jars from subversion.
Guys I have no solution at hand but let's not throw out the baby with
the bath water. I would be good to summarize all the pain points and
post them over in maven land. The pain being so bad that we are
(somehow) considering going back to ant should be alarming enough.
Actually, speaking on behalf of the ant team, can I extend a big
(tentative) welcome back :)
Another point seems to be forgotten in this discussion so far - the
legal aspects of distributing jars. Does the ASF want to re-distribute
3rd party jars? Plus: based on a chat Sylvain and me had with Cliff
during ApacheCon it seems we could have blocks providing bridging code
to LGPL ...as long as we do not provide the jar and the block is
optional. (Sylvain, did I summarize that correctly?)
There is always the option of a public yet locked down repository with
the sun jars and/or the other external dependencies. Working on a
sourceforge repo, we keep extra stuff under SCM, and have the dependency
logic look there first.
you could even have an SCM-managed repo on sourceforge or codehaus for
this other stuff, though it would be a somewhat public admission that
the main repository has failed.
I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.
Maybe we can get a statement on the maven self-update and
unreliable-messed-up-repository situation. From what it sounds they
are working on it. So let's not work this out in our little cocoon
corner but let's hear what they have to say.
In a way, many of the stuff in M2 is experimental; a build tool that
effectively encodes beliefs about how a project should be structured and
delivered, focusing on component-based development instead of
application dev. I also think its time to look at how well some of the
experiment is working.
Personally, I always experience a bit of fear when adding a new
dependency to a project. the repository stuff, and estimate a couple of
hours to get every addition stable, primarily by building up a good
exclusion list.
M2, and <m2:libraries> in ant, has changed the nature of the problem,
from "what versions of what things do I need with this?" to "how much of
this stuff do I really need?" and "why are my junit tests not compiling
with an error about assertTrue not being known", the latter seguing into
"where is junit3.7 coming from?". Its a form of progress, but still
painful. Similarly, keeping a repository cache under SCM does at least
give you a structured layout for storing multiple versions of stuff
under SCM, with flick-of-a-switch access to new versions. It just adds
an extra step "pom creation/fixup" to the process.
Is it worse than before? Better? Or just, well, different? and if things
are either worse or not as good as they could be, what can be changed?
One underlying cause seems to be pom quality. Open source software dev
is a vast collection of loosely coupled projects, and what we get in the
repository in terms of metadata matches this model. Each project
produces artifacts that match their immediate needs, with POM files that
appear to work at the time of publishing. Maven then caches those and
freezes that metadata forever, even if it turns out that the metadata
was wrong. There's far better coherence within Gump, where the metadata
is effectively maintained more by the gump team themselves than by the
individual projects.
Question is, what to do about it? And if the m2 repository was an
attempt to leave the problems of the M1 repository behind, has it worked?
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
