jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: [GUMP] Build Failure - Taglibs
Date Fri, 29 Jun 2001 16:04:59 GMT
Thanks for clarifying the purpose of GUMP, it really hadn't been clear to
me before.

I heartily agree with the goals of GUMP and applaud your efforts to
enforce some API quality control.

The only questions left are process related.

Who decides that an API is deprecated and no longer supported?

Can other projects comment on these decisions before it is made?
(For examples James comments about providing backward compatability)

Where are notifications about this sent?

How much advance notice is given so that projects which have dependencies
can take care of it before you enforce it with GUMP?

Perhaps GUMP could be run once when a decision to deprecate an API 
has been made so that those projects who are using the old API can 
be identified and notified.  (So that we don't get a long build failure
email every single day on the list)

Then later after a grace period, the nightly GUMP starts enforcing it.

Is there any place where the minimum API dependencies are documented
so that developers can determine in advance if they will be in
compliance?

Regards,

Glenn

Sam Ruby wrote:
> 
> Glenn Nielson wrote:
> >
> > What is GUMP, and what service does it provide for the jakarta-taglibs project?
> 
> Gump is an initiative I started late last year to provide early warning of
> version incompatibilities that will affect various Java projects,
> particularly those under the Jakarta and xml.apache.org umbrellas.
> 
> As taglibs have a lot of external dependencies, I would think that it would
> be difficult to monitor each, so a service which provides early
> notification would be of great value.  But that's just me.  What do you
> think?
> 
> Note: in many cases, the breaking API change was unintentional; in many
> others I have convinced the owner of the API to merely deprecate the old
> interface instead of removing it right away.
> 
> > GUMP does a verification that jakarta projects build, but doesn't honor their
> > API version dependencies?  Isn't that a bit draconian?  Is this something
> > you decided, or is this a position of the Jakarta PMC?
> 
> Gump does a verification that the jakarta projects build with the latest
> versions of their dependencies.
> 
> This is an initiative I have undertaken.  Every member of the PMC is aware
> of this, and many have encouraged me to be *MORE* draconian, but I have
> elected to be a bit more reserved.  In this case, I only started alerting
> on Xalan1 dependencies at the point when Xalan1 is going out of service.
> 
> Note: I personally have a serious problem with each project independently
> making version dependency choices, as all too often the end result is that
> it simply is not possible to deploy a solution containing multiple Jakarta
> projects.
> 
> > Perhaps verifying that jakarta projects build and policing use of deprecated
> > API's should be separate things.
> 
> Gump does the verification against deprecated APIs.  Much as I dislike the
> notion of a project having an strong dependency on an specific version of
> another product, if someone wants to verify that dependency, they certainly
> are free to do so - separately.
> 
> > Posting a long GUMP build failure to tablibs-dev every day due to GUMP not
> > honoring API dependicies doesn't solve anything, and when it fails doesn't
> > finish verifying the normal jakarta-taglibs build process.
> 
> Let me try once again.  Gump does a verification of taglibs-dev against the
> latest version of its dependencies.  As an extreme example, it actually
> builds jakarta-ant from source and then uses that version to build the
> remainder of the projects.  Since I have started doing this, the number of
> incompatible changes to Ant has dropped to essentially zero.
> 
> I can provide innumerable recent examples where this notification has
> resulted in the change in one or both of the projects involved.
> 
> Again, verifying the "normal" jakarta-taglibs build process is, as you
> suggest, a separate thing.
> 
> > (Not the author of jakarta-taglibs/xtags)
> 
> IMHO, if you can't find a maintainer for xtags, it should be removed.  If
> it is maintained, it should not depend on things which are out of service.
> 
> - Sam Ruby

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Mime
View raw message