Thanks Sean and greetings from the JavaOne,
Manfred
2005/6/28, Sean Schofield <[EMAIL PROTECTED]>:
> Bill,
>
> Making progress on the reorg. Share is its own subproject now. It
> doesn't have a build directory of its own though since that doesn't
> make sense. I removed RSS Ticker and ISBN Validator for now so there
> are no more compile issues with the jars you get with
> download-dependencies.
>
> Also I create svn:externals for "core" and "tomahawk-only." The build
> file is working ok but the resulting WARs do not yet work perfectly.
> You can run dist-all from current/build and build everything (javadoc,
> jars and wars.) You can run dist from each of the subprojects and
> that works too (as long as you build in the correct order.)
>
> sean
>
> On 6/25/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > 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 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > > > >>>>>> 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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>
