Or ask Dynark to add a compatible license.

On Jan 3, 2008 2:18 PM, Kevin Menard <[EMAIL PROTECTED]> wrote:
> 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.
>
> Regards,
> Kevin
>
>
> On 1/3/08 4:48 PM, in article
> [EMAIL PROTECTED], "Paul Cooley"
>
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >
> >> Correct, but that makes it practically useless as a core component :-/
> >>
> >> --
> >> Kevin
> >>
> >>
> >> On 1/3/08 3:23 PM, in article
> >> [EMAIL PROTECTED], "Paul Cooley"
> >> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Sounds like the policy has shifted again.  It's like quicksilver.
> >>>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to