tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <kmen...@servprise.com>
Subject Re: Dynarch licensing issue
Date Thu, 03 Jan 2008 22:18:32 GMT
It's an extra hurdle that isn't needed.  I'd just assume not use the
DateField component at all because I don't need to be chasing down a
dependency everytime I want to use that component.  Best case is that the
javascript gets packaged up into a component hosted on a non-ASF server and
can be deployed via maven, but someone has to step up to do that.
Otherwise, how do you distribute the JS in a standard manner?  Tell the user
that they also have to add it to the classpath for the component to find it?

Now, is this to be acceptable for each different component if each is to use
an LGPL library (obviously not the case, but worst case)?

At least in the case of the non-distributable JARs you mentioned there's a
standard way to deal with the problem.  Heck, maven even tells you where to
download the JARs from and how to deploy them to an internal repository.  A
process that's well defined and needs to be executed precisely once for each
maven environment as a whole.

At the end of the day, it's likely easier to just find another calendar that
has a compatible license or to roll our own.


On 1/3/08 4:48 PM, in article
b539f7630801031348s7dfff4d7id1986a84275de2b@mail.gmail.com, "Paul Cooley"
<pecooley@gmail.com> wrote:

> The same argument can be made for quite a few of the specific java libraries
> as well.  Those that are not included in maven require you to manually
> install them in your repository for builds, since they cannot be
> distributed.  I understand the warning, but I fail to see how this is a
> showstopper.  If it's an important library for the project, then all we need
> are release notes to know what needs to be installed separately from the
> distribution.
> After all, we're going to run into the same kinds of issues when packaging
> public webapps to be distributing via tomcat/jboss/etc for libraries that
> can't legally be packaged in an application.
> Cheers.
> On Jan 3, 2008 3:38 PM, Kevin Menard <kmenard@servprise.com> wrote:
>> Correct, but that makes it practically useless as a core component :-/
>> --
>> Kevin
>> On 1/3/08 3:23 PM, in article
>> b539f7630801031223h335d1a1bqcb21161ad3f81134@mail.gmail.com, "Paul Cooley"
>> <pecooley@gmail.com> wrote:
>>> Actually it appears it can be listed as a system requirement:  just not
>>> included for distribution.
>>> On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hlship@gmail.com> wrote:
>>>> Sounds like the policy has shifted again.  It's like quicksilver.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message