Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of ekoneil@gmail.com designates
 64.233.182.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=XPqdYqk7tEhxjM7e55WTMxGCjQXVZOV2lAFnz9uq3/GrTrTupZ30KOUmQ3sZFoji78n2uIsUmvMrbAoWluAxLjKKXri/h73a7420zenY70FlRXCeTz7Vhqsa0w0cnZNvMqbRAuxjwdcAvEsfk4tn+SVWcB3rX/6Ob81Yg0HionQ=
Message-ID: <e9ac83540606271221u4a27989etc7cba158f5d4ba5b@mail.gmail.com>
Date: Tue, 27 Jun 2006 12:21:52 -0700
From: "Eddie O'Neil" <ekoneil@gmail.com>
To: "Beehive Developers" <dev@beehive.apache.org>
Subject: Re: [jira] Commented: (BEEHIVE-206) control property
 constraint:AnnotationMemberTypes.Date accept one format
In-Reply-To: <2fd2f0570606271213g3cb2cf64k25ac8948a295dfef@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <33081538.1151351070949.JavaMail.jira@brutus>
	 <ecaa4efd0606271026w443c103xc7c5cb1c18a6420d@mail.gmail.com>
	 <e9ac83540606271137h5239872an42505e1a64e807bd@mail.gmail.com>
	 <ecaa4efd0606271159ge0a7193we5fa9755daf84572@mail.gmail.com>
	 <2fd2f0570606271213g3cb2cf64k25ac8948a295dfef@mail.gmail.com>

  Right -- agreed that the message change isn't a big deal to test.

  There isn't a good way (yet) to write tests that verify the behavior
of an annotation processor beyond testing the artifact it produces.  I
actually looked at this a while ago and started writing a JUnit
TestCase that could support hosting an annotation processor and
capturing its output (stdout/err and the generated messages).  Like
many side projects, I stopped working on it at one point...

  Would be an interesting thing to work on.

Eddie


On 6/27/06, Andrew McCulloch <amccullo@gmail.com> wrote:
> Hi Eddie,
>
> I did look into writing a JUnit test for this, but, since with or without
> this patch the particular error case is still a compile error I did not see
> a way to write a test that fit into the current test framework.  Is there a
> current way to write JUint tests to verify compiler errors/error messages
> (in this case due to malformed annotation values)?  In this case the bug was
> re-opened because the error was incorrect, I think the original issue did
> have a existing test case.
>
> On 6/27/06, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> >
> > I believe back when I made the original fix I added a tch case, I'll
> > verify that.  Andrew's patch just changed the error message displayed
> > when the test case fails.
> >
> > - Chad
> >
> > On 6/27/06, Eddie O'Neil <ekoneil@gmail.com> wrote:
> > > Chad / Andrew --
> > >
> > >   Thanks for the patch and fix -- do we have a test of this in
> > > Controls somewhere?  If not, could we add a JUnit one?
> > >
> > > Eddie
> > >
> > >
> > > On 6/27/06, Chad Schoettger <chad.schoettger@gmail.com> wrote:
> > > > Hi Andrew,
> > > >
> > > > Welcome to the Beehive community.   Thanks for the patch, I've applied
> > > > and committed it to svn.
> > > >
> > > > One tip for generating patch files:
> > > > When possible do your diff to generate the patch from your
> > > > <beehive/trunk> directory as this makes it a bit easier to apply.
> > > >
> > > > Thanks again for providing the patch --  hopefully your first of many.
> > > >
> > > >   - Chad
> > > >
> > > > On 6/26/06, Andrew McCulloch (JIRA) <dev@beehive.apache.org> wrote:
> > > > >     [
> > http://issues.apache.org/jira/browse/BEEHIVE-206?page=comments#action_12417889]
> > > > >
> > > > > Andrew McCulloch commented on BEEHIVE-206:
> > > > > ------------------------------------------
> > > > >
> > > > > When I use the test attached by James against the attached patch the
> > new error message is...
> > > > >
> > > > >       [apt]
> > /dev/svn/beehive/trunk/controls/test/src/units/org/apache/beehive/controls/test/java/property/MemberTypeTest.java:69:
> > A value assigned to a control property does not satisfy its constraints.
> > Cause: The value, 2007/01/31, assigned to maxValue date constraint property
> > is not in the specified format of: EEE, MMM d, ''yy
> > > > >       [apt]     private PersonControlBean thisPerson;
> > > > >       [apt]                                   ^
> > > > >       [apt] 1 error
> > > > >
> > > > >
> > > > > I believe this is the expected error for the attached version of
> > this testcase.
> > > > >
> > > > >
> > > > > > control property constraint:AnnotationMemberTypes.Date accept one
> > format
> > > > > >
> > ------------------------------------------------------------------------
> > > > > >
> > > > > >          Key: BEEHIVE-206
> > > > > >          URL: http://issues.apache.org/jira/browse/BEEHIVE-206
> > > > > >      Project: Beehive
> > > > > >         Type: Bug
> > > > >
> > > > > >   Components: Controls
> > > > > >     Versions: V1Beta
> > > > > >     Reporter: James Song
> > > > > >     Assignee: Chad Schoettger
> > > > > >     Priority: Minor
> > > > > >  Attachments: MemberTypeTest.java, MemberTypeTest.java,
> > PersonControl.java, PersonControl.java, diff-BEEHIVE-206.txt
> > > > > >
> > > > > > Currently, AnnotationMemberTypes.Date only accept YYYY/MM/DD.
> > > > > > There will be cases when user would like to specify the HH:MM, or
> > other input format, such as long date format.
> > > > >
> > > > > --
> > > > > This message is automatically generated by JIRA.
> > > > > -
> > > > > If you think it was sent incorrectly contact one of the
> > administrators:
> > > > >    http://issues.apache.org/jira/secure/Administrators.jspa
> > > > > -
> > > > > For more information on JIRA, see:
> > > > >    http://www.atlassian.com/software/jira
> > > > >
> > > > >
> > > >
> > >
> >
>
>