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 as optional while importing? Best regards Mirko -- Sent from my mobile Jörg Schaible <[email protected]> schrieb am Di., 17. Apr. 2018, 00:53: > On Mon, 16 Apr 2018 21:46:21 +0000 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.win32.win32.x84_x64:3.106.0.v20170608-0516 > - org.eclipse.swt:org.eclipse.swt.gtk.linux.x84:3.106.0.v20170608-0516 > - org.eclipse.swt:org.eclipse.swt.gtk.linux.x84_x64:3.106.0.v20170608-0516 > - more variants for Linux and MacOS > > It does not matter against which SWT library you're compiling, but the > user's of the library will require a > different SWT library depending on their target platform. Therefore the > library declares a dependency to > org.eclipse.swt:org.eclipse.swt.${swt.platform}:3.106.0.v20170608-0516 and > the property is set based on > profiles in the project's parent. > > Separate artifacts of this library do not make sense, it is always the > same save the dependency to the SWT > library. > > Any solution without profiles? I don't see one and the property has to be > kept in the customer POM also. > > Regards, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
