Yes, *if* a project wants to use it, they should all use the same thing. That way, we can put something in the parent pom file that uses the annotations.
On Thu, Mar 19, 2009 at 8:36 AM, Paul Benedict <pbened...@apache.org> wrote: > sebb, > > I must have mis-stated my point. If Commons Lang uses JCIP @Immutable > annotations, and another Commons project uses a theoretical XYZ > @NotMutable annotations, we will have lost the ability to track bugs > across project boundaries. So my point was that we should all agree > that using JCIP -- if you want to use them -- is the canonical > bug-detecting annotations for any Commons project. Let's just avoid > duplication. > > Paul > > On Thu, Mar 19, 2009 at 6:07 AM, sebb <seb...@gmail.com> wrote: >> On 19/03/2009, Paul Benedict <pbened...@apache.org> wrote: >>> I think the use of JCIP annotations should be an Apache Commons-wide >>> decision. It would only be sensible to share the annotations across >>> projects. Otherwise, we could get fragmentation pretty easily. >> >> Fragmentation? >> >> If a project uses concurrency annotations, it should use the same >> library, buy I see no reason why every component should _have_ to use >> them. >> >>> >>> Paul >>> >>> >>> On Wed, Mar 18, 2009 at 9:48 PM, sebb <seb...@gmail.com> wrote: >>> > On 19/03/2009, Stephen Colebourne <scolebou...@btopenworld.com> wrote: >>> >> sebb wrote: >>> >> >>> >> > >>> >> > > Are you proposing including these pieces of annotation code in >>> [lang], >>> >> or >>> >> > > just referencing them? If its just referencing them, then it has no >>> real >>> >> > > effect, and should be fine (aprt from making the compilation a >>> little >>> >> more >>> >> > > complex) >>> >> > > >>> >> > > >>> >> > >>> >> > I'm not sure what you mean by "including" or "referencing". >>> >> > >>> >> > I am proposing to add >>> >> > >>> >> > import net.jcip.annotations.Immutable >>> >> > and >>> >> > @Immutable >>> >> > >>> >> > to the source files of classes that deserve it. Similarly for the >>> other >>> >> cases. >>> >> > >>> >> > Much like using @Override, except that the annotations are not part >>> of the >>> >> JDK. >>> >> > >>> >> >>> >> Thats OK technically (as there is no runtime dependency on >>> >> net.jcip.annotations). However, I suspect it will confuse users, as >>> very few >>> >> people realise that no dependency is created beyond compilation time. >>> >> >>> >> So, overall, I'm dubious as to whether the value is sufficient to >>> >> compilcate the compliation and to field the inevitable >>> confusion/questions >>> >> as to 'why we added a dependency' (when we didn't add one really...) >>> >> >>> > >>> > Again, I'm not sure I follow. >>> > >>> > I don't see how the addition of a single new dependency complicates >>> > the compilation. >>> > If there is any complication, it is from trying to follow what Maven >>> > is doing ;-). >>> > >>> > Nor do I see why users will be confused, so long as the site shows >>> > that LANG depends on Java 1.5 only. Many of them will just use Maven >>> > to pick up the new version. If necessary one can always add some >>> > information on the site as to how annotations behave. >>> > >>> > I think it's well worth the exercise of checking all the classes to >>> > see which annotation applies; if necessary the annotations (and >>> > imports) could be added as single-line comments. [But I really don't >>> > want to do that.] >>> > >>> > I suspect that the change to using generics will be a much greater >>> > challenge to users; if they can cope with that, then annotations >>> > should be relatively easy. >>> > >>> > Indeed hopefully users will start adding annotations to their own code... >>> > >>> >> Stephen >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> > For additional commands, e-mail: dev-h...@commons.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
