Very likely a bug if the docs says otherwise. I did the last release of
that plugin but I can't recall any ticket about this change.
Please have a look at the tickets in JIRA for the 2.1-alpha-2 release and
see if you can find anything that seems related to this. If not, please
file a ticket of
Hi all,
my issue is no new one and I found some related posts - even on this list -
already. But none of them has been answered, so I try my luck.
What I want:
Copy one (or multiple) selected dependency of my project into a directory of
its own. That is, unlike the normal copy-dependencies
Hi from a newbie.
I too have been fighting with how best to develop maven artifacts
containing jni parts. Though I found several useful posts on jni and
maven , e.g.
http://www.tricoder.net/blog/?p=197
http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI
Thanks for the pointer to the bug. I've configured my project to use the 2.3.2
version of the release plugin and things are working as expected. I haven't
explored switching to different scm version dependency.
--
Julien Silland
On Thursday, January 3, 2013 at 2:34 AM, Robert Scholte wrote:
Date: Fri, 4 Jan 2013 11:54:46 -0800
From: stu...@apl.washington.edu
To: users@maven.apache.org
Subject: Re: JNI jars dependencies
Hi from a newbie.MGa newbie with extensive experience with maven and make
files!
I too have been fighting with how best to develop maven artifacts
Hi Martin, all,
the native code, either a .so or .dll, lives in the uber.jar at
/META-INF/lib/. We then link this in via wapmx's native loader:
import com.wapmx.nativeutils.jniloader.NativeLoader;
class LoadJNI {
static {
String libName = tsk4j;
try {
Sorry Martin, I missed some of your points:
Hi from a newbie.MGa newbie with extensive experience with maven and make
files!
Ah yes, I meant new to mailing list ;)
com.wapmx.native loader can unpack it at runtime. MGis this
NativeLoader what you're alluding
The real issue is https://jira.codehaus.org/browse/SCM-709
To solve it we could really use some feedback on this issue:
- which version of GIT are you using?
- what is the output of 'git status --porcelain' if a file is modified?
Robert
Op Fri, 04 Jan 2013 21:00:40 +0100 schreef Julien Silland
What are you actually trying to do?
Why do you need to do this? What makes your environment different from
everyone else's operation?
Perhaps there are easier ways to get what you want by reformulating the
problem.
Ron
On 04/01/2013 11:17 AM, Erik Fäßler wrote:
Hi all,
my issue is no new
I've defined a superpom and I'm using the import scope in another maven project
to apply those. I'm not seeing the configurations being applied for the plugins
I've defined in the superpom's pluginManagement.
Any ideas?
Regards,
Marcos
First, there is only one super-POM and that one is included in Maven
itself. What you probably mean is a parent pom.
To use that parent pom you declare it in the parent section, not as a
import scope dependency.
/Anders
On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez mar...@jitisoft.com wrote:
I understand the root issue is not from the release plugin itself but from the
SCM implementation. Though, I have to mention that the plugin was error'ing out
when I had left modified files before running maven:prepare.
My git version is: 1.7.7.5 (Apple Git-26)
Here's a sample output of git
I actually do mean super pom. We have multiple projects that have similar
configurations, dependencies, plugins, etc. I don't want to have them repeated
each time and they will not have the same parent - it is not feasible. I've
used the import scope for setting dependency versions (e.g.
I found this approach at
http://weblogs.java.net/blog/fabriziogiudici/archive/2010/02/21/shrink-your-pom.
Maybe the name is not correct, but I want a pom with most configurations that
I can import from all my separate projects. Works for dependencies, though I
have to define a separate process
I actually do mean super pom.
No, you don't. What you're talking about is something often called a BOM
(bill of material) or maybe an import-pom.
We have multiple projects that have similar configurations, dependencies,
plugins, etc. I don't want to have them repeated each time and they
thanks. i'll see if i can create a plugin to do it then.
On Jan 4, 2013, at 16:38, Anders Hammar and...@hammar.net wrote:
I actually do mean super pom.
No, you don't. What you're talking about is something often called a BOM
(bill of material) or maybe an import-pom.
We have multiple
If you really do, please discuss your approach here on the mailing list.
I'm sure it will be useful for others, too.
Am 04.01.2013 23:11 schrieb Marcos Mendez mar...@jitisoft.com:
thanks. i'll see if i can create a plugin to do it then.
On Jan 4, 2013, at 16:38, Anders Hammar
I seriously doubt it is possible. And even if it was, it's the wrong way to
go as there is already a standard way to handle it in Maven. And Maven is
all about conventions and not inventing your own solution.
/Anders
On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann
ok what us the maven way? if it is to have the same parent then it will not
work for me. conventions are fine until they impede.
On Jan 4, 2013, at 17:38, Anders Hammar and...@hammar.net wrote:
I seriously doubt it is possible. And even if it was, it's the wrong way to
go as there is already
Suggestions:
Dependency management: a small number of poms. In the beginning: could be
one pom.
Build behaviour: a small number of parent poms. One for each type of
artifact you're going to produce. Say: JAR, WAR. Maybe one common parent
where you define plugin versions and build behaviour which
I am currently working with a group that is migrating a group of applications
and libraries to Maven. I can’t seem to find the best way to handle the POM
versioning so I thought I would bounce that off those of you with more
experience. There are roughly 20 web apps and 10 libraries. What I am
thanks. i've done the dependency mgmt stuff. works fine and with a main import.
we actually have the poms set pretty much the way you describe. but we have a
lot of projects (diff repos and builds) and we need to change them all
correctly to update standard things which is not good. gonna
22 matches
Mail list logo
