Re: Openmeetings - A Shepherd's View
Well I still opt to use Meta descriptors such as Maven POMs or CMake (probably only applicable for native projects) files in such cases which would allow to generate Eclipse/IDE you name it specific files once the sources has been obtained. Cheers Daniel On Mon, Sep 17, 2012 at 10:22 PM, sebb wrote: > On 14 September 2012 13:57, Alexei Fedotov wrote: >> The most useful file containing the project classpath is only formatted >> automatically, it cannot be generated without project-specific knowledge. >> >> There is no techical problem to drop these files, yet developers who >> download our source release loose a useful code navigation tool without >> these files. > > Unfortunately, Eclipse .classpath and .project files are *not* > portable; the contents can depend on the individual Eclipse setup. > In particular, unless all developers use the same default JDK as > required by the project, the classpath files will vary. > Also, the .project file will vary if some developers have added > certain plugins, e.g. FindBugs or Maven. > > Having the files in SVN in the location where Eclipse expects to find > them will cause problems for some developers, as they will need to > modify the files locally in order to build. They cannot commit the > files without causing problems for others, and so their workspace will > always contain modifications. > > If you do wish to release IDE build files, I suggest you release them > as separate files, e.g. under > > res/ide-support/eclipse > res/ide-support/netbeans > > etc. > > The files can be named > > eclipse.classpath > eclipse.profile > > as files without names can cause problems. > >> 14.09.2012 16:46 пользователь "Jim Jagielski" написал: >> >>> >>> On Sep 14, 2012, at 5:02 AM, Mohammad Nour El-Din >>> wrote: >>> >>> > >>> > But can we add ASL headers to files which are defined and considered >>> > to be, even structure wise (please correct me if I am wrong), under >>> > the license of Eclipse ? >>> > >>> >>> If they are build artifacts (like stuff created by autoconf >>> for example), then there's no need to add AL headers (AL, not ASL). >>> AL headers are for actual work products (like source code, etc)... >>> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Ambari (incubating) 0.9 Release Candidate RC3.
Hi everyone, This is a call for a vote on Apache Ambari 0.9 incubating. This will be our first release. A vote was held on developer mailing list and it passed with 6 +1's. http://markmail.org/thread/7uxpmhwj7ak2z2zk +1s: mahadev (IPMC, PPMC) ddas (IPMC, PPMC) acmurthy (IPMC) jitendra (PPMC) hitesh (PPMC) yusaku (Committer) SVN source tag (r1379196) http://svn.apache.org/repos/asf/incubator/ambari/branches/branch-0.9/ Staging site: http://people.apache.org/~mahadev/ambari-0.9-incubating-rc3/ PGP release keys (signed using 8EE2F25C) http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x0DFF492D8EE2F25C One can look into the issues fixed in this release at https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12321561 Please download, test, and vote by September 20th at 4PM Pacific Time. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) thanks mahadev - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
automating history charts and Clutch
sebb wrote: > David Crossley wrote: > > Jukka Zitting wrote: > >> crossley wrote: > >> > r1386462 > >> > Modified: > >> > incubator/public/trunk/content/history/current.txt > >> > >> Thanks for keeping that file up to date! The graph at > >> http://incubator.apache.org/history/ is quite useful. > >> > >> However, I'm wondering if there really is need to manually maintain a > >> separate text file when all the required information should already be > >> present in podlings.xml. Can we generate the current.txt file from > >> podlings.xml, or (even better) have the client create the history > >> graph directly from podlings.xml? > > > > It would be fantastic if someone could automate that. > > At the moment, the current.txt (yellow) is maintained manually > > and the entry.txt (green) is automatically handled by Clutch. > > Ideally both would be automated independently of Clutch. > > Perhaps add a task to build.xml that generates current.txt and > entry.txt from podlings.xml? > Could extract the entry.txt code from clutch and extend it to handle > current.txt > > If that sounds reasonable, I'm happy to give that a try. That seems like a good solution, now that we have the podlings.xml file. > Maybe at some point clutch itself could be run automatically whenever > podlings.xml is updated. Perhaps just run it twice per day regardless. There are other things that it assesses too. Yesterday the podlings.xml was updated a number of times in quick succession to catch up with laggard graduates. So would not want to run cumbersome Clutch on each update. Or perhaps it could be triggered by Ant, say 30 minutes after the update, otherwise once per day. Clutch seems reasonably robust now. The main thing that used to trip it up was project names with inconsistent spellings for different resources. The recent addition of the "resourceAliases" attribute in podlings.xml does assist. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1386462 - /incubator/public/trunk/content/history/current.txt
On 17 September 2012 23:36, David Crossley wrote: > Jukka Zitting wrote: >> crossley wrote: >> > Modified: >> > incubator/public/trunk/content/history/current.txt >> >> Thanks for keeping that file up to date! The graph at >> http://incubator.apache.org/history/ is quite useful. >> >> However, I'm wondering if there really is need to manually maintain a >> separate text file when all the required information should already be >> present in podlings.xml. Can we generate the current.txt file from >> podlings.xml, or (even better) have the client create the history >> graph directly from podlings.xml? > > It would be fantastic if someone could automate that. > At the moment, the current.txt (yellow) is maintained manually > and the entry.txt (green) is automatically handled by Clutch. > Ideally both would be automated independently of Clutch. > Perhaps add a task to build.xml that generates current.txt and entry.txt from podlings.xml? Could extract the entry.txt code from clutch and extend it to handle current.txt If that sounds reasonable, I'm happy to give that a try. Maybe at some point clutch itself could be run automatically whenever podlings.xml is updated. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1386462 - /incubator/public/trunk/content/history/current.txt
Jukka Zitting wrote: > crossley wrote: > > Modified: > > incubator/public/trunk/content/history/current.txt > > Thanks for keeping that file up to date! The graph at > http://incubator.apache.org/history/ is quite useful. > > However, I'm wondering if there really is need to manually maintain a > separate text file when all the required information should already be > present in podlings.xml. Can we generate the current.txt file from > podlings.xml, or (even better) have the client create the history > graph directly from podlings.xml? It would be fantastic if someone could automate that. At the moment, the current.txt (yellow) is maintained manually and the entry.txt (green) is automatically handled by Clutch. Ideally both would be automated independently of Clutch. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Openmeetings - A Shepherd's View
On 14 September 2012 17:53, Benson Margulies wrote: > Does anyone seriously believe that IP notices are required in files like > these? > > These files cannot be copyrighted because they do not have any > 'creative' content. If they can't be copyrighted, they can't be > licensed. And, even it were otherwise, the notices at the top of the > tree are sufficient. This isn't the first instance of a 'source' file > format that has no provisions for an IP notice. Just for completeness: the file format does allow comments; it is standard XML and can therefore contain an IP notice should one be required. > On Fri, Sep 14, 2012 at 9:42 AM, dsh wrote: >> Well I think Maven allows to create both Eclipse and IDEA IntelliJ >> projects including metdata artifacts such as .classpath files... >> >> Cheers >> Daniel >> >> On Fri, Sep 14, 2012 at 2:57 PM, Alexei Fedotov >> wrote: >>> The most useful file containing the project classpath is only formatted >>> automatically, it cannot be generated without project-specific knowledge. >>> >>> There is no techical problem to drop these files, yet developers who >>> download our source release loose a useful code navigation tool without >>> these files. >>> 14.09.2012 16:46 пользователь "Jim Jagielski" написал: >>> On Sep 14, 2012, at 5:02 AM, Mohammad Nour El-Din wrote: > > But can we add ASL headers to files which are defined and considered > to be, even structure wise (please correct me if I am wrong), under > the license of Eclipse ? > If they are build artifacts (like stuff created by autoconf for example), then there's no need to add AL headers (AL, not ASL). AL headers are for actual work products (like source code, etc)... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Openmeetings - A Shepherd's View
On 14 September 2012 13:57, Alexei Fedotov wrote: > The most useful file containing the project classpath is only formatted > automatically, it cannot be generated without project-specific knowledge. > > There is no techical problem to drop these files, yet developers who > download our source release loose a useful code navigation tool without > these files. Unfortunately, Eclipse .classpath and .project files are *not* portable; the contents can depend on the individual Eclipse setup. In particular, unless all developers use the same default JDK as required by the project, the classpath files will vary. Also, the .project file will vary if some developers have added certain plugins, e.g. FindBugs or Maven. Having the files in SVN in the location where Eclipse expects to find them will cause problems for some developers, as they will need to modify the files locally in order to build. They cannot commit the files without causing problems for others, and so their workspace will always contain modifications. If you do wish to release IDE build files, I suggest you release them as separate files, e.g. under res/ide-support/eclipse res/ide-support/netbeans etc. The files can be named eclipse.classpath eclipse.profile as files without names can cause problems. > 14.09.2012 16:46 пользователь "Jim Jagielski" написал: > >> >> On Sep 14, 2012, at 5:02 AM, Mohammad Nour El-Din >> wrote: >> >> > >> > But can we add ASL headers to files which are defined and considered >> > to be, even structure wise (please correct me if I am wrong), under >> > the license of Eclipse ? >> > >> >> If they are build artifacts (like stuff created by autoconf >> for example), then there's no need to add AL headers (AL, not ASL). >> AL headers are for actual work products (like source code, etc)... >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Cordova (incubating) 2.1.0
Hey Everyone, This is a call for a vote on releasing the following candidate as Apache Cordova 2.1.0 (incubating). This will be our first release. A vote was held on the developer mailing list and passed with 17 +1s: http://markmail.org/thread/lkgvtg3t6r3wxvwj Binding Steven Gill +1 Simon MacDonald + 1 Fil Maj +1 Shazron Abdullah +1 Joe Bowser +1 Anis Kadri +1 Herm Wong +1 Tim Kim +1 Michael Brooks +1 Andrew Grieve +1 Brian LeRoux +1 Braden Shepherdson + 1 Dave Johnson +1 Jesse MacFayden +1 Becky Gibson +1 Bryce Curtis +1 Mentor/IPMC Jukka Zitting +1 We need two additional IPMC votes. Please download, test, and vote by September 20th at 12:00pm Pacific Time. Release files: http://people.apache.org/~steven/ The vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, -Steve Gill
Re: svn commit: r1386462 - /incubator/public/trunk/content/history/current.txt
Hi, On Mon, Sep 17, 2012 at 5:28 AM, wrote: > Log: > awf retired 2012-09-16 > > Modified: > incubator/public/trunk/content/history/current.txt Thanks for keeping that file up to date! The graph at http://incubator.apache.org/history/ is quite useful. However, I'm wondering if there really is need to manually maintain a separate text file when all the required information should already be present in podlings.xml. Can we generate the current.txt file from podlings.xml, or (even better) have the client create the history graph directly from podlings.xml? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
