| org/jsoup/nodes/Element.class | org/jsoup/nodes/Document.class | org/jsoup/Jsoup.class | org/jsoup/nodes/Element.class | org/jsoup/select/Elements.class | \_,- Not in the Portage tree; in my local overlay; needs to be revised. | ch/qos/logback/classic/Level.class | ch/qos/logback/classic/Logger.class | \_,- In the last-hope overlay as dev-java/logback-bin; is bin, source? | javax/interceptor/InvocationContext.class | \_,- In the java and sabayon overlay as www-servers/jboss-bin; is bin, source? | java/lang/Synthetic.class | \_,- No idea. | junit/framework/TestCase.class | \_,- Not sure if a RDEPEND on this is acceptable; what we need to figure out - for this one is whether it is to test Maven or used by Maven to test - something that is built.
Actually I think the conclusion here is wrong. Maven is delivered with all necessary classes for runtime. Classes in the jar files of Maven that refer classes which are not part of the delivery simply means, that those classes are actually not in use - otherwise Maven would fail. The only problem is, that this does not match very well with Gentoo's dependency mechanism. Therefore I am also not sure, if it is really wise to replace the delivered jars with the ones that have been emerged.
(In reply to Joerg Schaible from comment #1) > Maven is delivered with all necessary classes for runtime. This is against our policies, for both the Gentoo and Gentoo Java projects; binary code is normally only permitted when it is compiled by a Gentoo Developer from source code _or_ when we have no other option (which is not the case here), and bundled dependencies [2] are normally not permitted either unless we really have to. Maven can be build from source, and that's what we want to pursue. > Classes in the jar files of Maven that refer > classes which are not part of the delivery simply means, that those classes > are actually not in use - otherwise Maven would fail. Maven would fail if you would like to use them, otherwise we should remove those classes because they are not at all in use; but I doubt they would package that. > The only problem is, that this does not match very well with Gentoo's > dependency mechanism. That is why we need to build it from source. > Therefore I am also not sure, if it is really wise to > replace the delivered jars with the ones that have been emerged. Having proper dependencies is a good start for a source ebuild. We have been replacing jars for ages; so, it has shown to work well.
If you want to build from source, provide an maven-3.x.ebuild. maven-bin-3.x.ebuild is something else, however. And yes, I know very well about Gentoo and it's policies. I've looked at the various attempts to build Maven from source over the last 10 years here in Gentoo.
(In reply to Joerg Schaible from comment #3) > If you want to build from source, provide an maven-3.x.ebuild. > maven-bin-3.x.ebuild is something else, however. maven-bin-*.ebuild should be a product of maven-*.ebuild, not something else.
(In reply to Joerg Schaible from comment #1) > Actually I think the conclusion here is wrong. Maven is delivered with all > necessary classes for runtime. Classes in the jar files of Maven that refer > classes which are not part of the delivery simply means, that those classes > are actually not in use - otherwise Maven would fail. > > The only problem is, that this does not match very well with Gentoo's > dependency mechanism. Therefore I am also not sure, if it is really wise to > replace the delivered jars with the ones that have been emerged. I fully agree with this (see my comments in https://bugs.gentoo.org/show_bug.cgi?id=472850) maven-3.2.1 is out and maven guys added some of the missing jar's (see apache-maven-3.2.1/lib/) (In reply to Tom Wijsman (TomWij) from comment #0) > | org/jsoup/nodes/Element.class > | org/jsoup/nodes/Document.class > | org/jsoup/Jsoup.class > | org/jsoup/nodes/Element.class > | org/jsoup/select/Elements.class > | > \_,- Not in the Portage tree; in my local overlay; needs to be revised. Not needed anymore (apache-maven-3.2.1/lib/jsoup-1.7.2) > | java/lang/Synthetic.class > | > \_,- No idea. Probably comes from dev-java/jsr250-r1 (BTW this package is broken. There aren't any common-annotations (specified in jsr250) but jar contains something from JAXWS) > | junit/framework/TestCase.class > | > \_,- Not sure if a RDEPEND on this is acceptable; what we need to figure out > - for this one is whether it is to test Maven or used by Maven to test > - something that is built. I'm 100% sure that this dependency is not used in runtime. Other dependencies not needed since maven 3.2.1 and listed in *.ebuild because now bundled with maven-bin/lib: - dev-java/commons-cli:1 (commons-cli-1.2.jar) - dev-java/commons-io:1 (commons-io-2.2.jar) - dev-java/javax-inject:0 (cdi-api-1.0.jar) - dev-java/aopalliance:1 (aopalliance-1.0.jar) - dev-java/jsr250:0 (jsr250-api-1.0.jar)
See comment #2 about this; however, as long the source build is unavailable, the bundled version will be used when it appear to mismatch with what is provided by the package in the Portage tree (often that's because upstream patches it in one way or another).
I'm afraid I don't understand your comment. You mean : if there is java package in portage then we use that package. If not we use bundled *.jar versions?
It depends on whether they are the same.
To be clear. My comment#5 was about maven-3.2.1 (not in portage tree). I don't want to argue with you only trying convince you that your resolution isn't very good. (In reply to Tom Wijsman (TomWij) from comment #2) > This is against our policies, for both the Gentoo and Gentoo Java projects; > binary code is normally only permitted when it is compiled by a Gentoo > Developer from source code _or_ when we have no other option (which is not > the case here), and bundled dependencies [2] are normally not permitted > either unless we really have to. Maven can be build from source, and that's > what we want to pursue. Maybe it's time to change policy for java packages? These days policy is outdated (it's ok in ant world but not in maven world). > > Classes in the jar files of Maven that refer > > classes which are not part of the delivery simply means, that those classes > > are actually not in use - otherwise Maven would fail. > > Maven would fail if you would like to use them, otherwise we should remove > those classes because they are not at all in use; but I doubt they would > package that. They would. OSGi is an example. Many projects packing BundleActivator because jar can be used in OSGi environment too but won't be loaded because you need OSGi container. Another example is mvn.bat. They package this file but file isn't useful. On the other side maybe there is a reason why some of jar's are not bundled within archive? Why for example there isn't servlet-api (commons-logging dependency)? > > The only problem is, that this does not match very well with Gentoo's > > dependency mechanism. > > That is why we need to build it from source. And what do you do if you can build jar with maven only? "compile" time dependencies will be picked not from classpath but from local maven-repository. Next you will remove these dependencies (because maven copied from local mvn repository) and replace with jar's provided by portage? It could fail because packages "compile time" may differ from "runtime" (you build against one jar and run with another). If bug appears it will be gentoo specific. > > Therefore I am also not sure, if it is really wise to > > replace the delivered jars with the ones that have been emerged. > > Having proper dependencies is a good start for a source ebuild. We have been > replacing jars for ages; so, it has shown to work well. Yes with ant it probably works because you are building against the same jar as used in runtime. BUT you don't build maven-bin!!!. You only extract from tar.gz archive and replace jar's. That's wrong. <maven-bin-3.1.0 works well to (without this tricks) >=maven-bin-3.1.0 works well without these dependencies on my 3 machines
