This is how I see it. The apps in geronimo/server/trunk/applications
should be the ones that are absolutely required by the server. Eg:
console, welcome app etc.
The optional apps like servlet-examples, jsp-examples should be moved
elsewhere to a samples directory or project. There is no need to build
these samples every time we build the server. This will greatly reduce
our build time.
Next, I don't know why we make "car" out some of these example apps.
If we need to include a few of them in the assembly, we should just
"deploy" them.
Lastly, there is the Q about where the optional samples end up:
1. geronimo/server/trunk/samples
Pros:
a) samples version closely tied with the server.
Cons:
a) increases the time it takes to download the server tree
unnecessarily. (svn checkout)
b) have to use a separate profile to build them. More pom.xml
maintenance. This is assuming the fact that we don't build "car" for
these. If we have to build "car" too, then the story becomes more
complex.
2. geronimo/samples/trunk
Pros:
a) separate tree built and published separately.
b) the server tree now builds faster.
c) if assemblies need to include it, just add the artifact as a dependency.
Cons:
a) have to keep the version of this project in synch with the
version of the server. (Not really a big deal, similar to what we
could with specs). This means keeping the plans and DD updated with
every server release.
With every server release, we have broken the samples on the wiki
page. The plans and DD have changed and we have not kept that
updated.
Cheers
Prasad
On 1/25/07, Donald Woods <[EMAIL PROTECTED]> wrote:
Any thoughts on what we do with the new Samples being added to
/geronimo/samples/trunk and the /geronimo/plugins/trunk files?
We currently have 5 places for samples and plugins (the above 2
locations plus server/applications, server/configs and
geronimo/daytrader) and I would like to spend some time getting all of
this "optional" code (except for maybe Daytrader) into the same location
in svn before we release 2.0.
-Donald
Paul McMahan wrote:
> Thanks Donald for migrating this discussion onto [EMAIL PROTECTED] I posted
some
> feedback about option #1 in the JIRA you referenced. To sum up, I was
> concerned about moving optional modules to an area called "plugins",
> since IMO that's a misnomer since optional modules aren't always
> plugins and plugins aren't always optional :-) I am also concerned
> about complicating release management for optional modules that are
> sensitive to the Geronimo server version.
>
> I think we can solve the problem described in G2728 without
> reorganizing the source tree, for example by adjusting the server
> dependencies. But if there is also some motivation to further trim
> down what's in server/trunk (to speed up the build, perhaps) then I
> like option #2 better.
>
> Best wishes,
> Paul
>
> On 1/24/07, Donald Woods <[EMAIL PROTECTED]> wrote:
>> As part of the discussion on G2728 relating to the Directory server and
>> LDAP-Demo sample -
>> https://issues.apache.org/jira/browse/GERONIMO-2728
>> I'm wondering how others would like to see us handle optional server
>> components for 2.0, as we currently have some samples and plug-ins in
>> geronimo/server/trunk/, but others are under geronimo/samples/trunk and
>> geronimo/plugins/trunk.
>>
>> Should we:
>> 1) Move them out of geronimo/server/trunk and
>> - move all sample apps (like Magicgball, ldap-demo, ...) to the
>> existing geronimo/samples/trunk and have them automatically built and
>> published by gbuild
>> - move all optional and non-Geronimo plugins (like ApacheDS) to the
>> existing geronimo/plugins/trunk and have then built and published by
>> gbuild
>>
>> 2) Keep all the samples and plug-ins in the server tree, but under a new
>> directory like server/trunk/samples or server/trunk/opt and use a maven
>> profile so they are not always built, but always build and publish them
>> from gbuild
>>
>> I could also see us moving the minimal assemblies to the same location
>> as #2, for those people interested in them....
>>
>> Thoughts?
>>
>>
>> -Donald
>>
>>
>>
>
>
