maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <>
Subject Re: RFE support jar as modulepath argument
Date Fri, 04 Dec 2015 15:51:33 GMT
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


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message