qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: Dependencies and how it's going to affect the release
Date Tue, 07 Nov 2006 08:06:50 GMT
On 07/11/06, Daniel Kulp <daniel.kulp@iona.com> wrote:
>
> +1 to maven as well..   :-)
>
> There is also the jbossall-client.jar in the source tree.   I believe that
> is LGPL or part LGPL, also not allowed as part of a distribution at
> apache.
>
> I've been chatting with the Maven folks today about the LICENSE/NOTICE
> issues.   As of November 1, all apache projects have to have those files,
> including Maven releases.   Thus, they now have extra incentive to get
> that working smoothly.  :-)
>
> Seriously,  they are writing a plugin that will use the <license> tags
> from the maven poms to automatically build up the notice files and such.
> Should make things much easier to manage.
>
>
> Dan
>
>
>
> On Monday November 06 2006 6:58 pm, Steve Vinoski wrote:
> > +1 to maven, which I've been working on for awhile. So far in doing
> > the maven work I've been surprised by both 1) the number of
> > dependencies, which is much higher than I expected, and 2) the
> > dependencies which aren't really legal. The JMS jar is one. Another
> > is the Sun fscontext stuff, which AIUI is used only for testing, but
> > is seemingly unavailable from any maven repository as far as I can
> > see. As Rajith says, managing these dependencies will be a big part
> > of getting M1 right.
> >
> > The main thing that's been killing me as far as maven goes are the
> > test areas. They're not organized well, have dependencies between
> > them, and as I've pointed out before, they mix unit tests, system
> > tests, and performance tests. I also ran into the junit3 vs. junit4
> > issue with the maven surefire plugin, but have managed to get some of
> > the tests working with junit4 and the maven antrun plugin. If the
> > test areas were in better shape, the maven work would have been
> > finished weeks ago.
> >
> > I've been committing to the maven branch for a few weeks now, but
> > obviously it still needs work. Anyone can take a look at it if they
> > like, obviously. I'm currently working on ensuring that the maven
> > branch has the latest changes from trunk, so that I'm sure I'm not
> > chasing test failures that are already fixed. Meanwhile, if anyone
> > else wants to pitch in on the maven work, I'd be glad for the help.
> >
> > --steve
> >
> > On Nov 6, 2006, at 6:04 PM, Rajith Attapattu wrote:
> > > Hi All,
> > >
> > > AFAIK when we release we will have to package some of the
> > > dependcies with
> > > our binary distribution.
> > > When we do this we need to make sure we supply the license.txt's
> > > for those
> > > dependencies.
> > >
> > > Currently we have static dependencies in our lib files scattered
> > > over the
> > > project.
> > > So we need to think about them.
> > >
> > > For example the jms.jar. Now where did this come from?? where is
> > > the license
> > > associated with this?
> > > Usually in apache we use the geronimo spec project to get the
> > > API's, so we
> > > can use that for JMS.
> > >
> > > If I dependencies keeps growing then that will make things even more
> > > diffficult to manage, especially at distribtuion/release time.
> > >
> > > Maybe it's time to get things a bit more organized and move to a
> > > maven structure where some of these headache are taken care of.
> > >
> > > Regards,
> > >
> > > Rajith
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> daniel.kulp@iona.com
>

The sun fscontext is fine to include from Sun's point of view:
" Sun grants you a non-exclusive,
   non-transferable, limited license to reproduce and
   distribute the Software in binary form only,
   provided that you (i) distribute the Software
   complete and unmodified and only bundled as part
   of your Programs, "

http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7110-jndi-1.2.1-oth-JPR&SiteId=JSC&TransactionId=noreg

We may not have the source to include under the ASF license but we can
include the binary.

Are we not allowed to include non ASF-licensed(or equally permissive)
software in our release, be that source or binary format?


-- 
Martin Ritchie

Mime
View raw message