Jason Dillon wrote:
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.
"In theory there is no difference in theory and practice. In practice there
is."
I agree with your comments but I also recognize that it is a slippery slope. Who is responsible for
tracking the changes and lobbying the other groups? My limited experience tells me that this will
likely end up being a set of forked code from other projects that will be very difficult to manage.
for instance...say a quick change is made to XMLBeans and it get's put into our "local" copy. 4
months later the XMLBeans folks have not done anything with the patch and now after discussing it
further decide that it doens't fit with their direction. During that time Geronimo has relied on
the patch and changing direction is going to be painful.
I realize this is a worse case scenario but we had a similar situation with the Axis guys in cutting
a 1.4 release for us. It took about 6 months and I think was only done because David Blevins was
made a committer.
In order to consider this it would be great if you could flush out the different scenarios as you
see them and how we would handle them. I'm not the most administrative person on the planet and
what you are proposing sounds great and scare the heck out of me at the same time ;-0
--jason
