Hi Alek, Can you please raise jiras to improve the usability ?
Lahiru On Tue, Jan 31, 2012 at 3:07 PM, Lahiru Gunathilake <[email protected]>wrote: > Hi Alek, > > On Tue, Jan 31, 2012 at 2:37 PM, Aleksander Slominski <[email protected]>wrote: > >> Hi, >> >> I ran both tutorials: 5 minute worked fine but 10 minutes failed fro >> usability point of view: printing of XML shoudld be serialized not >> toString() or we get "echo_input=name[value] namespace[] which makes sense >> for underlying XML [1] but not for Message line ... >> > This issue is fixed in trunk. > > > Lahiru > >> >> See attached screenshot. >> >> Also I think we need to fix documentation on dependencies and NOTICE as >> mentioend before but also fix Disclaimer in README [2] as i think it should >> be Airavata not Rave? >> >> HTH, >> >> Alek >> >> [2] "Disclaimer >> ========== >> Apache Rave is an effort undergoing incubation at The Apache Software >> Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation is >> required >> of all newly accepted projects until a further review indicates that the >> infrastructure, communications, and decision making process have >> stabilized in a >> manner consistent with other successful ASF projects. While incubation >> status is >> not necessarily a reflection of the completeness or stability of the >> code, it >> does indicate that the project has yet to be fully endorsed by the ASF. >> " >> [1] >> <wor:invokingService infoModelVersion="2.6" >> xmlns:wor="http://airavata.apache.org/schemas/workflow_tracking_types >> "> >> <wor:notificationSource >> wor:serviceID="a39ad225_60bc_44a1_9a60_57017909e70f" /> >> <wor:timestamp>2012-01-31T14:23:28.691-05:00</wor:timestamp> >> <wor:description>echo_input=name[value] namespace[]</wor:description> >> <wor:annotation /> >> <wor:request> >> <wor:body> >> <n1:invoke_InputParams >> xmlns:n1=" >> http://schemas.airavata.apache.org/gfac/type/EchoService/xsd";> >> <echo_input> >> <value>Alek2</value> >> </echo_input> >> </n1:invoke_InputParams> >> </wor:body> >> </wor:request> >> <wor:receiver wor:serviceID="EchoService_invoke" >> wor:workflowID="a39ad225_60bc_44a1_9a60_57017909e70f" >> wor:workflowTimestep="0" wor:workflowNodeID="EchoService_invoke" /> >> </wor:invokingService> >> >> >> >> >> On Mon, Jan 23, 2012 at 5:06 PM, Mattmann, Chris A (388J) < >> [email protected]> wrote: >> >>> Cool sounds great! >>> >>> Cheers, >>> Chris >>> >>> On Jan 23, 2012, at 1:22 PM, Suresh Marru wrote: >>> >>> > Hi Chris, >>> > >>> > Thanks for pinging on and offering to help. We have enough features in >>> 0.2 branch and 0.3 trunk for going for a quick two releases. I will email >>> tonight with the list of tasks needed wrap to wrap release. >>> > >>> > Thanks, >>> > Suresh >>> > >>> > On Jan 23, 2012, at 3:55 PM, Mattmann, Chris A (388J) wrote: >>> > >>> >> Hey Guys, >>> >> >>> >> What's the status of Airavata 0.2-incubating? Can I help? Do you need >>> mentor >>> >> VOTEs or help respinning? Let me know and I'll try and find some time >>> this week >>> >> to take a look. >>> >> >>> >> Thanks! >>> >> >>> >> Cheers, >>> >> Chris >>> >> >>> >> On Dec 16, 2011, at 9:44 AM, Suresh Marru wrote: >>> >> >>> >>> Hi Chathura, >>> >>> >>> >>> I volunteer to take care of the incubator compliance. We have good >>> attention to detail mentors, so if we address all the issues raised in >>> community vote, we should be in good shape in general voting. Your time >>> line sounds good. I do not think we want to branch before Friday (as per >>> your testing time). We can defer the branching decision for now and >>> probably focus on getting good testing done within this timeline. >>> >>> >>> >>> Suresh >>> >>> >>> >>> On Dec 16, 2011, at 12:22 PM, Chathura Herath wrote: >>> >>> >>> >>>> Hi Suresh, >>> >>>> >>> >>>> I went through the JIRA's and categorized to 0.2 and future release. >>> >>>> (This will yeild our 0.3 goals hopefully). From the looks of it i >>> want >>> >>>> to focus on addressing few JIRA that i feel will be critical. I am >>> >>>> guessing we will be able to finish them by end of the day Monday >>> next >>> >>>> week. >>> >>>> >>> >>>> Rest of the week for testing and we could make the release on next >>> >>>> Friday. I am hoping you will go through the trouble of generating >>> the >>> >>>> distributions and incubator compliance. >>> >>>> >>> >>>> As for the branching, I would prefer to work on the trunk till >>> Monday >>> >>>> if no other major development task that conflicts. >>> >>>> >>> >>>> Thanks >>> >>>> Chathura >>> >>>> >>> >>>> On Fri, Dec 16, 2011 at 11:52 AM, Suresh Marru <[email protected]> >>> wrote: >>> >>>>> Hi All, >>> >>>>> >>> >>>>> I have been traveling and slow in catching up with Airavata. Since >>> the last release candidate and issues Ate raised, we have addressed them >>> and made some developments. But I see a flood of new JIRA tasks as well. >>> How about we freeze development for couple of days, test, address and close >>> any open issues and prepare for 0.2 release as discussed below? >>> >>>>> >>> >>>>> Any one wants to suggest a time line when we will be able to test >>> and update documentation and get ready for the release? >>> >>>>> >>> >>>>> If there is enough active development and if release is not going >>> smoothly, we can branch 0.2-snapshop and release the branch and ensure >>> everything is sync'ed back. >>> >>>>> >>> >>>>> Suresh >>> >>>>> >>> >>>>> On Nov 17, 2011, at 5:03 AM, Ate Douma wrote: >>> >>>>> >>> >>>>>> On 11/16/2011 05:01 PM, Lahiru Gunathilake wrote: >>> >>>>>>> I am +1 to create RC3 with trunk but we should branch again >>> first and then >>> >>>>>>> do the RC3. I have few more commits to go.. Suresh can you >>> please wait >>> >>>>>>> until you branch from trunk.. >>> >>>>>> >>> >>>>>> AFAIK the trunk now is on 0.2-incubating-SNAPSHOT. >>> >>>>>> As 0.1-incubating already has been tagged (and tags should never >>> be deleted/reused IMO), so we should be looking at creating a new >>> 0.2-incubating tag instead of a RC3. >>> >>>>>> >>> >>>>>> Not sure why you want to or think need to first branch to create >>> a 0.2-incubating tag. Typically this all can be done in one step from the >>> trunk using the maven-release-plugin. 'Downside' of that is that you >>> typically don't do 'RC' builds anymore, but once a build is stable/proper >>> (from a technical and construction POV) doing RC builds only adds up on the >>> work in my experience. >>> >>>>>> >>> >>>>>> Creating branches is more useful IMO for specific (refactoring) >>> experiments or (more importantly) maintenance trees, e.g. once Airavata >>> 1.0(.0) is released you might want to create a 1.0.x branch (or 1.x branch) >>> as a 'maintenance trunk' for development of minor update releases while >>> trunk development moves to 1.1 (or 2.0). >>> >>>>>> >>> >>>>>> If however you desire to use RC preparation branches (so trunk is >>> free to move forward, but then you'll need to 'sync' changes from the RC >>> branch back), that's fine too, but I then suggest using explicitly naming >>> for such branches. >>> >>>>>> The current RC branch was called 0.1-incubating, which IMO then >>> better should have been called 0.1-incubating-SNAPSHOT >>> >>>>>> >>> >>>>>> Ate >>> >>>>>> >>> >>>>>>> >>> >>>>>>> Lahiru >>> >>>>>>> >>> >>>>>>> On Wed, Nov 16, 2011 at 10:35 AM, Suresh Marru< >>> [email protected]>wrote: >>> >>>>>>> >>> >>>>>>>> Hi All, >>> >>>>>>>> >>> >>>>>>>> I suggest we make the RC3 with latest from trunk which includes >>> some of >>> >>>>>>>> the improvements/big fixes made after RC2. Any objections? If I >>> do not see >>> >>>>>>>> any objections, I will add the new JIRA's to the release notes >>> and after we >>> >>>>>>>> address rest of missing notice/license, re-tag from trunk >>> itself. >>> >>>>>>>> >>> >>>>>>>> Suresh >>> >>>>>>>> >>> >>>>>>>> On Nov 16, 2011, at 6:35 AM, Suresh Marru wrote: >>> >>>>>>>> >>> >>>>>>>>> Hi Ate, >>> >>>>>>>>> >>> >>>>>>>>> Thank you very much for the detailed feedback, will go by them >>> one by >>> >>>>>>>> one to address them. >>> >>>>>>>>> >>> >>>>>>>>> Suresh >>> >>>>>>>>> On Nov 16, 2011, at 5:48 AM, Ate Douma wrote: >>> >>>>>>>>> >>> >>>>>>>>>> I've shortly reviewed this release candidate and found >>> several issues >>> >>>>>>>> with it which regrettably makes me have to vote -1 on this >>> candidate: >>> >>>>>>>>>> >>> >>>>>>>>>> - BLOCKER: none of the *.jar artifacts (including derived >>> build >>> >>>>>>>> -javadoc.jar, -sources.jar) contain the required incubator >>> DISCLAIMER file >>> >>>>>>>>>> >>> >>>>>>>>>> - BLOCKER: the binary distributions LICENSE/NOTICE files are >>> not >>> >>>>>>>> covering all bundled external dependencies which have/require >>> separate >>> >>>>>>>> mentioning, e.g. like activation-1.1.jar (CDDL license!), >>> jaxen-1.1.1.jar, >>> >>>>>>>> logback-*.jar, jibx-*.jar, mex-*.jar, and probably (much) more, >>> I stopped >>> >>>>>>>> checking after finding already these. >>> >>>>>>>>>> In general any bundled artifact should be checked proper what >>> >>>>>>>> license/notice requirements it needs. For some this can be >>> derived from the >>> >>>>>>>> jar itself but many don't have any so they need looking up >>> elsewhere. And >>> >>>>>>>> even for ASF provided artifacts this is needed as some have >>> *additional* >>> >>>>>>>> notices (beyond the default ASF notice) which then also should >>> be >>> >>>>>>>> covered/copied in the project NOTICE file. I also see several >>> edu.indiana >>> >>>>>>>> provided artifacts (weps-beans, pegasuswebservice, maybe more) >>> of which it >>> >>>>>>>> isn't clear to me if/what license requirements they have. I see >>> xpp3 >>> >>>>>>>> mentioned in the NOTICE file, but not these? >>> >>>>>>>>>> >>> >>>>>>>>>> - In addition I see several cryptix-* and jce-* libraries >>> bundled: I >>> >>>>>>>> suppose these contain encryption techology/algorithms. I'm not >>> sure if/how >>> >>>>>>>> these should be handled and/or require special notices. >>> Possibly not, but I >>> >>>>>>>> suggest asking this specifically on general@incubator or check >>> related >>> >>>>>>>> documents just to be sure (this is not my expertise). >>> >>>>>>>>>> >>> >>>>>>>>>> - The binary distributions contain a lot license files under >>> >>>>>>>> standalone-server/lib which are not needed, at least not from >>> ASF pov (the >>> >>>>>>>> root LICENSE/NOTICE files already should cover everything), >>> besides there >>> >>>>>>>> are even some for artifacts which aren't even bundled... >>> >>>>>>>>>> >>> >>>>>>>>>> - The -source.tar.gz and -source.zip distributions, which are >>> different >>> >>>>>>>> from the already automatically maven produced >>> >>>>>>>> airavata-0.1-incubating-source-release.zip, have .svn folders >>> embedded. It >>> >>>>>>>> wonder why these separate source distributions are made anyway >>> as maven >>> >>>>>>>> already produces the only one needed... >>> >>>>>>>>>> (note: if only using this -source-release.zip, it is required >>> to copy >>> >>>>>>>> this to the official download area on the apache server) >>> >>>>>>>>>> >>> >>>>>>>>>> - POSSIBLE BLOCKER: The binary distributions (both .tar.gz >>> and .zip) >>> >>>>>>>> are also 'build' through maven *and* deployed to the >>> repository. However >>> >>>>>>>> these have different sizes. I haven't actually (binary) >>> compared them but >>> >>>>>>>> this seems odd. Furthermore, I would suggest not to deploy >>> these binary >>> >>>>>>>> distributions to the repository as they have no usage from a >>> maven (build) >>> >>>>>>>> perspective and these distributions in any case are required >>> (at least) to >>> >>>>>>>> be downloaded through the main apache server(s), something >>> which maven >>> >>>>>>>> central is *not*. Redundantly providing these also through the >>> maven >>> >>>>>>>> repository seems unneeded, if not undesired. >>> >>>>>>>>>> >>> >>>>>>>>>> - The distribution module also uses packaging type 'jar' >>> (default). For >>> >>>>>>>> assembly only poms better use packaging type 'pom', because now >>> even a >>> >>>>>>>> 'distribution-0.1-incubating.jar' (and derived -sources.jar) is >>> >>>>>>>> produced/deployed, which is useless. >>> >>>>>>>>>> To prevent deploying the assembly produced binary artifacts >>> to the >>> >>>>>>>> remote repositories just add<attach>false</attach> to the >>> assembly plugin >>> >>>>>>>> config. >>> >>>>>>>>>> >>> >>>>>>>>>> Ate >>> >>>>>>>>>> >>> >>>>>>>>>> On 11/11/2011 06:35 PM, Suresh Marru wrote: >>> >>>>>>>>>>> Discussion thread for vote on airavata 0.1-incubating release >>> >>>>>>>> candidate 2. >>> >>>>>>>>>>> >>> >>>>>>>>>>> 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 >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> -----BEGIN PGP SIGNATURE----- >>> >>>>> >>> >>>>> iQIcBAEBAgAGBQJO63c3AAoJEHmz9P1hfdutxzkP/jNDPTeqX786+ySaBVMIrHn7 >>> >>>>> 7KgJ2ED31H3CBLBcTHHSFe6ohg/cCmRH612OiovIHcLRGgebD3P+a+kYiNIE9WQt >>> >>>>> QT/wEx8MYZP8B4gHswqtnUwK/PAf3Z45I4W3Sthrh4zhj99Sl2S5jJGDVvXsp+L2 >>> >>>>> DvtSlrXyHC5QjvihzzWe1tFZqcDBRmSMhwITcot224xbUH7Sjt+TNiEYdSPj0EBK >>> >>>>> psg7lISLJt0CT5G+gax8RaJqnv2oIH97KF2AJAr3mnEBC1Z0yJnGPlIo/LoO0z6i >>> >>>>> OEZry4KKHA/oDlZpatdiJtxTPu2gXd2NldP7/PZgV6kdtP6pTXT3vB5/IEL8n/O4 >>> >>>>> u7u1kJJyMYZh8m9WpdaRd92S78M6NTqJs8i9gCSiHgh2+mT5U94HedgeXBySpv8A >>> >>>>> l6u3lQjG84r3ILuG49VfycMj2hb8aO/FCjJOtuQgKlgz8e/xb3s2Df69b+GsAVNr >>> >>>>> CAPG9b5d2KlCmkxQ+js5igWbtHLFKmL+eVWzl96MBGx/YM7O+szkzNp8892tXf8V >>> >>>>> a6MN8p4BdL4Z286HY+iJGHRvgTRPN6H8hnJnEAAS8siO1c3itEbfSvV2DWEq5Pgr >>> >>>>> uis5HUP9k4m2kGHOfqy1G+7aWgnVl4mG7s2nOsE/0KhFxZdxt4GgzoIJadz5UoRN >>> >>>>> lAjoS84lmDUSRjG3QI54 >>> >>>>> =mawE >>> >>>>> -----END PGP SIGNATURE----- >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Chathura Herath >>> >>>> http://people.apache.org/~chathura/ >>> >>>> http://chathurah.blogspot.com/ >>> >>> >>> >> >>> >> >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >> Chris Mattmann, Ph.D. >>> >> Senior Computer Scientist >>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>> >> Office: 171-266B, Mailstop: 171-246 >>> >> Email: [email protected] >>> >> WWW: http://sunset.usc.edu/~mattmann/ >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >> Adjunct Assistant Professor, Computer Science Department >>> >> University of Southern California, Los Angeles, CA 90089 USA >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >> >>> > >>> >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Chris Mattmann, Ph.D. >>> Senior Computer Scientist >>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>> Office: 171-266B, Mailstop: 171-246 >>> Email: [email protected] >>> WWW: http://sunset.usc.edu/~mattmann/ >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Adjunct Assistant Professor, Computer Science Department >>> University of Southern California, Los Angeles, CA 90089 USA >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> >> > > > -- > System Analyst Programmer > PTI Lab > Indiana University > > -- System Analyst Programmer PTI Lab Indiana University
