The Mojo team is pleased to announce the release of the Localization
Tools Maven Plugin version 1.0-alpha-1. This is the first release of
this plugin.
The Localization Tools Maven Plugin helps with internationalization and
localization of your projects.
Read more about it on the website:
dependencyManagement doesn't work for this scenario. I get this:
[INFO] [dependency:unpack {execution: default}]
[INFO] Configured Artifact: my.group.id:my-artifact:?:zip
I should have seen this:
[INFO] [dependency:unpack {execution: default}]
[INFO] Configured Artifact: my.group.id:my-artifact
Oops, I spoke too soon, even though there was "?" it still used the
correct version. Thanks.
On Sat, Mar 15, 2008 at 7:21 AM, deckrider <[EMAIL PROTECTED]> wrote:
> dependencyManagement doesn't work for this scenario. I get this:
>
> [INFO] [dependency:unpack {execution: default}]
> [INFO] Con
I'm responsible for the technical architecture of many projects at my
location. One project in particular (still in active development with
code released to production) will likely never upgrade past 2.0.4
because of the changes to dependency resolution. Although these
changes are a good thing, p
Well these questions are directed at the entire mailing list.
I do appreciate all the energy you've put into this.
We started work on a series of plugins because of how little is known about
this particular one (can I submit changes to the documentation that helped
me?), but I'd hate to manage
I do want to point out that "14" is not the version of "ojdbc". It's
the J2SE version that that jar supports; "classes12" is for java 1.2,
ojdbc14 is for java 1.4, ojdbc5 and ojdbc 6 are for java 5 and 6
respectively. You should probably be referencing the jars as
com.oracle
ojdbc14
Hello,
am trying to mavenize an existing ant based projet. One of the
caracteristics of the project is it's source tree organization
modules/x/src/...
modules/y/src/...
modules/z/src/...
I thought first of using maven modules for this, but the dependency
graph makes it impossible (x depends
> (can I submit changes to the documentation that helped me?),
Yes, we love patches to docs. Naturally the users are best at pointing
out what's wrong or confusing. Just attach the patch to a jira.
>but I'd hate to manage a plugin that is pretty much a duplicate of what
is offered out of the box
Hi,
I had this problem earlier trying to migrate from ant.
I had sources in src/java and src/util.
What I did is put the to src and put includes and
excludes in the maven-compiler-plugin configuration.
So for you it would be modules in sourceDirectory and then
x/src/**/*.java
y/src/**/*.j
My gut feeling is that remote-resources is NOT the plugin to be used for
this. remote-resources will only process specific files in the bundle
and only if the bundle is properly created with the
remote-resources:bundle goal. It also only fills in properties/values
that are specifically se
have a look at the buildhelper-maven-plugin at org.codehaus.mojo
it has the ability to add multiple source paths the "right" way rather
than your hack
Sent from my iPod
On 15 Mar 2008, at 16:55, "Cyril Ledru" <[EMAIL PROTECTED]> wrote:
Hi,
I had this problem earlier trying to migrate from
Jack
this is a critical point
in my 2.0.8 distro located at $M2_HOME/archetype/pom.xml I have this
maven2.0 I have the following profile configuration..
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.
Hi Matthew,
Authentication defined in settings.xml is a supported feature: your problem is
surprising.
Can you attach your pom.xml, simplified as much as possible, and settings.xml
(and strike your password, of course) to let me see?
Can you send the "ant -v" output too? It should contain "Usin
Eugene Kuleshov on 14/03/08 19:41, wrote:
deckrider wrote:
By the way, I like have a multi-module project like this:
pom.xml
foo/pom.xml
bar/pom.xml
...
I like that I can check this out of Subversion as a Maven project
using this same structure so that it does not become individual
Eclipse pr
I don't follow...what's the bug here?
-Original Message-
From: Martin Gainty [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 15, 2008 4:57 PM
To: [EMAIL PROTECTED]
Cc: Maven Users List
Subject: Re: [POLL] Why are you not able to use the most recent maven
release?
Jack
this is a critical
>I'm responsible for the technical architecture of many projects at my
>location. One project in particular (still in active development with
>code released to production) will likely never upgrade past 2.0.4
>because of the changes to dependency resolution. Although these
>changes are a good
16 matches
Mail list logo