[OT] Let's have a beer.

[James Mitchell]

Sean (or anyone who wants to get together), I'll be up there next month 
(14th thru 23rd) if you want to get together for a beer.  I'll be staying at 
my in-laws place about 200 feet from the Breezy point marina (between 
Annapolis and Chesapeake beach).  I'd love to hook up and chat for a while.


If anyone would like to join us, please let me know via instant message. 
I'm on almost all the time.


Thanks and sorry for the OT cross-post! 



--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: jmitchtx

- Original Message - 
From: "Sean Schofield" <[EMAIL PROTECTED]>

To: "MyFaces Development" 
Sent: Saturday, June 25, 2005 11:00 AM
Subject: Re: New Subversion


Bill,

I've been thinking more about your proposal.  The one problem I have
is that we don't really want to treat the share stuff as an
independent project.  We also agreed that it would be confusing to
have a share.jar.

Of course there are several ways around this, the trick is choosing
the right one.  In my OBRTA ("one build rules them all" ) scenario, I
build jars for each of the subprojects.  I do have properties for each
of the subprojects, so maybe we could have a flag to skip jar
generation.

Plus OBRTA can just skip the share project all together.  I think the
combination of these approaches might work.

Let me know if you have any other ideas.  I'm taking the day off from
open source and heading to the Chesapeake Bay fir a little R&R.  I'll
try moving the shared stuff out to its own subproject as you suggest
on Sunday.

sean

On 6/24/05, Sean Schofield <[EMAIL PROTECTED]> wrote:

Bill,

Interesting proposal.  I suppose its possible to link an external
*directly* to another external.  I hadn't thought of that.

Its possible this back and forth may be converging on a nice solution.
 BTW, LOL at your "one build to rule them all reference"

A couple of thoughts ...

You forgot sandbox.  No big deal that can just be part of the
"current" link.  I would also suggest "tomahawk-standalone" or
something like that as the shortcut for the tomahawk plus dependency
source (instead of extensions.)  Just so we don't muddle the names
extensions and tomahawk.

The beauty of SVN is that its possible to copy and move things around
easily.  I think I will try move things around the way you suggest and
see how that works.  I think that sharing build and entity stuff is no
big deal but I agree with what you are trying to do as far as the
shared source.

I've been able to come up with several tricks to get ant to
recursively go through the subprojects.  We may end up needing two
build files but I hope that the top level one can be lite as possible
(if necessary.)

As for the requirement of building one subproject before the other, I
am currently doing something like that now with the impl and tomahawk
subprojects.

I am currently working on the examples.  If I get time later on
tonight I will try moving things around.  For now I want to finish up
this current phase of the build and figure out what challenges remain
for either approach.

Thanks for the input.

sean

On 6/24/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> Sean,
>
> My thoughts;
>
> 5 sub-projects, the main spot to live for our stuff
>
> api
>  src/java
>  ...
>
> share
>  src/java
>  ...
>
> impl
>  src/java
>  ...
>
> tomahawk/
>  src/java
>  ...
>
> examples
>  src/java
>  ...
>
> 3 projects with externals
> core/
>  api/
>  share/
>  impl/
>
> current
>  core/
>  tomahawk/
>  examples/
>
> extensions <-- not sure this is needed but it would be useful for
> people working just on the tomahawk stuff
>  core/
>  tomahawk/
>
>
> I really like the idea of a common set of targets in each of the
> projects. I'm not sure we can make it so that they are all the same
> though but here are my initial thoughts, assume the download-depends
> has already happened;
>
> 'ant dist' <-- build the product from this project (i.e. api.jar,
> share.jar, examples.war etc)
>
> We define a property for each of the sub-projects products
> myfaces.api.jar
> myfaces.share.jar
> myfaces.impl.jar
> myfaces.tomahawak.jar
> myfaces.examples.jar
>
> Any dependency to the other sub-projects would be meet with these
> properties.
>
> so from tomahawk or examples (the sub-projects with the most
> dependencies) you'd have to run 'ant dist' in each of the 3 sub-
> projects before you could build either. From impl you'd have to have
> run 'ant dist' in both api & share.
>
> In the 3 projects (core, current & extensions) you could run ant dist
> to get a .tar.gz file for distribution.
>
> I don't think this lends its self well to one build file to rule them
> all. but I think that is ok as long as we have 2 build files, one for
> the sub-projects and one for the projects.
>
> Also we should have a default 

DO NOT REPLY [Bug 35506] New: - Struts-Faces Library - core-library and example1-webapp patches

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35506

   Summary: Struts-Faces Library - core-library and example1-webapp
patches
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Struts-Faces Library
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


A couple one line patches to work with tomcat 5.5

1)Changed the assumed action "tour/" in the struts-config of the example1 
application to use an "include" on the the static document "tour.htm".  The 
forward wants the target to be a jsp resource.

2)Change the signature of the call to get the ModuleConfig to use the 
ServletContext, another overload.  This is in the JavasrciptValidatorTag.  
This was raising a null pointer exception when not dispatched thru the request 
processor first.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35506] - Struts-Faces Library - core-library and example1-webapp patches

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35506





--- Additional Comments From [EMAIL PROTECTED]  2005-06-25 20:45 ---
Created an attachment (id=15534)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15534&action=view)
patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]