Subject | Re: [Firebird-Java] JBoss CVS dependency |
---|---|
Author | David Jencks |
Post date | 2002-11-16T02:20:29Z |
On 2002.11.15 16:09:00 -0500 Doug Chamberlin wrote:
license for them and decided we probably weren't allowed to distribute
them, so I removed them. I'm not interested in writing or maintaining
another copy of these classes, and I don't have copyright for the jboss
versions. anyway, I'm not sure we could check in copies of the jboss
source code. If we are going to have to build the jars ourselves anyway, I
want it to be part of the build process. Remember that all classes we use
from jboss are the interfaces and classes from the specs we use, not any
jboss specific code. As such, they shouldn't change, at least not more
often than the specs.
My understanding and experience of what happens now is that if the built
jars are missing, the build will download the jboss stuff and build the
needed jars. If they are present, nothing happens, even if the jars are
out of date with respect to jboss source. I would prefer that we check out
the source based on a particular date, and update if the date (from the
build file) changes, but haven't had time to set this up yet.
I don't understand the utility of catering to development without cvs.
It's a small project, checking out the whole thing is very quick. No doubt
we should release prebuilt binary versions more often, but I dont think
this justifies making life harder for the developers.
david jencks
> At 11/15/2002 02:33 PM (Friday), David Jencks wrote:we started with sun jars checked into cvs. After a while I looked at the
> >I disagree with everything you say. The current system has evolved as
> the
> >solution to several earlier problems. Please suggest something concrete
> >and explain its advantages, and in particular how it will reduce the
> >maintenance effort needed by the jaybird developers.
>
> Well, to do that I'd have to know what the earlier problems were that you
>
> say were solved and how the current practice solves them.
>
> Without that info, I would just say that de-coupling the downloading of
> some JBoss code from the building of Jaybird is all that is required. I
> would create a separate Ant target for doing this and NOT include it in
> the
> normal Jaybrd build. Re-downloading should only be done during QA to
> insure
> the latest Jaybird works with the latest JBoss.
>
> My goal would be to have a system which allows a Java developer to
> download
> a collection of source from a Jaybird site and build it without requiring
> a
> CVS installation or anything else.
>
> So, what is it I'm missing?
license for them and decided we probably weren't allowed to distribute
them, so I removed them. I'm not interested in writing or maintaining
another copy of these classes, and I don't have copyright for the jboss
versions. anyway, I'm not sure we could check in copies of the jboss
source code. If we are going to have to build the jars ourselves anyway, I
want it to be part of the build process. Remember that all classes we use
from jboss are the interfaces and classes from the specs we use, not any
jboss specific code. As such, they shouldn't change, at least not more
often than the specs.
My understanding and experience of what happens now is that if the built
jars are missing, the build will download the jboss stuff and build the
needed jars. If they are present, nothing happens, even if the jars are
out of date with respect to jboss source. I would prefer that we check out
the source based on a particular date, and update if the date (from the
build file) changes, but haven't had time to set this up yet.
I don't understand the utility of catering to development without cvs.
It's a small project, checking out the whole thing is very quick. No doubt
we should release prebuilt binary versions more often, but I dont think
this justifies making life harder for the developers.
david jencks
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>