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 <[EMAIL PROTECTED]> wrote:
Bill,
I've been thinking more about your proposal. The one problem I have
is that we don't really want to treat the share stuff as an
independent project. We also agreed that it would be confusing to
have a share.jar.
Of course there are several ways around this, the trick is choosing
the right one. In my OBRTA ("one build rules them all" ) scenario, I
build jars for each of the subprojects. I do have properties for
each
of the subprojects, so maybe we could have a flag to skip jar
generation.
Plus OBRTA can just skip the share project all together. I think the
combination of these approaches might work.
Let me know if you have any other ideas. I'm taking the day off from
open source and heading to the Chesapeake Bay fir a little R&R. I'll
try moving the shared stuff out to its own subproject as you suggest
on Sunday.
sean
On 6/24/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
Bill,
Interesting proposal. I suppose its possible to link an external
*directly* to another external. I hadn't thought of that.
Its possible this back and forth may be converging on a nice
solution.
BTW, LOL at your "one build to rule them all reference"
A couple of thoughts ...
You forgot sandbox. No big deal that can just be part of the
"current" link. I would also suggest "tomahawk-standalone" or
something like that as the shortcut for the tomahawk plus dependency
source (instead of extensions.) Just so we don't muddle the names
extensions and tomahawk.
The beauty of SVN is that its possible to copy and move things
around
easily. I think I will try move things around the way you
suggest and
see how that works. I think that sharing build and entity stuff
is no
big deal but I agree with what you are trying to do as far as the
shared source.
I've been able to come up with several tricks to get ant to
recursively go through the subprojects. We may end up needing two
build files but I hope that the top level one can be lite as
possible
(if necessary.)
As for the requirement of building one subproject before the
other, I
am currently doing something like that now with the impl and
tomahawk
subprojects.
I am currently working on the examples. If I get time later on
tonight I will try moving things around. For now I want to
finish up
this current phase of the build and figure out what challenges
remain
for either approach.
Thanks for the input.
sean
On 6/24/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Sean,
My thoughts;
5 sub-projects, the main spot to live for our stuff
api
src/java
...
share
src/java
...
impl
src/java
...
tomahawk/
src/java
...
examples
src/java
...
3 projects with externals
core/
api/
share/
impl/
current
core/
tomahawk/
examples/
extensions <-- not sure this is needed but it would be useful for
people working just on the tomahawk stuff
core/
tomahawk/
I really like the idea of a common set of targets in each of the
projects. I'm not sure we can make it so that they are all the same
though but here are my initial thoughts, assume the download-
depends
has already happened;
'ant dist' <-- build the product from this project (i.e. api.jar,
share.jar, examples.war etc)
We define a property for each of the sub-projects products
myfaces.api.jar
myfaces.share.jar
myfaces.impl.jar
myfaces.tomahawak.jar
myfaces.examples.jar
Any dependency to the other sub-projects would be meet with these
properties.
so from tomahawk or examples (the sub-projects with the most
dependencies) you'd have to run 'ant dist' in each of the 3 sub-
projects before you could build either. From impl you'd have to
have
run 'ant dist' in both api & share.
In the 3 projects (core, current & extensions) you could run ant
dist
to get a .tar.gz file for distribution.
I don't think this lends its self well to one build file to rule
them
all. but I think that is ok as long as we have 2 build files,
one for
the sub-projects and one for the projects.
Also we should have a default set of properties that is set
assuming
the 'download-dependencies' was called. If someone wants to do
something else they can with the build.local.properties file.
Thoughts?
-bd-
On Jun 24, 2005, at 9:37 AM, Sean Schofield wrote:
Bill,
I see your point. I've been grappling with some of these
issues as I
work on the build for the entire project and each of the
subprojects.
Here is what I am thinking. If you can check out current and
run 'ant
download-dependencies dist-all' you get all of the jars and
javadoc.
Also if you checkout tomahawk *only* and run the same command
you get
the same thing but for tomahawk only. Finally, as a developer you
should be able to work in any one of three setups: current
(everything), core (api + impl), or just tomahawk.
If you are working in tomahawk you should be able to make and
commit
changes to the share code. Impl does need api but its not
really a
stand alone subproject. In fact, I had initially made it part
of the
same subproject core. Compiling them seperately, etc got to be
a pain
though.
I'm thinking of creating a "core" external that would checkout
these
two projects. Like current but minus tomahawk and examples.
Thoughts?
sean
On 6/24/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Sean,
On Jun 24, 2005, at 9:11 AM, Sean Schofield wrote:
No the share code is right. Tomahawk needs it too. This way
you
can
check out the tomahawk subproject by itself and compile it
(without
downloading the impl subproject.)
Well, impl needs api but its not linked in via a share. I was
thinking that if you get all three of the 'subprojects' (api,
impl &
tomahawk) you would have to build api, copy the jar into impl,
build
impl and copy api & impl jar files into tomahawk. That would
avoid
the duplication wouldn't it? Share would have everything
linked in
(once) and you can make the build smart enough to do all that for
you.
I think this manual process when using the sub-projects is
consistent
with the idea of having a current project. The 3 subproj's are
for
people who know and only want to work on the pieces. current
is for
people who want to work on the whole thing or who want to work on
tomahawk without having to thinking about the other sub-
projects etc.
When you check out current, you do get two copies of the
share code
but they are linked. So if you make a change to impl/share/
src and
check in you will see it in tomahawk/share/src after you update.
OK for people who know but IMO this will be a constant point of
confusion for new people trying to get started with developing
MyFaces.
TTFN,
-bd-
sean
On 6/24/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Sean,
So far so good!
I've tried the 'download-dependencies' and it works fine
except for
the 1.2 version of commons-validator.jar which is to be
expected
until that is released.
The myfaces-current looks good except for getting multiple
copies of
the share code, is that expected?
myfaces-current/
api/
src/java
build/
examples/
forest/
impl/
share/src <-- share src, this is where it belongs
correct?
The 'home' of share if I'm reading the svn:externals correctly.
src <-- impl src
sandbox/
tomahawk/
share/src <-- share src, I did not expect this
src <-- tomahawk src
If this is just noise for you now please feel free to let me
know, I
don't want to make it more difficult for you.
Thanks again,
-bd-
On Jun 24, 2005, at 8:00 AM, Sean Schofield wrote:
errr....
https://svn.apache.org/repos/asf/myfaces/current
On 6/24/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
Martin,
I'm still working on the build so I haven't had a chance
to post
instructions yet.
Try https://svn.apache.org/asf/repos/myfaces/current
It takes a little while but that has nothing to do with the
reorg,
just the volume of files. If its hanging on you there
might be a
problem with the SVN server or on your end.
Keep me posted.
sean
On 6/24/05, Martin Marinschek <[EMAIL PROTECTED]>
wrote:
Hi everyone,
how do you guys handle the checkout of the newly laid out
subversion
tree? I am trying to checkout all at once, but both Tortoise
SVN and
the subversion command line client (on my windows box)
stop dead
sometime during the process (it seems to be that there is
just too
much to checkout if all the branches are coming out as
well?).
What to do instead? I don't want to checkout only trunk
in every
subdirectory of MyFaces, that would take to long I think,
and I
couldn't do a single update anymore.
Does anyone have suggestions to solve this problem?
regards,
Martin
