I was mainly thinking about the pgp / signing wrt development time. It's just I don't think people want want to put into production a product that will download artifacts from uncontrolled locations (uncontrolled from their pov, such as maven central). So pgp/signing is less an issue imho. Licensing should definitely be clearly advertised, you're absolutely right.
On Sun, May 8, 2011 at 22:02, Jamie G. <jamie.goody...@gmail.com> wrote: > I'm not sure if there is a distinction between development time and > provisioning here WRT to licensing, as something we release we have to > ensure we clearly delineate where users could be expecting to be > building on our project vs a third party (ie. a user builds a distro, > then they should know what licenses they've pickup from the global > repo). If its in a repo file then all we would need to do is add a > meta tag to indicate license. That would seem to be scalable, and > reasonable to maintain. > > J > > On Sun, May 8, 2011 at 5:18 PM, Guillaume Nodet <gno...@gmail.com> wrote: >> Yes, and the point you raised are really important. >> We definitely need to find a good mechanism to ensure we don't break >> anything on existing karaf (well, maybe in production, we should just >> tell people to disable this feature anyway, as it should just be a >> call to features:removeurl somehow or modifying the correct >> configuration file). >> Also, pgp / signing and licensing are definitely good idea too, but >> I'm slightly less worried about that, as I think the main goal is ease >> of use at developement time and not really a provisioning mechanism to >> be used in production (where you want to test before installing stuff >> anyway, so you'd not use the global repo directly I think). >> >> On Sun, May 8, 2011 at 20:40, Jamie G. <jamie.goody...@gmail.com> wrote: >>> To be clear the general concept I am ok with, I'm just reviewing >>> potential issues that should be resolved. >>> >>> As an enhancement to the concept, I also think that each entry in a >>> repo file should include a license notice of some sort so that we can >>> adhere to categories A, B, and X under Apache licensing rules: >>> http://www.apache.org/legal/3party.html#criteriaandcategories >>> >>> Cheers, >>> Jamie >>> >>> On Sat, May 7, 2011 at 3:35 AM, Andreas Pieber <anpie...@gmail.com> wrote: >>>> On Sat, May 7, 2011 at 7:51 AM, Ioannis Canellos <ioca...@gmail.com> wrote: >>>>> Thanks Guillaume, >>>>> >>>>> >>>>>> If we agree on that, I think we should also trim down a bit the >>>>>> standard descriptor to remove any non core-karaf related features >>>>>> (such as spring, spring-dm, spring-web, and even war). >>>>>> >>>>> >>>>> I like the idea of the repository file, however I don't see war and cellar >>>>> fall back to this category (imho this is a solution fit for external >>>>> projects and not sub-projects). This could be a great idea for providing >>>>> functionality to the minimal distribution, but not on standard. >>>> >>>> TBH I'm with Guaillaume here (although I also share Jamies concerns >>>> about stability). This is quite similar to what I've described on >>>> another thread (extracting deployer (spring at least), management, >>>> web, ...). This will allow us to keep the "karaf-kernel" as small as >>>> possible. In addition, using this model we can release components >>>> independent of Karaf. >>>> >>>> Kind regards, >>>> Andreas >>>> >>>>> >>>>> -- >>>>> *Ioannis Canellos* >>>>> * >>>>> http://iocanel.blogspot.com >>>>> >>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>> Apache ServiceMix <http://servicemix.apache.org/> Committer >>>>> * >>>>> >>>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> Connect at CamelOne May 24-26 >> The Open Source Integration Conference >> http://camelone.com/ >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com Connect at CamelOne May 24-26 The Open Source Integration Conference http://camelone.com/
