[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-15 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1721284115

   Draft stage until the next SIS release.  We cannot merge until that release. 
 The current draft relies on a local build of their snaphot.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-16 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1722265254

   Best handled by jar exclusions or is there something better we can do w
   restructuring dependencies? We have some flexibility in 3.x to get it
   right.
   
   On Sat, Sep 16, 2023 at 12:53 AM Maxim Solodovnik ***@***.***>
   wrote:
   
   > @tballison  I believe warning from
   > shade:3.5.0:shade have to be addressed before merge:
   >
   > lots of them 
   >
   > [WARNING] log4j-slf4j2-impl-2.20.0.jar, tika-async-cli-3.0.0-SNAPSHOT.jar 
define 13 overlapping classes and resources:
   > [WARNING]   - 
META-INF/maven/org.apache.logging.log4j/log4j-slf4j2-impl/pom.properties
   > [WARNING]   - 
META-INF/maven/org.apache.logging.log4j/log4j-slf4j2-impl/pom.xml
   > [WARNING]   - org.apache.logging.slf4j.Log4jEventBuilder
   > [WARNING]   - org.apache.logging.slf4j.Log4jLogger
   > [WARNING]   - org.apache.logging.slf4j.Log4jLoggerFactory
   > [WARNING]   - org.apache.logging.slf4j.Log4jMDCAdapter
   > [WARNING]   - org.apache.logging.slf4j.Log4jMDCAdapter$1
   > [WARNING]   - 
org.apache.logging.slf4j.Log4jMDCAdapter$ThreadLocalMapOfStacks
   > [WARNING]   - org.apache.logging.slf4j.Log4jMarker
   > [WARNING]   - org.apache.logging.slf4j.Log4jMarkerFactory
   > [WARNING]   - 3 more...
   >
   > [WARNING] jaxb-core-4.0.3.jar, tika-server-core-3.0.0-SNAPSHOT.jar define 
128 overlapping classes and resources:
   > [WARNING]   - META-INF/maven/org.glassfish.jaxb/jaxb-core/pom.properties
   > [WARNING]   - META-INF/maven/org.glassfish.jaxb/jaxb-core/pom.xml
   > [WARNING]   - org.glassfish.jaxb.core.Locatable
   > [WARNING]   - org.glassfish.jaxb.core.StackHelper
   > [WARNING]   - org.glassfish.jaxb.core.Utils
   > [WARNING]   - org.glassfish.jaxb.core.WhiteSpaceProcessor
   > [WARNING]   - org.glassfish.jaxb.core.annotation.OverrideAnnotationOf
   > [WARNING]   - org.glassfish.jaxb.core.annotation.XmlIsSet
   > [WARNING]   - org.glassfish.jaxb.core.annotation.XmlLocation
   > [WARNING]   - org.glassfish.jaxb.core.api.ErrorListener
   > [WARNING]   - 118 more...
   >
   >
   > As well as bundle inclusion list from here:
   > tika-bundles/tika-bundle-standard/pom.xml
   >
   > —
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   > You are receiving this because you were mentioned.Message ID:
   > ***@***.***>
   >
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-18 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1723300367

   > Note that uber JAR files created by Maven Shade Plugin may not work 
anymore in a JPMS world. Currently, the plugin seems to workaround by removing 
all `module-info.class` files. It works if the dependencies duplicate all their 
services declarations into `META-INF/services/` for compatibility with the old 
world. Apache SIS and Derby for instances do that. But any library could decide 
to stop doing this duplication in some future version, because it makes more 
difficult to use some features that are unique to `module-info`. It may be 
safer to progressively move away from uber JAR if possible.
   
   Do you have recommendations for first steps in this direction?  We have some 
flexibility with 3.x.  How do we start?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-18 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1723394374

   > I was working locally for myself on the migration of Tika from javax to 
jakarta before I found out this PR and now have a few comments/hints, 
especially WRT to `tika-parent/pom.xml`:
   > 
   > 1. The different CXF dependencies could be replaced by the import BOM.
   > 
   > 2. The same mechanism could be used for SLF4J that also offers a BOM; 
no need to manage three dependencies.
   > 
   > 3. On my tests I had to add an exclusion for `xml-apis:xml-apis` in 
the dependency manangement section for `xerces:xercesImpl`. Otherwise I get 
tons of errors in my IDE (Eclipse) because the package `org.xml.sax` is 
accessible from more than one module: ``, `java.xml`. Haven't you seen 
them too?
   > 
   > 4. Running `mvn verify` fails in Tika server core:
   > 
   > 
   > ```
   > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
0.054 s <<< FAILURE! -- in org.apache.tika.server.core.StackTraceTest
   > [ERROR] org.apache.tika.server.core.StackTraceTest.testEmptyParser -- Time 
elapsed: 0.006 s <<< FAILURE!
   > org.opentest4j.AssertionFailedError: bad type: /tika ==> expected: <200> 
but was: <500>
   >at 
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
   > (...)
   > ```
   > 
   Thank you!  Adding the above shortly.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-18 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1723395686

   > 
   > 4. Running `mvn verify` fails in Tika server core:
   > 
   > 
   > ```
   > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
0.054 s <<< FAILURE! -- in org.apache.tika.server.core.StackTraceTest
   > [ERROR] org.apache.tika.server.core.StackTraceTest.testEmptyParser -- Time 
elapsed: 0.006 s <<< FAILURE!
   > org.opentest4j.AssertionFailedError: bad type: /tika ==> expected: <200> 
but was: <500>
   >at 
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
   > (...)
   > ```
   > 
   No idea. Let me see if I can reproduce this locally and figure out what's 
going on. Thank you.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-18 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1723398386

   Separately, we're doing a better job of moving most dependencies into 
dependencyManagement and using boms.  Should we get rid of the version numbers 
in the  elements and just control the versions via the boms where 
possible?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [tika] tballison commented on pull request #1345: TIKA-3948 -- migrate from javax -> jakarta

2023-09-19 Thread via GitHub


tballison commented on PR #1345:
URL: https://github.com/apache/tika/pull/1345#issuecomment-1725249315

   @solomax Will these work for you?
   
   ```
   mvn versions:display-plugin-updates
   mvn versions:display-dependency-updates
   ```
   
   If not, I can revert the last commit.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org