No, I believe that there will always be a time when builds are in
limbo due to reliance on our projects artifacts being deployed to a
remote repository... when they have not made it there yet.
IMO, the only way to avoid this limbo is to always build components
from source, removing the remote repository from the equation.
This is also the only way to ensure that when working with SNAPSHOT
artifacts, that you always use a known set, and don't accidentally
get a new artifact midway through your build.
--jason
On Dec 16, 2006, at 10:35 AM, Dain Sundstrom wrote:
This is because we have not been diligent in releasing sub projects
like Genesis, Specs, JavaMail and Geronimo schema. If we had, then
then nothing would be in limbo at all. In the future, I think we
should have the rule be no SNAPSHOTS to subprojects we control and
the exception to be SNAPSHOTS. Not like we currently have it were
everything under G has a SNAPSHOT dependency.
Basically, this shouldn't happen again.
-dain
On Dec 15, 2006, at 5:11 PM, Jason Dillon wrote:
Why is it that when we go through a voting cycle that builds are
left in limbo?
For example, to build server 1.2 at the moment, users need to also
know that they must build genesis 1.1 from its tag, openejb from
its tag, and then a handful of specs, from each of their
respective tags. I don't even know which tag is actually needed
for each of the damn specs, so I have to go hunt down what version
is actually being used, then check out each tag one by one...
or I have to hack the pom to add the "staged" repos, which is
equally worse has to build as tag I have to change its source?!?!
and IMO that is just unacceptable.
I would much rather check out everything that is needed from the
tag and build... though that brings me right back to this mess
with per-module versioned specs. Its a nightmare to find the
right tags, check them out and build them. The entire process
would be dramatically easier if there was on tag for the specs to
be checked out and built... and that is for manual or automated.
IMO these projects, and their branches should always be buildable,
at any time, with out making changes to sources... and we need to
be able to setup an automation process to help ensure that they
always remain buildable. It should be possible to setup an
automated build for release branches/tags during the voting phase,
and even more so, it should be possible to setup the automated
system to actually handle cutting that release.
BUT... to get to that point with the tools which we have decided
to use, we need to adhere to a few restrictions which simplify the
entire matter... which I don't think that many of you have even
thought about.
maybe the community does not want stable builds? maybe the
community does not want to have durable builds? maybe the
community does not want to have an automated system to ensure
build consistency?
maybe I am just wasting my time?
--jason
