Greetings and some opinions

[Gokhan Demir]

Hi all,
I'm Gokhan Demir. I just join the project. I have been looking out
repository history to learn how to collaborate. For warming up I'll
start with small steps, I want to begin migrating
"lucere.analysis.enumerator" namespace if it's ok for everyone else. I
also altered the mapping document.

At phase one-stage one, will we be just migrating the contract and
tests on lucere.definition and lucere.test projects ?
I am asking this for clarity and I saw some implementations under the
"lucere.io.concurrency" namespace.

Plus, I am also with Moq for mocking but i see its assembly directly
in lucere.test project's folder. I think 3th party libraries should be
in a more appropriate folder like "resource\lib" or just "lib".

Thanks,
Gokhan Demir.

[Troy Howard]

Hi Gokhan!

"At phase one-stage one, will we be just migrating the contract and tests"

Yes.

Regarding third-party dependencies...

Neither source code or binaries of dependencies should be included in
the repository. We don't want to redistribute content from other
projects. Instead, the file 'compilation-notes.txt' should include
instructions on how to download the appropriate binary file or source
code, where to place it and how to configure it. See that file for
reference.

For example.. If you wanted to include MyCoolLibrary.dll. You would
edit compilation-notes.txt, adding to the dependencies description
there.

Example:

----

Dependencies
--------------------

This project depends on MyCoolLibrary.dll version 3.5.2.

File download link:

http://mycoollibrary.org/downloads/MyCoolLibrary/3.5.2/MyCoolLibrary-3.5.2.zip

Unzip the file 'MyCoolLibrary.dll' and place it in the following location:

If this file (compilation-notes.txt) is located at:

C:\repository\lucere\trunk\compilation-notes.txt

The DLL should be located at:

C:\repository\lib\MyCoolLibrary\3.5.2\MyCoolLibrary.dll

----

This way, anyone who wants to build the project can follow the
instructions and setup their compilation environment correctly.

This is one reason why I hope to keep the dependencies of the project
to a minimum.

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.
> For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
>
>

[Troy Howard]

I went ahead and updated the repository to remove Moq.dll, updated the
lucere.test.csproj and included instructions on how to download and
setup in compilation-notes.txt...

Thanks,
Troy

[Gokhan Demir]

Thank Troy, it's make sense. 

Recently in work we had issues with large word documents(actually useless frds), so we gave up versioning them. mercurial already warns when files bigger than 10mb get checked.

--
Gokhan Demir.

[Hakeem Mohammed]

Troy,

If the users are told to go get the dependencies themselves, they might get a version which is not compatible with the dependent code. I know in an ideal world this should not be the case as they all should be backward compatible. Including all dependencies in a separate lib folder as Gokhan suggested lets us be in control of the dependencies. That way end users can just get the whole library and run the build script right off the bat and have a working build. This is the setup I've seen for most OS frameworks, though one could also make a case for what you proposed

Thanks!

[Troy Howard]

This is the technique common in the C++ open source world. Users are
given guidance about what packages are necessary and directed to
download the source code and compile for their platform, statically
linking the results. Specifically, it's my opinion that dependencies
should not be referenced in binary form at all, but rather referenced
as source code and compiled.

The reason for this is for cross platform compatibility; 32 vs 64 bit,
Linux vs Windows... etc. A binary is built for a specific execution
environment. This is less of an issue for .NET but still a significant
concern.

Regarding versioning... Ideally, the compilation-notes.txt would be
updated with setup instructions and references to current download
locations for the correct versions. This becomes a problem when the
correct versions are not readily available for download. In which case
we should start preserving libraries in the repository.

Another significant concern is legality. If we do include external
content in the library we must be sure that we are complying with all
restrictions and provisions of the license for that content. We may
need to include copyright, license or other legal documents along with
the content to ensure that we are legally redistributing it. I prefer
to avoid the complexities of the law by just not including them in
public repositories and by keeping third-party references to a
minimum.

At work, in our private repository, we do preserve specific versions
in our repository, often as binaries, sometimes as source. In that
context, we don't have to worry about legality since it's not public.

Anyhow, I realize it's a bit of a hassle. Also.. this is just my
suggestion and reasons. We don't have to do it this way if you all
would rather not. Mostly, since I'm not an expert on the topic of
software legality, I just avoid the topic and workaround it.

Thanks,
Troy

[Ciaran Roarty]

All

 

I added the Moq.dll binary into the project as it was the easiest way we found on our project to onboard a new developer and it made the CI build easier.

 

I think, if I downloaded a source package I'd be looking for it to compile before I looked for the compilation-notes.txt. I am not saying I wouldn't go looking for guidance but compile & run tests would be my first port of call.

Ciaran

[Sergey Mirvoda]

@Ciaran

at least you have to put files in common location ie lib, thirdparty, dependencies 

etc

--Regards, Sergey Mirvoda

[Ciaran Roarty]

Yep, accepted.

 

Will do that if we agree to add it back into the project.

Ciaran

[Hakeem Mohammed]

The platform compatibility may not be an issue with .NET projects, but I do agree with the distributing\licensing 3rd party frameworks. I go by the premise that most OS frameworks have the same kind of licensing that we are releasing this with. I too don't know about all the various licensing restrictions. But what Ciaran said is what I was trying to emphasize. End users may tend to build and test out a framework as soon as they get it to prove to themselves that it has what they are looking for. One alternative would be to have the build script go get the dependent libraries itself and save them the first time it is run

Thanks!

[Mark Perry]

Perhaps we could include a NuGet script or create a NuGet Package for
lucere dependencies.

Then we don't need to re-distribute but the user can install the third
party dependencies quickly.

Mark