Urg... this is another thing about Maven that really bothers me...
we are SO completely dependent on other projects for our own
project to succeed.
This would not be a problem if we had our own repo that we had
complete ownership of. We could fix any poms and install fixed
plugins.
How would we get these fixes back into the community? I worry that
having our own repo would make it harder to assure that we are
using generally available versions of other projects, and make it
harder to contribute our fixes back to those projects. For
instance, it took me some time to get an m2 build of howl working
and find out how to get it published, but the result is IMO much
better for both howl and us than if we simply said "we'll just
stick a pom for howl in our private repo".
We could use JIRA to manage any customizations that we have been
forced to make to get _our_ build working, and then work with the
external groups to merge the changes and ultimately get sync'd up
with more official drops.
BUT, I still believe that it is in our communities best interest to
maintain our own repository.
And... the build would be completely repeatable. Chances are
that in a year or two, if anyone tries to build anything with
Maven off of an old branch it will fail miserably. IMO this is
not acceptable.
Future build failures should only result from someone trashing the
supposedly permanent ibiblio repo. As far as your other points,
any time we decide to use software written by some other community,
we are depending on them to do some work for us. I think we need
to adopt a process that assures our contributions to their project
in fact get back to their project in a timely fashion.
I agree completely. What I am suggesting is that we use our own repo
to facilitate this process while letting our project move forward.
The alternative is that we must work in lock step with every other
community... where a trivial change to a pom takes weeks to get
implemented and pushed.
I really don't like to have to go and check out a bunch of
external tools or libraries and then go step by step, configure
and build them... and hope like heck that their builds work all of
the time, and pray that Maven does not freak-out halfway through a
long build due to a missing dependency or repository timeout...
just to get the right bits in place to maybe get our build moving
forward,
Seems to me the alternative is to not use anyone elses code, which
I find unacceptable.
I don't believe that not using thirdparty code is an option. We just
need to find and implement a better way of dealing with them.
I do believe that for a large project like Geronimo, that the central
remote repository model breaks down and is not very functional for
current builds or for repeatable builds of older code.
I surely don't have all the answers, but I'd prefer that anything
we adopt doesn't result in our having all sorts of private changes
that are not accepted by projects we use.
I do not believe that this will be the case. The repo would mostly
exist to support the longevity of our builds and for short-term fixes
while we wait the term and lobby external groups to get changes
pushed back into their community.
So, some kind of geronimo repo that has a subset of publically
available stuff is ok with me, but putting private patches that
aren't from the originating project seems like asking for trouble.
I agree, though as mentioned above, some artifacts may be custom in
the short-term. For example, we could "fix" the xmlbeans artifacts
and poms, deploy them to our repo and then track the progress of
integrating them back into the main xmlbeans community with JIRA.
This is a case where we have a private version in the repo, but it
will only live there (with a specialized version of course) until the
time is passed when the xmlbeans team can work in the changes.
--jason
