I think each .aar file should have its dependencies wrapped in it because users should be able to host these services in to different axis2 distributions independently.. in real it should be like that, I don't think its a good idea to remove the common artifacts from .aar files.
Lahiru On Sun, Nov 6, 2011 at 11:01 AM, Suresh Marru <[email protected]> wrote: > Thanks again Ate. I will fix this and will make a RC2 before calling for a > vote. > > Meanwhile, I request all dev's to look into optimizing the binary > distribution and I agree with Ate that there are quite a few duplicates we > can get rid of. > > Suresh > > On Nov 6, 2011, at 7:39 AM, Ate Douma wrote: > > > On 11/06/2011 07:12 AM, Suresh Marru wrote: > >> Hi Ate, > >> > >> Thank you very much for reviewing and early feedback. This really helps > to sort out things before the formal vote which is still waiting on fixing > the nexus setup. As for the LICENSE and NOTICE files, I was lost reading > too many release guides. Your discussion on rave-dev list ( > http://goo.gl/v482T) helped me clear up the confusion. Can you please > verify if I understood the following correctly: > > > > For the incubator the guidelines from the Release Management document > really are very clear IMO, and those should be followed. > > > >> > >> 1) We will need to maintain two sets of LICENSE and NOTICE files. Since > airavata source does not have any external code in the source tree, the > LICENSE and NOTICE files within the root of source should remove mentioning > of all third party delegates and only should have ASF V2. Is this correct? > > Yes > > > >> > >> 2) The binary distribution should have a different set of LICENSE and > NOTICE files. Since at build time, we pull in multiple jars in package them > up, the binary distribution should actually have all the licenses of the > dependent jars explicitly mentioned. > > Yes > > > >> > >> 3) If we have multiple jars of same license, can we just name multiple > dependencies and the license/notice or should we explicitly spell out each > one separately? > > Just mention which dependency uses which license and its OK then to > group them up together, no need for unneeded redundancy here :) > > > >> > >> If 2 is correct, can you please point me to a good reference > (preferably java project which bundles jars in distribution)? I tried to > follow, https, axis2 and ODE examples. To my own surprise, in comparison, > Airavata has fairly large dependent jars (making the binary distribution > 200MB). The diverse features may be the reason, but that still not an > excuse and this is something we need to work in the future releases to > closely analyze all dependencies and strip off the ones which are really > not needed or have redundant implementations. > > Apache Rave should be a good example :) > > > > I haven't really reviewed the actual contents of the distributions. > 200Mb seems like quite a lot. I think there might be some dependencies > doubled up multiple times here? Like these .aar files which are rather big, > do they (again) maybe package the same set of dependencies within? > > I also noticed there is a target build folder (although small) in one of > the examples which could be stripped. And I see the > jackrabbit-standalone-2.2.7 ueber-jar packaged under /lib (which is 33Mb). > Probably that one also doubles several dependencies. > > I think there should be room for further optimizing the size of this > distribution quite a lot. > > > >> Thanks, > >> Suresh > >> > >> > >> On Nov 6, 2011, at 4:48 AM, Ate Douma wrote: > >> > >>> Hi Suresh, > >>> > >>> While I haven't checked out the code yet I noticed a first issue right > up with regards to the LICENSE and NOTICE files. > >>> Currently these files 'delegate' to 3rd party LICENSE/NOTICE files > embedded in bundled artifacts. However, this is not according to the Apache > rules and will likely result in down voting this release if put up for vote. > >>> > >>> Please use and follow the instructions and guidelines as given in the > Incubator Release Management Guideline [1] and specifically [2] for this. > >>> > >>> [1] http://incubator.apache.org/guides/releasemanagement.html > >>> [2] > http://incubator.apache.org/guides/releasemanagement.html#best-practice-license > >>> > >>> Kind regards, > >>> > >>> Ate > >>> > >>> > >>> On 11/05/2011 06:53 PM, Suresh Marru wrote: > >>>> Discussion thread for vote on airavata 0.1-incubating release > candidate. > >>>> > >>>> Since we are waiting on the nexus setup for the formal vote, I am > sending the details ahead. So please continue testing and discuss results. > >>>> > >>>> Detailed change log/release notes: > >>>> > https://svn.apache.org/repos/asf/incubator/airavata/tags/0.1-incubating/RELEASE_NOTES > >>>> > >>>> SVN source tag (r1198113): > >>>> > https://svn.apache.org/repos/asf/incubator/airavata/tags/0.1-incubating/ > >>>> > >>>> Maven staging repo: > >>>> TODO > >>>> > >>>> Source release: > >>>> > http://people.apache.org/builds/incubator/airavata/0.1-incubating/apache-airavata-0.1-incubating-source.tar.gz > >>>> > http://people.apache.org/builds/incubator/airavata/0.1-incubating/apache-airavata-0.1-incubating-source.zip > >>>> > >>>> Binary Artifacts > >>>> > http://people.apache.org/builds/incubator/airavata/0.1-incubating/apache-airavata-0.1-incubating-bin.tar.gz > >>>> > http://people.apache.org/builds/incubator/airavata/0.1-incubating/apache-airavata-0.1-incubating-bin.zip > >>>> > >>>> PGP release keys (signed using 617DDBAD): > >>>> https://svn.apache.org/repos/asf/incubator/airavata/KEYS > >>>> > >>>> If you have any questions or feedback or to post results of > validating the release, please reply to this thread. > >>>> > >>>> For reference, the Apache release guide - > http://www.apache.org/dev/release.html > >>>> Incubator specific release guidelines - > http://incubator.apache.org/guides/releasemanagement.html > >>>> > >>>> Some tips to validate the release before you vote: > >>>> > >>>> * Download the binary version and run the 5 minute or 10 minute > tutorial as described in README and website. > >>>> * Download the source files from compressed files and release tag and > build (which includes tests). > >>>> * Verify the distributon for the required LICENSE, NOTICE and > DISCLAIMER files > >>>> * Verify if all the staged files are signed and the signature is > verifiable. > >>>> * Verify if the signing key in the project's KEYS file is hosted on a > public server > >>>> > >>>> Thanks for your time in validating the release and voting, > >>>> Suresh > >> > > -- System Analyst Programmer PTI Lab Indiana University
