Re: JPMS whitebox testing issues

2024-10-11 Thread Ceki Gulcu 



I forgot to mention that the original mail from Stephen is quite 
informative and I thank him for that.


On 10/10/2024 22:49, Ceki Gulcu wrote:


Hi Stephen,

Thank you for broaching the issue of whitebox testing with JMPS. I think 
that it is an important topic.


I should also like to mention for a related feature.

If JMPS project "Bee" depends on JMPS project "Insect", is often useful 
to use the insect-tests.jar in the tests of project "Bee". Perhaps if 
the whitebox testing issue with JMPS is settled on, then depending on 
tests-jars can be solved as well.


Best regards,



--
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: JPMS whitebox testing issues

2024-10-10 Thread Ceki Gulcu 



Hi Stephen,

Thank you for broaching the issue of whitebox testing with JMPS. I think 
that it is an important topic.


I should also like to mention for a related feature.

If JMPS project "Bee" depends on JMPS project "Insect", is often useful 
to use the insect-tests.jar in the tests of project "Bee". Perhaps if 
the whitebox testing issue with JMPS is settled on, then depending on 
tests-jars can be solved as well.


Best regards,

--
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch


On 23/09/2024 17:47, Stephen Colebourne wrote:

Hi all,
Apologies for the long email, but whitebox testing is a complex topic.
I know not everyone agrees with whitebox testing, but it is a major
factor in how many projects are written, and IMO Maven should fully
and easily support it.

A "whitebox mode" test has two module-info.java files, both with the
same module name. The goal is to support unit testing with full access
to the internals of the module as in the "good ole days" while
ensuring that the test occurs on the module-path (test failures can
occur on the module-path which do not occur on the class-path, and
vice versa):

root
- pom.xml
- src/main/java
-- module-info.java
-- mypackage
--- Main,java
- src/main/resources
-- mypackage
--- main.txt
- src/test/java
-- module-info.java
-- mypackage
--- Test,java

The main module-info would be something like:
   module mymodule {
 exports mypackage;
   }

The test module-info would be something like:
   open module mymodule {
 // duplicate contents of main module-info
 exports mypackage;
 // any additional test dependencies/services
 requires transitive org.junit.jupiter;
   }

The good news is that a setup like this mostly works today in Maven
(tested with v3.9.9 and Java 21).
However there are three key issues:

The way Maven currently operates is:

1) In `testCompile`, the test source code is compiled using:
   --module-path target/test-classes:target/classes
   --patch-module mymodule=src/main/java

2) In `surefire`, the tests are run with:
--module-path target/test-classes:target/classes:<< dependencies >>
--class-path << surefire jar files >>

What actually happens is (I think) very surprising. TestCompile
compiles BOTH the main and test source code into
`target/test-classes`:
target/classes contains
- module-info.class (from src/main/java)
- mypackage/Main.class
- mypackage/main.txt
target/test-classes contains
- module-info.class (from src/test/java)
- mypackage/Main.class
- mypackage/Test.class

This results in three issues:

A) The code in `src/main/java` is compiled twice, which is
unnecessary, surprising and slows things down

B) There is no need to refer to `target/classes` on the module-path,
as it is not used in TestCompile or Surefire.

C) Any resource files (src/main/resources) are UNAVAILABLE to
Surefire, which results in the tests failing, eg.
`Main.class.getResourceAsStream("main.txt")` will return null. This is
because Surefire sees the code in target/test-classes as the complete
definition of the module, and as shown above `main.txt` is not present
in `target/test-classes`.

-
Option 1:
Do nothing. End users can fix the resource file issue by adding this
to the pom.xml:
   
org.apache.maven.plugins
maven-surefire-plugin

 --patch-module mymodule=src/main/resources;

   

This causes Surefire to pickup the resource folder and patch it into the module.

Option 2:
Automate the patch-module described above. When Surefire runs in
"whitebox mode", the --patch-module outlined above should be
automatically generated and added to the command line. Care will be
needed not to clash with any patch-module the user adds manually.

This fixes issue C.

Option 3:
Properly address the issue. maven-compiler-plugin already recognises
that there are two module-info.java files and checks the names. If
they are different it sets up "blackbox mode". IMO,
maven-compiler-plugin needs an official "whitebox mode".
The correct approach, as far as I can determine, is for TestCompile to
do the following:
   --module-path target/test-classes
   --patch-module mymodule=target/classes
This avoids the main source code being compiled twice - it is patched
in instead.

The same change needs to be applied to Surefire
   --module-path target/test-classes:<< dependencies >>
   --patch-module mymodule=target/classes

This fixes issues A , B and C. (The resource files in target/classes
are patched in alongside the .class files).
Note that the java command line generates a warning about duplicate
module-info.class files, but that is expected in this case,and can be
ignored.

---
So, what do people think? Is there appetite to raise an issue to get
option 2 or 3 done?

thanks for reading this far
Stephen Colebourne

PS. IDEs don't like the two module-info.java files of whitebox
tes

Re: Unexpected behavior of the javadoc plugin?

2024-01-08 Thread Ceki Gulcu 
Hi Tamás,

Thank you for your comments.

My question is more regarding the need to place a javadoc 
element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml.

Once the javadoc related  element is in the BOM file, it works fine.

However, given the BOM file is intended to be imported, I would prefer
to keep it minimal and have it free of any  and  elements
in order to not pollute importing projects.

Is my concern warranted?

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 12/28/2023 7:17 PM, Tamás Cservenák wrote:
> Hej Ceki,
> 
> I also experience javadoc misbehaviour when JPMS/jigsaw is involved, and _I
> think_ it boils down when it tries to be "smart" when it comes to JPMS...
> See master of maven-resolver, as it was suffering with similar issues, and
> this change:
> https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae
> (that was a few releases ago, things may have changed around).
> 
> Try out this flag if you are on fairly new version:
> https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode
> 
> HTH
> Tamas
> 
> On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu  wrote:
> 
>>
>> Hello all,
>>
>> Given the javadoc generation is an important part of software projects,
>> maybe someone would care to comment whether the behavior described below
>> is expected or not?
>>
>> In the meantime, happy new year to all,
>>
>> --
>> Ceki Gülcü
>>
>> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
>>
>> On 12/23/2023 9:34 PM, Ceki Gulcu wrote:
>>>
>>> Hello,
>>>
>>> I would like to share what looks to me like an unexpected behavior of
>>> the javadoc plugin, more specifically when run as javadoc:aggregate.
>>>
>>>
>>> The SLF4J project uses the "Refining the BOM Pattern" variant as
>>> explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
>>> specifically, the top level pom.xml is the BOM and project modules
>>> import ../parent/pom.xml.
>>>
>>> Source code is available at [2].
>>>
>>> Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized
>> project.
>>>
>>> When trying to create aggregated javadocs with the javadoc:aggreate
>>> command, the javadoc generation would fail with javadoc complaining
>>> about unnamed modules and other miscellaneous problems. The solution was
>>> to skip certain modules for which there was no need to generate javadocs
>>> to begin with.
>>>
>>> Surprisingly, adding  in parent/pom.xml of the
>>> javdoc-plugin configuration would have no effect. However, specifying
>>> -Dmaven.javadoc.skippedModules would work as expected.
>>>
>>> The advice commonly found on various forum about the placement of the
>>> javadoc plugin configuration pertain to  and/or 
>>> section. In my case, this advice looks irrelevant (see below).
>>>
>>> After a lot of head scratching, placing the javadoc-plugin configuration
>>> in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
>>> configuration have the desired effect. This is quite surprising as the
>>> configuration of other plugins have an effect when placed in
>> parent/pom.xml.
>>>
>>> To reproduce this behavior, you can check out the code of the SLF4J
>>> project from [2] and run "mvn javadoc:aggregate". (To observe a failure
>>> the javadoc-plugin configuration needs to commented out in top-level
>>> pom.xml and uncommented in parent/pom.xml before running "mvn
>>> javadoc:aggregate".)
>>>
>>> I am wondering whether the behavior of javadoc:aggregate described above
>>> is expected or actually a problem?
>>>
>>> Best regards,
>>>
>>> [1]
>> https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern
>>> [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unexpected behavior of the javadoc plugin?

2023-12-28 Thread Ceki Gulcu 


Hello all,

Given the javadoc generation is an important part of software projects,
maybe someone would care to comment whether the behavior described below
is expected or not?

In the meantime, happy new year to all,

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 12/23/2023 9:34 PM, Ceki Gulcu wrote:
> 
> Hello,
> 
> I would like to share what looks to me like an unexpected behavior of
> the javadoc plugin, more specifically when run as javadoc:aggregate.
> 
> 
> The SLF4J project uses the "Refining the BOM Pattern" variant as
> explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
> specifically, the top level pom.xml is the BOM and project modules
> import ../parent/pom.xml.
> 
> Source code is available at [2].
> 
> Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized project.
> 
> When trying to create aggregated javadocs with the javadoc:aggreate
> command, the javadoc generation would fail with javadoc complaining
> about unnamed modules and other miscellaneous problems. The solution was
> to skip certain modules for which there was no need to generate javadocs
> to begin with.
> 
> Surprisingly, adding  in parent/pom.xml of the
> javdoc-plugin configuration would have no effect. However, specifying
> -Dmaven.javadoc.skippedModules would work as expected.
> 
> The advice commonly found on various forum about the placement of the
> javadoc plugin configuration pertain to  and/or 
> section. In my case, this advice looks irrelevant (see below).
> 
> After a lot of head scratching, placing the javadoc-plugin configuration
> in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
> configuration have the desired effect. This is quite surprising as the
> configuration of other plugins have an effect when placed in parent/pom.xml.
> 
> To reproduce this behavior, you can check out the code of the SLF4J
> project from [2] and run "mvn javadoc:aggregate". (To observe a failure
> the javadoc-plugin configuration needs to commented out in top-level
> pom.xml and uncommented in parent/pom.xml before running "mvn
> javadoc:aggregate".)
> 
> I am wondering whether the behavior of javadoc:aggregate described above
> is expected or actually a problem?
> 
> Best regards,
> 
> [1] https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern
> [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Unexpected behavior of the javadoc plugin?

2023-12-23 Thread Ceki Gulcu 


Hello,

I would like to share what looks to me like an unexpected behavior of
the javadoc plugin, more specifically when run as javadoc:aggregate.


The SLF4J project uses the "Refining the BOM Pattern" variant as
explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
specifically, the top level pom.xml is the BOM and project modules
import ../parent/pom.xml.

Source code is available at [2].

Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized project.

When trying to create aggregated javadocs with the javadoc:aggreate
command, the javadoc generation would fail with javadoc complaining
about unnamed modules and other miscellaneous problems. The solution was
to skip certain modules for which there was no need to generate javadocs
to begin with.

Surprisingly, adding  in parent/pom.xml of the
javdoc-plugin configuration would have no effect. However, specifying
-Dmaven.javadoc.skippedModules would work as expected.

The advice commonly found on various forum about the placement of the
javadoc plugin configuration pertain to  and/or 
section. In my case, this advice looks irrelevant (see below).

After a lot of head scratching, placing the javadoc-plugin configuration
in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
configuration have the desired effect. This is quite surprising as the
configuration of other plugins have an effect when placed in parent/pom.xml.

To reproduce this behavior, you can check out the code of the SLF4J
project from [2] and run "mvn javadoc:aggregate". (To observe a failure
the javadoc-plugin configuration needs to commented out in top-level
pom.xml and uncommented in parent/pom.xml before running "mvn
javadoc:aggregate".)

I am wondering whether the behavior of javadoc:aggregate described above
is expected or actually a problem?

Best regards,

[1] https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern
[2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Working around "Can't compile test sources when main sources are missing a module descriptor"

2023-07-12 Thread Ceki Gülcü 


Hi Mark,

I ran into a similar problem today, July 12th.

In the logback project in order to test support for jigsaw/jpms in
maven-module 'x', we create a maven-module called x-blackbox. The
x-blackbox module contains junit5 tests under src/test/java and without
a src/main folder. This works nicely.

I have tried to do the same for the jul-to-slf4j module in slf4j. Thus,
I have created jul-to-slf4j-bloackbox module following the same recipe
as in the logback project.

To my astonishment this resulted in the following error:

Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile
failed: Can't compile test sources when main sources are missing a
module descriptor

I have tried fixing the problem by tweaking plugin and jdk versions to
no avail.  However, as far as I can tell, the only significant
difference between slf4j and logback is that slf4j uses junit4 and
logback uses junit5. Moving jul-to-slf4j-bloackbox module into a
distinct project and using junit 5 fixed the issue.

It seems to me that moving to Junit 5 is the critical element.

WARNING: The assertion above is speculative as I have not tried to
debunk said assertion.

Best regards,

ps. I did not have time to read
   https://github.com/junit-team/junit5/discussions/3370

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 6/29/2023 7:02 PM, Mark Raynsford wrote:
> (Re-sent using correct address!)
> 
> Hello!
> 
> I recently started a discussion thread on the JUnit 5 repos detailing a
> problem I'd been running into on a lot of projects:
> 
>   https://github.com/junit-team/junit5/discussions/3370
> 
> Long story short: In my projects, for various reasons, I put all of the
> tests in one module rather than having a src/test/java in each. This
> works fine, except for the fact that I have to maintain duplicate module
> descriptors in the src/main/java and src/main/test directories of the
> *.tests module, and I also have to maintain a shadow package hierarchy
> in src/main/java filled with empty classes (one for each exported
> package).
> 
> I'm about to start experimenting with putting test sources in
> src/main/java in the *.tests module, but I'm slightly nervous about
> doing this. It's quite an obvious divergence from Maven's conventions
> (although arguably putting all tests in a *.tests module might be
> considered one too [although the conventions were chosen before
> Java platform modules existed!]). I'm not clear on how all of the tools
> might misbehave if tests aren't in the source directory they're expected
> to be in.
> 
> I realized I'm really only doing this because the Maven Compiler plugin
> produces the error above if I don't have module descriptors in both
> directories:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile
> (default-testCompile) on project com.io7m.idstore.tests: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0:testCompile
> failed: Can't compile test sources when main sources are missing a
> module descriptor -> [Help 1]
> 
> Is there perhaps a better way to get the Compiler plugin to ignore
> src/main/java and just compile the tests?
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: BOM files referencing optional dependencies

2023-06-17 Thread Ceki Gülcü 



On 6/17/2023 9:32 PM, Ceki Gülcü wrote:
> 
> Hello,
> 
> Is it considered good practice to reference optional dependencies in BOM
> files?

My question is probably silly as BOM files are reserved for declaring
artifacts a project builds itself and not for dependencies, optional or
otherwise.


-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

BOM files referencing optional dependencies

2023-06-17 Thread Ceki Gülcü 


Hello,

Is it considered good practice to reference optional dependencies in BOM
files?

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Modular path vs. class path determination

2022-10-17 Thread Ceki Gülcü 


Hello Martin, Olivier,

Since I posted on this thread, I have abandoned the idea of integration
testing in the same Maven module. Instead, for module X, white-box
testing is still done within X/src/test/ and integration testing done in
a new and separate module X-blackbox which is also Jigsaw/JPMS modular.

This approach is a lot less painful than in-single-module testing.

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 10/17/2022 1:27 PM, Martin Desruisseaux wrote:
> Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
> 
>> I wanted to have some opinions on what sort of configurations we could
>> add but this didn't get much attention :)
>> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
>> really cares of jpms...
>>
> On my side I do care a lot about JPMS. But I got the feeling that Maven
> model is not well suited to JPMS, which caused me to stop following JPMS
> issues on Maven and look for other build solution.
> 
> The difficulty I have with JPMS in Maven is that I would like to break
> the "one Maven module = one JPMS module" relationship. Instead I would
> like "one Maven module = one compilation unit", i.e. a single call to
> javac, javadoc or other java tools, which may itself comprise many JPMS
> module.
> 
>     Martin
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Modular path vs. class path determination

2022-09-30 Thread Ceki Gülcü 

Hello all,

The logback is attempting to migrate to Junit 5. As a consequence of
this migration, a handful of tests that were previously successful, now
fail.

For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest
recently failed with the following error:

java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException

During surefire execution, the j.m.i.AddressException class is not
found. It is part of jakarta-mail.jar. I believe this artifact is on the
module path but somehow is not resolved.

Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to
help. Don't ask me why...

I am also puzzled by the fact that many JMPS modularized artifacts are
placed on the class path instead of the module path when the tests are run.

Anyway, I think I may have stumbled upon a bug in Maven or the surefire
plugin. Indeed, when I run mvn install from within the logback-classic
module, the DilutedSMTPAppenderTest mentioned above succeeds.

However, when I run it as

mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest

the test fails with the following exception

[ERROR]
ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy
 Time elapsed: 0.001 s  <<< ERROR!
java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
at
ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)

[cut]...
Caused by: java.lang.ClassNotFoundException:
jakarta.mail.internet.AddressException
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 74 more


Comparing the command line of the two executions, the 'mvn install'
execution has jakarta-mail-api on the module-path, whereas the 'mvn test
-D=..." has jakarta-mail-api on the class-path.

If you wish to confirm this, I have created tag 'possible_mvn_issue'
in the logback repository on github .

  https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue

Let me know if this merits the creation of a Jira issue.

Your feedback would be most appreciated.

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch--module-path
"C:\\home\\buzz\\logback\\logback-classic\\target\\classes;
C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\logback\\logback-core\\1.4.2-SNAPSHOT\\logback-core-1.4.2-SNAPSHOT.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\slf4j-api\\2.0.1\\slf4j-api-2.0.1.jar;
C:\\Users\\buzz\\.m2\\repository\\jakarta\\mail\\jakarta.mail-api\\2.1.0\\jakarta.mail-api-2.1.0.jar;
C:\\Users\\buzz\\.m2\\repository\\jakarta\\activation\\jakarta.activation-api\\2.1.0\\jakarta.activation-api-2.1.0.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\eclipse\\angus\\angus-mail\\1.0.0\\angus-mail-1.0.0.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\eclipse\\angus\\angus-activation\\1.0.0\\angus-activation-1.0.0.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\codehaus\\janino\\janino\\3.1.9-SNAPSHOT\\janino-3.1.9-SNAPSHOT.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\codehaus\\janino\\commons-compiler\\3.1.9-SNAPSHOT\\commons-compiler-3.1.9-SNAPSHOT.jar;
C:\\Users\\buzz\\.m2\\repository\\jakarta\\servlet\\jakarta.servlet-api\\5.0.0\\jakarta.servlet-api-5.0.0.jar"
--class-path
"C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-booter\\3.0.0-M7\\surefire-booter-3.0.0-M7.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-api\\3.0.0-M7\\surefire-api-3.0.0-M7.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-logger-api\\3.0.0-M7\\surefire-logger-api-3.0.0-M7.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-shared-utils\\3.0.0-M7\\surefire-shared-utils-3.0.0-M7.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire-extensions-spi\\3.0.0-M7\\surefire-extensions-spi-3.0.0-M7.jar;
C:\\home\\buzz\\logback\\logback-classic\\target\\test-classes;
C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\slf4j-api\\2.0.1\\slf4j-api-2.0.1-tests.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\log4j-over-slf4j\\2.0.1\\log4j-over-slf4j-2.0.1.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\slf4j\\jul-to-slf4j\\2.0.1\\jul-to-slf4j-2.0.1.jar;
C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\reload4j\\reload4j\\1.2.18.4\\reload4j-1.2.18.4.jar;
C:\\Users\\buzz\\.m2\\repository\\org\\dom4j\\dom4j\\2.0.3\\dom4j-2.0.3.jar;
C:\\Users\\buzz\\.m2\\repository\\ch\\qos\\logback\\logback-core\\1.4.2-SNAPSHOT\\logback-core-1.4.2-SNAPSHOT-tests.jar;
C:\\Users\\buzz\\.m2\\rep

Re: Race condition in slf4j-simple

2021-07-08 Thread Ceki 

Hi Tibor,

Your analysis makes sense. As SimpleLogger acts as an appender as found 
in log4j/logback backends, SimpleLogger should cater for concurrent 
access with some sort of synchronization. It currently does not.


Please create a jira issue for this problem.

Best regards,
--
Ceki Gülcü

On 08.07.2021 15:23, Tibor Digaňa wrote:

Hi Ceki,

We have observed a strange behavior of the logger slf4j-simple when two 
or more parallel Maven modules log the exceptions and the messages.


It produces corrupted lines in the log and they are partially mixed with 
other lines.

The lines look like this and they are obviously not expected in the log.

[ERROR] R] *.util.json.formatter.JsonFormatterTest
  [ERROR] Process Exit Code: 0
[ERROR] *.util.json.formatter.JsonFormatterTest


After our analysis we found the place in SLF4J code which seems to be 
the root cause.


The method [1] is a critical section and must be synchronized with a 
singleton lock which avoids reordering of the nested method calls across 
multiple Threads. Without it, the normal messages and stack trace may 
mix especially if two parallel Maven modules print the stacktrace.


[1]: 
https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243 
<https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243>


Pls analyse the class SimpleLogger.java and answer with your opinion 
about this issue and a proposal with the fix.
If there are more other critical sections which need to have some 
concurrency treatments, we can talk about it in this mailing list.


--
Cheers
Tibor




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Loading groovy as a Jigsaw auto-module

2017-12-03 Thread Ceki Gulcu 


Hi Robert,

I found running the command

 mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve \ 


-DexcludeTransitive

to be highly informative. Thank you.

Apparently, there were issues in the way I edited MANIFEST.MF file in
groovy-2.4.13.jar. I won't bore you with the details. Anyhow, I reverted 
to the original jar file, ran m-dependency-p and got:


Can't extract module name from groovy-2.4.13.jar: Provider class groovy 
not in module


After some investigation, it appeared that this is due to the contents 
of the file

 META-INF/services/org.codehaus.groovy.source.Extensions

Removing this file solves the problem at least as far as Jigsaw module 
resolution is concerned. Running m-dependency-p, I see:


o.c.groovy:groovy:jar:2.4.13:compile (optional)  -- module groovy (auto)

Again, thank you very much for your help,

--
Ceki

On 03.12.2017 14:06, Robert Scholte wrote:

On Sun, 03 Dec 2017 13:40:51 +0100, Ceki Gulcu  wrote:



Hello all,

The logback project, more specifically logback-classic, offers the 
possibility of configuration via a script written in Groovy. Thus, 
logback-classic has source files written in Java and a few source 
files in Groovy.


While attempting to (Jigsaw) modularize the logback project, I first 
tried to declare "requires static groovy" in logback-classic's 
module-info.java file but the compiler was unable to load 
groovy-2.4.13.jar as an auto-module.


To get the ball rolling, I had to resort to the "--add-reads 
ch.qos.logback.classic=ALL-UNNAMED" compiler directive. This is very 
unsatisfactory.


On twitter, Cédric Champeau‏ suggested manually editing MANIFEST.MF in 
groovy-2.4.13.jar adding "Automatic-Module-Name: groovylang". I edited 
the file and also declared "requires static groovylang" in 
logback-classic's module-info.java. However, this did not help and I 
still get "module not found: groovylang"


Building with maven's -X option, I see that  groovy-2.4.13.jar ends up 
on the compiler's class path instead of the module path.


Still on twitter, Robert Scolte responded that m-compiler-p only puts 
the jars on the module path if they are referred to by a requires 
statement anywhere in the module descriptors tree. The rest ends up on 
the classpath.


I am assuming here that "module descriptors tree" refers to 
module-info.java files and not dependency declarations in pom.xml 
files. Thus, if I understand correctly m-compiler-p parses 
module-info.java files before invoking javac. Really?


Yes, really. In fact it goes beyond that. It also parses 
module-info.class, reads the MANIFEST.MF for Automatic-Module-Name and 
uses some specific Java9 code to extract the automatic module name from 
the jarfile.


The code for this can be found at 
https://github.com/codehaus-plexus/plexus-languages/tree/master/plexus-java


If you want to know the module names per jar, please run (with JAVA_HOME 
pointing to /path/to/java9):
mvn compile 
org.apache.maven.plugins:maven-dependency-plugin:3.0.2:resolve 
-DexcludeTransitive


thanks,
Robert



Best regards,

--
Ceki Gülcü


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Loading groovy as a Jigsaw auto-module

2017-12-03 Thread Ceki Gulcu 


Hello all,

The logback project, more specifically logback-classic, offers the 
possibility of configuration via a script written in Groovy. Thus, 
logback-classic has source files written in Java and a few source files 
in Groovy.


While attempting to (Jigsaw) modularize the logback project, I first 
tried to declare "requires static groovy" in logback-classic's 
module-info.java file but the compiler was unable to load 
groovy-2.4.13.jar as an auto-module.


To get the ball rolling, I had to resort to the "--add-reads 
ch.qos.logback.classic=ALL-UNNAMED" compiler directive. This is very 
unsatisfactory.


On twitter, Cédric Champeau‏ suggested manually editing MANIFEST.MF in 
groovy-2.4.13.jar adding "Automatic-Module-Name: groovylang". I edited 
the file and also declared "requires static groovylang" in 
logback-classic's module-info.java. However, this did not help and I 
still get "module not found: groovylang"


Building with maven's -X option, I see that  groovy-2.4.13.jar ends up 
on the compiler's class path instead of the module path.


Still on twitter, Robert Scolte responded that m-compiler-p only puts 
the jars on the module path if they are referred to by a requires 
statement anywhere in the module descriptors tree. The rest ends up on 
the classpath.


I am assuming here that "module descriptors tree" refers to 
module-info.java files and not dependency declarations in pom.xml files. 
Thus, if I understand correctly m-compiler-p parses module-info.java 
files before invoking javac. Really?


Best regards,

--
Ceki Gülcü


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: bug? strange resolution of commons-logging dependency

2009-07-01 Thread Ceki Gulcu 



Using Maven 2.2.0, the behavior remains the same as with Maven
2.0.9. Moreover, if you remove the dependency on
net.sf.ehcache:ehcache:1.6.0 from the pom file for "htmlunitbug", then
the test passes (with the original pom files for hibernate-ehcache
hibernate-parent referencing commons-logging version 99).

In summary, there is strong evidence that common-logging 99 is not the
culprit here.

Can it be that the various dependencies, some in test scope and some
in runtime scope, are confusing Maven's dependency resolution
mechanism?


Ceki Gulcu wrote:



Lucas Bergman wrote:

Dennis Lundberg wrote:



That is your problem. What this does is mess the dependency-tree. It
removes commons-logging from the dependency tree because that
version "99.0-..." is larger than the latest current release of
commons-logging.  The "99.0-..." version should *never ever* reach
end users. It can *only* be used by internal project.


Thanks for the input.  Are you saying that the dependency of the
hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
I'm sympathetic to that view, but I just want to be sure.  To be sure,
it seems foolish for the Hibernate developers to put something like
this in a library's POM, since it would seem to impose their kludge
on the programmer using the library.

Of course, we fixed our particular problem by adding an 
for commons-logging from our hibernate-ehcache dependency.


Hello,

I was able to reproduce the dependency resolution issue with the help
of a small test project called "htmlunitbug" as supplied by Lucas
Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".

However, I appears that commons-logging version 99 is not the culprit
as it is *not* involved in the resolution of commons-logging within
"htmlunitbug", the test application supplied by Lucas. At least, the
output of "mvn -X test" never mentions version 99. As further proof, I
have removed any references to version 99 in the pom files for
hibernate-ehcache and hibernate-parent, with the same results.


Just as importantly, the pom files for hibernate-ehcache and
hibernate-parent reference commons-logging version 99 in *scope*
*test*. Given that the test scope is not transitive, and given that
even after removing references to version 99, "htmlunitbug" still
fails, it would be premature to incriminate version 99. Something else
is afoot here.

[1] http://tinyurl.com/nfw332



-- Lucas




--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: bug? strange resolution of commons-logging dependency

2009-07-01 Thread Ceki Gulcu 


I forgot to mention that my tests were conducted using Maven 2.0.9. I will redo 
the tests with Maven 2.2.0.


Ceki Gulcu wrote:



Lucas Bergman wrote:

Dennis Lundberg wrote:



That is your problem. What this does is mess the dependency-tree. It
removes commons-logging from the dependency tree because that
version "99.0-..." is larger than the latest current release of
commons-logging.  The "99.0-..." version should *never ever* reach
end users. It can *only* be used by internal project.


Thanks for the input.  Are you saying that the dependency of the
hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
I'm sympathetic to that view, but I just want to be sure.  To be sure,
it seems foolish for the Hibernate developers to put something like
this in a library's POM, since it would seem to impose their kludge
on the programmer using the library.

Of course, we fixed our particular problem by adding an 
for commons-logging from our hibernate-ehcache dependency.


Hello,

I was able to reproduce the dependency resolution issue with the help
of a small test project called "htmlunitbug" as supplied by Lucas
Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".

However, I appears that commons-logging version 99 is not the culprit
as it is *not* involved in the resolution of commons-logging within
"htmlunitbug", the test application supplied by Lucas. At least, the
output of "mvn -X test" never mentions version 99. As further proof, I
have removed any references to version 99 in the pom files for
hibernate-ehcache and hibernate-parent, with the same results.


Just as importantly, the pom files for hibernate-ehcache and
hibernate-parent reference commons-logging version 99 in *scope*
*test*. Given that the test scope is not transitive, and given that
even after removing references to version 99, "htmlunitbug" still
fails, it would be premature to incriminate version 99. Something else
is afoot here.

[1] http://tinyurl.com/nfw332



-- Lucas




--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: bug? strange resolution of commons-logging dependency

2009-07-01 Thread Ceki Gulcu 



Lucas Bergman wrote:

Dennis Lundberg wrote:



That is your problem. What this does is mess the dependency-tree. It
removes commons-logging from the dependency tree because that
version "99.0-..." is larger than the latest current release of
commons-logging.  The "99.0-..." version should *never ever* reach
end users. It can *only* be used by internal project.


Thanks for the input.  Are you saying that the dependency of the
hibernate-ehcache POM on commons-logging 99.0-does-not-exist is a bug?
I'm sympathetic to that view, but I just want to be sure.  To be sure,
it seems foolish for the Hibernate developers to put something like
this in a library's POM, since it would seem to impose their kludge
on the programmer using the library.

Of course, we fixed our particular problem by adding an 
for commons-logging from our hibernate-ehcache dependency.


Hello,

I was able to reproduce the dependency resolution issue with the help
of a small test project called "htmlunitbug" as supplied by Lucas
Bergman in his message [1] dated "26 Jun 2009 11:46:32 -0500".

However, I appears that commons-logging version 99 is not the culprit
as it is *not* involved in the resolution of commons-logging within
"htmlunitbug", the test application supplied by Lucas. At least, the
output of "mvn -X test" never mentions version 99. As further proof, I
have removed any references to version 99 in the pom files for
hibernate-ehcache and hibernate-parent, with the same results.


Just as importantly, the pom files for hibernate-ehcache and
hibernate-parent reference commons-logging version 99 in *scope*
*test*. Given that the test scope is not transitive, and given that
even after removing references to version 99, "htmlunitbug" still
fails, it would be premature to incriminate version 99. Something else
is afoot here.

[1] http://tinyurl.com/nfw332



-- Lucas


--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: bug? strange resolution of commons-logging dependency

2009-06-30 Thread Ceki Gulcu 



Jörg Schaible wrote:


You've been right, I should have read your question closer. See Dennis'
answer. Actually there was an attempt to release an official empty
commons-logging at Apache recently and it was tunred down exactly because
we could foresee this problem you're facing now :-/


Note that we wanted to release version 0.0-EMPTY, not version 99. One
could argue that releasing 0.0-EMPTY could have prevented this issue
from occurring.


- Jörg


--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-29 Thread Ceki Gulcu 

Olivier,

Since projects A and B seem to be just artifacts, I am still wondering
why projects A and B need a configuration file for logging. If it is
for testing purposes, why not use logback-text.xml and place it under
/src/test/resources/ directory?


--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Best practices for avoiding duplicate configuration files

2009-04-29 Thread Ceki Gulcu 


> About slf4j complaining about multiple configuration files present in
> the CP, I suppose it must be possible to overcome this
> complaining. But what is annoying to me is that these redundant files
> are included when they should not, because from a logical point of
> view project C does not need the config files of project A or B. Even
> if I get slf4j to ignore them, I would consider that a workaround
> rather than a solution.

This is somewhat off topic, but since the question has been raised in
this forum, allow me to explain.

First, it is not SLF4J which is complaining, it's logback-classic
which Olivier indicated he was using.  During automatic
initialization, if and when logback-classic sees two or more
configuration files on the class path, it emits a warning:
"Hey, I see N different copies of logback.xml on your class path. The
copies are located at path1, path2, ..., pathN. I am picking the first
one." (It's just a warning...)

Lobgack-classic is noticing an ambiguity and informing the user.

HTH,

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: release maven-ear-plugin

2006-12-20 Thread ceki 
Thanks Tom. I've just seen  the vote in progress  [1] on the maven dev 
list. 

[1] http://marc.theaimsgroup.com/?t=11662974761&r=1&w=2

"Tom Huybrechts" <[EMAIL PROTECTED]> wrote on 19.12.2006 16:28:15:

> the vote for releasing the ear plugin is ongoing
> just a little more patience...
> 
> On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > I am unaware (as in oblivious) of possible considerations preventing 
the
> > release of the ear plug-in. However, looking through my peephole, I 
can
> > say that our team is eagerly waiting for its release. In particular
> > because the availability of the ear plug-in as a snapshot does not do 
us
> > much good because our repository proxy prevents our users from 
accessing
> > snapshot releases.
> >
> > Many thanks in advance,


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

release maven-ear-plugin

2006-12-19 Thread ceki 
Hello all,

I am unaware (as in oblivious) of possible considerations preventing the 
release of the ear plug-in. However, looking through my peephole, I can 
say that our team is eagerly waiting for its release. In particular 
because the availability of the ear plug-in as a snapshot does not do us 
much good because our repository proxy prevents our users from accessing 
snapshot releases.

Many thanks in advance, 

 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

Re: Re: Re: Dependency scopes

2006-08-30 Thread ceki 
Thanks!


















"Martijn Dashorst" <[EMAIL PROTECTED]>
 
 
30.08.2006 16:17 
Please respond to
"Maven Users List" 



To
"Maven Users List" 
cc

Subject
Re: Re: Re: Dependency scopes



 Reviewed by Category 


Yes, but "runtime classpath" != "runtime scope"

runtime classpath == union(compile, runtime scope)

Martijn

On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> So, this means that war and ear plug-ins reference the runtime classpath
> instead of say compile or test. Correct?
>
> "Martijn Dashorst" <[EMAIL PROTECTED]> wrote on 30.08.2006
> 15:37:56:
>
> > No, but maven is also used to create war, ear and other distribution
> > packages. These packages need those actual runtime dependencies inside
> > them.
> >
> > So for testing I need junit, but not at runtime -> test scope
> > For testing I may not have a need for oracle-jdbc (using hsqldb for
> > unittests), but at runtime I will (if deploying on an oracle database)
> > -> runtime scope.
> >
> > For testing I need the interfaces for the servlet api, but those
> > interfaces are available at runtiime in the tomcat server for my web
> > application. So the servlet api JAR (javax.servlet-2.3.jar) is needed
> > for compile *and* test, but doesn't need to go into the WAR archive ->
> > provided scope.
> >
> > hth.
> >
> > Martijn
>
>
>  DISCLAIMER 
> This message is intended only for use by the person
> to whom it is addressed. It may contain information
> that is privileged and confidential. Its content does
> not constitute a formal commitment by Lombard
> Odier Darier Hentsch Group and any of its affiliates.
> If you are not the intended recipient of this message,
> kindly notify the sender immediately and destroy this
> message. Thank You.
> *
>
>


-- 
Download Wicket 1.2.2 now! New Ajax components: Tree, TreeTable and 
ModalWindow
-- http://wicketframework.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

Re: Re: Dependency scopes

2006-08-30 Thread ceki 
So, this means that war and ear plug-ins reference the runtime classpath 
instead of say compile or test. Correct?

"Martijn Dashorst" <[EMAIL PROTECTED]> wrote on 30.08.2006 
15:37:56:

> No, but maven is also used to create war, ear and other distribution
> packages. These packages need those actual runtime dependencies inside
> them.
> 
> So for testing I need junit, but not at runtime -> test scope
> For testing I may not have a need for oracle-jdbc (using hsqldb for
> unittests), but at runtime I will (if deploying on an oracle database)
> -> runtime scope.
> 
> For testing I need the interfaces for the servlet api, but those
> interfaces are available at runtiime in the tomcat server for my web
> application. So the servlet api JAR (javax.servlet-2.3.jar) is needed
> for compile *and* test, but doesn't need to go into the WAR archive ->
> provided scope.
> 
> hth.
> 
> Martijn


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

Re: Dependency scopes

2006-08-30 Thread ceki 
> On 8/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> > The difference between the runtime and test scopes is also not very
> > clear to me.

"Nick Veys" <[EMAIL PROTECTED]> wrote on 17.08.2006 06:16:40:

> This was already answered, but the test dependencies aren't needed for
> "normal" runtime, so they are left out.  It allows you to pull in a
> test harness, or mock libraries during your tests but leave that out
> for "real" execution or packaging.

While I understand that certain libs may be required at compile time
but not compile time, I don't see what "normal" runtime means in terms
of Maven. Maven is a build system, it does not execute your
applications, so how can it have a runtime classpath? There is no
such thing as runtime Maven or is there? 


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

Re: Dependency scopes

2006-08-17 Thread ceki 
Nick,

I very much appreciate your response. I wish the article of reference
on subject, namely, "Introduction to the Dependency Mechanism" was
somewhat more precise. Perhaps the maintainers of the document could
have another look at it. Is filing a bug report appropriate?


"Nick Veys" <[EMAIL PROTECTED]> wrote on 17.08.2006 06:16:40:

> On 8/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The said article mentions the notion of "runtime classpath." While I
> > can see what compile and test classpaths mean, I fail to understand
> > what a runtime classpath is, in particular how it differs from the
> > test classpath.
> 
> Think of Runtime as somewhat of an optimization for the build process.
>  The jar itself is not needed to compile the code as it has no direct
> dependency on it, though the code itself still needs this jar to
> execute, as such it will travel along transitively in case it is
> needed down the line, and will also be included in the test scope as
> it may be called upon since the code has a runtime dependency on it.
> 
> > Moreover, the article defines  "provided scope" as follows:
> >
> >  provided - this is much like compile, but indicates you expect theJDK
> > or a container to provide it.  It is only available on the 
compilation
> >classpath, and is not transitive.
> >
> > However, in a small project I've created to test dependency scopes, it
> > seems that a dependency declared with the "provided" scope is
> > available when compiling the source, compiling the test cases as well
> > as when running them (the test cases). Thus, it looks like the
> > provided scope is the same as the compile scope, except that the
> > provided scope is not transitive.
> 
> The documentation may be slightly wrong, as you experienced the
> provided scope jars are available to tests (at least in my
> experience), though I believe only that local project tests, as you
> have no transitivity (I may be wrong here, corrections?).  Provided is
> very much like compile w/o transitivity.  It is assumed that your
> container or system will provide this jar when needed.
> 
> > The difference between the runtime and test scopes is also not very
> > clear to me.
> 
> This was already answered, but the test dependencies aren't needed for
> "normal" runtime, so they are left out.  It allows you to pull in a
> test harness, or mock libraries during your tests but leave that out
> for "real" execution or packaging.
> 
> > The small table which illustrates the effects of scopes on
> > transitivity is not easy to grok. In particular, the explanation
> > (quoted below) preceding the table does not define the direction of
> > any of the dependencies.
> 
> I'm guessing it's trying to tell you the precidence of dependencies
> when the same dependency is referenced in multiple scopes in one
> project, but you're right, the preceeding paragraph is not exactly
> clear in what it is talking about.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*

Re: Dependency scopes

2006-08-16 Thread ceki 
Mike, thank you for taking the time to respond. My question had
several parts and your response relates to the difference between
runtime scope and the test scope. I wonder if someone would care to
respond to the remaining parts.

Mike Perham <[EMAIL PROTECTED]> wrote on 15.08.2006 18:04:17:

> 
> Runtime - contains things that you don't need at compile but you do need
> for your app to actually run.  You might compile against JMS but require
> ActiveMQ at runtime (i.e. a JMS engine).
> Test - contains test specific classes.  Junit, mocks, a lightweight
> database like HSQLDB, etc.
> 
> [EMAIL PROTECTED] wrote on 08/15/2006 08:32:26 AM:
> 
> > Hello,
> >
> > I would like to ask a question regarding dependency scopes in
> > Maven2. After reading the article "Introduction to the Dependency
> > Mechanism" [1], I've got several questions that may have been answered
> > previously. I apologize in advance if that is the case.
> >
> > The said article mentions the notion of "runtime classpath." While I
> > can see what compile and test classpaths mean, I fail to understand
> > what a runtime classpath is, in particular how it differs from the
> > test classpath.
> >
> > Moreover, the article defines  "provided scope" as follows:
> >
> >  provided - this is much like compile, but indicates you expect theJDK
> > or a container to provide it.  It is only available on the
> compilation
> >classpath, and is not transitive.
> >
> > However, in a small project I've created to test dependency scopes, it
> > seems that a dependency declared with the "provided" scope is
> > available when compiling the source, compiling the test cases as well
> > as when running them (the test cases). Thus, it looks like the
> > provided scope is the same as the compile scope, except that the
> > provided scope is not transitive.
> >
> > The difference between the runtime and test scopes is also not very
> > clear to me.
> >
> > The small table which illustrates the effects of scopes on
> > transitivity is not easy to grok. In particular, the explanation
> > (quoted below) preceding the table does not define the direction of
> > any of the dependencies.
> >
> > 
> > Each of the scopes affects transitive dependencies in different ways,
> > as is demonstrated in the table below. If a dependency is set to the
> > scope in the left column, dependencies with the scope across the top
> > row will result in a dependency in the main project with the scope
> > listed at the intersection. If no scope is listed, it means the
> > dependency will be omitted.
> > 
> >
> > Your enlightenment would be greatly appreciated,
> >
> > [1]
> > http://maven.apache.org/guides/introduction/introduction-to-
> > dependency-mechanism.html


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dependency scopes

2006-08-15 Thread ceki 
Hello,

I would like to ask a question regarding dependency scopes in
Maven2. After reading the article "Introduction to the Dependency
Mechanism" [1], I've got several questions that may have been answered
previously. I apologize in advance if that is the case.

The said article mentions the notion of "runtime classpath." While I
can see what compile and test classpaths mean, I fail to understand
what a runtime classpath is, in particular how it differs from the
test classpath.

Moreover, the article defines  "provided scope" as follows:

 provided - this is much like compile, but indicates you expect theJDK
or a container to provide it.  It is only available on the compilation
   classpath, and is not transitive.

However, in a small project I've created to test dependency scopes, it
seems that a dependency declared with the "provided" scope is
available when compiling the source, compiling the test cases as well
as when running them (the test cases). Thus, it looks like the
provided scope is the same as the compile scope, except that the
provided scope is not transitive.

The difference between the runtime and test scopes is also not very
clear to me.

The small table which illustrates the effects of scopes on
transitivity is not easy to grok. In particular, the explanation
(quoted below) preceding the table does not define the direction of
any of the dependencies.


Each of the scopes affects transitive dependencies in different ways,
as is demonstrated in the table below. If a dependency is set to the
scope in the left column, dependencies with the scope across the top
row will result in a dependency in the main project with the scope
listed at the intersection. If no scope is listed, it means the
dependency will be omitted.


Your enlightenment would be greatly appreciated,

[1] 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html


 DISCLAIMER 
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard
Odier Darier Hentsch Group and any of its affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Utility to create upload bundles

2006-07-28 Thread Ceki Gülcü 

At 07:26 AM 7/22/2006, Tim Kettler wrote:
Will see that I find a home for it. But this will probably take abaout a 
week or two.


Ivo Limmen schrieb:

Sounds like a very usefull tool. I recently had the same problem, this would
have been a great help.
On 7/20/06, Tim Kettler <[EMAIL PROTECTED]> wrote:


Hi,

I recently had to add a bunch of 3d-party artifacts to our repository and
creating the
poms with all the transitive dependencies by hand was a major pain in the
a**. So I sat
down and wrote a little tool that takes a couple of jars as its input,
analyzes the
dependencies, generates the poms and writes upload bundles for each
artifact. It has a
rudimentary GUI that allows basic editing of the generated information for
the poms.

The tool is currently not very polished and has much room for improvements
but it is
useful and works for me. If there is interest in the community I will look
for a place
where I can make the tool available to the public.

-Tim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Ceki Gülcü
http://ceki.blogspot.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to be compatible with both M1 and M2 repos

2006-07-16 Thread Ceki Gülcü 


Hello,

An slf4j user recently observed that he could not get maven2 to include 
slf4j as a dependency. He traced the cause to the incompatibility between 
maven1 and maven2 pom files. I suspect the problem is due to the fact that 
we export pom.xml files using the maven1 format.


Is there a way to upload dependencies on ibiblio so that they are 
compatible with both maven1 and maven2?


Thank you for your input,



--
Ceki Gülcü
http://ceki.blogspot.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [m2] jetty6 plugin & log4j

2006-02-18 Thread Ceki Gülcü 

David,

I am not very familiar with maven-jetty6-plugin. However, from what
you describe, it looks like jetty is using SLF4J's SimpleLogger
binding instead of its log4j binding. This is attested by the
following line:

 2 [main] INFO org.mortbay.log - Logging to
[EMAIL PROTECTED] via org.mortbay.log.Slf4jLog

When Jetty uses SLF4J's SimpleLogger binding log4j configuration files
have no affect as log4j is not used by Jetty. You need to instruct
Maven or Jetty to use the correct binding. For more details on SLF4J
bindings please see http://www.slf4j.org.

> Hello all -
>
> Could anyone help me to understand how to change the log level that
> the maven-jetty6-plugin uses?  I would like to put debug logging
> statements into my code, but then I can't seem to figure out how to
> get the plugin to change from its default info level.  I would also
> like to set different logging levels on package name.
>
> Note also that I am using the Spring framework.  So first I tried
> using its Log4jConfigListener web util class in web.xml and pointing
> it at my log4j.properties file.  Info messages appeared indicating
> that it was alive and had read my configuration:
>
> 929 [main] INFO /myapp - Initializing Log4J from [/Users/davidm/
> dev/myapp/src/main/resources/webapp/WEB-INF/log4j.properties]
>
> But no changes were evident in the logged message, neither in format
> nor level.
>
> Then I found a posting on Gmane that indicated you can give Jetty
> your own log4j.properties file by configuring a systemProperty named
> "log4j.configuration", which I did in pom.xml.  Again, messages
> indicated that Jetty recognized my property setting:
>
> [INFO] Property log4j.configuration=/WEB-INF/log4j.properties was
> set
>
> but nothing seemed to change the way it logs.  In fact, two lines
> later in the log, there is this message:
>
> 2 [main] INFO org.mortbay.log - Logging to
> [EMAIL PROTECTED] via org.mortbay.log.Slf4jLog
>
> Here's my (very simple) log4j.properties file:
>
> log4j.rootLogger=WARN, stdout
>
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c
> {1}:%L - %m%n
>
> log4j.logger.net.sf.hibernate=WARN
> log4j.logger.net.sf.hibernate.type=WARN
> log4j.logger.org.springframework=WARN
>
> I read Jetty's tutorial on logging, but it :
> http://www.mortbay.org/jetty/tut/logging.html
>
> Finally, I gave the "-DDEBUG" and "-DDEBUG_PATTERNS=net.sf.hibernate"
> a shot, but these too seemed to be ignored.
>
> I get the feeling that I am clashing somehow with Jetty's own
> logging.  Can anyone help me unravel this?
>
> Thanks
> --David


--
Ceki Gülcü


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Quickly changing the Maven template

2003-09-23 Thread Ceki Gülcü 
Thank you very much, Dion.

At 08:34 PM 9/21/2003 +1000, [EMAIL PROTECTED] wrote:
It's in the documentation.

See
http://maven.apache.org/reference/plugins/xdoc/faq.html#navigation-images
--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 20/09/2003 05:37:06 AM:

>
> Hello all,
>
> How difficult is it to change the Maven template so that the generated
> project pages contain an extra image?
>
> For an example of what is meant please refer to:
>
> http://jakarta.apache.org
>
> The image for ApacheCon 2003 was added by modifying a template file
> for Anakia.
>
> Is there a similar procedure for doing the same with Maven?
>
> Your answers will be collated and forwarded to the various ASF
> projects using Maven.
>
> TIA,
>
>
> --
> Ceki Gülcü
>
>   For log4j documentation consider "The complete log4j manual"
>   ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>   import org.apache.Facetime;
>   ApacheCon US 2003, 18-21 November http://apachecon.com/
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Quickly changing the Maven template

2003-09-20 Thread Ceki Gülcü 
At 10:40 PM 9/19/2003 -0400, Jason van Zyl wrote:
On Fri, 2003-09-19 at 15:37, Ceki Gülcü wrote:
> Hello all,
>
> How difficult is it to change the Maven template so that the generated
> project pages contain an extra image?
>
> For an example of what is meant please refer to:
>
> http://jakarta.apache.org
Are you asking if we will change the template so that all projects using
Maven advertise ApacheCon? I am assuming not.
No, that is not it.

If you mean for the maven.apache.org site that would be easy enough.
For example, the for the OJB project which uses Maven, Thomas wanted to 
modify the template so all OJB  pages would be affected. However, he did 
not know how to do it. I am just asking whether there is a way  to do 
modify the template and if so, could it be described for the benefit of all 
projects.

--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Quickly changing the Maven template

2003-09-19 Thread Ceki Gülcü 
Hello all,

How difficult is it to change the Maven template so that the generated
project pages contain an extra image?
For an example of what is meant please refer to:

   http://jakarta.apache.org

The image for ApacheCon 2003 was added by modifying a template file
for Anakia.
Is there a similar procedure for doing the same with Maven?

Your answers will be collated and forwarded to the various ASF
projects using Maven.
TIA,

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]