You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2005/06/24 15:56:14 UTC
New Subversion
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
Re: New Subversion
Posted by Manfred Geiler <ma...@gmail.com>.
Thanks Sean and greetings from the JavaOne,
Manfred
2005/6/28, Sean Schofield <se...@gmail.com>:
> 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 <se...@gmail.com> 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 <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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>
Re: New Subversion
Posted by Bill Dudney <bd...@mac.com>.
Fantastic work Sean,
Thanks again! Wish you were out here so I could buy dinner or
something :-)
TTFN,
-bd-
On Jun 28, 2005, at 9:19 AM, Sean Schofield wrote:
> 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 <se...@gmail.com> 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 <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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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 <se...@gmail.com> 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 <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
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
[OT] Let's have a beer.
Posted by 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[OT] Let's have a beer.
Posted by 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
Re: New Subversion
Posted by Bill Dudney <bd...@mac.com>.
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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
Re: New Subversion
Posted by Bill Dudney <bd...@mac.com>.
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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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.)
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.
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
> >>>
> >>>
> >>
> >
>
>
Re: New Subversion (explained)
Posted by James Mitchell <jm...@apache.org>.
We also need to keep one more *critical* thing in mind.
Unless things have changed in the last 6 months, when you branch/tag, the svn:externals 'pointers' (for lack of a better term) still point to https://my/repos/foo/trunk, so it is entirely possible that you make a change to a branch, but it will actually commit to the main line (HEAD).
This means when a branch or tag happens, you must go there and fix the svn:externals properties to point to https://my/repos/foo/branches/MY_BRANCH.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: John Fallows
To: MyFaces Development
Sent: Friday, June 24, 2005 6:40 PM
Subject: Re: New Subversion (explained)
Be careful when committing changes across svn:external links.
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3
<quote>
The support that exists for externals definitions in Subversion today can be a little misleading, though.
First, an externals definition can only point to directories, not files.
Second, the externals definition cannot point to relative paths (paths like ../../skins/myskin).
Third, the working copies created via the externals definition support are still disconnected from the primary working copy (on whose versioned directories the svn:externals property was actually set).
And Subversion still only truly operates on non-disjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones.
</quote>
Kind Regards,
John Fallows.
On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> That's correct.
>
> Think of svn:externals as like a symbolic link, but the link is not a *file*
> itself but a property of a directory. So, you won't see it, but svn will.
>
>
> So (using the current myfaces repository) if you are in myfaces/current/ (or
> whatever you called it) and you do 'svn proplist .' <==== notice the
> period, that was intentional, but it is not required
>
> [Everything after the $ is my interaction on the command line]
>
> jmitchell@compaq ~/svn/myfaces
> $ svn proplist .
> Properties on '.':
> svn:ignore
> svn:externals
>
>
> Ok, so that tells me there are:
> - svn properties for ignoring file types (like .cvsignore)
> - svn properties that describe external locations that svn will pull during
> a checkout or update
>
>
> Now I want to see what I pulled by checking out 'current'.
>
> jmitchell@compaq ~/svn/myfaces
> $ svn propget svn:externals . <==== (there's that period again)
> build https://svn.apache.org/repos/asf/myfaces/build/trunk
> api https://svn.apache.org/repos/asf/myfaces/api/trunk
> impl https://svn.apache.org/repos/asf/myfaces/impl/trunk
> examples https://svn.apache.org/repos/asf/myfaces/examples/trunk
> sandbox https://svn.apache.org/repos/asf/myfaces/sandbox/trunk
> tomahawk https://svn.apache.org/repos/asf/myfaces/tomahawk/trunk
> forrest https://svn.apache.org/repos/asf/myfaces/forrest/trunk
>
>
> That explains where everything is coming from now, but what is this "share"
> business?
>
> jmitchell@compaq ~/svn/myfaces
> $ cd tomahawk/
>
> (let's look at what's in tomahawk)
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ ls -l
> total 5
> drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:17 build
> -rw-r--r-- 1 jmitchell None 983 Jun 24 11:17 build.properties
> drwxr-xr-x+ 3 jmitchell None 0 Jun 24 11:17 conf
> -rw-r--r-- 1 jmitchell None 217 Jun 24 11:17 manifest.properties
> drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:18 share
> drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:17 src
> drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:18 tld
>
> (Ok, I see "share", but it looks normal to me)
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn proplist .
> Properties on '.':
> svn:externals
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn propget svn:externals .
> build https://svn.apache.org/repos/asf/myfaces/build/trunk
> share https://svn.apache.org/repos/asf/myfaces/impl/trunk/share
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn status
> X build
> X share
> X tld/entities
> X tld/misc
>
> Performing status on external item at 'build'
>
> Performing status on external item at 'share'
>
> Performing status on external item at 'tld/entities'
>
> Performing status on external item at 'tld/misc'
>
>
>
> By now you should see the pattern here.
>
> The only difficult part of this is keeping up with what is real and what is
> pulled in via svn:externals. Trust me, if you change something in
> current/tomahawk/tld/misc, but it will be reflected across all the locations
> that include it.
>
>
> FYI - you could probably deal with the issue of missing RSS files in a
> similar manner (use svn:externals to pull in the missing sources right from
> commons).
>
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
> ----- Original Message -----
> From: "Bill Dudney" < bdudney@mac.com>
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Sent: Friday, June 24, 2005 11:05 AM
> Subject: Re: New Subversion
>
>
> > 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 <sean.schofield@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
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
>
>
Re: New Subversion (explained)
Posted by John Fallows <jo...@gmail.com>.
Be careful when committing changes across svn:external links.
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3
<quote>
The support that exists for externals definitions in Subversion today can be
a little misleading, though.
First, an externals definition can only point to directories, not files.
Second, the externals definition cannot point to relative paths (paths like
../../skins/myskin).
Third, the working copies created via the externals definition support are
still disconnected from the primary working copy (on whose versioned
directories the svn:externals property was actually set).
And Subversion still only truly operates on non-disjoint working copies. So,
for example, if you want to commit changes that you've made in one or more
of those external working copies, you must run svn commit explicitly on
those working copies—committing on the primary working copy will not recurse
into any external ones.
</quote>
Kind Regards,
John Fallows.
On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> That's correct.
>
> Think of svn:externals as like a symbolic link, but the link is not a
*file*
> itself but a property of a directory. So, you won't see it, but svn will.
>
>
> So (using the current myfaces repository) if you are in myfaces/current/
(or
> whatever you called it) and you do 'svn proplist .' <==== notice the
> period, that was intentional, but it is not required
>
> [Everything after the $ is my interaction on the command line]
>
> jmitchell@compaq ~/svn/myfaces
> $ svn proplist .
> Properties on '.':
> svn:ignore
> svn:externals
>
>
> Ok, so that tells me there are:
> - svn properties for ignoring file types (like .cvsignore)
> - svn properties that describe external locations that svn will pull
during
> a checkout or update
>
>
> Now I want to see what I pulled by checking out 'current'.
>
> jmitchell@compaq ~/svn/myfaces
> $ svn propget svn:externals . <==== (there's that period again)
> build https://svn.apache.org/repos/asf/myfaces/build/trunk
> api https://svn.apache.org/repos/asf/myfaces/api/trunk
> impl https://svn.apache.org/repos/asf/myfaces/impl/trunk
> examples https://svn.apache.org/repos/asf/myfaces/examples/trunk
> sandbox https://svn.apache.org/repos/asf/myfaces/sandbox/trunk
> tomahawk https://svn.apache.org/repos/asf/myfaces/tomahawk/trunk
> forrest https://svn.apache.org/repos/asf/myfaces/forrest/trunk
>
>
> That explains where everything is coming from now, but what is this
"share"
> business?
>
> jmitchell@compaq ~/svn/myfaces
> $ cd tomahawk/
>
> (let's look at what's in tomahawk)
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ ls -l
> total 5
> drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:17 build
> -rw-r--r-- 1 jmitchell None 983 Jun 24 11:17 build.properties
> drwxr-xr-x+ 3 jmitchell None 0 Jun 24 11:17 conf
> -rw-r--r-- 1 jmitchell None 217 Jun 24 11:17 manifest.properties
> drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:18 share
> drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:17 src
> drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:18 tld
>
> (Ok, I see "share", but it looks normal to me)
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn proplist .
> Properties on '.':
> svn:externals
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn propget svn:externals .
> build https://svn.apache.org/repos/asf/myfaces/build/trunk
> share https://svn.apache.org/repos/asf/myfaces/impl/trunk/share
>
> jmitchell@compaq ~/svn/myfaces/tomahawk
> $ svn status
> X build
> X share
> X tld/entities
> X tld/misc
>
> Performing status on external item at 'build'
>
> Performing status on external item at 'share'
>
> Performing status on external item at 'tld/entities'
>
> Performing status on external item at 'tld/misc'
>
>
>
> By now you should see the pattern here.
>
> The only difficult part of this is keeping up with what is real and what
is
> pulled in via svn:externals. Trust me, if you change something in
> current/tomahawk/tld/misc, but it will be reflected across all the
locations
> that include it.
>
>
> FYI - you could probably deal with the issue of missing RSS files in a
> similar manner (use svn:externals to pull in the missing sources right
from
> commons).
>
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
> ----- Original Message -----
> From: "Bill Dudney" <bd...@mac.com>
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Sent: Friday, June 24, 2005 11:05 AM
> Subject: Re: New Subversion
>
>
> > 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
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
>
>
Re: New Subversion (explained)
Posted by James Mitchell <jm...@apache.org>.
That's correct.
Think of svn:externals as like a symbolic link, but the link is not a *file*
itself but a property of a directory. So, you won't see it, but svn will.
So (using the current myfaces repository) if you are in myfaces/current/ (or
whatever you called it) and you do 'svn proplist .' <==== notice the
period, that was intentional, but it is not required
[Everything after the $ is my interaction on the command line]
jmitchell@compaq ~/svn/myfaces
$ svn proplist .
Properties on '.':
svn:ignore
svn:externals
Ok, so that tells me there are:
- svn properties for ignoring file types (like .cvsignore)
- svn properties that describe external locations that svn will pull during
a checkout or update
Now I want to see what I pulled by checking out 'current'.
jmitchell@compaq ~/svn/myfaces
$ svn propget svn:externals . <==== (there's that period again)
build https://svn.apache.org/repos/asf/myfaces/build/trunk
api https://svn.apache.org/repos/asf/myfaces/api/trunk
impl https://svn.apache.org/repos/asf/myfaces/impl/trunk
examples https://svn.apache.org/repos/asf/myfaces/examples/trunk
sandbox https://svn.apache.org/repos/asf/myfaces/sandbox/trunk
tomahawk https://svn.apache.org/repos/asf/myfaces/tomahawk/trunk
forrest https://svn.apache.org/repos/asf/myfaces/forrest/trunk
That explains where everything is coming from now, but what is this "share"
business?
jmitchell@compaq ~/svn/myfaces
$ cd tomahawk/
(let's look at what's in tomahawk)
jmitchell@compaq ~/svn/myfaces/tomahawk
$ ls -l
total 5
drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:17 build
-rw-r--r-- 1 jmitchell None 983 Jun 24 11:17 build.properties
drwxr-xr-x+ 3 jmitchell None 0 Jun 24 11:17 conf
-rw-r--r-- 1 jmitchell None 217 Jun 24 11:17 manifest.properties
drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:18 share
drwxr-xr-x+ 4 jmitchell None 0 Jun 24 11:17 src
drwxr-xr-x+ 5 jmitchell None 0 Jun 24 11:18 tld
(Ok, I see "share", but it looks normal to me)
jmitchell@compaq ~/svn/myfaces/tomahawk
$ svn proplist .
Properties on '.':
svn:externals
jmitchell@compaq ~/svn/myfaces/tomahawk
$ svn propget svn:externals .
build https://svn.apache.org/repos/asf/myfaces/build/trunk
share https://svn.apache.org/repos/asf/myfaces/impl/trunk/share
jmitchell@compaq ~/svn/myfaces/tomahawk
$ svn status
X build
X share
X tld/entities
X tld/misc
Performing status on external item at 'build'
Performing status on external item at 'share'
Performing status on external item at 'tld/entities'
Performing status on external item at 'tld/misc'
By now you should see the pattern here.
The only difficult part of this is keeping up with what is real and what is
pulled in via svn:externals. Trust me, if you change something in
current/tomahawk/tld/misc, but it will be reflected across all the locations
that include it.
FYI - you could probably deal with the issue of missing RSS files in a
similar manner (use svn:externals to pull in the missing sources right from
commons).
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "Bill Dudney" <bd...@mac.com>
To: "MyFaces Development" <de...@myfaces.apache.org>
Sent: Friday, June 24, 2005 11:05 AM
Subject: Re: New Subversion
> 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
>>>>
>>>>
>>>
>>
>
>
Re: New Subversion
Posted by Bill Dudney <bd...@mac.com>.
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
>>>
>>>
>>
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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
> >
>
Re: New Subversion
Posted by Sean Schofield <se...@gmail.com>.
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
>