On 2010-11-28 11.10, Niclas Hedhman wrote:
Binary tarball;
$root/
lib/ # Flat or Mavenized structure?
Would it make sense to have /core, /lib, /extensions etc.
subdirectories? Or are you suggesting all-in-one as an option? I think I
prefer with subdirectories, so that would be mavenized I suppose.
For myself it's a non-issue as I'll be working with Maven on my end
anyway, i.e. accessing Qi4j from repo.
javadoc/
index.html
org/
I think I'd prefer as above, i.e. one Javadoc set per module rather than
one big chunk.
documentation/
index.html
reports/
index.html
coverage/
unittests/
samples/
dddsample/
pom.xml
src/
main
java/
org/
tutorials/
index.html
composite/
index.html
LICENSE.txt
NOTICE.txt
This makes sense.
Source tarball;
$root/
src/
build.gradle
gradle.settings
gradlew
gradlew.bat
qi4j-core/
build.gradle
gradle.settings
api/
main/
docs/
java/
test/
java/
bootstrap/
main/
qi4j-libraries/
:
qi4j-samples/
build.gradle
gradle.settings
dddsample
main/
sample/
pom.xml
src/
main/
java/
Looks ok to me.
So, if one downloads the SRC tarball and run the build, one should end
up with the BIN tarball that one can download.
Yeah, that makes sense.
If that (the end game) is the starting point of a build system,
doesn't a lot can be backed out from that??
Since we have multiple GitHub repositories, we would need a
consolidated master build view, where the repositories are linked in,
let's say in the qi4j-sdk repository that already exists. So, if we
simply link them into the SDK repository, wouldn't it then make sense
if the layout of the Git repository follows that we have in mind for
the SRC tarball??
Absolutely!
Anyone else have any thoughts on this??
Most of the above makes sense to me. As for the open questions, yeah,
I'd prefer a mavenized structure to the libraries+javadoc.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
