Hello Jörg,
I understand your problem, however this is quite specific. AFAIK currently
profiles are *not* evaluated while resolving imported dependencies, only
those inherited, so this would be a very drastic change.
For your eclipse example: maybe put OS specific stuff in modules and mark
them a
+1:
On Tue, Apr 17, 2018 at 12:37 AM, Hervé BOUTEMY
wrote:
> Hi,
>
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12317320&version=12342365&styleName=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jq
On Mon, 16 Apr 2018 21:46:21 + Mirko Friedenhagen wrote:
> Hello,
>
> I do not see why profiles should be part of the consumer pom.
If you're building a library based on SWT you have:
- org.eclipse.swt:org.eclipse.swt.win32.win32.x84:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.
Hi,
We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320&version=12342365&styleName=Text
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIASITETOOLS%20AND%20status%20%3D%20Open%20ORDER%20BY%20k
Hello,
I do not see why profiles should be part of the consumer pom.
That would require evaluating profiles on import and I do not think this to
be a good idea.
At work I created a division pom with own lifecycles and profiles to
achieve automated packaging and upload/Maven-deploy of spring-boot
Hi Christian,
could you base your commit on
https://github.com/apache/maven-compiler-plugin ?
I know this is a long standing with to do whitebox testing, even though
some others JPMS experts don't agree ;)
My comment did indicate i had no idea at that time what to do with it, so
maybe this
Hi everybody,
I filed a PR against AbstractCompilerMojo and TestCompilerMojo some days
ago [1] and would like to discuss it. The PR introduces support for test
sources organized as modules and solves the inline comment reading " //
maybe some extra analysis required " in the TestCompilerMojo.
A s
On 15 Apr 2018, at 1:29 AM, Hervé BOUTEMY wrote:
> yes, this will require a xhtml5 Doxia sink
>
> since each skin defines a site template as direct html source (without Doxia
> interaction), the maven-site-plugin switch from xhtml to xhtml5 would have to
> be done on configuration from the ski
With absolutely impeccable timing, I've had a couple of hardware
failures. It is theoretically possible that this was the cause of the
performance issues - although there were no error messages logged
anywhere.
I'm waiting for replacement parts, so it'll be a week or so before I
can continue pulli
