Ross Gardler wrote: > Ross Gardler wrote: > >David Crossley wrote: > >> > >>* jars without accompanying licenses. > >>* jar filenames not following our naming convention. > > > >Sorry, Lazy, I will sort that out today. > > Done.
Thanks, that is quite an effort i know. > A couple of jars are still without version numbers as I can't find what > version they are. Which makes it obvious why we need such metadata about the jars. Oh well, next time we update them, we can assign better filenames. Another topic for later: Should we be keeping better track of our supporting jars like Cocoon does: http://cocoon.apache.org/2.1/installing/jars.html The page is generated from xml and the build system, verifies that each jar has an entry in the table. Another aspect to this licensing job is to review each license to see if there are any other conditions that they specify, such as asking for attribution in the NOTICE.txt at our top-level. All seems okay. However, activation.jar is a worry. http://maven.apache.org/reference/standard-sun-jar-names.html We need to tell people to download that separately. Sounds like the beginning of the user documentation for our Eclipse plugin. Anil and others ... One feature of the Apache Software Foundation is that we don't add any supporting libraries that impose conditions that are any more restrictive than the Apache License 2. > Also, I need some advice on the license for xmlParsersAPIs-2.5.jar, > there are three licenses inside the jar: > > dom-documentation > dom-software > sax > > Right now I have have each of them in the lib directory, and have added > an XMLParserAPIs- prefix. This means there are three licenses for one > jar. Is that OK? Sounds fine. The main thing is that we make our best effort to inform users about each jar and its license. > >>* bloated distribution. > >> > >>This commit r202158 added a huge quantity of data. > >>Our svn checkout was 132816 kb before and 144516 kb after > >>(an increase of 9%). We already have problems with the size > >>of the distribution due to all the Cocoon stuff. > > > >There is no need for this tool to be included in the distribution. How > >about we move the eclipse support stuff into a separate SVN tree? > > > >Although, most of that bloat is from duplicated jars so the above issue > >may solve this. Lets talk about this in a separate thread. Not neccessarily right now, but sometime we need to revisit the discussion about Tools/Sub-projects and how to manage them. -David
