[prev in list] [next in list] [prev in thread] [next in thread]
List: maven-user
Subject: Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "p
From: Hervé BOUTEMY <herve.boutemy () free ! fr>
Date: 2019-01-22 9:10:02
Message-ID: 2290361.EpoDI98XBa () giga
[Download RAW message or body]
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" <herve.boutemy@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" <herve.boutemy@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic