It is meant to be under a classifier of "all", the problem is that the
profile has no way of adding that to the deployment just yet. I've
already filed a JIRA.
I prefer *.model.v3_0_0 in general. I used o.a.m.project so that it
could be used in Maven 1.1 without any backwards compatibility issues.
dan tran wrote:
Hi Andy, it is the correct behavior, ${finalName} is used only on your local
${maven.build.dir} but when maven try to install/deploy to remote
remote, it uses the enforced naming. ${artifactid}-${version}.${ext}
There were similar discussions on war plugin in the last couple wee
Hi Andy, it is the correct behavior, ${finalName} is used only on your local
${maven.build.dir} but when maven try to install/deploy to remote
remote, it uses the enforced naming. ${artifactid}-${version}.${ext}
There were similar discussions on war plugin in the last couple weeks.
-D
On 9/7/05
Andy Glick wrote:
Wanted to let you know that I just did an install build and the artifact
does appear in the target directory with the final name as assigned in
the profile "maven-model-2.0-beta-1-SNAPSHOT-all.jar" but the version
name installed in maven.repo.local was different and was miss
Brett Porter wrote:
Sorry for the confusion - I was referring to the modello plugin
configuration:
Wanted to let you know that I just did an install build and the artifact does appear in the target
directory with the final name as assigned in the profile
"maven-model-2.0-beta-1-SNAPSHOT-all.
At 11:48 AM 9/7/2005, you wrote:
Sorry for the confusion - I was referring to the modello plugin
configuration:
Thanks, that worked. I appreciate your help.
A quick question, if I might?
In M1, the V3 Model code lives in a package named org.apache.maven.project.
In the repoclean code, and i
Sorry for the confusion - I was referring to the modello plugin
configuration:
all-models
allmodels.enabled
true
${pom.artifactId}-${pom.version}-all
org.codehaus.modello
modello-maven-plugin
Brett Porter wrote:
This is correct, you just need to add the element to the profile
(another regression I encountered during the process).
Hope that's everything, sorrry for the run around.
Brett, sorry, but its not everything. If there is existing documentation that
shows how to add a mod
Andy Glick wrote:
>
> But when I filled it in:
>
>
> all-models
>
>
> allmodels.enabled
> true
>
>
>
> and invoked m2 as follows:
>
> m2 -Dallmodels.enabled=true generate-sources
>
> I encountered the error trace listed below.
This is correct
Brett Porter wrote:
The way I got it to work was to add a property activator inside the
profile and to set that property from the command line.
Would you mind providing an example of what worked for you? I looked at the
Build Profiles page at http://docs.codehaus.org/display/MAVEN/Build+Pro
Hi Andy,
When I tried this the other day, it didn;t work at all (as you might
recall I said I got sidetracked - this was it). I filed it in JIRA - I
don't believe profiles are being properly activated in the current code
from settings or the command line.
The way I got it to work was to add a pro
I've seen 2 different behaviors while working in the maven-model subproject
today when I executed m2.
A number of times, consistently, some hours ago I could execute
m2 -P all-models generate-sources
and find that the following source trees had been created
org.apache.maven.model and subdirec
It is coming through from the modello plugin. It is a really crappy
situation which we need to sort out before the next modello release as
it has introduced dependencies for some other applications that maven
doesn't need.
You can rollback to alpha-2 of the modello plugin until we get it sorte
Hi,
I am trying to update my Eclipse workspace and "m2 eclipse:eclipse" is
blowing up while generating eclipse project for "maven-model". Attached
is the output for the execution. I think the artifact:
"http://www.ibiblio.org/maven2//servletapi/servlet/2.4/servlet-2.4.pom";
is incorrect - the
14 matches
Mail list logo
