Exploded modules are useful in developer usecases. For example, I work on a codebase with 25M+ lines of code spread over 1100+ projects. To save time, we suppress packaging of jars when developers run builds locally.
-- Regards, Igor On Fri, Dec 4, 2015, at 07:03 AM, Alan Bateman wrote: > > On 03/12/2015 19:49, Robert Scholte wrote: > > > > After reading the specs it seems like I can only refer to a directory > > containing modules. For a dependency specified in the pom.xml I could > > refer to the directory (within the local repository) containing that > > specific artifact. However, such directory contains more files, so I > > can't be certain the correct file is picked up (e.g. > > cooomons-lang3-3.4[2]. Both commons-lang3-3.4.jar and > > commons-lang3-3.4-tests.jar might contain a module-info.class, but it > > is uncertain if this was the file specified as dependency). > > As Mark said, this has come up a few times and good to support this > (it's easy, the only question might be whether it should allow exploded > modules too). > > Just on the example, then I assume that commons-lang3-3.4-sources.jar > and commons-lang3-3.4-javadoc.jar won't have a module declaration and so > would be treated as automatic modules. This isn't going to work of > course because the module name derived for both will be "commons-lang3" > and we can't have 2+ modules with the same name in the same directory. > > I think *-tests.jar brings many discussion points and maybe something > for another thread. In brief, if the tests are in their own package > hierarchy, not overlapping with the packages in the library that they > test, then the tests could be another module with their own module > declaration. If the tests are in the same packages as the APIs that they > are testing (this is typical, also necessary when testing package > private types or methods) then they won't be their own module but will > instead need to be grafted onto the module that they are testing. We've > worked through several examples and I think we have all the options in > place, we'll just need to make sure that it is easy to use and having > Maven plugins supporting those options would be a great help. > > -Alan. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
