| Summary: | enhance java-pkg-simple with new functionality | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Miroslav Šulc <fordfrog> |
| Component: | Eclasses | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo, kingjon3377, wizardedit |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=926308 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
(In reply to Miroslav Šulc from comment #0) > > * JAVA_SOURCE_VERSION/JAVA_TARGET_VERSION - though these will be used really > seldom, there might be cases when the source and target versions differ and > in that case these variables will be needed These should be handled automatically via deps, want a different source version, use a different JDK version in DEPEND. Need a different target version, set a different JRE in RDEPEND. If that is not good enough there is also JAVA_PKG_WANT_SOURCE JAVA_PKG_WANT_TARGET The others seem viable. and java-pkg-simple does need some code for generic tests. So I agree with all of that pertaining to tests. (In reply to William L. Thomson Jr. from comment #1) > (In reply to Miroslav Šulc from comment #0) > > > > * JAVA_SOURCE_VERSION/JAVA_TARGET_VERSION - though these will be used really > > seldom, there might be cases when the source and target versions differ and > > in that case these variables will be needed > > These should be handled automatically via deps, want a different source > version, use a different JDK version in DEPEND. Need a different target > version, set a different JRE in RDEPEND. i did not know about this, it is even better. i'll update java-ebuilder to do it the way you write. done in https://gitweb.gentoo.org/proj/java-ebuilder.git/commit/?id=3d9b3b066c32ca55f2e982b3f85d5c6bfacd2a5d monsieurp has put forward a prototype that makes use of JAVA_TEST_SRC_DIR and JAVA_GENTOO_TEST_CLASSPATH. https://github.com/gentoo/gentoo/commit/8692f9e5e384a31d9571dc1d13e51297189d1733 He actually called the latter JAVA_TEST_CLASSPATH. I think neither is correct. ;) To be consistent with what we already have, it should be JAVA_TEST_GENTOO_CLASSPATH. JAVA_TEST_SRC_DIR is a good counterpart to JAVA_SRC_DIR. The default value of src/main/test makes the eclass look a little Mavenesque but I suppose it is only a default and even Maven packages may need to change it. I previously considered adding a JAVA_RESOURCE_DIRS variable but in non-Maven cases, the resources are often intermixed with the .java files. I added a helper called java-pkg-addres instead that allows you to specify additional arguments to find for maximum flexibility. The variable approach makes sense for Maven packages though as they always have their resources in a separate directory tree. fordfrog says that the name of this directory can be overridden but I have never seen it called anything but resources. Do you have any examples, fordfrog? Adding a MANIFEST.MF file when using java-pkg-simple is a bit of a pain so JAVA_MAIN_CLASS could be useful there, though only for jars with no dependencies as "java -jar" ignores externally specified classpaths. I suppose also creating a launcher off the back of this wouldn't hurt. My main concern is that by making everything variable-driven, it becomes quite inflexible, and it's important to remember that Maven projects often consist of several components. Sometimes you would want to package these separately (see log4j 2) but other times not (see antlr 4). Even now, I am having to do something like for this antlr 4. This is very simplified (antlr is weird) and not yet committed. src_compile() { JAVA_SRC_DIR="runtime/Java/src" JAVA_JAR_FILENAME="${PN}-runtime.jar" java-pkg-simple_src_compile JAVA_SRC_DIR="tool/src" JAVA_JAR_FILENAME="${PN}-tool.jar" java-pkg-simple_src_compile } What do you think? Forgot to say how would java-ebuilder cope with multiple pom.xml files for a single package? (In reply to James Le Cuirot from comment #4) > JAVA_TEST_SRC_DIR is a good counterpart to JAVA_SRC_DIR. The default value > of src/main/test makes the eclass look a little Mavenesque but I suppose it > is only a default and even Maven packages may need to change it. in fact in maven the path is src/test/java so it's not maven path :-) but the default value could be anything, even just 'test'. > I previously considered adding a JAVA_RESOURCE_DIRS variable but in > non-Maven cases, the resources are often intermixed with the .java files. I > added a helper called java-pkg-addres instead that allows you to specify > additional arguments to find for maximum flexibility. The variable approach > makes sense for Maven packages though as they always have their resources in > a separate directory tree. fordfrog says that the name of this directory can > be overridden but I have never seen it called anything but resources. Do you > have any examples, fordfrog? i won't give you any example but imagine project that is built using ant and has has pom.xml added. then either the ant-ish project stracture would have to be adjusted to maven or pom.xml would have to be updated to work with the ant-ish structure. > Adding a MANIFEST.MF file when using java-pkg-simple is a bit of a pain so > JAVA_MAIN_CLASS could be useful there, though only for jars with no > dependencies as "java -jar" ignores externally specified classpaths. I > suppose also creating a launcher off the back of this wouldn't hurt. that was the initial intent. as you wrote, it would not work without internal classpath anyway. > My main concern is that by making everything variable-driven, it becomes > quite inflexible, and it's important to remember that Maven projects often > consist of several components. Sometimes you would want to package these > separately (see log4j 2) but other times not (see antlr 4). Even now, I am > having to do something like for this antlr 4. This is very simplified (antlr > is weird) and not yet committed. > > src_compile() { > JAVA_SRC_DIR="runtime/Java/src" JAVA_JAR_FILENAME="${PN}-runtime.jar" > java-pkg-simple_src_compile > JAVA_SRC_DIR="tool/src" JAVA_JAR_FILENAME="${PN}-tool.jar" > java-pkg-simple_src_compile > } > > What do you think? i expected that the main purpose of the eclass would be for single-jar packages as i was told, we should prefer packaging libraries one by one, like lucene for example. anyway this usage seems to be possible. (In reply to James Le Cuirot from comment #5) > Forgot to say how would java-ebuilder cope with multiple pom.xml files for a > single package? java-ebuilder attempts the problem as one pom.xml -> one library -> one ebuild. i did not think about putting many libraries into single ebuild as it seems against the prefered way which is splitting even larger projects (lucene) into separate ebuilds. Meanwhile 'java-pkg-simple.eclass' got the proposed eclass variables added and some ebuilds already produce multiple jar files. Closing. |
for java-ebuilder there is new functionality needed. in fact it might be needed for any package being handled by java-pkg-simple. * JAVA_SOURCE_VERSION/JAVA_TARGET_VERSION - though these will be used really seldom, there might be cases when the source and target versions differ and in that case these variables will be needed * the eclass should be able to handle tests aswell, for which we would need JAVA_GENTOO_TEST_CLASSPATH for putting extra classes needed during tests compilation and running (junit, ...), JAVA_TEST_SRC_DIR and JAVA_TEST_RESOURCE_DIRS for test sources path and test resources paths respectively * java libs sometimes comes with resources which are in maven projects located in separate directory. to grab these and package them into jar aswell we need JAVA_RESOURCE_DIRS * some jars represent applications so we would need launchers for them. the launcher usually needs just main class specified, hence JAVA_MAIN_CLASS. other vars like JAVA_LAUNCHER_NAME might be needed but java-ebuilder does not use these atm and instead supposes launcher name would be ${PN}. by design, maven pom.xml makes it possible to place resources into several directories, which is used seldom i guess, but for that JAVA_RESOURCE_DIRS and JAVA_TEST_RESOURCE_DIRS should be able to handle paths separated by ':' to cover these edge cases. none of these variables are maven specific, any java project may need them when putting non-java resources aside, having specific need for source/target versions and/or running tests aswell as creating app launcher.