Could you please confirm that IDE like Intellij Idea will not be able to import the mavenized structure of the project ? Do you plan to publish the Idea-specific project files (.iml,..) to the repository ?
Phil On Sun, Nov 28, 2010 at 3:16 PM, Georg Ragaller <[email protected]>wrote: > Sounds good, I've only those questions: > > > > lib/ # Flat or Mavenized structure? > > - Would *lib* contain the qi4j artifacts *and* all dependencies? > - 'Mavenized' == Maven Repository like structure? I personally would only > differentiate between qi4j and dependencies e.g. lib/qi4j lib/deps or so. > > > javadoc/ > > index.html > > org/ > > - Shouldn't there be a subdirectory per module, where the module javadocs > are seperately generated but connected with the -link option, or are you > planning to have a single javadoc run over all sources? > > Cheers, > Georg > > > Niclas Hedhman wrote: > >> Guys, >> >> since I am looking towards getting away from Maven, the question is >> what should remain and what should be tossed from Maven's "imposed >> structure". >> >> On one hand, there are many things I like with Maven, such as >> everything up to building a jar file with classes and a jar file with >> source code. But beyond that point things starts get messy very >> quickly, especially if you want to deliver an open source project, as >> tarball in sources and binaries respectively. I would therefor like to >> build the 'requirements' from the end result's point of view; >> >> If we view Qi4j as a single project, that happens to have the modules >> of 'core', 'libraries' and so on, and we want a source distribution >> available and a binary SDK available, how should these look like? >> Also, I think it is convenient to be able to 'overlay' both the binary >> and the source distro into the same directory; >> >> Binary tarball; >> >> $root/ >> lib/ # Flat or Mavenized structure? >> javadoc/ >> index.html >> org/ >> 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 >> >> 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/ >> >> >> So, if one downloads the SRC tarball and run the build, one should end >> up with the BIN tarball that one can download. >> >> 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?? >> >> Anyone else have any thoughts on this?? >> >> >> Cheers >> > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
