On Tue, Jun 22, 2021 at 9:32 PM Gary Gregory wrote:
>
> It feels to me like JPMS just plainly breaks the informal industry standard
> of the Maven project layout we have all been using for a million years.
I don't think so. Reusing test classes downstream sounds to me highly unusual.
Jochen
--
> On Jun 22, 2021, at 2:29 PM, Andres Almiray wrote:
>
> Ralph,
>
> Once you move test code to their own Maven module they become a top level
> module, that is, they have a life of their own as any other top level module.
>
> In contrast -tests jars are not top level, but a “variant” (that’
Ralph,
Once you move test code to their own Maven module they become a top level
module, that is, they have a life of their own as any other top level module.
In contrast -tests jars are not top level, but a “variant” (that’s why they
have a classifier) of their owning top level module.
Test
> On Jun 22, 2021, at 11:16 AM, Robert Scholte wrote:
>
> If I understand correctly you want both log4j-core main classes and test
> classes be distributed as modularized jars.
> To me with JPMS you should move the modularized test-classes to a separate
> Maven module as a first citizen arti
That's just broken, I can have any number of package private classes (or
methods) that perform lower level or non-customer appropriate tasks but
that are large enough or complex enough to merrit unit testing on their own.
Only testing public APIs is saying that blackboxing is the only way to test
Ralph,
Apologies. I did not link to Jipsy as a suggestion to be used as a dependency
but rather as an example of how the ModiTect plugin may be applied to a project
that produces and tests an APT.
I believe Jipsy has a 2nd Maven module that produces a “test” jar without it
being an actual tes
Andres,
I looked at moditect when I first started doing the work. I’m afraid I am not
understanding how
it could help solve the problem with the test jar and unit tests. Could you
please explain that?
I am also not sure I understand how Jipsy will help. Log4j generates the file
in META-INF/se
Gary, the test jar doesn’t perform tests. It provides test utility classes like
LoggerContextRule.
> On Jun 22, 2021, at 12:31 PM, Gary Gregory wrote:
>
> It feels to me like JPMS just plainly breaks the informal industry standard
> of the Maven project layout we have all been using for a mil
> On Jun 22, 2021, at 1:19 PM, Elliotte Rusty Harold wrote:
>
> On Tue, Jun 22, 2021 at 7:32 PM Gary Gregory wrote:
>
>> In addition, how is one supposed to test package private code if a test jar
>> tests a main jar where all packages are now different?
>
> Some projects adhere to strictly
> On Jun 22, 2021, at 12:01 PM, Benjamin Marwell wrote:
>
>> So now you would have a maven module with only the main source and no tests,
>> and a second module
>> where the “main” source is actually the test classes
>> and the unit tests test the code in a different Maven
>> module with a mod
On Tue, Jun 22, 2021 at 7:32 PM Gary Gregory wrote:
> In addition, how is one supposed to test package private code if a test jar
> tests a main jar where all packages are now different?
Some projects adhere to strictly testing through the public API only.
It definitely makes tests more robust a
It feels to me like JPMS just plainly breaks the informal industry standard
of the Maven project layout we have all been using for a million years.
In addition, how is one supposed to test package private code if a test jar
tests a main jar where all packages are now different? This seems like a
p
> So now you would have a maven module with only the main source and no tests,
> and a second module
> where the “main” source is actually the test classes
> and the unit tests test the code in a different Maven
> module with a module info that opens the module-info of the main source jar.
> Seems
Yes, you understand correctly. And yes, the test classes could be moved to a
separate maven module, but
then the unit tests would also have to move as well as they are dependent on
those test classes. Of course,
the test classes are dependent on the main source. As an example, log4j-core
has a
If I understand correctly you want both log4j-core main classes and test
classes be distributed as modularized jars.
To me with JPMS you should move the modularized test-classes to a separate
Maven module as a first citizen artifact.
That should make it a lot easier.
It should also make the separ
+1
On Mon, Jun 21, 2021, 22:23 Michael Osipov wrote:
> Hi,
>
> We solved 9 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230&version=12346985
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20D
Have you tried using the ModiTect Maven plugin?
https://github.com/moditect/moditect
There are many ways to use it:
- with explicit module-info.java
- with an embedded DSL in the pom.xml
- with an embedded module descriptor in the pom.xml
Ii use the last option on Jipsy [https://github.com/kord
17 matches
Mail list logo
