If use the maven-shade-plugin, is the generated jar directly usable in other
builds using the dependency mechanism? I had assumed otherwise.
Specifying the complete class path is a reasonable option for me, but is there
a way to do that without specifying the entire manifest?
Thanks,
Russ
On J
Hi Andy,
> I have the classic jar and dll
If you want an even simpler solution, you can build the DLL outside Maven
(with e.g. CMake), then put the DLL into src/main/resources so that it is
included in the JAR, then use native-lib-loader [1] at runtime to load the
library.
Regards,
Curtis
P.S.
I also happen to know that there are/used to be "features" in Nexus groups
that leave orphan checksum files hanging around. As well as metadata files
*I think*...
/Anders
On Wed, Jun 5, 2013 at 2:34 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> What Anders is saying is that N
You could use the maven native plugin to do this:
http://mojo.codehaus.org/maven-native/native-maven-plugin/usage.html
dll is one of the options. There is also jnilib as one of the options (I
am assuming for linux jni binaries)
Thanks,
Roy Lyons
On 6/5/13 7:26 AM, "Andy" wrote:
>Hi All,
Ok! Got it! Thanks!
On 5 June 2013 15:12, Stephen Connolly wrote:
> But JBoss public is a mirror of several repositories using the priorities
> that suit JBoss's requirements, you probably only want a subset of their
> repositories, especially given that you have Maven Central in the mix also.
>
But JBoss public is a mirror of several repositories using the priorities
that suit JBoss's requirements, you probably only want a subset of their
repositories, especially given that you have Maven Central in the mix also.
On 5 June 2013 13:42, Henri Tremblay wrote:
> That is extremely interest
Hi Stanimir,
Stanimir Stamenkov wrote:
> states it should behave as you expect. May be it is a bug in the
> javadoc plugin, but I can't say for sure. Do you use the latest (2.9)
> plugin version? Does it happen with Maven 2 or 3, or both?
I'm using maven 3.0.4, java 1.6.0_27 (openjdk), and mav
That is extremely interesting.
I'm not sure to understand why it makes a difference.
Currently I have:
- maven-public-mirror: A nexus group containing:
- Maven Central: A proxy for Maven Central
- JBoss public: A proxy for JBoss public
- ...
I can order my proxies in my gro
pom
that stops the "deploying a jar when you don't have one" problem
As for your second issue I would use
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
On 5 June 2013 13:26, Andy wrote:
> Hi All,
>
> I have searched to death the jni project solutions and would j
What Anders is saying is that Nexus should not be proxying proxies, but
rather proxying the original source.
i.e. you have something like
http://your-nexus/content/groups/public
which is an aggregate view of
http://my-nexus/content/groups/public
http://his-nexus/content/groups/public
What you
Why? Maven allows a mirror to be a mirror of many repositories. So why
should I avoid it?
Knowing that, unless I'm mistaken, doing this grouping prevent maven to
look into many repositories for each download.
On 5 June 2013 14:15, Anders Hammar wrote:
> You shouldn't be proxying a Nexus group,
Hi All,
I have searched to death the jni project solutions and would just like a simple solution to a trivial issue, but having
difficulty pulling it off.
I have the classic jar and dll (I am really not interested the native plugin or packaging the dll in a jar yet, etc. I
just don't have the
You shouldn't be proxying a Nexus group, but rather the specific repo(s)
that you need.
/Anders
On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay wrote:
> I digged a bit and, helped by your thought, seem to have found the cause.
>
> We use Nexus to be a mirror of many repositories. All these publi
I digged a bit and, helped by your thought, seem to have found the cause.
We use Nexus to be a mirror of many repositories. All these public
repositories are in a group which is defined to be the mirror in our
settings.xml.
On of these public repositories is JBoss (
https://repository.jboss.org/n
Take a look at this tutorial to get you started binding your plugin to
user-selected phase
http://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html
Bon Chance,
Martin
__
Note de déni et de confidentialité
Ce messag
it is possible the remote repositories cannot be reached so a metadata stub is
put into your local repository indicating the attributes of the plugin maven is
looking for..here is an example
com.opensymphony
xwork
2.1.6-SNAPSHOT
20090909.201054
1
20090909201
dependency:tree when used on Maven 3.x can give slightly confusing results
as the "closest" reference with the same version as the "winning" reference
to the dependency is the reference that is shown. So you could have the
dependency somewhere else in your dependency tree (i.e. somewhere with a
hig
Maven has a couple of default packaging types that have defined lifecycles.
e.g. `jar`, `war`, `ear`, etc.
If you don't specify `` then Maven assumes that your project is
`jar` by default.
Maven will then consult its registry of lifecycles and see the lifecycle
for the `jar` (or whatever packagi
Ok. I managed to check.
So no, there is no range like in your example from what I see. The
dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 is
referencing version 1.2 and that's it.
I just realized that the problem occurs when I'm using the -U option. The
help is telling that it "F
what i want to do is to force to execute my plugin
in a specific phase
with a specific goal (my plugin will have only one goal)
without declare it
i mean that i don't want that the user declare the tag
as for example i use the jar-plugin
--
View this message in context:
http://maven.401
20 matches
Mail list logo
