You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Christofer Dutz <ch...@c-ware.de> on 2019/01/07 13:23:48 UTC
Supporting custom "Scopes" and Maven support for "Non-Java" languages
(WAS: Re: Any update on "polyglot" Maven?)
Hi Hervé,
thanks for that info ... I adjusted the topic to distinguish from the other topic :)
Well I first ran into problems when taking over the maintenance of the Flexmojos maven plugin, which allowed building Flex applications with maven.
A while ago a "bug" was fixed, which that plugin relied on (non-standard scopes were treated as compile when it came to transitive dependencies - I think).
In flex there were different types of linking (Think of it as "static linking" (scope "compile" and "test") and "dynamic linking" (scope "rsl") (RSL = Runtime Shared Library)).
Now with C/C++ we have a similar problem.
What I would like to be able to do, would be that if I am using a plugin to provide the means to build a custom type of module, that there would be an additional extension point in the plugin.xml
where we could provide an additional scope resolver (or whatever we call the thing).
So If I'm for example providing something that's going to be a "cpp-library" then I could for example use scopes like "dynamicly-linked" or "staticly-linked" and the thing would tell
maven how to transitively resolve these libraries. Ideally this would sort of be a stack, so if a scope isn't recognized, it defaults to the next level.
As this has been a problem I have been running into again and again but always with different problems, I would really like to have this solved or help with solving it (I'm not expecting you folks to do that for me)
Chris
PS: I'm currently using the cmake maven plugin abstracting even more from the actual build
Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" <he...@free.fr>:
Hi Christofer,
I know C/C++ people who used nar-maven-plugin [1] with success: did you have a
look?
Notice: in Maven, "polyglot" term has always been used for other POM format
than XML.
Here, it's more on Maven support for non-java languages
One key requirement in such multi-languages context will be to have common
understanding and vocabulary on the requirements of the alternate languages,
sharing concrete examples to make sure both java and non-java people see the
same case.
That was my key finding when I worked a little bit to help these C/C++ people
discover the plugin and find their way. But I never got too much in details on
how finely they managed dependencies: I know there were both static and
dynamic libraries, and multi-platform support, then 2 key topics for C/C++
than Java does not require
Regards,
Hervé
[1] http://maven-nar.github.io/
Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit :
> Hi all,
>
> after leaving the Flex project I sort of lost the need for supporting
> alternate dependency strategies. Now in PLC4X we’re currently starting to
> work on the C and C++ versions of our PLC drivers.
This brings the old
> problem up again that not all programming languages have the same
> super-simple dependency types as Java has them.
> I remember us discussing options to provide extensions for maven, that for
> example the type of a pom would not only pull in a dedicated lifecycle
> mapping, but also provide an alternate dependency resolution mechanism.
> In the C/C++ world we unfortunately have things like static and dynamic
> linking etc. I would really like to not start with hacks as I always did
> them in Flex and Flexmojos (which is now no longer possible anyway).
> Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)
Posted by Hervé BOUTEMY <he...@free.fr>.
I don't have all the details, but on static vs dynamic libs, static libs are
classical dependencies from a Maven point of view, ie. downloaded from the
repository and added to something like a classpath, where dynamic libs are
classically managed by the distribution's package manager: I don't know how
this is dealt with during the build, where updating the machine with a Linux
package is not really an option
I'll try to get in touch with the guy I know who did work on that
Regards,
Hervé
Le lundi 14 janvier 2019, 15:03:55 CET Christofer Dutz a écrit :
> Hi Herve,
>
> well I know for example that I have some libraries, that are statically
> linked and some expect libraries to be installed on the host system.
I had
> the exact same problem with Flex in the past ... here I could also have
> dynamically linked versions of libraries, then I had to also reference all
> the dynamically linked dependencies of that too. Usually always some
> dependencies were intentionally statically linked and some intentionally
> dynamically linked. It all boils down how to interpret the transitive
> dependencies of a dependency depending on its linkage type.
> So I guess this would be a quite generic requirement. One I seem to
> encounter multiple times with different languages.
> In my current example of PLC4X with C++, I simply statically link
> everything.
> Chris
>
>
>
> Am 08.01.19, 02:59 schrieb "Hervé BOUTEMY" <he...@free.fr>:
>
> let's try to dig into your requirements
>
> instead of trying to explain generic mechanisms, can you provide some
> concrete
C++ examples, please?
>
> Regards,
>
> Hervé
>
> Le lundi 7 janvier 2019, 14:23:48 CET Christofer Dutz a écrit :
>
> > Hi Hervé,
> >
> > thanks for that info ... I adjusted the topic to distinguish from the
> > other
topic :)
>
>
>
> > Well I first ran into problems when taking over the maintenance of
> > the
> > Flexmojos maven plugin, which allowed building Flex applications with
> > maven.
>
> A while ago a "bug" was fixed, which that plugin relied on
>
> > (non-standard scopes were treated as compile when it came to
> > transitive
> > dependencies - I think). In flex there were different types of
> > linking
> > (Think of it as "static linking" (scope "compile" and "test") and
> > "dynamic
> > linking" (scope "rsl") (RSL = Runtime Shared Library)).
> > Now with C/C++ we have a similar problem.
> >
> > What I would like to be able to do, would be that if I am using a
> > plugin to
provide the means to build a custom type of module, that
> > there would be an additional extension point in the plugin.xml
>
> where we could provide an
>
> > additional scope resolver (or whatever we call the thing). So If I'm
> > for
> > example providing something that's going to be a "cpp-library" then I
> > could
for example use scopes like "dynamicly-linked" or
> > "staticly-linked" and the thing would tell maven how to transitively
> > resolve these libraries. Ideally this would sort of be a stack, so if
> > a scope isn't recognized, it defaults to the next level.
> > As this has been a problem I have been running into again and again
> > but
> > always with different problems, I would really like to have this
> > solved or
> > help with solving it (I'm not expecting you folks to do that for me)
>
>
>
> > Chris
> >
> >
> > PS: I'm currently using the cmake maven plugin abstracting even more
> > from
> > the actual build
>
>
>
> >
> > Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" <he...@free.fr>:
> >
> >
> > Hi Christofer,
> >
> > I know C/C++ people who used nar-maven-plugin [1] with success:
> > did you
> >
> > have a
>
> look?
>
> >
> > Notice: in Maven, "polyglot" term has always been used for other
> > POM
> >
> > format
>
> than XML.
>
> > Here, it's more on Maven support for non-java languages
> >
> > One key requirement in such multi-languages context will be to
> > have
> >
> > common
>
> understanding and vocabulary on the requirements of the alternate
>
> > languages, sharing concrete examples to make sure both java and
> > non-java
> > people see the same case.
> >
> > That was my key finding when I worked a little bit to help these
> > C/C++
> >
> > people
>
> discover the plugin and find their way. But I never got too much
>
> > in details on how finely they managed dependencies: I know there were
> > both
> > static and dynamic libraries, and multi-platform support, then 2 key
> > topics
for C/C++ than Java does not require
> >
> >
> > Regards,
> >
> > Hervé
> >
> > [1] http://maven-nar.github.io/
> >
> > Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit
> > :
> >
> >
> >
> > > Hi all,
> > >
> > > after leaving the Flex project I sort of lost the need for
> > > supporting
> > > alternate dependency strategies. Now in PLC4X we’re currently
> > > starting
> > > to
> > > work on the C and C++ versions of our PLC drivers.
> >
> >
> >
> > This brings the old
> >
> >
> >
> > > problem up again that not all programming languages have the
> > > same
> > > super-simple dependency types as Java has them.
> > > I remember us discussing options to provide extensions for
> > > maven, that
> > > for
> > > example the type of a pom would not only pull in a dedicated
> > > lifecycle
> > > mapping, but also provide an alternate dependency resolution
> > > mechanism.
> >
> >
> >
> >
> >
> >
> >
> > > In the C/C++ world we unfortunately have things like static and
> > > dynamic
> > > linking etc. I would really like to not start with hacks as I
> > > always
> > > did
> > > them in Flex and Flexmojos (which is now no longer possible
> > > anyway).
> >
> >
> >
> >
> >
> >
> >
> > > Chris
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------
> > ---
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Supporting custom "Scopes" and Maven support for "Non-Java"
languages (WAS: Re: Any update on "polyglot" Maven?)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Herve,
well I know for example that I have some libraries, that are statically linked and some expect libraries to be installed on the host system.
I had the exact same problem with Flex in the past ... here I could also have dynamically linked versions of libraries, then I had to also reference all the dynamically linked dependencies of that too.
Usually always some dependencies were intentionally statically linked and some intentionally dynamically linked. It all boils down how to interpret the transitive dependencies of a dependency depending on its linkage type.
So I guess this would be a quite generic requirement. One I seem to encounter multiple times with different languages.
In my current example of PLC4X with C++, I simply statically link everything.
Chris
Am 08.01.19, 02:59 schrieb "Hervé BOUTEMY" <he...@free.fr>:
let's try to dig into your requirements
instead of trying to explain generic mechanisms, can you provide some concrete
C++ examples, please?
Regards,
Hervé
Le lundi 7 janvier 2019, 14:23:48 CET Christofer Dutz a écrit :
> Hi Hervé,
>
> thanks for that info ... I adjusted the topic to distinguish from the other
> topic :)
> Well I first ran into problems when taking over the maintenance of the
> Flexmojos maven plugin, which allowed building Flex applications with
> maven.
A while ago a "bug" was fixed, which that plugin relied on
> (non-standard scopes were treated as compile when it came to transitive
> dependencies - I think). In flex there were different types of linking
> (Think of it as "static linking" (scope "compile" and "test") and "dynamic
> linking" (scope "rsl") (RSL = Runtime Shared Library)).
> Now with C/C++ we have a similar problem.
>
> What I would like to be able to do, would be that if I am using a plugin to
> provide the means to build a custom type of module, that there would be an
> additional extension point in the plugin.xml
where we could provide an
> additional scope resolver (or whatever we call the thing). So If I'm for
> example providing something that's going to be a "cpp-library" then I could
> for example use scopes like "dynamicly-linked" or "staticly-linked" and the
> thing would tell maven how to transitively resolve these libraries. Ideally
> this would sort of be a stack, so if a scope isn't recognized, it defaults
> to the next level.
> As this has been a problem I have been running into again and again but
> always with different problems, I would really like to have this solved or
> help with solving it (I'm not expecting you folks to do that for me)
> Chris
>
>
> PS: I'm currently using the cmake maven plugin abstracting even more from
> the actual build
>
> Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" <he...@free.fr>:
>
> Hi Christofer,
>
> I know C/C++ people who used nar-maven-plugin [1] with success: did you
> have a
look?
>
> Notice: in Maven, "polyglot" term has always been used for other POM
> format
than XML.
> Here, it's more on Maven support for non-java languages
>
> One key requirement in such multi-languages context will be to have
> common
understanding and vocabulary on the requirements of the alternate
> languages, sharing concrete examples to make sure both java and non-java
> people see the same case.
> That was my key finding when I worked a little bit to help these C/C++
> people
discover the plugin and find their way. But I never got too much
> in details on how finely they managed dependencies: I know there were both
> static and dynamic libraries, and multi-platform support, then 2 key topics
> for C/C++ than Java does not require
>
> Regards,
>
> Hervé
>
> [1] http://maven-nar.github.io/
>
> Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit :
>
> > Hi all,
> >
> > after leaving the Flex project I sort of lost the need for supporting
> > alternate dependency strategies. Now in PLC4X we’re currently starting
> > to
> > work on the C and C++ versions of our PLC drivers.
>
> This brings the old
>
> > problem up again that not all programming languages have the same
> > super-simple dependency types as Java has them.
> > I remember us discussing options to provide extensions for maven, that
> > for
> > example the type of a pom would not only pull in a dedicated
> > lifecycle
> > mapping, but also provide an alternate dependency resolution
> > mechanism.
>
>
>
> > In the C/C++ world we unfortunately have things like static and
> > dynamic
> > linking etc. I would really like to not start with hacks as I always
> > did
> > them in Flex and Flexmojos (which is now no longer possible anyway).
>
>
>
> > Chris
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)
Posted by Hervé BOUTEMY <he...@free.fr>.
let's try to dig into your requirements
instead of trying to explain generic mechanisms, can you provide some concrete
C++ examples, please?
Regards,
Hervé
Le lundi 7 janvier 2019, 14:23:48 CET Christofer Dutz a écrit :
> Hi Hervé,
>
> thanks for that info ... I adjusted the topic to distinguish from the other
> topic :)
> Well I first ran into problems when taking over the maintenance of the
> Flexmojos maven plugin, which allowed building Flex applications with
> maven.
A while ago a "bug" was fixed, which that plugin relied on
> (non-standard scopes were treated as compile when it came to transitive
> dependencies - I think). In flex there were different types of linking
> (Think of it as "static linking" (scope "compile" and "test") and "dynamic
> linking" (scope "rsl") (RSL = Runtime Shared Library)).
> Now with C/C++ we have a similar problem.
>
> What I would like to be able to do, would be that if I am using a plugin to
> provide the means to build a custom type of module, that there would be an
> additional extension point in the plugin.xml
where we could provide an
> additional scope resolver (or whatever we call the thing). So If I'm for
> example providing something that's going to be a "cpp-library" then I could
> for example use scopes like "dynamicly-linked" or "staticly-linked" and the
> thing would tell maven how to transitively resolve these libraries. Ideally
> this would sort of be a stack, so if a scope isn't recognized, it defaults
> to the next level.
> As this has been a problem I have been running into again and again but
> always with different problems, I would really like to have this solved or
> help with solving it (I'm not expecting you folks to do that for me)
> Chris
>
>
> PS: I'm currently using the cmake maven plugin abstracting even more from
> the actual build
>
> Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" <he...@free.fr>:
>
> Hi Christofer,
>
> I know C/C++ people who used nar-maven-plugin [1] with success: did you
> have a
look?
>
> Notice: in Maven, "polyglot" term has always been used for other POM
> format
than XML.
> Here, it's more on Maven support for non-java languages
>
> One key requirement in such multi-languages context will be to have
> common
understanding and vocabulary on the requirements of the alternate
> languages, sharing concrete examples to make sure both java and non-java
> people see the same case.
> That was my key finding when I worked a little bit to help these C/C++
> people
discover the plugin and find their way. But I never got too much
> in details on how finely they managed dependencies: I know there were both
> static and dynamic libraries, and multi-platform support, then 2 key topics
> for C/C++ than Java does not require
>
> Regards,
>
> Hervé
>
> [1] http://maven-nar.github.io/
>
> Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit :
>
> > Hi all,
> >
> > after leaving the Flex project I sort of lost the need for supporting
> > alternate dependency strategies. Now in PLC4X we’re currently starting
> > to
> > work on the C and C++ versions of our PLC drivers.
>
> This brings the old
>
> > problem up again that not all programming languages have the same
> > super-simple dependency types as Java has them.
> > I remember us discussing options to provide extensions for maven, that
> > for
> > example the type of a pom would not only pull in a dedicated
> > lifecycle
> > mapping, but also provide an alternate dependency resolution
> > mechanism.
>
>
>
> > In the C/C++ world we unfortunately have things like static and
> > dynamic
> > linking etc. I would really like to not start with hacks as I always
> > did
> > them in Flex and Flexmojos (which is now no longer possible anyway).
>
>
>
> > Chris
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org