Morgan Delagrange wrote:
>
> A common binary repository sounds like the way to go.
> There's no strict need for everbody to buy into it
> though. If, for some reason, a new release of a JAR
> breaks a particular subproject, that subproject can
> always check in the required version of a binary
> locally. Or ignore the common repository and check
> everything in locally, if they're dead set against the
> idea. To me, a common repository sounds like a lot
> less work for the individual subproject owners, but
> Jakarta members are nothing if not peculiar.
The way to build a community is to actually build something that people are
interested in contributing to(*). With this in mind, it would be really
nice is such a repository could be seeded with as many of the following as
is legally permitted:
ejb-1_1
j2ee_connector-1_0-pfd2
jaas1_0
jaf-1.0.1
javamail-1.2
jaxp-1.1
jdbc2_0
jms1.0.2
jmx-1_0
jndi1_2_1
jsse1.0.2
jta-spec1_0_1
jts1_0
IANAL, but ISTR that it is legal to distribute jaxp but not jsse. I'm sure
that the rest will need to be looked at on a case by case basis.
> Of course, there are administrative details to
> consider. I would be very wary of putting anything
> approaching a beta release in the common repository.
> We would need some ground rules to make sure that
> didn't happen.
How about the following rule: non released jars must go on a branch.
- Sam Ruby
(*) :-P :-P :-P
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
