Third Party Dependencies

[Troy Howard]

To summarize the 3rd party dependency issues, I've made a list of the
details of the discussion:

Including Binary Dependencies in Repository
----------------------------------------------------------------

Pros
- One-step build experience; Good for new users, easy to maintain for developers
- Solid control of dependency versioning since we control the DLL

Cons
- No debugging support for 3rd party libs (as opposed to checking in
source code of 3rd party libs)
- Could lead to 'binary bloat' in repository
- Could lead to platform specific issues (eg 32vs64 bit or other OS
platform/framework issues)
- Could lead to legal issues with redistribution
- Requires developers to do extra work to ensure they are complying
with license restrictions for redistribution ( eg, read and understand
the license and do whatever steps it requires)

Including Source Code Dependencies in Repository
---------------------------------------------------------------------------

Pros
- One-step build experience; Good for new users, easy to maintain for developers
- Full debugging support of 3rd party lib (can step through code, etc)
- Allows modification of 3rd party source, if needed.
- Fine grained control of versioning using VCS of 3rd party project
(can include a specific and move back/forwards easily)

Cons
- Could lead to source code bloat in repository
- Requires full build environment for 3rd party lib/dependencies
- Could lead to legal issues with redistribution
- Requires developers to do extra work to ensure they are complying
with license restrictions for redistribution ( eg, read and understand
the license and do whatever steps it requires)

Including Source/Binary Dependencies Outside of Repository
----------------------------------------------------------------------------------------

Pros
- No potential legal liability
- No bloat in repository of content that is not our work product
- End users/developers may choose how to setup/configure libs for their platform
- Allows 3rd party projects to control access to their content (ie:
download link could have updated version or be made non-public if they
choose to do so)

Cons
- Confusing for new users/developers. Need to read documentation and
perform setup before they can compile
- Requires developers to do extra work to maintain
compilation-notes.txt accurately
- Could lead to unavailability of 3rd party content if URLs change or
other unforseen circumstances

Let's put it to a basic vote. Please respond with on of the following
three options:

+1 Include binaries in repository
+1 Include source in repository
+1 Include either binaries or source in repository
+1 Do not include binaries or source in repository

Thanks,
Troy

[Prescott Nasser]

+1 Include binaries in repository (I assume they will be in "thirdparty" project of some kind to keep them cleanly separate)
 
I also think we need a page that lists all third party libs/tools included in the repository, giving links to their pages, downloads for other versions and some instructions / common issues people encounter that users should look out for.

> --
> You received this message because you are subscribed to the Google Groups "Lucere Development" group.
> To post to this group, send email to lucer...@googlegroups.com.
> To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
>

[Sergey Mirvoda]

+1 to include binaries with same license.

also as Mark suggest

we can write NuGet package with all required dependencies.

-1 to source code. It will complicate things very much.

--
--Regards, Sergey Mirvoda

[Ciaran Roarty]

+1 Include binaries in repository if it is legal to do so.

[Hakeem Mohammed]

+1 Binaries in repository.

Include the dependencies in a separate folder named lib or some such. So when a user downloads the Lucere framework there would be a build folder with the build scripts, a lib folder with all dependencies and a src folder with the actual library code. The readme.txt/compilation notes would be in the root folder and if we are to include documentation with it that could be in a doc folder

Thanks!

[Ciaran Roarty]

So, am I right in thinking that we have agreed to include binary dependencies?

 

If so, I was going to create a folder in lucere.test and call it binary dependencies. Any better suggestions?

 

Ciaran

[Prescott Nasser]

I think a new project is cleaner, because the tests are our work.

-----Original Message-----
From: Ciaran Roarty <ciaran...@gmail.com>
Date: Sun, 21 Nov 2010 21:57:40
To: <lucer...@googlegroups.com>
Subject: RE: [lucere-dev] Third Party Dependencies

So, am I right in thinking that we have agreed to include binary dependencies?
 
If so, I was going to create a folder in lucere.test and call it binary dependencies. Any better suggestions?
 
Ciaran
 
From: lucer...@googlegroups.com [mailto:lucer...@googlegroups.com] On Behalf Of Hakeem Mohammed
Sent: 20 November 2010 15:07
To: lucer...@googlegroups.com
Subject: Re: [lucere-dev] Third Party Dependencies
 
+1 Binaries in repository.

Include the dependencies in a separate folder named lib or some such. So when a user downloads the Lucere framework there would be a build folder with the build scripts, a lib folder with all dependencies and a src folder with the actual library code. The readme.txt/compilation notes would be in the root folder and if we are to include documentation with it that could be in a doc folder

Thanks!

On Sat, Nov 20, 2010 at 3:57 AM, Ciaran Roarty <ciaran...@gmail.com <mailto:ciaran...@gmail.com> > wrote:
+1 Include binaries in repository if it is legal to do so.

> To post to this group, send email to lucer...@googlegroups.com <mailto:lucer...@googlegroups.com> .
> To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com <mailto:lucere-dev%2Bunsu...@googlegroups.com> .

> For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "Lucere Development" group.

To post to this group, send email to lucer...@googlegroups.com <mailto:lucer...@googlegroups.com> .
To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com <mailto:lucere-dev%2Bunsu...@googlegroups.com> .

For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
 
--
You received this message because you are subscribed to the Google Groups "Lucere Development" group.

To post to this group, send email to lucer...@googlegroups.com <mailto:lucer...@googlegroups.com> .
To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com <mailto:lucere-dev+...@googlegroups.com> .

[curren...@gmail.com]

I dont have time to write about this now, but i disagree, and it only looks like a few people have stated their opinions on this so far. I will post my thoughts on this hopefully later today or tomorrow.

---Original Message---
From: lucer...@googlegroups.com
Sent: 11/21/2010 12:57 pm
To: lucer...@googlegroups.com
Subject: RE: [lucere-dev] Third Party Dependencies

So, am I right in thinking that we have agreed to include binary dependencies? If so, I was going to create a folder in lucere.test and call it binary dependencies. Any better suggestions? Ciaran From: lucer...@googlegroups.com [mailto:lucer...@googlegroups.com] On Behalf Of Hakeem Mohammed Sent: 20 November 2010 15:07 To: lucer...@googlegroups.com Subject: Re: [lucere-dev] Third Party Dependencies +1 Binaries in repository. Include the dependencies in a separate folder named lib or some such. So when a user downloads the Lucere framework there would be a build folder with the build scripts, a lib folder with all dependencies and a src folder with the actual library code. The readme.txt/compilation notes would be in the root folder and if we are to include documentation with it that could be in a doc folder Thanks! On Sat, Nov 20, 2010 at 3:57 AM, Ciaran Roarty <ciaran...@gmail.com> wrote: +1 Include binaries in repository if it is legal to do so. On 20 Nov 2010, at 01:01, Troy Howard <thow...@gmail.com> wrote: > To summarize the 3rd party dependency issues, I've made a list of the > details of the discussion: > > Including Binary Dependencies in Repository > ---------------------------------------------------------------- > > Pros > - One-step build experience; Good for new users, easy to maintain for developers > - Solid control of dependency versioning since we control the DLL > > Cons > - No debugging support for 3rd party libs (as opposed to checking in > source code of 3rd party libs) > - Could lead to 'binary bloat' in repository > - Could lead to platform specific issues (eg 32vs64 bit or other OS > platform/framework issues) > - Could lead to legal issues with redistribution > - Requires developers to do extra work to ensure they are complying > with license restrictions for redistribution ( eg, read and understand > the license and do whatever steps it requires) > > > Including Source Code Dependencies in Repository > --------------------------------------------------------------------------- > > Pros > - One-step build experience; Good for new users, easy to maintain for developers > - Full debugging support of 3rd party lib (can step through code, etc) > - Allows modification of 3rd party source, if needed. > - Fine grained control of versioning using VCS of 3rd party project > (can include a specific and move back/forwards easily) > > Cons > - Could lead to source code bloat in repository > - Requires full build environment for 3rd party lib/dependencies > - Could lead to legal issues with redistribution > - Requires developers to do extra work to ensure they are complying > with license restrictions for redistribution ( eg, read and understand > the license and do whatever steps it requires) > > > Including Source/Binary Dependencies Outside of Repository > ---------------------------------------------------------------------------- ------------ > > Pros > - No potential legal liability > - No bloat in repository of content that is not our work product > - End users/developers may choose how to setup/configure libs for their platform > - Allows 3rd party projects to control access to their content (ie: > download link could have updated version or be made non-public if they > choose to do so) > > Cons > - Confusing for new users/developers. Need to read documentation and > perform setup before they can compile > - Requires developers to do extra work to maintain > compilation-notes.txt accurately > - Could lead to unavailability of 3rd party content if URLs change or > other unforseen circumstances > > > > Let's put it to a basic vote. Please respond with on of the following > three options: > > +1 Include binaries in repository > +1 Include source in repository > +1 Include either binaries or source in repository > +1 Do not include binaries or source in repository > > > Thanks, > Troy > > -- > You received this message because you are subscribed to the Google Groups "Lucere Development" group. > To post to this group, send email to lucer...@googlegroups.com. > To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com <mailto:lucere-dev%2Bunsu...@googlegroups.com> . > For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Lucere Development" group. To post to this group, send email to lucer...@googlegroups.com. To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com <mailto:lucere-dev%2Bunsu...@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Lucere Development" group. To post to this group, send email to lucer...@googlegroups.com. To unsubscribe from this group, send email to lucere-dev+unsubscribe@

[Hakeem]

The dependencies folder should be outside the Test folder as it may
contain dependencies for other projects as well. This is what I was
thinking for the folder structure that a user will get after
downloading the library

Lucere
build
lib (this has all 3rd party dependencies)
src (this includes test project and all other lucere projects)
readme.txt

On Nov 21, 4:57 pm, "Ciaran Roarty" <ciaran.roa...@gmail.com> wrote:
> So, am I right in thinking that we have agreed to include binary
> dependencies?
>
> If so, I was going to create a folder in lucere.test and call it binary
> dependencies. Any better suggestions?
>
> Ciaran
>
> From: lucer...@googlegroups.com [mailto:lucer...@googlegroups.com] On
> Behalf Of Hakeem Mohammed
> Sent: 20 November 2010 15:07
> To: lucer...@googlegroups.com
> Subject: Re: [lucere-dev] Third Party Dependencies
>
> +1 Binaries in repository.
>
> Include the dependencies in a separate folder named lib or some such. So
> when a user downloads the Lucere framework there would be a build folder
> with the build scripts, a lib folder with all dependencies and a src folder
> with the actual library code. The readme.txt/compilation notes would be in
> the root folder and if we are to include documentation with it that could be
> in a doc folder
>
> Thanks!
>

> On Sat, Nov 20, 2010 at 3:57 AM, Ciaran Roarty <ciaran.roa...@gmail.com>

> wrote:
>
> +1 Include binaries in repository if it is legal to do so.
>

> <mailto:lucere-dev%2Bunsu...@googlegroups.com> .> For more options, visit this group at

>
> http://groups.google.com/group/lucere-dev?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lucere Development" group.
> To post to this group, send email to lucer...@googlegroups.com.
> To unsubscribe from this group, send email to
> lucere-dev+...@googlegroups.com

> <mailto:lucere-dev%2Bunsu...@googlegroups.com> .
> For more options, visit this group athttp://groups.google.com/group/lucere-dev?hl=en.

[Gokhan Demir]

Ciaran,

It's better to put in a more common folder like lib. If multiple projects depend on same the assembly, they should reference from the same path. But I think NuGet will be the correct choice.

Gokhan Demir.

[Andy Pook]

+0.5 for binaries in repo (where licence is compatible)
OR
+1 for NuGet script

The primary reason is for a clone -> build experience. This means it
would be simple to use a public build server like
teamcity.codebetter.com

Can we make this decision fairly soon. The reference to Moq has been
changed several times over the weekend with various relative paths,
with and without the version in the path. Fixing the ref or
rearranging my "lib" folder is getting tedious.
Also, a ref to StructureMap has been added.
Lastly, whoever changes the ref paths should also be responsible for
updating the "compilation_notes.txt" file.

Cheers

[Ciaran Roarty]

I agree

 

I don't care too much about the decision, just that one gets made. We can change it if it gets unwieldy.

C

[Hakeem]

I added that SM ref. sorry bout that. For now it is not needed and
I'll remove that. I started work on a Service locator so that various
DI frameworks could be used. Will put it back then

Thanks!

On Nov 22, 6:57 am, Ciaran Roarty <ciaran.roa...@gmail.com> wrote:
> I agree
>
> I don't care too much about the decision, just that one gets made. We can
> change it if it gets unwieldy.
> C

> On 22 November 2010 11:40, Andy Pook <andy.p...@gmail.com> wrote:
>
> > +0.5 for binaries in repo (where licence is compatible)
> > OR
> > +1 for NuGet script
>
> > The primary reason is for a clone -> build experience. This means it
> > would be simple to use a public build server like
> > teamcity.codebetter.com
>
> > Can we make this decision fairly soon. The reference to Moq has been
> > changed several times over the weekend with various relative paths,
> > with and without the version in the path. Fixing the ref or
> > rearranging my "lib" folder is getting tedious.
> > Also, a ref to StructureMap has been added.
> > Lastly, whoever changes the ref paths should also be responsible for
> > updating the "compilation_notes.txt" file.
>
> > Cheers
>

> > On 22 November 2010 07:11, Gokhan Demir <yadaz...@gmail.com> wrote:
> > > Ciaran,
> > > It's better to put in a more common folder like lib. If multiple projects
> > > depend on same the assembly, they should reference from the same
> > path. But I
> > > think NuGet will be the correct choice.
>

> > > On Sun, Nov 21, 2010 at 11:57 PM, Ciaran Roarty <ciaran.roa...@gmail.com

>
> > > wrote:
>
> > >> So, am I right in thinking that we have agreed to include binary
> > >> dependencies?
>
> > >> If so, I was going to create a folder in lucere.test and call it binary
> > >> dependencies. Any better suggestions?
>
> > >> Ciaran
>
> > >> From: lucer...@googlegroups.com [mailto:lucer...@googlegroups.com]
> > On
> > >> Behalf Of Hakeem Mohammed
> > >> Sent: 20 November 2010 15:07
>
> > >> To: lucer...@googlegroups.com
> > >> Subject: Re: [lucere-dev] Third Party Dependencies
>
> > >> +1 Binaries in repository.
>
> > >> Include the dependencies in a separate folder named lib or some such. So
> > >> when a user downloads the Lucere framework there would be a build folder
> > >> with the build scripts, a lib folder with all dependencies and a src
> > folder
> > >> with the actual library code. The readme.txt/compilation notes would be
> > in
> > >> the root folder and if we are to include documentation with it that
> > could be
> > >> in a doc folder
>
> > >> Thanks!
>

> > >> On Sat, Nov 20, 2010 at 3:57 AM, Ciaran Roarty <ciaran.roa...@gmail.com

>
> > >> wrote:
>
> > >> +1 Include binaries in repository if it is legal to do so.
>

> > >> > lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

> > >> > For more options, visit this group at
> > >> >http://groups.google.com/group/lucere-dev?hl=en.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Lucere Development" group.
> > >> To post to this group, send email to lucer...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

> > >> For more options, visit this group at
> > >>http://groups.google.com/group/lucere-dev?hl=en.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Lucere Development" group.
> > >> To post to this group, send email to lucer...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

> > >> For more options, visit this group at
> > >>http://groups.google.com/group/lucere-dev?hl=en.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Lucere Development" group.
> > >> To post to this group, send email to lucer...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

> > >> For more options, visit this group at
> > >>http://groups.google.com/group/lucere-dev?hl=en.
>
> > > --
> > > Gokhan Demir.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Lucere Development" group.
> > > To post to this group, send email to lucer...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

> > > For more options, visit this group at
> > >http://groups.google.com/group/lucere-dev?hl=en.
>
> > --
> >  You received this message because you are subscribed to the Google Groups
> > "Lucere Development" group.
> > To post to this group, send email to lucer...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > lucere-dev+...@googlegroups.com<lucere-dev%2Bunsu...@googlegroups.com>
> > .

[Rich Kantrowitz]

+1 Include binaries in repository if no legal issues.

Doing so would just make life easier for everyone involved in terms of
project maintainability and setup. I think its important for new
people to pull down the repo and hit the ground running and not have
to wade through potential dependency issues.

Rich

[Ciaran Roarty]

Ok, I think there's enough momentum behind including them in the initial thrust of the project; we can revisit if necessary.

 

I will add a solution folder for dependencies.

 

Cheers,

Ciaran

--
You received this message because you are subscribed to the Google Groups "Lucere Development" group.
To post to this group, send email to lucer...@googlegroups.com.

To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.

[Christopher Currens]

I've given it some though, I suppose I'm not entirely against
including binaries where legal issues aren't involved. It goes
against my habits and instincts, but I suppose it could be helpful for
people, even though I would hope the target audience for a project
such as this would be able to add the libraries themselves. I don't
think that, at least at this point in time, that our dependencies, or
specific versions of them, would be unavailable, since we're using
relatively high-profile libs. But I digress.

I think that having the dependencies in a separate root folder, like
lib or resource would be idea, in the trunk folder. just my 2c.

On Nov 22, 9:14 am, Ciaran Roarty <ciaran.roa...@gmail.com> wrote:
> Ok, I think there's enough momentum behind including them in the initial
> thrust of the project; we can revisit if necessary.
>
> I will add a solution folder for dependencies.
>
> Cheers,
> Ciaran

> > lucere-dev+...@googlegroups.com<lucere-dev%2Bunsubscribe@googlegrou ps.com>
> > .

[Ciaran Roarty]

I will wait until I hear more opinions then.

Cheers,
Ciaran

Thanks!

To post to this group, send email to lucer...@googlegroups.com.

To unsubscribe from this group, send email to

lucere-dev+...@googlegroups.com.

[Troy Howard]

My opinions pretty much echo Christopher's. The only other concern I
have is that I want to be careful regarding licensing issues because
we don't have the support that being part of a larger organization
like the ASF would provide for those matters (both in terms of
prescriptive guidance and legal protections).

Obvious 'careful' doesn't mean 'paranoid'... So as long as we do due
diligence to ensure that we're complying with licensing, I don't see
that this is much of a concern.

I'd like to keep the third-party dependencies to a minimum and keep
the code isolated to specific Visual Studio projects/DLLs. This way we
can build as much as possible without dependencies.

With regard to the location of dependency storage, there is already a
directory intended for this purpose: The 'resource' directory under
trunk is meant for binary file storage. We should add a subdirectory
to resource for external libraries.

For third-party resource storage, our work repository follows this pattern:

~/trunk/resource/third-party/<organization-name>/<project-name>/<version>/<resource>.<ext>

So, for example, Moq would be:

~/trunk/resource/third-party/Clarius Consulting/Moq/4.0/Moq.dll

or Lucene.Net 2.9.2 would be:

~/trunk/resource/third-party/Apache Software
Foundation/Lucene.Net/2.9.2/Lucene.Net.dll

We find keeping it organized this way keeps track of things well and
multiple versions can live side-by-side easily, etc... i'd suggest
using the same structure here for external libraries.

Thanks,
Troy

[ThePilot]

Hi all... sorry I missed out on the dev discussion earlier. Had
missed this particular list, and was jabbering on the primary Lucere
list. :)

I'm strongly in favor of maintaining a branch relative binary resource
directory for these types of dependencies. Specifically, Moq and (I'm
assuming) Structuremap are being used as development tools to aid in
writing tests, not as external deliverables (i.e. end users of Lucere
shouldn't need moq.dll to load the lucere assembly(ies)). This should
keep us farther out of any licensing / distribution issues (maybe.)

Anyway, just my quick 2 cents.

ThePilot

> > On Sat, Nov 20, 2010 at 3:57 AM, Ciaran Roarty <ciaran.roa...@gmail.com
> > <mailto:ciaran.roa...@gmail.com> > wrote:
> > +1 Include binaries in repository if it is legal to do so.
>

> > On 20 Nov 2010, at 01:01, Troy Howard <thowar...@gmail.com

[Hakeem Mohammed]

Tests can be more than just that. They can act as specs too. So a end user might want to run test cases to understand the various parts of the framework. As such, all dependencies for running the test cases need to be included in the package that a user downloads.

As for all the licensing concerns, we could limit our dependencies to those that have liberal licenses allowing us to redistribute freely. I believe most of the 3rd party libraries that we use fall under this category. Where there are cases in which we have a dependency with license restrictions, that could be documented in the release notes and have the user go get it.

A few more cents in the jar :D