[OT] Let's have a beer.

[James Mitchell <jm...@apache.org>]

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! <ducking4cover/>



--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
MSN:   jmitchell@apache.org
Skype: jmitchtx

----- Original Message ----- 
From: "Sean Schofield" <se...@gmail.com>
To: "MyFaces Development" <de...@myfaces.apache.org>
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 <se...@gmail.com> 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 <bd...@mac.com> 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 set of properties that is set assuming
> > the 'download-dependencies' was called. If someone wants to do
> > something else they can  with the build.local.properties file.
> >
> > Thoughts?
> >
> > -bd-
> >
> > On Jun 24, 2005, at 9:37 AM, Sean Schofield wrote:
> >
> > > Bill,
> > >
> > > I see your point.  I've been grappling with some of these issues as I
> > > work on the build for the entire project and each of the subprojects.
> > >
> > > Here is what I am thinking.  If you can check out current and run 'ant
> > > download-dependencies dist-all' you get all of the jars and javadoc.
> > > Also if you checkout tomahawk *only* and run the same command you get
> > > the same thing but for tomahawk only.  Finally, as a developer you
> > > should be able to work in any one of three setups: current
> > > (everything), core (api + impl), or just tomahawk.
> > >
> > > If you are working in tomahawk you should be able to make and commit
> > > changes to the share code.  Impl does need api but its not really a
> > > stand alone subproject.  In fact, I had initially made it part of the
> > > same subproject core.  Compiling them seperately, etc got to be a pain
> > > though.
> > >
> > > I'm thinking of creating a "core" external that would checkout these
> > > two projects.  Like current but minus tomahawk and examples.
> > >
> > > Thoughts?
> > >
> > > sean
> > >
> > > On 6/24/05, Bill Dudney <bd...@mac.com> wrote:
> > >
> > >> Hi Sean,
> > >>
> > >> On Jun 24, 2005, at 9:11 AM, Sean Schofield wrote:
> > >>
> > >>
> > >>> No the share code is right.  Tomahawk needs it too.  This way you
> > >>> can
> > >>> check out the tomahawk subproject by itself and compile it (without
> > >>> downloading the impl subproject.)
> > >>>
> > >>>
> > >>
> > >> Well, impl needs api but its not linked in via a share. I was
> > >> thinking that if you get all three of the 'subprojects' (api, impl &
> > >> tomahawk) you would have to build api, copy the jar into impl, build
> > >> impl and copy api & impl jar files into tomahawk. That would avoid
> > >> the duplication wouldn't it? Share would have everything linked in
> > >> (once) and you can make the build smart enough to do all that for
> > >> you.
> > >>
> > >> I think this manual process when using the sub-projects is consistent
> > >> with the idea of having a current project. The 3 subproj's are for
> > >> people who know and only want to work on the pieces. current is for
> > >> people who want to work on the whole thing or who want to work on
> > >> tomahawk without having to thinking about the other sub-projects etc.
> > >>
> > >>
> > >>> When you check out current, you do get two copies of the share code
> > >>> but they are linked.  So if you make a change to impl/share/src and
> > >>> check in you will see it in tomahawk/share/src after you update.
> > >>>
> > >>>
> > >>
> > >> OK for people who know but IMO this will be a constant point of
> > >> confusion for new people trying to get started with developing
> > >> MyFaces.
> > >>
> > >> TTFN,
> > >>
> > >> -bd-
> > >>
> > >>
> > >>> sean
> > >>>
> > >>> On 6/24/05, Bill Dudney <bd...@mac.com> wrote:
> > >>>
> > >>>
> > >>>> Hi Sean,
> > >>>>
> > >>>> So far so good!
> > >>>>
> > >>>> I've tried the 'download-dependencies' and it works fine except for
> > >>>> the 1.2 version of commons-validator.jar which is to be expected
> > >>>> until that is released.
> > >>>>
> > >>>> The myfaces-current looks good except for getting multiple
> > >>>> copies of
> > >>>> the share code, is that expected?
> > >>>>
> > >>>> myfaces-current/
> > >>>>      api/
> > >>>>          src/java
> > >>>>      build/
> > >>>>      examples/
> > >>>>      forest/
> > >>>>      impl/
> > >>>>          share/src  <-- share src, this is where it belongs
> > >>>> correct?
> > >>>> The 'home' of share if I'm reading the svn:externals correctly.
> > >>>>          src <-- impl src
> > >>>>      sandbox/
> > >>>>      tomahawk/
> > >>>>          share/src <-- share src, I did not expect this
> > >>>>          src <-- tomahawk src
> > >>>>
> > >>>> If this is just noise for you now please feel free to let me
> > >>>> know, I
> > >>>> don't want to make it more difficult for you.
> > >>>>
> > >>>> Thanks again,
> > >>>>
> > >>>> -bd-
> > >>>>
> > >>>>
> > >>>> On Jun 24, 2005, at 8:00 AM, Sean Schofield wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>> errr....
> > >>>>>
> > >>>>> https://svn.apache.org/repos/asf/myfaces/current
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 6/24/05, Sean Schofield <se...@gmail.com> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Martin,
> > >>>>>>
> > >>>>>> I'm still working on the build so I haven't had a chance to post
> > >>>>>> instructions yet.
> > >>>>>>
> > >>>>>> Try https://svn.apache.org/asf/repos/myfaces/current
> > >>>>>>
> > >>>>>> It takes a little while but that has nothing to do with the
> > >>>>>> reorg,
> > >>>>>> just the volume of files.  If its hanging on you there might be a
> > >>>>>> problem with the SVN server or on your end.
> > >>>>>>
> > >>>>>> Keep me posted.
> > >>>>>>
> > >>>>>> sean
> > >>>>>>
> > >>>>>> On 6/24/05, Martin Marinschek <ma...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> Hi everyone,
> > >>>>>>>
> > >>>>>>> how do you guys handle the checkout of the newly laid out
> > >>>>>>> subversion
> > >>>>>>> tree? I am trying to checkout all at once, but both Tortoise
> > >>>>>>> SVN and
> > >>>>>>> the subversion command line client (on my windows box) stop dead
> > >>>>>>> sometime during the process (it seems to be that there is
> > >>>>>>> just too
> > >>>>>>> much to checkout if all the branches are coming out as well?).
> > >>>>>>>
> > >>>>>>> What to do instead? I don't want to checkout only trunk in every
> > >>>>>>> subdirectory of MyFaces, that would take to long I think, and I
> > >>>>>>> couldn't do a single update anymore.
> > >>>>>>>
> > >>>>>>> Does anyone have suggestions to solve this problem?
> > >>>>>>>
> > >>>>>>> regards,
> > >>>>>>>
> > >>>>>>> Martin
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
>