You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> on 2012/01/23 21:55:56 UTC
[DISCUSS] Airavata 0.2 release (was Re: Preparing Apache Airavata
0.2-Incubating Release)
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 <sm...@apache.org> 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<sm...@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [DISCUSS] Airavata 0.2 release (was Re: Preparing Apache Airavata
0.2-Incubating Release)
Posted by Lahiru Gunathilake <gl...@gmail.com>.
Hi Alek,
Can you please raise jiras to improve the usability ?
Lahiru
On Tue, Jan 31, 2012 at 3:07 PM, Lahiru Gunathilake <gl...@gmail.com>wrote:
> Hi Alek,
>
> On Tue, Jan 31, 2012 at 2:37 PM, Aleksander Slominski <as...@apache.org>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) <
>> chris.a.mattmann@jpl.nasa.gov> 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 <sm...@apache.org>
>>> 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<
>>> smarru@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
>>> >> 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: chris.a.mattmann@nasa.gov
>>> 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
Re: [DISCUSS] Airavata 0.2 release (was Re: Preparing Apache Airavata
0.2-Incubating Release)
Posted by Lahiru Gunathilake <gl...@gmail.com>.
Hi Alek,
On Tue, Jan 31, 2012 at 2:37 PM, Aleksander Slominski <as...@apache.org>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) <
> chris.a.mattmann@jpl.nasa.gov> 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 <sm...@apache.org>
>> 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<
>> smarru@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
>> >> 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: chris.a.mattmann@nasa.gov
>> 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
Re: [DISCUSS] Airavata 0.2 release (was Re: Preparing Apache Airavata
0.2-Incubating Release)
Posted by Aleksander Slominski <as...@apache.org>.
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) <
chris.a.mattmann@jpl.nasa.gov> 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 <sm...@apache.org>
> 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<
> smarru@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
> >> 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: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
Re: [DISCUSS] Airavata 0.2 release (was Re: Preparing Apache
Airavata 0.2-Incubating Release)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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 <sm...@apache.org> 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<sm...@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
>> 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: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [DISCUSS] Airavata 0.2 release (was Re: Preparing Apache Airavata 0.2-Incubating Release)
Posted by Suresh Marru <sm...@iu.edu>.
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 <sm...@apache.org> 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<sm...@cs.indiana.edu>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: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>