maven -P or -D for things like docgen
by Michael Burman
Hi,
>From #hawkular and PR 158. Originally I replaced a -Ddocgen with -Pdocgen as I thought it was originally a mistake. To me generating documentation was just another goal of the project, different target environment. However, originally one used to set up with -D a parameter that would then also generate the documentation.
I guess the same process should be shared among all our different targets & projects, so which one is preferred?
- Micke
9 years, 9 months
Fwd: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than what it looks like
by Heiko W.Rupp
FYI from wildfly-dev, as we seem to "still" be using 3.1.x stream of jboss.logging.
> Anfang der weitergeleiteten Nachricht:
>
> Von: Sanne Grinovero <sanne(a)hibernate.org>
> Datum: 27. Februar 2015 21:08:00 MEZ
> An: "wildfly-dev(a)lists.jboss.org" <wildfly-dev(a)lists.jboss.org>
> Betreff: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than what it looks like
>
> Hi all,
> today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
> in an Hibernate project, and got some integration test failures.
>
> The surprising aspect is that everything seemed fine at compile level:
> just switch the version in the pom, and without needing any further
> changes it compiles fine and runs all unit tests successfully.. but
> fails when using the freshly built libraries in WildFly 8.2.
>
> It's not a regression of jboss-logging, but one of its improvements
> require a bit of attention.
>
> This is what happened to us:
> we have some log statements which look like this in source code (after
> simplifying):
>
> int i = ...
> log.debugf( "Number: %d", i );
>
> This does of course compile fine in both old an new versions of JBoss
> Logger. And it all works as expected in unit tests.
> But when deploying the modified version of this Hibernate library in
> WildFly 8.2, you'd get some of these:
> - java.lang.NoSuchMethodError:
> org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
>
> When using the older version of JBoss Logger (at compile time), the
> above line of code is compiled as an invocation to:
>
> void debugf(String format, Object param1);
>
> (which is a method present in both versions)
>
> When using the new version of JBoss Logger (at compile time), the same
> line of code is interpreted as the (better) invocation to:
>
> void debugf(String format, int arg);
>
> So that's what the library is going to invoke at runtime - and that
> method doesn't exist in WildFly 8.2.
>
> Be aware of this when upgrading as it might look like a trivial
> version bump but it makes it quite hard to guarantee backwards
> compatibility with older versions of the logger.
>
> Personally since I want to upgrade the logger but don't want to drop
> compatibility with existing WildFly releases, I'm trying to figure how
> to reliably validate that no logging statement is going to invoke one
> of the new ones.. for now.
>
> I guess this also means that users won't actually benefit from the
> better performance of the new logging methods until we recompile all
> of its client libraries using the new version ;-)
> Auto-boxing is evil..
>
> Sanne
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
9 years, 9 months
