Re: [dna-dev] End-of-line characters
by John Verhaeg
The Eclipse preferences have been updated, so I would ask that all developers please get these and import them into your Eclipse IDE. I would like to schedule a conversion of all the existing files in SVN to use the UNIX line delimiter for 1AM UTC next Wednesday (January 28th) morning. The conversion won't affect all files, but it will probably affect most. If you have anything to check in, please try to get it checked in before then. If you would like me to skip a particular project because you have lots of changes that won't be able to be checked in by that time, please let me know.
Thanks,
John Verhaeg
Red Hat, Inc.
(314) 336-2950
----- "Randall Hauch" <rhauch(a)redhat.com> wrote:
| John,
|
Why don't you commit the change to the Eclipse preference file that's in SVN, and developers can start grabbing that. We can then bulk change the files after that.
|
Best regards,
|
Randall
|
On Jan 21, 2009, at 10:12 AM, Randall Hauch wrote:
|
Considering that we already have files with every combination of line delimiter (though thankfully each file is consistent), has anyone experienced problems in your development environments? If so, please speak up. I know Eclipse handles them well enough, and I suspect other Java tools do as well. And for the most part I think the operating systems and tools are pretty good about how they handle these files.
|
Best regards,
|
Randall
|
On Jan 21, 2009, at 10:00 AM, John Verhaeg wrote:
| I'd like to propose that we change our Eclipse preferences (or the associated preferences in whatever IDE you use) to force all created/edited files to be saved with UTF-8 encoding and to use /n (LF) as the end-of-line delimiter. I'd also like to convert all of the existing files in the DNA repository to use this encoding and delimiter.
|
| Currently the files in the DNA SVN repository contain a mixture of encoding formats and end-of-line delimiters based upon the default behavior of the OS that was used to create them. With regard to delimiters, Windows ends lines of text with \r\n (CR/LF), *nix with \n (LF), and OS X with \r (CR). Eclipse apparently attempts to maintain the encoding and delimiters used when the file was originally created, but other editors and file manipulation tools don't. This sometimes results in multiple delimiter techniques used within the same file.
|
|
| One of the main problems with this situation is many tools can't handle this mixture of encodings and/or delimiters. Git, for instance, relies upon \n only to determine what constitutes a line. Thus, if you modify a single character in a git-managed file created using OS X, then compare the file to the one in the repository, git will report the entire file has changed. I've also seen problems in the past where someone inserts a copyright symbol in a file header comment from Windows, and subsequent compilations fail on a server performing continuous builds using Ant.
|
| Given that we do standardize our encoding technique, I doubt anyone would object to the ubiquitous UTF-8 standard. Regarding the delimiter, the two characters used by Windows increases the size of each file needlessly and, considering DNA is a JBoss project, Windows will probably be the least commonly used platform by developers. The OS X seems inappropriate simply due to the number of tools that assume the existence of line-feeds.
|
| I'd like to get everyone's feedback on this proposal. Since the second part of this proposal probably involves modifying a large number of files in SVN, we'd obviously want to do this sooner rather than later. Please comment when you get a chance.
|
| Thanks,
|
| John Verhaeg
| Red Hat, Inc.
| (314) 336-2950
| _______________________________________________
| dna-dev mailing list
| dna-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/dna-dev
|
| _______________________________________________
| dna-dev mailing list
| dna-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/dna-dev
|
|
| _______________________________________________ dna-dev mailing list dna-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/dna-dev
15 years, 3 months
End-of-line characters
by John Verhaeg
I'd like to propose that we change our Eclipse preferences (or the associated preferences in whatever IDE you use) to force all created/edited files to be saved with UTF-8 encoding and to use /n (LF) as the end-of-line delimiter. I'd also like to convert all of the existing files in the DNA repository to use this encoding and delimiter.
Currently the files in the DNA SVN repository contain a mixture of encoding formats and end-of-line delimiters based upon the default behavior of the OS that was used to create them. With regard to delimiters, Windows ends lines of text with \r\n (CR/LF), *nix with \n (LF), and OS X with \r (CR). Eclipse apparently attempts to maintain the encoding and delimiters used when the file was originally created, but other editors and file manipulation tools don't. This sometimes results in multiple delimiter techniques used within the same file.
One of the main problems with this situation is many tools can't handle this mixture of encodings and/or delimiters. Git, for instance, relies upon \n only to determine what constitutes a line. Thus, if you modify a single character in a git-managed file created using OS X, then compare the file to the one in the repository, git will report the entire file has changed. I've also seen problems in the past where someone inserts a copyright symbol in a file header comment from Windows, and subsequent compilations fail on a server performing continuous builds using Ant.
Given that we do standardize our encoding technique, I doubt anyone would object to the ubiquitous UTF-8 standard. Regarding the delimiter, the two characters used by Windows increases the size of each file needlessly and, considering DNA is a JBoss project, Windows will probably be the least commonly used platform by developers. The OS X seems inappropriate simply due to the number of tools that assume the existence of line-feeds.
I'd like to get everyone's feedback on this proposal. Since the second part of this proposal probably involves modifying a large number of files in SVN, we'd obviously want to do this sooner rather than later. Please comment when you get a chance.
Thanks,
John Verhaeg
Red Hat, Inc.
(314) 336-2950
15 years, 3 months
Recent changes to the DNA codebase
by Randall Hauch
This week was a busy one for the project, with several changes to the
codebase that impacted a lot of files. Some of these changes were
simple housekeeping, including:
DNA-271 Change mechanism to declare copyright, moving from source
code into separate file included with distributions
DNA-275 Change plural package names to be singular
DNA-270 Simplify the ExecutionContext framework
DNA-272 Move the In-Memory connector into "dna-graph"
The first one obviously touched almost all of the files, while the
second also impacted quite a few. And, the last resulting in the
"trunk/extensions/dna-connector-inmemory" project being removed.
So, if you haven't already updated from SVN, be aware that there are a
lot of changes, and that you may need to adjust your IDE workspace
accordingly.
Best regards,
Randall
15 years, 3 months
Re: [dna-dev] Re: @author tags in our codebase
by John Verhaeg
I'm not completely sold on this, but I don't really have much of an argument against it either, beyond worrying that potential contributors might not feel they're getting "enough" attribution without the direct tie-in between the source and their names. Not sure if I understand Sergey's comments about accepting contributor efforts - how does this preclude those efforts? Other than that, I'd give a +1.
John Verhaeg
Red Hat, Inc.
(314) 336-2950
----- "Sergey Litsenko" <litsenko_sergey(a)yahoo.com> wrote:
|
|
| -1
| It is optional - would be better to allow keeping authors tags while automating process of getting full list.
|
| On one hand, I'm not sold on the idea that if the author tag will be removed it might help to brought more commiters. If I see some issue in the source code and I know how to fix it - I'll provide a patch/fix whetever I'm in the "magic list" or not.
|
| The only question that might be asked: are OSS team members interested in accepting such contributor's efforts or not?
| It's about mentality and maturity of committers as well as part of OSS project's culture established by team members - e.g. responding to user questions, issues, etc - in e-mails, users forums, etc and welcoming user's opinions on how things should work (functional requirements). Also you can use something like following: "@author DNA Expert Group" for classes/packages designed / developed by group of authors.
|
| Generally, I believe that everything that is part of Java Language specification (e.g.) and/or part of general practices is valid and justified to be part of any source code.
|
| On the other hand, since it's possible to automate process of getting list of autors from both - SCM repository and source code/POM - maintenance would not be that hard , and IMO efforts should go that way rather than removing tags. I bet that I can find some maven plugin or develop my own to automate that process. For example, http://www.statsvn.org and http://stat-scm.sourceforge.net are good starting points.
|
| I will vote "+2" on the ability to automate process of getting full list of contributors (maven report plugin) and makit it part of distribution and Maven project site .
|
| Sergiy
|
|
|
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
| To: dna-dev(a)lists.jboss.org
| Sent: Wednesday, 14 January, 2009 6:43:27 PM
| Subject: dna-dev Digest, Vol 10, Issue 5
|
| Send dna-dev mailing list submissions to
| dna-dev(a)lists.jboss.org
|
| To subscribe or unsubscribe via the World Wide Web, visit
| https://lists.jboss.org/mailman/listinfo/dna-dev
| or, via email, send a message with subject or body 'help' to
| dna-dev-request(a)lists.jboss.org
|
| You can reach the person managing the list at
| dna-dev-owner(a)lists.jboss.org
|
| When replying, please edit your Subject line so it is more specific
| than "Re: Contents of dna-dev digest..."
|
|
| Today's Topics:
|
| 1. Re: @author tags in our codebase (Randall Hauch)
| 2. Re: @author tags in our codebase (Vatsal)
|
|
| ----------------------------------------------------------------------
|
| Message: 1
| Date: Tue, 13 Jan 2009 16:03:23 -0600
| From: Randall Hauch < rhauch(a)redhat.com >
| Subject: Re: [dna-dev] @author tags in our codebase
| To: JBoss DNA < dna-dev(a)lists.jboss.org >
| Message-ID: < 160467FE-4D64-4943-BBAC-3D9535FD670C(a)redhat.com >
| Content-Type: text/plain; charset="us-ascii"
|
| We never really came to a consensus on this question, and I'd like to
| try to do that. To be clear, here is the proposal:
|
| 1) Remove the @author lines from the code, and instead rely upon SVN
| as the official master record of individual contributions
| 2) Change the Eclipse preference files to remove the @author lines
| from the code templates
| 3) Add a AUTHORS file to the distribution(s); this file will contain
| the names and email addresses for all contributors, and can even allow
| a contributor to describe their contribution if they so desire.
| 4) Change the headers to remove the "@author" wording and to replace
| it with "See the AUTHORS file in the
| distribution for a full listing of individual contributors."
| 5) Change the POM files to include the AUTHORS file in each
| distribution.
|
| The AUTHORS file would look like this:
|
| Randall Hauch ( rhauch(a)redhat.com )
| John Verhaeg ( jverhaeg(a)redhat.com )
| Dan Florian ( dflorian(a)redhat.com )
| Stefano Maestri ( stefano.maestri(a)javalinux.it )
| Serge Pagop ( Serge.Pagop(a)innoq.com )
| Michael Trezzi ( michael(a)mathwizard.org )
| Alexandre Porcelli ( porcelli(a)devexp.com.br )
| Sergiy Litsenko ( litsenko_sergey(a)yahoo.com )
|
| Note that unlike the @author tags, this file will list all
| contributors, and the names of new contributors will be appended to
| the list by the project lead. (No names will be removed from this
| file.)
|
| I would prefer to hear from every contributor, so please respond with
| +1 if you agree with this proposal, 0 if you don't care, or -1 if you
| want to keep the @author tags. If you vehemently want to keep the
| @author tags and names in the source file, please say so.
|
| Best regards,
|
| Randall
|
| On Nov 18, 2008, at 3:33 PM, Randall Hauch wrote:
|
| >
| > On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
| >
| >>
| >> Randall Hauch wrote on 17/11/08 22:17:
| >>> I've recently read a suggestions for open source communities that
| >>> the
| >>> author names are removed from the content. In the case of DNA's
| >>> codebase, that would mean removing the @author tags.
| >> May I ask where?
| >
| > I knew someone was going to ask. :-) I had to go back and look, but
| > here are a few:
| > http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
| > http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
| > http://subversion.tigris.org/hacking.html#other-conventions
| > http://blogs.sun.com/ahe/entry/author_tags
| >
| >>
| >>>
| >>> tags:
| >>>
| >>> 1. When there are no @author tags, then there is a far smaller
| >>> notion of ownership by the author(s). On one side of this, the
| >>> author(s) may not appreciate changes to "their" code, and on the
| >>> other side, non-authors may feel intimidated about working on
| >>> code for which they are not an author. IMO, we want to
| >>> _discourage_ ownership and _encourage_ everyone to work in any
| >>> area of the code they want.
| >>>
| >> +1...but is really @author tag intimating someone, or giving
| >> ownership
| >> to some other? Quiet frankly not for me.
| >
| > I hope it doesn't discourage people from contributing and diving in
| > wherever they want. BTW, it's quite possible that no matter what
| > our policy, some people may not like it. For example, if we were to
| > adopt a policy of NOT including @author tags, some people may refuse
| > to join the community because they see the @author tag as proof they
| > worked on it. It takes all kinds of people. :-)
| >
| >>
| >> Anyway I agree on the _discurage_ownership and _encourage_everyone to
| >> work in any area, so if it can help, remove @author tag.
| >>
| >>> 1. @author tags can be inaccurate. SVN has the true history of who
| >>> contributed exactly what code.
| >>>
| >> +1
| >
| > IMO, this is perhaps the biggest justifiable reason. Its rubbish if
| > its not up-to-date, so it seems far better to not have @author tags.
| >
| >>
| >>>
| >>> The only benefit I can think of is that the @author tag does help to
| >>> give some notion of who is the "expert" of the class, in case they
| >>> need to be consulted. However, I don't believe this is really
| >>> much of
| >>> a reason, since it's far better to consult the SVN history and see
| >>> who
| >>> actually modified the different parts of the code. In fact, the
| >>> annotated views in Fisheye even show on many of the lines the name
| >>> of
| >>> the last person to change it. For example,
| >>> see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
| >>>
| >> abosolutely better to use fisheye...if fine people of JBoss.org would
| >> also mind to upgrade it to a more recent version it would be even
| >> better. Also Jira integration may help a lot.
| >>
| >> I would just add that if we decide to remove the tag we have to
| >> change
| >> also the license information at the beginnig of any file which say:
| >> /* 2
| >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| >> >
| >> * JBoss, Home of Professional Open Source. 3
| >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| >> >
| >> * Copyright 2008, Red Hat Middleware LLC, and individual
| >> contributors 4
| >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| >> >
| >> * as indicated by the @author tags. See the copyright.txt file in
| >> the 5
| >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| >> >
| >> * distribution for a full listing of individual contributors.
| >>
| >
| > Yes, we'd have to update the headers.
| >
| > Best regards,
| >
| > Randall
| >
|
| -------------- next part --------------
| An HTML attachment was scrubbed...
| URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20090113/d2486bd9/at...
|
| ------------------------------
|
| Message: 2
| Date: Wed, 14 Jan 2009 13:13:23 +0530
| From: Vatsal < vatsal.avasthi(a)gmail.com >
| Subject: Re: [dna-dev] @author tags in our codebase
| To: dna-dev(a)lists.jboss.org
| Message-ID:
| < c82836c60901132343w54b690a9ha9c183e5ee61d019(a)mail.gmail.com >
| Content-Type: text/plain; charset="iso-8859-1"
|
| Sometimes it is fun to see your name in author tag of a project at a later
| date when the project has matured but my vote would be for Randall's
| suggestions due to practical & maintenance reasons discussed earlier, so a
| +1 from me for this proposal(though I am not a contributor yet :) )...
| - Vatsal
|
| On Wed, Jan 14, 2009 at 3:33 AM, Randall Hauch < rhauch(a)redhat.com > wrote:
|
| > We never really came to a consensus on this question, and I'd like to try
| > to do that. To be clear, here is the proposal:
| >
| > 1) Remove the @author lines from the code, and instead rely upon SVN as the
| > official master record of individual contributions
| > 2) Change the Eclipse preference files to remove the @author lines from the
| > code templates
| > 3) Add a AUTHORS file to the distribution(s); this file will contain the
| > names and email addresses for all contributors, and can even allow a
| > contributor to describe their contribution if they so desire.
| > 4) Change the headers to remove the "@author" wording and to replace it
| > with "See the AUTHORS file in the
| > distribution for a full listing of individual contributors."
| > 5) Change the POM files to include the AUTHORS file in each distribution.
| >
| > The AUTHORS file would look like this:
| >
| > Randall Hauch ( rhauch(a)redhat.com )
| >
| > John Verhaeg ( jverhaeg(a)redhat.com )
| > Dan Florian ( dflorian(a)redhat.com )
| > Stefano Maestri ( stefano.maestri(a)javalinux.it )
| > Serge Pagop ( Serge.Pagop(a)innoq.com )
| > Michael Trezzi ( michael(a)mathwizard.org )
| > Alexandre Porcelli ( porcelli(a)devexp.com.br )
| > Sergiy Litsenko ( litsenko_sergey(a)yahoo.com )
| >
| >
| > Note that unlike the @author tags, this file will list all contributors,
| > and the names of new contributors will be appended to the list by the
| > project lead. (No names will be removed from this file.)
| >
| > I would prefer to hear from every contributor, so please respond with +1 if
| > you agree with this proposal, 0 if you don't care, or -1 if you want to keep
| > the @author tags. If you vehemently want to keep the @author tags and names
| > in the source file, please say so.
| >
| > Best regards,
| >
| > Randall
| >
| > On Nov 18, 2008, at 3:33 PM, Randall Hauch wrote:
| >
| >
| > On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
| >
| >
| > Randall Hauch wrote on 17/11/08 22:17:
| >
| > I've recently read a suggestions for open source communities that the
| >
| > author names are removed from the content. In the case of DNA's
| >
| > codebase, that would mean removing the @author tags.
| >
| > May I ask where?
| >
| >
| > I knew someone was going to ask. :-) I had to go back and look, but here
| > are a few:
| >
| > http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
| > http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
| > http://subversion.tigris.org/hacking.html#other-conventions
| > http://blogs.sun.com/ahe/entry/author_tags
| >
| >
| >
| > tags:
| >
| >
| > 1. When there are no @author tags, then there is a far smaller
| >
| > notion of ownership by the author(s). On one side of this, the
| >
| > author(s) may not appreciate changes to "their" code, and on the
| >
| > other side, non-authors may feel intimidated about working on
| >
| > code for which they are not an author. IMO, we want to
| >
| > _discourage_ ownership and _encourage_ everyone to work in any
| >
| > area of the code they want.
| >
| >
| > +1...but is really @author tag intimating someone, or giving ownership
| >
| > to some other? Quiet frankly not for me.
| >
| >
| > I hope it doesn't discourage people from contributing and diving in
| > wherever they want. BTW, it's quite possible that no matter what our
| > policy, some people may not like it. For example, if we were to adopt a
| > policy of NOT including @author tags, some people may refuse to join the
| > community because they see the @author tag as proof they worked on it. It
| > takes all kinds of people. :-)
| >
| >
| > Anyway I agree on the _discurage_ownership and _encourage_everyone to
| >
| > work in any area, so if it can help, remove @author tag.
| >
| >
| > 1. @author tags can be inaccurate. SVN has the true history of who
| >
| > contributed exactly what code.
| >
| >
| > +1
| >
| >
| > IMO, this is perhaps the biggest justifiable reason. Its rubbish if its
| > not up-to-date, so it seems far better to not have @author tags.
| >
| >
| >
| > The only benefit I can think of is that the @author tag does help to
| >
| > give some notion of who is the "expert" of the class, in case they
| >
| > need to be consulted. However, I don't believe this is really much of
| >
| > a reason, since it's far better to consult the SVN history and see who
| >
| > actually modified the different parts of the code. In fact, the
| >
| > annotated views in Fisheye even show on many of the lines the name of
| >
| > the last person to change it. For example,
| >
| > see
| > http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
| >
| >
| > abosolutely better to use fisheye...if fine people of JBoss.org would
| >
| > also mind to upgrade it to a more recent version it would be even
| >
| > better. Also Jira integration may help a lot.
| >
| >
| > I would just add that if we decide to remove the tag we have to change
| >
| > also the license information at the beginnig of any file which say:
| >
| > /* 2
| >
| > <
| > http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| > >
| >
| > * JBoss, Home of Professional Open Source. 3
| >
| > <
| > http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| > >
| >
| > * Copyright 2008, Red Hat Middleware LLC, and individual contributors 4
| >
| > <
| > http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| > >
| >
| > * as indicated by the @author tags. See the copyright.txt file in the 5
| >
| > <
| > http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
| > >
| >
| > * distribution for a full listing of individual contributors.
| >
| >
| >
| > Yes, we'd have to update the headers.
| >
| > Best regards,
| >
| > Randall
| >
| >
| >
| > _______________________________________________
| > dna-dev mailing list
| > dna-dev(a)lists.jboss.org
| > https://lists.jboss.org/mailman/listinfo/dna-dev
| >
| >
| -------------- next part --------------
| An HTML attachment was scrubbed...
| URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20090114/4b648c37/at...
|
| ------------------------------
|
| _______________________________________________
| dna-dev mailing list
| dna-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/dna-dev
|
|
| End of dna-dev Digest, Vol 10, Issue 5
| **************************************
|
|
Stay connected to the people that matter most with a smarter inbox. Take a look .
| _______________________________________________ dna-dev mailing list dna-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/dna-dev
15 years, 3 months
Re: dna-dev Digest, Vol 10, Issue 8
by Serge Emmanuel Pagop
Hi DNA Volk,
I do not have any problems with that, if the @author tag has to be
removed on source codes, so that we can win more contributors (most
important is that thereby we reach sth.). I give a +1.
Best regards,
Serge.
-------
|||| Serge Emmanuel Pagop
|||| IT Senior Consultant
||||
|||| JBUG Munich Founder
||||
|||| innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
||||
|||| Business mobile: +49 178 4049592,
|||| Business Fax: +49 2102 77160-1,
|||| Business E-Mail: serge.pagop(a)innoq.com,
|||| Private E-Mail: serge.pagop(a)googlemail.com
|||| Web: http://www.innoq.com,
|||| Weblog: http://www.innoq.com/blog/sp,
|||| JBUG Munich: http://www.jbug-munich.org
On Jan 15, 2009, at 6:29 PM, dna-dev-request(a)lists.jboss.org wrote:
> Send dna-dev mailing list submissions to
> dna-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/dna-dev
> or, via email, send a message with subject or body 'help' to
> dna-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> dna-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dna-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Re: @author tags in our codebase (John Verhaeg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Jan 2009 12:29:27 -0500 (EST)
> From: John Verhaeg <jverhaeg(a)redhat.com>
> Subject: Re: [dna-dev] Re: @author tags in our codebase
> To: Sergey Litsenko <litsenko_sergey(a)yahoo.com>
> Cc: dna-dev(a)lists.jboss.org
> Message-ID:
> <406785845.1506141232040567551.JavaMail.root(a)zmail02.collab.prod.int.phx2.redhat.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> I'm not completely sold on this, but I don't really have much of an
> argument against it either, beyond worrying that potential
> contributors might not feel they're getting "enough" attribution
> without the direct tie-in between the source and their names. Not
> sure if I understand Sergey's comments about accepting contributor
> efforts - how does this preclude those efforts? Other than that, I'd
> give a +1.
>
> John Verhaeg
> Red Hat, Inc.
> (314) 336-2950
>
> ----- "Sergey Litsenko" <litsenko_sergey(a)yahoo.com> wrote:
> |
> |
> | -1
> | It is optional - would be better to allow keeping authors tags
> while automating process of getting full list.
> |
> | On one hand, I'm not sold on the idea that if the author tag will
> be removed it might help to brought more commiters. If I see some
> issue in the source code and I know how to fix it - I'll provide a
> patch/fix whetever I'm in the "magic list" or not.
> |
> | The only question that might be asked: are OSS team members
> interested in accepting such contributor's efforts or not?
> | It's about mentality and maturity of committers as well as part of
> OSS project's culture established by team members - e.g. responding
> to user questions, issues, etc - in e-mails, users forums, etc and
> welcoming user's opinions on how things should work (functional
> requirements). Also you can use something like following: "@author
> DNA Expert Group" for classes/packages designed / developed by group
> of authors.
> |
> | Generally, I believe that everything that is part of Java Language
> specification (e.g.) and/or part of general practices is valid and
> justified to be part of any source code.
> |
> | On the other hand, since it's possible to automate process of
> getting list of autors from both - SCM repository and source code/
> POM - maintenance would not be that hard , and IMO efforts should go
> that way rather than removing tags. I bet that I can find some maven
> plugin or develop my own to automate that process. For example, http://www.statsvn.org
> and http://stat-scm.sourceforge.net are good starting points.
> |
> | I will vote "+2" on the ability to automate process of getting
> full list of contributors (maven report plugin) and makit it part of
> distribution and Maven project site .
> |
> | Sergiy
> |
> |
> |
> From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org
> >
> | To: dna-dev(a)lists.jboss.org
> | Sent: Wednesday, 14 January, 2009 6:43:27 PM
> | Subject: dna-dev Digest, Vol 10, Issue 5
> |
> | Send dna-dev mailing list submissions to
> | dna-dev(a)lists.jboss.org
> |
> | To subscribe or unsubscribe via the World Wide Web, visit
> | https://lists.jboss.org/mailman/listinfo/dna-dev
> | or, via email, send a message with subject or body 'help' to
> | dna-dev-request(a)lists.jboss.org
> |
> | You can reach the person managing the list at
> | dna-dev-owner(a)lists.jboss.org
> |
> | When replying, please edit your Subject line so it is more specific
> | than "Re: Contents of dna-dev digest..."
> |
> |
> | Today's Topics:
> |
> | 1. Re: @author tags in our codebase (Randall Hauch)
> | 2. Re: @author tags in our codebase (Vatsal)
> |
> |
> |
> ----------------------------------------------------------------------
> |
> | Message: 1
> | Date: Tue, 13 Jan 2009 16:03:23 -0600
> | From: Randall Hauch < rhauch(a)redhat.com >
> | Subject: Re: [dna-dev] @author tags in our codebase
> | To: JBoss DNA < dna-dev(a)lists.jboss.org >
> | Message-ID: < 160467FE-4D64-4943-BBAC-3D9535FD670C(a)redhat.com >
> | Content-Type: text/plain; charset="us-ascii"
> |
> | We never really came to a consensus on this question, and I'd like
> to
> | try to do that. To be clear, here is the proposal:
> |
> | 1) Remove the @author lines from the code, and instead rely upon SVN
> | as the official master record of individual contributions
> | 2) Change the Eclipse preference files to remove the @author lines
> | from the code templates
> | 3) Add a AUTHORS file to the distribution(s); this file will contain
> | the names and email addresses for all contributors, and can even
> allow
> | a contributor to describe their contribution if they so desire.
> | 4) Change the headers to remove the "@author" wording and to replace
> | it with "See the AUTHORS file in the
> | distribution for a full listing of individual contributors."
> | 5) Change the POM files to include the AUTHORS file in each
> | distribution.
> |
> | The AUTHORS file would look like this:
> |
> | Randall Hauch ( rhauch(a)redhat.com )
> | John Verhaeg ( jverhaeg(a)redhat.com )
> | Dan Florian ( dflorian(a)redhat.com )
> | Stefano Maestri ( stefano.maestri(a)javalinux.it )
> | Serge Pagop ( Serge.Pagop(a)innoq.com )
> | Michael Trezzi ( michael(a)mathwizard.org )
> | Alexandre Porcelli ( porcelli(a)devexp.com.br )
> | Sergiy Litsenko ( litsenko_sergey(a)yahoo.com )
> |
> | Note that unlike the @author tags, this file will list all
> | contributors, and the names of new contributors will be appended to
> | the list by the project lead. (No names will be removed from this
> | file.)
> |
> | I would prefer to hear from every contributor, so please respond
> with
> | +1 if you agree with this proposal, 0 if you don't care, or -1 if
> you
> | want to keep the @author tags. If you vehemently want to keep the
> | @author tags and names in the source file, please say so.
> |
> | Best regards,
> |
> | Randall
> |
> | On Nov 18, 2008, at 3:33 PM, Randall Hauch wrote:
> |
> | >
> | > On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
> | >
> | >>
> | >> Randall Hauch wrote on 17/11/08 22:17:
> | >>> I've recently read a suggestions for open source communities
> that
> | >>> the
> | >>> author names are removed from the content. In the case of DNA's
> | >>> codebase, that would mean removing the @author tags.
> | >> May I ask where?
> | >
> | > I knew someone was going to ask. :-) I had to go back and look,
> but
> | > here are a few:
> | > http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
> | > http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
> | > http://subversion.tigris.org/hacking.html#other-conventions
> | > http://blogs.sun.com/ahe/entry/author_tags
> | >
> | >>
> | >>>
> | >>> tags:
> | >>>
> | >>> 1. When there are no @author tags, then there is a far smaller
> | >>> notion of ownership by the author(s). On one side of this, the
> | >>> author(s) may not appreciate changes to "their" code, and on the
> | >>> other side, non-authors may feel intimidated about working on
> | >>> code for which they are not an author. IMO, we want to
> | >>> _discourage_ ownership and _encourage_ everyone to work in any
> | >>> area of the code they want.
> | >>>
> | >> +1...but is really @author tag intimating someone, or giving
> | >> ownership
> | >> to some other? Quiet frankly not for me.
> | >
> | > I hope it doesn't discourage people from contributing and diving
> in
> | > wherever they want. BTW, it's quite possible that no matter what
> | > our policy, some people may not like it. For example, if we were
> to
> | > adopt a policy of NOT including @author tags, some people may
> refuse
> | > to join the community because they see the @author tag as proof
> they
> | > worked on it. It takes all kinds of people. :-)
> | >
> | >>
> | >> Anyway I agree on the _discurage_ownership and
> _encourage_everyone to
> | >> work in any area, so if it can help, remove @author tag.
> | >>
> | >>> 1. @author tags can be inaccurate. SVN has the true history of
> who
> | >>> contributed exactly what code.
> | >>>
> | >> +1
> | >
> | > IMO, this is perhaps the biggest justifiable reason. Its rubbish
> if
> | > its not up-to-date, so it seems far better to not have @author
> tags.
> | >
> | >>
> | >>>
> | >>> The only benefit I can think of is that the @author tag does
> help to
> | >>> give some notion of who is the "expert" of the class, in case
> they
> | >>> need to be consulted. However, I don't believe this is really
> | >>> much of
> | >>> a reason, since it's far better to consult the SVN history and
> see
> | >>> who
> | >>> actually modified the different parts of the code. In fact, the
> | >>> annotated views in Fisheye even show on many of the lines the
> name
> | >>> of
> | >>> the last person to change it. For example,
> | >>> see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
> | >>>
> | >> abosolutely better to use fisheye...if fine people of JBoss.org
> would
> | >> also mind to upgrade it to a more recent version it would be even
> | >> better. Also Jira integration may help a lot.
> | >>
> | >> I would just add that if we decide to remove the tag we have to
> | >> change
> | >> also the license information at the beginnig of any file which
> say:
> | >> /* 2
> | >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> | >> >
> | >> * JBoss, Home of Professional Open Source. 3
> | >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> | >> >
> | >> * Copyright 2008, Red Hat Middleware LLC, and individual
> | >> contributors 4
> | >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> | >> >
> | >> * as indicated by the @author tags. See the copyright.txt file in
> | >> the 5
> | >> < http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> | >> >
> | >> * distribution for a full listing of individual contributors.
> | >>
> | >
> | > Yes, we'd have to update the headers.
> | >
> | > Best regards,
> | >
> | > Randall
> | >
> |
> |
15 years, 3 months
@author tags in our codebase
by Randall Hauch
I've recently read a suggestions for open source communities that the
author names are removed from the content. In the case of DNA's
codebase, that would mean removing the @author tags. I'm not sure
there was a lot of thought put into using author tags vs. not using
them, but I'd like to reconsider our policy.
What does everyone think about the @author tags? Please reply to all,
stating your opinion (or lack of one).
I'll start. I see a couple of advantages to getting rid of all
@author tags:
When there are no @author tags, then there is a far smaller notion of
ownership by the author(s). On one side of this, the author(s) may
not appreciate changes to "their" code, and on the other side, non-
authors may feel intimidated about working on code for which they are
not an author. IMO, we want to _discourage_ ownership and _encourage_
everyone to work in any area of the code they want.
When there are no @author tags, we don't need a policy that says when
you can add your name to a class/method as an author. I'm not even
sure what our policy is, but I think we're not being consistent (other
than when we create a new class/interface)
@author tags can be inaccurate. SVN has the true history of who
contributed exactly what code.
The only benefit I can think of is that the @author tag does help to
give some notion of who is the "expert" of the class, in case they
need to be consulted. However, I don't believe this is really much of
a reason, since it's far better to consult the SVN history and see who
actually modified the different parts of the code. In fact, the
annotated views in Fisheye even show on many of the lines the name of
the last person to change it. For example, see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
What does everyone think about the @author tags? This isn't an
official vote (we've never had one), but I would like to hear
everyone's thoughts, so please reply to all and let us know what you
think.
Best regards,
Randall
15 years, 3 months
Re: @author tags in our codebase
by Sergey Litsenko
-1
It is optional - would be better to allow keeping authors tags while automating process of getting full list.
On one hand, I'm not sold on the idea that if the author tag will be removed it might help to brought more commiters. If I see some issue in the source code and I know how to fix it - I'll provide a patch/fix whetever I'm in the "magic list" or not.
The only question that might be asked: are OSS team members interested in accepting such contributor's efforts or not?
It's about mentality and maturity of committers as well as part of OSS
project's culture established by team members - e.g. responding to
user questions, issues, etc - in e-mails, users forums, etc and welcoming user's opinions on how things should work (functional requirements). Also you can use something like following: "@author DNA Expert Group"
for classes/packages designed / developed by group of authors.
Generally, I believe that everything that is part of Java Language specification (e.g.) and/or part of general practices is valid and justified to be part of any source code.
On the other hand, since it's possible to automate process of getting list of autors from both - SCM repository and source code/POM - maintenance would not be that hard, and IMO efforts should go that way rather than removing tags. I bet that I can find some maven plugin or develop my own to automate that process. For example, http://www.statsvn.org and http://stat-scm.sourceforge.net are good starting points.
I will vote "+2" on the ability to automate process of getting full list of contributors (maven report plugin) and makit it part of distribution and Maven project site.
Sergiy
________________________________
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
To: dna-dev(a)lists.jboss.org
Sent: Wednesday, 14 January, 2009 6:43:27 PM
Subject: dna-dev Digest, Vol 10, Issue 5
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. Re: @author tags in our codebase (Randall Hauch)
2. Re: @author tags in our codebase (Vatsal)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Jan 2009 16:03:23 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: Re: [dna-dev] @author tags in our codebase
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <160467FE-4D64-4943-BBAC-3D9535FD670C(a)redhat.com>
Content-Type: text/plain; charset="us-ascii"
We never really came to a consensus on this question, and I'd like to
try to do that. To be clear, here is the proposal:
1) Remove the @author lines from the code, and instead rely upon SVN
as the official master record of individual contributions
2) Change the Eclipse preference files to remove the @author lines
from the code templates
3) Add a AUTHORS file to the distribution(s); this file will contain
the names and email addresses for all contributors, and can even allow
a contributor to describe their contribution if they so desire.
4) Change the headers to remove the "@author" wording and to replace
it with "See the AUTHORS file in the
distribution for a full listing of individual contributors."
5) Change the POM files to include the AUTHORS file in each
distribution.
The AUTHORS file would look like this:
Randall Hauch (rhauch(a)redhat.com)
John Verhaeg (jverhaeg(a)redhat.com)
Dan Florian (dflorian(a)redhat.com)
Stefano Maestri (stefano.maestri(a)javalinux.it)
Serge Pagop (Serge.Pagop(a)innoq.com)
Michael Trezzi (michael(a)mathwizard.org)
Alexandre Porcelli (porcelli(a)devexp.com.br)
Sergiy Litsenko (litsenko_sergey(a)yahoo.com)
Note that unlike the @author tags, this file will list all
contributors, and the names of new contributors will be appended to
the list by the project lead. (No names will be removed from this
file.)
I would prefer to hear from every contributor, so please respond with
+1 if you agree with this proposal, 0 if you don't care, or -1 if you
want to keep the @author tags. If you vehemently want to keep the
@author tags and names in the source file, please say so.
Best regards,
Randall
On Nov 18, 2008, at 3:33 PM, Randall Hauch wrote:
>
> On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
>
>>
>> Randall Hauch wrote on 17/11/08 22:17:
>>> I've recently read a suggestions for open source communities that
>>> the
>>> author names are removed from the content. In the case of DNA's
>>> codebase, that would mean removing the @author tags.
>> May I ask where?
>
> I knew someone was going to ask. :-) I had to go back and look, but
> here are a few:
> http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
> http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
> http://subversion.tigris.org/hacking.html#other-conventions
> http://blogs.sun.com/ahe/entry/author_tags
>
>>
>>>
>>> tags:
>>>
>>> 1. When there are no @author tags, then there is a far smaller
>>> notion of ownership by the author(s). On one side of this, the
>>> author(s) may not appreciate changes to "their" code, and on the
>>> other side, non-authors may feel intimidated about working on
>>> code for which they are not an author. IMO, we want to
>>> _discourage_ ownership and _encourage_ everyone to work in any
>>> area of the code they want.
>>>
>> +1...but is really @author tag intimating someone, or giving
>> ownership
>> to some other? Quiet frankly not for me.
>
> I hope it doesn't discourage people from contributing and diving in
> wherever they want. BTW, it's quite possible that no matter what
> our policy, some people may not like it. For example, if we were to
> adopt a policy of NOT including @author tags, some people may refuse
> to join the community because they see the @author tag as proof they
> worked on it. It takes all kinds of people. :-)
>
>>
>> Anyway I agree on the _discurage_ownership and _encourage_everyone to
>> work in any area, so if it can help, remove @author tag.
>>
>>> 1. @author tags can be inaccurate. SVN has the true history of who
>>> contributed exactly what code.
>>>
>> +1
>
> IMO, this is perhaps the biggest justifiable reason. Its rubbish if
> its not up-to-date, so it seems far better to not have @author tags.
>
>>
>>>
>>> The only benefit I can think of is that the @author tag does help to
>>> give some notion of who is the "expert" of the class, in case they
>>> need to be consulted. However, I don't believe this is really
>>> much of
>>> a reason, since it's far better to consult the SVN history and see
>>> who
>>> actually modified the different parts of the code. In fact, the
>>> annotated views in Fisheye even show on many of the lines the name
>>> of
>>> the last person to change it. For example,
>>> see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
>>>
>> abosolutely better to use fisheye...if fine people of JBoss.org would
>> also mind to upgrade it to a more recent version it would be even
>> better. Also Jira integration may help a lot.
>>
>> I would just add that if we decide to remove the tag we have to
>> change
>> also the license information at the beginnig of any file which say:
>> /* 2
>> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
>> >
>> * JBoss, Home of Professional Open Source. 3
>> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
>> >
>> * Copyright 2008, Red Hat Middleware LLC, and individual
>> contributors 4
>> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
>> >
>> * as indicated by the @author tags. See the copyright.txt file in
>> the 5
>> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
>> >
>> * distribution for a full listing of individual contributors.
>>
>
> Yes, we'd have to update the headers.
>
> Best regards,
>
> Randall
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20090113/d2486bd9/at...
------------------------------
Message: 2
Date: Wed, 14 Jan 2009 13:13:23 +0530
From: Vatsal <vatsal.avasthi(a)gmail.com>
Subject: Re: [dna-dev] @author tags in our codebase
To: dna-dev(a)lists.jboss.org
Message-ID:
<c82836c60901132343w54b690a9ha9c183e5ee61d019(a)mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sometimes it is fun to see your name in author tag of a project at a later
date when the project has matured but my vote would be for Randall's
suggestions due to practical & maintenance reasons discussed earlier, so a
+1 from me for this proposal(though I am not a contributor yet :) )...
- Vatsal
On Wed, Jan 14, 2009 at 3:33 AM, Randall Hauch <rhauch(a)redhat.com> wrote:
> We never really came to a consensus on this question, and I'd like to try
> to do that. To be clear, here is the proposal:
>
> 1) Remove the @author lines from the code, and instead rely upon SVN as the
> official master record of individual contributions
> 2) Change the Eclipse preference files to remove the @author lines from the
> code templates
> 3) Add a AUTHORS file to the distribution(s); this file will contain the
> names and email addresses for all contributors, and can even allow a
> contributor to describe their contribution if they so desire.
> 4) Change the headers to remove the "@author" wording and to replace it
> with "See the AUTHORS file in the
> distribution for a full listing of individual contributors."
> 5) Change the POM files to include the AUTHORS file in each distribution.
>
> The AUTHORS file would look like this:
>
> Randall Hauch (rhauch(a)redhat.com)
>
> John Verhaeg (jverhaeg(a)redhat.com)
> Dan Florian (dflorian(a)redhat.com)
> Stefano Maestri (stefano.maestri(a)javalinux.it)
> Serge Pagop (Serge.Pagop(a)innoq.com)
> Michael Trezzi (michael(a)mathwizard.org)
> Alexandre Porcelli (porcelli(a)devexp.com.br)
> Sergiy Litsenko (litsenko_sergey(a)yahoo.com)
>
>
> Note that unlike the @author tags, this file will list all contributors,
> and the names of new contributors will be appended to the list by the
> project lead. (No names will be removed from this file.)
>
> I would prefer to hear from every contributor, so please respond with +1 if
> you agree with this proposal, 0 if you don't care, or -1 if you want to keep
> the @author tags. If you vehemently want to keep the @author tags and names
> in the source file, please say so.
>
> Best regards,
>
> Randall
>
> On Nov 18, 2008, at 3:33 PM, Randall Hauch wrote:
>
>
> On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
>
>
> Randall Hauch wrote on 17/11/08 22:17:
>
> I've recently read a suggestions for open source communities that the
>
> author names are removed from the content. In the case of DNA's
>
> codebase, that would mean removing the @author tags.
>
> May I ask where?
>
>
> I knew someone was going to ask. :-) I had to go back and look, but here
> are a few:
>
> http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
> http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
> http://subversion.tigris.org/hacking.html#other-conventions
> http://blogs.sun.com/ahe/entry/author_tags
>
>
>
> tags:
>
>
> 1. When there are no @author tags, then there is a far smaller
>
> notion of ownership by the author(s). On one side of this, the
>
> author(s) may not appreciate changes to "their" code, and on the
>
> other side, non-authors may feel intimidated about working on
>
> code for which they are not an author. IMO, we want to
>
> _discourage_ ownership and _encourage_ everyone to work in any
>
> area of the code they want.
>
>
> +1...but is really @author tag intimating someone, or giving ownership
>
> to some other? Quiet frankly not for me.
>
>
> I hope it doesn't discourage people from contributing and diving in
> wherever they want. BTW, it's quite possible that no matter what our
> policy, some people may not like it. For example, if we were to adopt a
> policy of NOT including @author tags, some people may refuse to join the
> community because they see the @author tag as proof they worked on it. It
> takes all kinds of people. :-)
>
>
> Anyway I agree on the _discurage_ownership and _encourage_everyone to
>
> work in any area, so if it can help, remove @author tag.
>
>
> 1. @author tags can be inaccurate. SVN has the true history of who
>
> contributed exactly what code.
>
>
> +1
>
>
> IMO, this is perhaps the biggest justifiable reason. Its rubbish if its
> not up-to-date, so it seems far better to not have @author tags.
>
>
>
> The only benefit I can think of is that the @author tag does help to
>
> give some notion of who is the "expert" of the class, in case they
>
> need to be consulted. However, I don't believe this is really much of
>
> a reason, since it's far better to consult the SVN history and see who
>
> actually modified the different parts of the code. In fact, the
>
> annotated views in Fisheye even show on many of the lines the name of
>
> the last person to change it. For example,
>
> see
> http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
>
>
> abosolutely better to use fisheye...if fine people of JBoss.org would
>
> also mind to upgrade it to a more recent version it would be even
>
> better. Also Jira integration may help a lot.
>
>
> I would just add that if we decide to remove the tag we have to change
>
> also the license information at the beginnig of any file which say:
>
> /* 2
>
> <
> http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
>
> * JBoss, Home of Professional Open Source. 3
>
> <
> http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
>
> * Copyright 2008, Red Hat Middleware LLC, and individual contributors 4
>
> <
> http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
>
> * as indicated by the @author tags. See the copyright.txt file in the 5
>
> <
> http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
>
> * distribution for a full listing of individual contributors.
>
>
>
> Yes, we'd have to update the headers.
>
> Best regards,
>
> Randall
>
>
>
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20090114/4b648c37/at...
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 10, Issue 5
**************************************
Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox
15 years, 3 months
Fwd: Updated: (DNA-270) Simplify the ExecutionContext framework
by Randall Hauch
Something about the ExecutionContext framework has been bugging me
over the past few weeks, so today I took a whack at addressing what I
perceived to be the problems. Some of these are outlined in the issue
below, but perhaps the biggest problem was in what users/clients saw:
the current design seemed to emphasize design/dependency perspective
and sacrificed simplicity for the user/client.
The patch outlined below (and attached to the issue) has the changes
I'm proposing. I'm pretty positive about these changes, because I
really think it simplifies what users/clients see (including how DNA
repositories will be configured). Basically, the existing
ExecutionContext interface is changed to a concrete implementation
(with default constructor, and methods to create other instances
relative to the context), and ExecutionContext now implements the
ExecutionContextFactory interface. Also, several implementations were
removed, and now there really is just one component (ExecutionContext)
that users/clients have to worry about.
If you have a chance, please review the patch and provide feedback.
Note that the patch was created using revision 701 (the current
revision as of tonight) as a baseline, so it should be easy to grab
the latest and apply the patch.
Best regards,
Randall
Begin forwarded message:
> From: "Randall Hauch (JIRA)" <jira-events(a)lists.jboss.org>
> Date: January 12, 2009 5:40:03 PM CST
> To: dna-issues(a)lists.jboss.org
> Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
> ExecutionContext framework
>
>
> [ https://jira.jboss.org/jira/browse/DNA-270?page=com.atlassian.jira.plugin...
> ]
>
> Randall Hauch updated DNA-270:
> ------------------------------
>
> Attachment: dna-270-executioncontext.patch
>
>
> Attached a patch file that has the proposed changes (relative to
> revision 701), and which results in all tests passing.
>
>> Simplify the ExecutionContext framework
>> ---------------------------------------
>>
>> Key: DNA-270
>> URL: https://jira.jboss.org/jira/browse/DNA-270
>> Project: DNA
>> Issue Type: Task
>> Components: API, Connectors, Documentation, Examples,
>> Graph, Sequencers
>> Affects Versions: 0.3
>> Reporter: Randall Hauch
>> Assignee: Randall Hauch
>> Fix For: 0.4
>>
>> Attachments: dna-270-executioncontext.patch
>>
>>
>> The ExecutionContext interface is used throughout the system. It's
>> defined in 'dna-graph', and used to represent the context or
>> environment for executing various activities. There is also
>> ExecutionContextFactory, which is an interface for creating other
>> contexts with different JAAS security contexts (login context or
>> access control contexts). There are also the Basic*
>> implementations of these interfaces, as well as several subclasses
>> (with various implementations).
>> The idea of using an interface for this was to simplify the design
>> of the components that uses/took an ExecutionContext, to prevent
>> propagating dependencies, and to allow customization. However,
>> since ExecutionContext is largely just an aggregation of
>> references, there's little need to customize the behavior, and this
>> doesn't really add any other dependencies to the classpath (all
>> implementations of the aggregated components are already in 'dna-
>> graph') and it doesn't expose any implementations through the
>> method signatures. Using interfaces also complicates the usage,
>> since clients have to know about the concrete implementations.
>> This is even more true when they're setting up the DNA services and
>> repositories in 'dna-repository' and 'dna-jcr'.
>> So, consider changing this interface to a concrete class, with
>> methods that make it easy to create instances as well as instances
>> with custom components (e.g., a new context that is the same as
>> 'this' but with a supplied NamespaceRegistry implementation).
>> This will change the public API, but this should be acceptable
>> given that we're not yet at 1.0 (and this really improves both the
>> client code, and doesn't really change extension implementations).
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
> _______________________________________________
> dna-issues mailing list
> dna-issues(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-issues
15 years, 3 months
