You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2008/05/21 16:57:49 UTC
Samples release process
I've been stuck attempting to use the maven-release-plugin for samples
for a few reasons. I would like go ahead and create a branch for this
release which will later be converted to a tag (the old fashioned way).
Are there any strong objects? (Note: I'm asking because of this sentence
in our release process doc - "...most smaller projects such as specs,
plugins, components, and most likely tools should avoid the complexity
of branches unless clearly necessary and agreed upon." )
Here are the problems that I'm having using the release-plugin/process:
1) There is a version property defined in the root pom to match the
release version. The maven-release-plugin will not change this version
property (just the version element in the root pom) during mvn
release:prepare
I attempted to remove the version property but it appears this is used
to generate the directory to scan by the jasper builder as I get the
following error when I attempt to remove it.
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Could not scan directory for TLD files:
jar:file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/target/repository/org/apache/geronimo/samples/CustomerService-jetty/${version}/CustomerService-jetty-${version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar!/META-INF
Illegal character in path at index 153:
file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/target/repository/org/apache/geronimo/samples/CustomerService-jetty/${version}/CustomerService-jetty-${version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar
Attempting to change this version property manually prior to release
didn't work either. Apparently, the maven-release does a build prior to
the svn changes (which fails with a manual change) and after the svn
changes (which fails without the manual change).
BTW, we have this same version property defined in the server root pom.
2) When using the maven-release-plugin I have to specify the release
and the new snapshot version. The release default is fine because we
are currently using 2.1-SNAPSHOT and so the release will be 2.1.
However, I must manually specify the development release to
2.1.1-SNAPSHOT or it will default to 2.2-SNAPSHOT. This isn't a big
problem but it is annoying (especially since I have to enter that value
78 times ... once for each artifact). Newer versions of the
maven-release-plugin have parms to override these versions on the
command line but the version included in genesis 1.4 does not.
3) This isn't necessary a problem but it doesn't seem right to me. When
The scm entries are updated for a tag with the name:
- http://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1
I understand why this based upon the release-plugin structure. However
the name doesn't seem intuitive to me. I think a structure that matches
our server structure makes much more sense. So I would prefer:
- http://svn.apache.org/repos/asf/geronimo/samples/tags/2.1.0 (with or
without the .0)
I think this makes much more sense and more clearly matches the samples
to the server (and we indicated on earlier threads that we wanted to
keep these in sync).
4) I'm becoming more and more of the opinion that we should merge the
samples svn back into the server svn. I see little advantage in keeping
these independent and a lot of problems in doing so. If I can convince
folks that is the right thing to do then it doesn't make much sense to
get the samples releasing with the maven-release-plugin while the server
is still released manually.
Some reasons I think the samples should be merged back into the server svn.
- The samples are tied to a particular server release.
- It's important to have samples available ASAP with a server release.
Tying these together would ensure that they are available in conjunction
with the server release (you can't do any better than that).
- The samples are versioned to match the server and this would make it a
no-brainer to keep them in sync.
- Samples could take advantage of the dependency management in server
root pom to ensure that everything is in sync with the server. As it
stands now dependency versions for samples are spread across numerous
poms and managed independently from the server.
- We have had 0 success to date releasing samples independently of the
server.
Regarding #4 ... I would get 2.1 samples and 2.1.1 samples released
independently and then suggest we merge the samples under the server svn
in branches/2.1 and trunk. We don't need to decide #4 right away since
we still have to get 2.1 & possibly 2.1.1 out the door. The only
advantage I can think of in keeping them independent is the ability to
build samples without building the server but as I mentioned in another
post I don't believe this is possible anyway at the moment.
Joe
Re: Samples release process
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
>
> On May 21, 2008, at 11:19 AM, David Jencks wrote:
>
>>
>> On May 21, 2008, at 10:57 AM, Joe Bohn wrote:
>>
>>> I've been stuck attempting to use the maven-release-plugin for
>>> samples for a few reasons. I would like go ahead and create a branch
>>> for this release which will later be converted to a tag (the old
>>> fashioned way). Are there any strong objects? (Note: I'm asking
>>> because of this sentence in our release process doc - "...most
>>> smaller projects such as specs, plugins, components, and most likely
>>> tools should avoid the complexity of branches unless clearly
>>> necessary and agreed upon." )
>>>
>>>
>>> Here are the problems that I'm having using the release-plugin/process:
>>>
>>> 1) There is a version property defined in the root pom to match the
>>> release version. The maven-release-plugin will not change this
>>> version property (just the version element in the root pom) during
>>> mvn release:prepare
>>>
>>> I attempted to remove the version property but it appears this is
>>> used to generate the directory to scan by the jasper builder as I get
>>> the following error when I attempt to remove it.
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Could not scan directory for TLD files:
>>> jar:file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/target/repository/org/apache/geronimo/samples/CustomerService-jetty/${version}/CustomerService-jetty-${version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar!/META-INF
>>> Illegal character in path at index 153:
>>> file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/target/repository/org/apache/geronimo/samples/CustomerService-jetty/${version}/CustomerService-jetty-${version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar
>>>
>>>
>>> Attempting to change this version property manually prior to release
>>> didn't work either. Apparently, the maven-release does a build prior
>>> to the svn changes (which fails with a manual change) and after the
>>> svn changes (which fails without the manual change).
>>>
>>> BTW, we have this same version property defined in the server root pom.
>>
>> This is a problem we'll have to solve to release the server with the
>> release plugin. I thought I'd dealt with it successfully in the
>> apacheds plugin release but maybe not....
>
> yup, this was due to someone trying hard to mess up the c-m-p by
> including part of the environment element that it generates correctly.
> After I removed them (in trunk) the ${version} property is not needed.
Excellent. I'll merge this back into 2.1 in case we decide to release
form the branch.
>>
>>>
>>>
>>> 2) When using the maven-release-plugin I have to specify the release
>>> and the new snapshot version. The release default is fine because we
>>> are currently using 2.1-SNAPSHOT and so the release will be 2.1.
>>> However, I must manually specify the development release to
>>> 2.1.1-SNAPSHOT or it will default to 2.2-SNAPSHOT. This isn't a big
>>> problem but it is annoying (especially since I have to enter that
>>> value 78 times ... once for each artifact). Newer versions of the
>>> maven-release-plugin have parms to override these versions on the
>>> command line but the version included in genesis 1.4 does not.
>>
>> I think there's a configuration setting so you only have to specify it
>> once. You can set this on the command line although I think its
>> better to include in the samples root pom (or the next version of
>> genesis).
>> -DautoVersionSubmodules=true
>>>
>>>
>>> 3) This isn't necessary a problem but it doesn't seem right to me.
>>> When The scm entries are updated for a tag with the name:
>>> -
>>> http://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1
>>> I understand why this based upon the release-plugin structure.
>>> However the name doesn't seem intuitive to me. I think a structure
>>> that matches our server structure makes much more sense. So I would
>>> prefer:
>>> - http://svn.apache.org/repos/asf/geronimo/samples/tags/2.1.0 (with
>>> or without the .0)
>>> I think this makes much more sense and more clearly matches the
>>> samples to the server (and we indicated on earlier threads that we
>>> wanted to keep these in sync).
>>
>> While it isn't what we've been doing by hand I am 100% in favor of
>> following maven default behavior unless it breaks stuff. We don't
>> need to look different from everyone else.
>>
>>>
>>>
>>> 4) I'm becoming more and more of the opinion that we should merge the
>>> samples svn back into the server svn. I see little advantage in
>>> keeping these independent and a lot of problems in doing so. If I
>>> can convince folks that is the right thing to do then it doesn't make
>>> much sense to get the samples releasing with the maven-release-plugin
>>> while the server is still released manually.
>>>
>>> Some reasons I think the samples should be merged back into the
>>> server svn.
>>> - The samples are tied to a particular server release.
>>> - It's important to have samples available ASAP with a server
>>> release. Tying these together would ensure that they are available in
>>> conjunction with the server release (you can't do any better than that).
>>> - The samples are versioned to match the server and this would make
>>> it a no-brainer to keep them in sync.
>>> - Samples could take advantage of the dependency management in server
>>> root pom to ensure that everything is in sync with the server. As it
>>> stands now dependency versions for samples are spread across numerous
>>> poms and managed independently from the server.
>>> - We have had 0 success to date releasing samples independently of
>>> the server.
>>
>> I don't buy this. IMO we should be working hard so that samples don't
>> need to be updated and released for every server release. I think we
>> also agreed that our long term direction should be that the server
>> plugins are generally built and released independently of a server.
>> Adding more stuff to the giant monolithic server build is against this
>> goal.
>>
>> One thing that might help here is to specify includeVersion false in
>> the car-maven-plugin configuration. We'd have to see if the plugins
>> still worked :-)
>>
>>
>> I'll take a look and see if I can figure out what is going on with the
>> ${version} property.
>
> I fixed this in trunk.
>
> I'm not ok with releasing with the datasources set up the way they are,
> with the generic tranql connector. I would really prefer we provide say
> a derby and postgres database plugin for samples and depend on the derby
> one in all the samples and have the postgres (e.g.) one replace it.
> This would be a nice demonstration of recommended best practices and if
> someone doesn't want to use a sample app plugin directly they can always
> install the db plugin they want.
>
> If there are no objections and no volunteers I'll set this up. If
> there's a volunteer I can answer any questions. The roller plugin is
> set up to do this.
I'd be glad to look into this and take you up on your offer to answer
questions. My only concern is the further delay in getting some samples
released. I wonder if it might be best to pursue this in trunk and get
the 2.1 samples out the door.
>
> If people don't like this we could use a derby specific tranql adapter.
>
> My comment about "no branches" in the release guidelines would in this
> case result in removing samples/branches/2.1, changing the version in
> trunk back to 2.1-SNAPSHOT and releasing directly from trunk. I think
> this is a really good idea.
Perhaps we need to see if includeVersion=false works first. Otherwise,
we might get in a position where we need samples for a 2.1.x release and
a 2.2 release which might be impossible without the branch. I guess the
other question is "Will we always be able to release samples from trunk
for any server release or might there come a time when there are some
2.1 specific samples and 2.2 specific sames as functions change?"
>
> Before this stuff gets released I would like to know what happens if we
> set includeVersions=false... do the samples still work? If they do I
> think the samples are likely to keep working on 2.1.1, 2.1.2 etc etc.
> This might even be a reasonable compatibility test for 2.1.x, x>=1.
I'll give this a try.
>
> Are there any automated tests to see what happens when you deploy the
> sample plugins? If not, would it be worth setting up something sort of
> like testsuite that starts up say the framework server and installs the
> plugin? (framework so jetty or tomcat can be pulled in as appropriate).
AFAIK there are no automated tests yet for samples. That's an
interesting idea - sort of a testsuite for samples. I could see where
this might have some user value to if they want to install all of the
samples and play around some.
>
> thanks
> david jencks
>
>>
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>> Regarding #4 ... I would get 2.1 samples and 2.1.1 samples released
>>> independently and then suggest we merge the samples under the server
>>> svn in branches/2.1 and trunk. We don't need to decide #4 right away
>>> since we still have to get 2.1 & possibly 2.1.1 out the door. The
>>> only advantage I can think of in keeping them independent is the
>>> ability to build samples without building the server but as I
>>> mentioned in another post I don't believe this is possible anyway at
>>> the moment.
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>
>
>
Re: Samples release process
Posted by David Jencks <da...@yahoo.com>.
On May 21, 2008, at 11:19 AM, David Jencks wrote:
>
> On May 21, 2008, at 10:57 AM, Joe Bohn wrote:
>
>> I've been stuck attempting to use the maven-release-plugin for
>> samples for a few reasons. I would like go ahead and create a
>> branch for this release which will later be converted to a tag (the
>> old fashioned way). Are there any strong objects? (Note: I'm asking
>> because of this sentence in our release process doc - "...most
>> smaller projects such as specs, plugins, components, and most
>> likely tools should avoid the complexity of branches unless clearly
>> necessary and agreed upon." )
>>
>>
>> Here are the problems that I'm having using the release-plugin/
>> process:
>>
>> 1) There is a version property defined in the root pom to match the
>> release version. The maven-release-plugin will not change this
>> version property (just the version element in the root pom) during
>> mvn release:prepare
>>
>> I attempted to remove the version property but it appears this is
>> used to generate the directory to scan by the jasper builder as I
>> get the following error when I attempt to remove it.
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Could not scan directory for TLD files: jar:file:/Users/bohn/
>> geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/
>> target/repository/org/apache/geronimo/samples/CustomerService-jetty/
>> ${version}/CustomerService-jetty-${version}.car/CustomerService-
>> ejb-2.1-SNAPSHOT.jar!/META-INF Illegal character in path at index
>> 153: file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/
>> CustomerService-jetty/target/repository/org/apache/geronimo/samples/
>> CustomerService-jetty/${version}/CustomerService-jetty-$
>> {version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar
>>
>> Attempting to change this version property manually prior to
>> release didn't work either. Apparently, the maven-release does a
>> build prior to the svn changes (which fails with a manual change)
>> and after the svn changes (which fails without the manual change).
>>
>> BTW, we have this same version property defined in the server root
>> pom.
>
> This is a problem we'll have to solve to release the server with the
> release plugin. I thought I'd dealt with it successfully in the
> apacheds plugin release but maybe not....
yup, this was due to someone trying hard to mess up the c-m-p by
including part of the environment element that it generates
correctly. After I removed them (in trunk) the ${version} property is
not needed.
>
>>
>>
>> 2) When using the maven-release-plugin I have to specify the
>> release and the new snapshot version. The release default is fine
>> because we are currently using 2.1-SNAPSHOT and so the release will
>> be 2.1. However, I must manually specify the development release to
>> 2.1.1-SNAPSHOT or it will default to 2.2-SNAPSHOT. This isn't a
>> big problem but it is annoying (especially since I have to enter
>> that value 78 times ... once for each artifact). Newer versions of
>> the maven-release-plugin have parms to override these versions on
>> the command line but the version included in genesis 1.4 does not.
>
> I think there's a configuration setting so you only have to specify
> it once. You can set this on the command line although I think its
> better to include in the samples root pom (or the next version of
> genesis).
> -DautoVersionSubmodules=true
>>
>>
>> 3) This isn't necessary a problem but it doesn't seem right to me.
>> When The scm entries are updated for a tag with the name:
>> - http://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1
>> I understand why this based upon the release-plugin structure.
>> However the name doesn't seem intuitive to me. I think a structure
>> that matches our server structure makes much more sense. So I
>> would prefer:
>> - http://svn.apache.org/repos/asf/geronimo/samples/tags/2.1.0 (with
>> or without the .0)
>> I think this makes much more sense and more clearly matches the
>> samples to the server (and we indicated on earlier threads that we
>> wanted to keep these in sync).
>
> While it isn't what we've been doing by hand I am 100% in favor of
> following maven default behavior unless it breaks stuff. We don't
> need to look different from everyone else.
>
>>
>>
>> 4) I'm becoming more and more of the opinion that we should merge
>> the samples svn back into the server svn. I see little advantage
>> in keeping these independent and a lot of problems in doing so. If
>> I can convince folks that is the right thing to do then it doesn't
>> make much sense to get the samples releasing with the maven-release-
>> plugin while the server is still released manually.
>>
>> Some reasons I think the samples should be merged back into the
>> server svn.
>> - The samples are tied to a particular server release.
>> - It's important to have samples available ASAP with a server
>> release. Tying these together would ensure that they are available
>> in conjunction with the server release (you can't do any better
>> than that).
>> - The samples are versioned to match the server and this would make
>> it a no-brainer to keep them in sync.
>> - Samples could take advantage of the dependency management in
>> server root pom to ensure that everything is in sync with the
>> server. As it stands now dependency versions for samples are
>> spread across numerous poms and managed independently from the
>> server.
>> - We have had 0 success to date releasing samples independently of
>> the server.
>
> I don't buy this. IMO we should be working hard so that samples
> don't need to be updated and released for every server release. I
> think we also agreed that our long term direction should be that the
> server plugins are generally built and released independently of a
> server. Adding more stuff to the giant monolithic server build is
> against this goal.
>
> One thing that might help here is to specify includeVersion false in
> the car-maven-plugin configuration. We'd have to see if the plugins
> still worked :-)
>
>
> I'll take a look and see if I can figure out what is going on with
> the ${version} property.
I fixed this in trunk.
I'm not ok with releasing with the datasources set up the way they
are, with the generic tranql connector. I would really prefer we
provide say a derby and postgres database plugin for samples and
depend on the derby one in all the samples and have the postgres
(e.g.) one replace it. This would be a nice demonstration of
recommended best practices and if someone doesn't want to use a sample
app plugin directly they can always install the db plugin they want.
If there are no objections and no volunteers I'll set this up. If
there's a volunteer I can answer any questions. The roller plugin is
set up to do this.
If people don't like this we could use a derby specific tranql adapter.
My comment about "no branches" in the release guidelines would in this
case result in removing samples/branches/2.1, changing the version in
trunk back to 2.1-SNAPSHOT and releasing directly from trunk. I think
this is a really good idea.
Before this stuff gets released I would like to know what happens if
we set includeVersions=false... do the samples still work? If they do
I think the samples are likely to keep working on 2.1.1, 2.1.2 etc
etc. This might even be a reasonable compatibility test for 2.1.x,
x>=1.
Are there any automated tests to see what happens when you deploy the
sample plugins? If not, would it be worth setting up something sort
of like testsuite that starts up say the framework server and installs
the plugin? (framework so jetty or tomcat can be pulled in as
appropriate).
thanks
david jencks
>
>
> thanks
> david jencks
>
>>
>>
>> Regarding #4 ... I would get 2.1 samples and 2.1.1 samples released
>> independently and then suggest we merge the samples under the
>> server svn in branches/2.1 and trunk. We don't need to decide #4
>> right away since we still have to get 2.1 & possibly 2.1.1 out the
>> door. The only advantage I can think of in keeping them
>> independent is the ability to build samples without building the
>> server but as I mentioned in another post I don't believe this is
>> possible anyway at the moment.
>>
>>
>> Joe
>>
>>
>>
>>
>
Re: Samples release process
Posted by David Jencks <da...@yahoo.com>.
On May 21, 2008, at 10:57 AM, Joe Bohn wrote:
> I've been stuck attempting to use the maven-release-plugin for
> samples for a few reasons. I would like go ahead and create a
> branch for this release which will later be converted to a tag (the
> old fashioned way). Are there any strong objects? (Note: I'm asking
> because of this sentence in our release process doc - "...most
> smaller projects such as specs, plugins, components, and most likely
> tools should avoid the complexity of branches unless clearly
> necessary and agreed upon." )
>
>
> Here are the problems that I'm having using the release-plugin/
> process:
>
> 1) There is a version property defined in the root pom to match the
> release version. The maven-release-plugin will not change this
> version property (just the version element in the root pom) during
> mvn release:prepare
>
> I attempted to remove the version property but it appears this is
> used to generate the directory to scan by the jasper builder as I
> get the following error when I attempt to remove it.
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Could not scan directory for TLD files: jar:file:/Users/bohn/
> geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/
> target/repository/org/apache/geronimo/samples/CustomerService-jetty/$
> {version}/CustomerService-jetty-${version}.car/CustomerService-
> ejb-2.1-SNAPSHOT.jar!/META-INF Illegal character in path at index
> 153: file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/
> CustomerService-jetty/target/repository/org/apache/geronimo/samples/
> CustomerService-jetty/${version}/CustomerService-jetty-$
> {version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar
>
> Attempting to change this version property manually prior to release
> didn't work either. Apparently, the maven-release does a build
> prior to the svn changes (which fails with a manual change) and
> after the svn changes (which fails without the manual change).
>
> BTW, we have this same version property defined in the server root
> pom.
This is a problem we'll have to solve to release the server with the
release plugin. I thought I'd dealt with it successfully in the
apacheds plugin release but maybe not....
>
>
> 2) When using the maven-release-plugin I have to specify the
> release and the new snapshot version. The release default is fine
> because we are currently using 2.1-SNAPSHOT and so the release will
> be 2.1. However, I must manually specify the development release to
> 2.1.1-SNAPSHOT or it will default to 2.2-SNAPSHOT. This isn't a big
> problem but it is annoying (especially since I have to enter that
> value 78 times ... once for each artifact). Newer versions of the
> maven-release-plugin have parms to override these versions on the
> command line but the version included in genesis 1.4 does not.
I think there's a configuration setting so you only have to specify it
once. You can set this on the command line although I think its
better to include in the samples root pom (or the next version of
genesis).
-DautoVersionSubmodules=true
>
>
> 3) This isn't necessary a problem but it doesn't seem right to me.
> When The scm entries are updated for a tag with the name:
> - http://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1
> I understand why this based upon the release-plugin structure.
> However the name doesn't seem intuitive to me. I think a structure
> that matches our server structure makes much more sense. So I would
> prefer:
> - http://svn.apache.org/repos/asf/geronimo/samples/tags/2.1.0 (with
> or without the .0)
> I think this makes much more sense and more clearly matches the
> samples to the server (and we indicated on earlier threads that we
> wanted to keep these in sync).
While it isn't what we've been doing by hand I am 100% in favor of
following maven default behavior unless it breaks stuff. We don't
need to look different from everyone else.
>
>
> 4) I'm becoming more and more of the opinion that we should merge
> the samples svn back into the server svn. I see little advantage in
> keeping these independent and a lot of problems in doing so. If I
> can convince folks that is the right thing to do then it doesn't
> make much sense to get the samples releasing with the maven-release-
> plugin while the server is still released manually.
>
> Some reasons I think the samples should be merged back into the
> server svn.
> - The samples are tied to a particular server release.
> - It's important to have samples available ASAP with a server
> release. Tying these together would ensure that they are available
> in conjunction with the server release (you can't do any better than
> that).
> - The samples are versioned to match the server and this would make
> it a no-brainer to keep them in sync.
> - Samples could take advantage of the dependency management in
> server root pom to ensure that everything is in sync with the
> server. As it stands now dependency versions for samples are spread
> across numerous poms and managed independently from the server.
> - We have had 0 success to date releasing samples independently of
> the server.
I don't buy this. IMO we should be working hard so that samples don't
need to be updated and released for every server release. I think we
also agreed that our long term direction should be that the server
plugins are generally built and released independently of a server.
Adding more stuff to the giant monolithic server build is against this
goal.
One thing that might help here is to specify includeVersion false in
the car-maven-plugin configuration. We'd have to see if the plugins
still worked :-)
I'll take a look and see if I can figure out what is going on with the
${version} property.
thanks
david jencks
>
>
> Regarding #4 ... I would get 2.1 samples and 2.1.1 samples released
> independently and then suggest we merge the samples under the server
> svn in branches/2.1 and trunk. We don't need to decide #4 right
> away since we still have to get 2.1 & possibly 2.1.1 out the door.
> The only advantage I can think of in keeping them independent is the
> ability to build samples without building the server but as I
> mentioned in another post I don't believe this is possible anyway at
> the moment.
>
>
> Joe
>
>
>
>