Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

Christofer Dutz
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" <[hidden email]>:

    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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

Hervé BOUTEMY
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" <[hidden email]>:
>
>     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: [hidden email]
>     For additional commands, e-mail: [hidden email]
>    
>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

Christofer Dutz
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" <[hidden email]>:

    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" <[hidden email]>:
    >
    >     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: [hidden email]
    >     For additional commands, e-mail: [hidden email]
    >    
    >    
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail: [hidden email]
    > For additional commands, e-mail: [hidden email]
   
   
   
   
   
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

Hervé BOUTEMY
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" <[hidden email]>:
>
>     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" <[hidden email]>:
>     >
>     >
>     >     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: [hidden email]
>     >     For additional commands, e-mail: [hidden email]
>     >    
>     >    
>     >
>     >
>     >
>     > ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: [hidden email]
>     > For additional commands, e-mail: [hidden email]
>
>    
>    
>    
>    
>    
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     For additional commands, e-mail: [hidden email]
>    
>    
>





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]