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