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 ...
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
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
