Hello Silvio, thank you for sharing tetra. Feel free to enhance the docs, that you need to install: ruby-devel gcc-c++ zlib-devel (at least on fedora)
Actually compilation of commons-collections-3.2.1 failed on my machine. (Errors below.) I know that building of java packages with all their dependencies and dependencies of their dependencies and ... is pain. However, I do not think we would adopt tetra for building Spacewalk java packages. The most java packages we use from the old jpackage repository [1] as they are and honestly - we're happy we do not need to (re)build, fix and maintain them. Part of the java packages we use from the OS and the rest we build in Spacewalk Koji Build System [2]. For building those we definitely prefer installing buildroots from rpms. Regards, -- Tomas Lestach Red Hat Satellite Engineering, Red Hat [1] http://mirrors.dotsrc.org/jpackage/5.0/generic/free/RPMS/ [2] http://koji.spacewalkproject.org/koji/ [INFO] Compiling 273 source files to /tmp/commons-collections/src/commons-collections-3.2.1-src/target/classes [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 10.161 s [INFO] Finished at: 2015-04-16T11:36:12+02:00 [INFO] Final Memory: 26M/258M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project commons-collections: Compilation failure: Compilation failure: [ERROR] /tmp/commons-collections/src/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiMap.java:[69,18] error: remove(Object,Object) in MultiMap clashes with remove(Object,Object) in Map [ERROR] [ERROR] return type Object is not compatible with boolean [ERROR] /tmp/commons-collections/src/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,18] error: remove(Object,Object) in MultiKeyMap cannot implement remove(Object,Object) in Map [ERROR] [ERROR] return type Object is not compatible with boolean [ERROR] /tmp/commons-collections/src/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,18] error: remove(Object,Object) in MultiValueMap cannot implement remove(Object,Object) in Map [ERROR] [ERROR] return type Object is not compatible with boolean [ERROR] /tmp/commons-collections/src/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,18] error: remove(Object,Object) in MultiHashMap cannot implement remove(Object,Object) in Map [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException ----- Original Message ----- > From: "Silvio Moioli" <smoi...@suse.de> > To: "spacewalk-devel" <spacewalk-devel@redhat.com> > Sent: Monday, March 2, 2015 12:39:59 PM > Subject: [Spacewalk-devel] Introducing tetra > > Dear Spacewalk developers, > > in the SUSE Manager team we have been looking for ways to simplify > the packaging of Java software, in particular Maven based projects, > since some time. Now we have finally settled on a solution, so I am > glad to present it here today and I would like to gather some > feedback from you. > > It boils down to this: > > 1) we allow prebuilt (binary JAR) build dependencies. This means that > all software we ship is still completely built from source, but its > "build chain", which we don't ship, is mostly copied in binary form > from the Maven Central repository instead of being rebuilt from > scratch; > 2) we make use of a tool I wrote, tetra, to greatly simplify the > process given the above assumption. > > https://github.com/moio/tetra > > As an example, I could get basically all Spacewalk Java dependencies > to build for openSUSE in two weeks - without it would have easily > taken months. > > My main question now now is: if we update versions of libraries such > as commons-lang, commons-collections or Hibernate and refactor > Spacewalk's code accordingly, would you accept contributions in the > form of specfiles/tarballs generated with tetra, or anyway assuming > 1)? > > Comments, thoughts and further discussion are of course very welcome. > > Silvio > > PS: currently tetra outputs SUSE-centric specfiles, but they are so > simple that tweaking templates for Fedora or Red Hat distros would > be trivial. > -- > Silvio Moioli > SUSE LLC > Maxfeldstraße 5, 90409 Nürnberg Germany > > _______________________________________________ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
