Hi Georg, I just checked the trunk and I can’t compile
trunk> svn up Updating '.': At revision 1671257. trunk> mvn clean install [INFO] Scanning for projects... [ERROR] The build could not read 3 projects -> [Help 1] [ERROR] [ERROR] The project org.apache.fulcrum:fulcrum-cache:1.1.1-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/cache/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 2] [ERROR] [ERROR] The project org.apache.fulcrum:fulcrum-configuration:1.0.3-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/configuration/impl/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 22, column 11 -> [Help 2] [ERROR] [ERROR] The project org.apache.fulcrum:fulcrum-crypto:1.0.8-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/crypto/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 2] [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/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException It seems the fulcrum-parent.pom is missing in my setup …. Thanks in advance Siegfried Goeschl > On 27 Mar 2015, at 08:29, Georg Kallidis <[email protected]> wrote: > > Hi Siegfried, > > thanks for the comments! > > If we think about a bulk release of Fulcrums, we should IMO include > - upgrade test frameworks to Junit 4 > - align dependencies with Turbine M2 Trunk and > - probably do a lazy release of parents beforehand. > > To have a schedule, may be we should > - review by end of june the changes? > - check then, if it worth the effort to do a bulk release or just a > selection of components (JSON should be included) ? > > BTW: Any thoughts about Atmosphere framework? > > Best regards, Georg > > > > Von: Siegfried Goeschl <[email protected]> > An: Turbine Developers List <[email protected]> > Datum: 23.03.2015 22:24 > Betreff: Re: Concerning Releases / Settings > > > > Hi folks, > > a few thoughts along the line > > @Turbine Parent POM - there is lazy consensus and there are lazy > committers - shame on me - can’t remember the email but I’m fine with the > decision > > @Logging - agreeing with Thomas. Avalon uses it’s own logging facade and > the Fulcrum services are not directly dependent on Log4J. If we are > planning to change the underlying logging framework this might be tricky > and requires some investigation > > @Releases - I suggest to make a “bulk” release of Fulcrum components - > from my POV > > * I touched “fulcrum-testcontainer” to set the log level manually since I > drown in DEBUG output > * Did some cosmetic changes to “fulcrum-yaafi” - only really thing is > proper closing of file handles when working with decrypting input streams > * Synced “fulcrum-commonsemail” with my production code - this is about > supporting SSL & TLS and using the latest version of commons-email > > Any other components which need some care? > > Thanks in advance > > Siegfried Goeschl > > >> On 22 Mar 2015, at 12:41, Thomas Vandahl <[email protected]> wrote: >> >> Hi Georg, >> >> On 19.03.15 20:09, Georg Kallidis wrote: >>> Hi list, >>> >>> concerning upcoming releases of Turbine: >>> >>> - Turbine parent release should be either done without voting or not - > we still have not concluded IMO or have we? I think, it should be released > this year to enable up-to-date releases (including current reference to > Apache parent pom, ..). >> >> I thought I proposed a lazy consensus vote and nobody objected. >> >>> >>> - The next Turbine RC is waiting for Torque 4.1 (which is not yet > released), right? It should have the scheduler removed or replaced. What > are the other goals for this release or the release after this? May be, we > should make a clear cut and explicitely support only Java 8? If we decide > to do so, the same should be true for the Fulcrum components to be > consistent. Should we do it by allowing 1.x releases (Java 5) and 2.x > (Java 8)? And Http/2-support is coming (in browsers is and in Java 9).. >> >> I started to do some work on the scheduler. It's supposed to use >> fulcrum-quartz when it's ready but I face some backward compatibility >> issues (ScheduledJob is a module) >> >>> - Logging: Turbine Trunk had log4j as logging framework and has > currently slf4j with default log4j, cft.http://www.slf4j.org/legacy.html. > This should conform with Avalog default logging behaviour. May be logback > would be even better instead of log4j (same for the Fulcrum components)? > But log4j 2.x would be an alternative, too. I am happy with each one of > them. Which way we should go? >> >> My view: As Fulcrum components are Avalon services by (current) >> definition, they should use Avalon logging only. All components I >> touched have been modified to use Avalon logging if at all possible and >> unless some dependency pulls in log4j or similar. >> >> Turbine is supposed to use commons-logging for the time being. I'm >> completely aware that the manual initialization of log4j in the Turbine >> class contradicts with this statement and my suggestion would be to get >> rid of that special handling. >> >> If logging in a certain environment were an issue, it would be no big >> deal to create a simple logging stub on our own that can be attached to >> different logging backends. Many frameworks do this. >> >> Bye, Thomas. >> >> --------------------------------------------------------------------- >> 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
