beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Beehive/tooling issue
Date Fri, 09 Sep 2005 16:37:55 GMT
One other thing here.  Jim Cummings has pointed out that this eliminates
the need for the "weboutputdir" attribute on the <build-pageflows>
macro, as well as the "web.output.root" option for our annotation
processors. I'd like to deprecate the "weboutputdir" attribute, and
remove the "web.output.root" option.  Any thoughts/objections?

Rich

Rich Feit wrote:

>OK, great.  Thanks for taking a look at it so quickly.
>
>Does anyone have any opposition to this fix getting checked in?
>
>Also, one quick thing:  the nightly-test script failed on my Windows box
>because it tried to create a directory with ':' in it:
>     build\dist\apache-beehive-20050909-svn279336:279683M
>
>I think all we need to do is filter the output of 'svnversion' in
>nightly.xml, to replace the ':' with something else.  Does that make sense?
>
>Rich
>
>Eddie O'Neil wrote:
>
>  
>
>>Rich--
>>
>> The diff looks good -- making this change definitely makes the
>>webapp build process simpler as it removes another tmp directory to
>>clean / manage.
>>
>> Nice...
>>
>>Eddie
>>
>>
>>
>>On 9/9/05, Rich Feit <richfeit@gmail.com> wrote:
>> 
>>
>>    
>>
>>>Ah, that's great.  I'd been doing a build.dist.full, then running a
>>>script to expand the dists and run tests against them.  This is nicer.  :)
>>>
>>>Rich
>>>
>>>Eddie O'Neil wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>You can run a full-on distribution test run by:
>>>>
>>>>cd trunk/ant
>>>>ant -f nightly.xml run
>>>>
>>>>It should run end-to-end without any trouble, though there are
>>>>occasionally intermittant failures during controls testing on Linux.
>>>>
>>>>Eddie
>>>>
>>>>
>>>>
>>>>On 9/9/05, Rich Feit <richfeit@gmail.com> wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>That's great, thanks -- hopefully there'll be agreement on this.  FYI,
>>>>>this passes tests in the tree (will be important to test against the
>>>>>distributions though).
>>>>>
>>>>>Anyone else have comments about this?
>>>>>
>>>>>Rich
>>>>>
>>>>>Eddie O'Neil wrote:
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>>>I'd fix it too.  :)  It makes sense to have the generated
>>>>>>struts-config files end up in WEB-INF/classes because they're really
>>>>>>not meant to be read / write configuration files (like web.xml or
>>>>>>beehive-netui-config.xml).
>>>>>>
>>>>>>Also, better to ship 1.0 without having to change the behavior later.
>>>>>>
>>>>>>Will take a look over the patch...
>>>>>>
>>>>>>Eddie
>>>>>>
>>>>>>
>>>>>>On 9/9/05, Rich Feit <richfeit@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>OK, I've added a patch for this in the bug.  Feel free to give
it a good
>>>>>>>once-over.
>>>>>>>
>>>>>>>I'm running tests now -- looks OK so far.  The only ill effect
of this
>>>>>>>change is one which would only get worse over time (the longer
we wait
>>>>>>>to do it): for *legacy* apps, where the root Struts-config file
path is
>>>>>>>specified in web.xml, we can no longer honor that path when we
generate
>>>>>>>the file.  In these apps, you will get an error logged at Servlet
>>>>>>>startup about Struts not being able to load the file (though everything
>>>>>>>does work fine).
>>>>>>>
>>>>>>>Rich
>>>>>>>
>>>>>>>Rich Feit wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Hi all,
>>>>>>>>
>>>>>>>>I just entered http://issues.apache.org/jira/browse/BEEHIVE-915
: Page
>>>>>>>>Flow annotation processors generate files in an IDE-unfriendly
way.  It
>>>>>>>>turns out that the way we generate files when running under
apt works
>>>>>>>>fine on the command line, but makes it hard for an IDE (implementing
the
>>>>>>>>Mirror interfaces) to know when/where our generated files
are created.
>>>>>>>>
>>>>>>>>This from the bug:
>>>>>>>>
>>>>>>>>"Unfortunately, [apt's] Filer offers only two choices of places
to
>>>>>>>>create files: the source directory and the build directory.
This means
>>>>>>>>that to fix this bug, our generated files need to move out
of WEB-INF,
>>>>>>>>into WEB-INF/classes, i.e., they will not only be generated
into a
>>>>>>>>different place, but they will be read through a different
mechanism in
>>>>>>>>the runtime."
>>>>>>>>
>>>>>>>>So, this is definitely not a trivial change.  I am working
on the fix
>>>>>>>>for this, and I'd like to have the discussion about whether
to get it
>>>>>>>>into v1.0.  If we don't, v1.0 won't be toolable in an IDE.
>>>>>>>>Additionally, it could cause back-compat problems between
this and the
>>>>>>>>next version, if people begin to depend on our current location
for
>>>>>>>>generated files.  On the other hand, it's a risky change in
that we
>>>>>>>>don't have a lot of time to have people hammer on this.  The
one saving
>>>>>>>>grace is that the file location is so fundamental that presumably,
any
>>>>>>>>bug would cause blatantly bad behavior across the framework.
>>>>>>>>
>>>>>>>>Let me know what you think.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Rich
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>         
>>>>>>
>>>>>>            
>>>>>>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>
>  
>

Mime
View raw message