Re: Configuring Continuum to send email only in certain cases
By default, continuum send a mail if the build status is modified, so, it send a mail for build in success only if the previous build was a build in failure or error. Emmanuel javier g a écrit : Hi Is there a way to configure Continuum so it will only send email notification of a successful build *only* if the last build failed? For what I've seen so far in the documentation and the conf file, is pretty much an all-or-nothing approach. Best regards javierg
Online Gambling-Online Black Jack-Black Jack Casino-Online Slots-Slots Online
rking999 wrote:
Hi,
I am building a profile to assemble my project. However, when I add the
dir tags I get the following error:
Embedded error: Unrecognised tag: 'baseDirectory' (position: START_TAG
seen ...\n ... @7:18)
The xml is as follows:
all
dir
true
${FATTOUSH_HOME}
com.cellectivity:account
com.cellectivity:administration
com.cellectivity:bet
com.cellectivity:casino
com.cellectivity:dating
com.cellectivity:image
com.cellectivity:portal
com.cellectivity:provisioning
com.cellectivity:registration
com.cellectivity:router
com.cellectivity:vendor
webapps/${artifactId}
true
false
com.cellectivity:fattoush-app-administration
com.cellectivity:fattoush-agent-bet
com.cellectivity:fattoush-app-bet
com.cellectivity:fattoush-agent-spark
com.cellectivity:fattoush-app-dating
com.cellectivity:fattoush-app-provisioning
com.cellectivity:fattoush-app-registration
com.cellectivity:fattoush-app-account
com.cellectivity:fattoush-app-image
com.cellectivity:fattoush-product
com.cellectivity:fattoush-app-vendor
com.cellectivity:fattoush-app-portal
com.cellectivity:fattoush-app-casino
com.cellectivity:fattoush-app-partygaming
lib
true
false
Why cant I use this tag?? What am I doing wrong.
thanks in advance,
Richard
http://www.www-online-blackjack.info Online Black Jack
--
View this message in context:
http://www.nabble.com/baseDirectory-tag-unrecognised-for-assembly-tf2847389s177.html#a8121001
Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Problem with ear-plugin
On 02/01/07, Bryan Loofbourrow [EMAIL PROTECTED] wrote: A second point, one you may already know but it's not clear from your example. In general, I am pretty sure that the xxxModule configurations are only necessary when you want to configure something about that module's inclusion. The main way you tell the ear pom what you want in the ear is by including dependencies on the artifacts you want packaged up, and, yes, those dependencies are pulled from the repository. -- Bryan -Original Message- From: Petar Tahchiev [mailto:[EMAIL PROTECTED] Sent: Monday, January 01, 2007 2:01 PM To: Maven Users List Subject: Problem with ear-plugin Hi guys, Happy New Year to all of you. I have the following problem: I have a project in which I produce some jars and wars which get installed in the local repository. The in one of my modules I want to package some of those jars and wars into an ear archive, so I do this in my pom: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration modules jarModule groupIdorg.my.test.jarModules/groupId artifactIdjar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /jarModule warModule groupIdorg.my.test.warModules/groupId artifactIdwar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /warModule /modules /configuration /plugin /plugins /build but when running the build I get the following error: [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-ear-plugin:2.2 Cause: Class 'org.apache.maven.plugin.ear.EarModule' cannot be instantiated After running mvn with the -e option I get this one: org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: org.apache.maven.plugins:maven-ear-plugin. Reason: Unable to parse the created DOM for plugin configuration at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:563) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle (DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) I read in the archive to try replacing the jarModule tag with javaModule, but it didn't work - I still get the same exception. :-( So, does anyone have an idea, what is going on here? P.S. Do I need to include only modules that are submodules of the pom that builds the ear, i.e. is it obligatory for them to be submodules of my module, or they just have to be in the repository? Thanks for any help. -- Regards, Petar! Karlovo, Bulgaria. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Bryan, thank you very much for the response, I was looking at this page [1], and maybe that's why I have confused myself. It may be a bug in the documantation, or just the documentation is about version 2.4-SNAPSHOT. I tried just including my desired modules as a dependencies and it worked as expected. Again, thanks a lot. [1] http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-a-module.html -- Regards, Petar! Karlovo, Bulgaria.
Re: [ANN] Maven Plugin Plugin 2.2 Released
On 1/2/07, Brett Porter [EMAIL PROTECTED] wrote: Thanks - have you opened a corresponding plugin plugin issue? Just did it: http://jira.codehaus.org/browse/MPLUGIN-26 J
Configure java compiler fork
Hi, Is there a way to set (in the java compiler plugin) the fork value to true not through the pom.xml but using property? (something like maven.compiler.fork=true) Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE Scheduled build do not see changes in source code
HAPPY NEW YEAR yes, it is the same SCM URL for both builds. Actually, my pom file only has one scm url On 1/2/07, Guillaume BETEND [EMAIL PROTECTED] wrote: Hello all, Is your Scm Url is OK ? Cheers -- Guillaume BETEND Carlos Henriquez carlosalberto.he A [EMAIL PROTECTED] Continuum continuum-users@maven.apache.org cc 29/12/2006 21:47 Objet Scheduled build do not see changes Veuillez répondre in source code à [EMAIL PROTECTED] aven.apache.org Hi all. Merry Christmass to all the Christians and Happy New Year next monday. I have two scheduled builds with Maven projects, a clean install and a test a few minutes later. They are both done at night. The problem is that any change made to a source file is ignored by the first build but notice in the second. That happens to be a problem because the new jar is built with the old sources. What could be happening? -- Carlos Henriquez -- Carlos Henriquez Wincor-Nixdorf +58-416-839.94.28
Re: Configure java compiler fork
http://www.google.com/search?q=maven2+compiler+forkie=utf-8oe=utf-8rls=org.mozilla:en-US:officialclient=firefox-a On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote: Hi, Is there a way to set (in the java compiler plugin) the fork value to true not through the pom.xml but using property? (something like maven.compiler.fork=true) Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configure java compiler fork
I read the documentation, but I didn't see the option to set it using property. -Original Message- From: Tom Huybrechts [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 3:14 PM To: Maven Users List Subject: Re: Configure java compiler fork http://www.google.com/search?q=maven2+compiler+forkie=utf-8oe=utf-8rl s=org.mozilla:en-US:officialclient=firefox-a On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote: Hi, Is there a way to set (in the java compiler plugin) the fork value to true not through the pom.xml but using property? (something like maven.compiler.fork=true) Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-dependency-plugin from apache snapshot repo
Hello, i try to use the maven-dependency-plugin, i need the lastest snapshot
(2.0-alpha-1-SNAPSHOT) for the dependency:build-classpath goal from
http://people.apache.org/repo/m2-snapshot-repository/ (FTPluginSnaphots).
i have registered the plugin like this :
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.0-alpha-1-SNAPSHOT/version
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory
}/dependency/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
And when i launch the command mvn package, i got following messages :
-
[DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from
repository FTPluginSnaphots
[DEBUG] Skipping disabled repository central
[DEBUG] maven-resources-plugin: resolved to version
2.3-20061118.060205-2from repository FTPluginSnaphots
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::4-SNAPSHOT for project:
null:maven-resources-plugin:maven-plugin:2.3-20061118.060205-2 from the
repository.
[DEBUG] Skipping disabled repository central
[DEBUG] maven-plugins: resolved to version 4-20061029.113029-2 from
repository FTPluginSnaphots
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4 for project:
org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.maven:maven-parent:pom:4 from the repository.
[DEBUG] Skipping blacklisted repository central
[DEBUG] maven-compiler-plugin: resolved to version 2.1-SNAPSHOT from
repository FTPluginSnaphots
[DEBUG] Skipping disabled repository central
[DEBUG] maven-compiler-plugin: resolved to version
2.1-20060829.112045-2from repository FTPluginSnaphots
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::3 for
project: null:maven-compiler-plugin:maven-plugin:2.1-20060829.112045-2 from
the repository.
[DEBUG] Trying repository codehaus.org
Downloading:
http://snapshots.repository.codehaus.org//org/apache/maven/plugins/maven-plugins/3/maven-plugins-3.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: null:maven-compiler-plugin:maven-plugin:2.1-20060829.112045-2
Reason: Cannot find parent: org.apache.maven.plugins:maven-plugins for
project: null:maven-compiler-plugin:maven-plugin:2.1-20060829.112045-2
-
I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from
http://repo1.maven.org/maven2.
Is there an other way to use the apache maven-dependency-plugin, not the
codehaus one ?
Thanks
Re: maven-dependency-plugin from apache snapshot repo
On 1/2/07, Antoine Véret [EMAIL PROTECTED] wrote: And when i launch the command mvn package, i got following messages : - [DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from repository FTPluginSnaphots [DEBUG] Skipping disabled repository central ... I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from http://repo1.maven.org/maven2. Looks like Maven isn't able to connect to central at all. Are you behind a proxy? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: root project path property
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the absolute
path location of the current build working directory. Does it exist ?
If not, have you got an idea to get this piece of information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each project
in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification, I
have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or an
existing property (to do distinction between root project and module
project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: Firewall/proxy issues
I tried ntlmaps, and it won't validate me on the network. I don't really know how ntlm authentication works, but apparently the machine you're requesting from must be a member of the domain as well as the user, so that didn't work for me either. Since BASIC authentication is available, I still can't quite understand why I can't get maven to communicate using just a username/password. I've tried all the permutations of username, with and without domain. I'm curious about why maven's proxy setting doesn't seem to work essentially the same way firefox and wget and curl do, since the lightweight http client looks to me like it should. On 12/29/06, Barrie Treloar [EMAIL PROTECTED] wrote: Like I said before, my company removed basic, so it is forcing me to do NTLM. To work around this I plan to write a proxy-proxy. I will create a java program that will negotiate NTLM with the companies proxy. Just use NTLMAPS at sourceforge. http://ntlmaps.sourceforge.net/ Then point Maven at that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I'm just an unfrozen caveman software developer. I don't understand your strange, modern ways.
Re: root project path property
What do you try to do exactly?
Do you want the working directory or the path of the target directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the absolute
path location of the current build working directory. Does it exist ?
If not, have you got an idea to get this piece of information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each project
in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification, I
have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or an
existing property (to do distinction between root project and module
project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: maven-dependency-plugin from apache snapshot repo
Yes, i am behind a proxy, but i use Archiva. PS : I work with Maven 2.0.4 On 1/2/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/2/07, Antoine Véret [EMAIL PROTECTED] wrote: And when i launch the command mvn package, i got following messages : - [DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from repository FTPluginSnaphots [DEBUG] Skipping disabled repository central ... I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from http://repo1.maven.org/maven2. Looks like Maven isn't able to connect to central at all. Are you behind a proxy? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-dependency-plugin from apache snapshot repo
It seems like the compiler plugin is pulling in that version not the dependency plugin. I did notice this morning that ibiblio was a little slow, maybe it just timed out for you? -Original Message- From: Antoine Véret [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 10:48 AM To: Maven Users List Subject: Re: maven-dependency-plugin from apache snapshot repo Yes, i am behind a proxy, but i use Archiva. PS : I work with Maven 2.0.4 On 1/2/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/2/07, Antoine Véret [EMAIL PROTECTED] wrote: And when i launch the command mvn package, i got following messages : - [DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from repository FTPluginSnaphots [DEBUG] Skipping disabled repository central ... I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from http://repo1.maven.org/maven2. Looks like Maven isn't able to connect to central at all. Are you behind a proxy? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: root project path property
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir' is
managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something like
that. So I need a solution to say to maven and to my test that the root
project dir is 'continuum-install-path/apps/continuum/workingdir/1/'.
For example with a '-Droot.dir=${the.fucking.var.I.look.for}' when I
define in continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to fix
directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory. Does
it exist ? If not, have you got an idea to get this piece of
information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification, I
have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or
an existing property (to do distinction between root project and
module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: root project path property
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir' is
managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something like
that. So I need a solution to say to maven and to my test that the root
project dir is 'continuum-install-path/apps/continuum/workingdir/1/'.
For example with a '-Droot.dir=${the.fucking.var.I.look.for}' when I
define in continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to fix
directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory. Does
it exist ? If not, have you got an idea to get this piece of
information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification, I
have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or
an existing property (to do distinction between root project and
module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: maven-dependency-plugin from apache snapshot repo
A simple mvn -U package has clean the dependencies. Thanks mister Héritier. PS : the mvn package command works with the lastest Apache version, contrary to the mvn dependency:build-classpath command which call the Codehaus plugin. On 1/2/07, Brian E. Fox [EMAIL PROTECTED] wrote: It seems like the compiler plugin is pulling in that version not the dependency plugin. I did notice this morning that ibiblio was a little slow, maybe it just timed out for you? -Original Message- From: Antoine Véret [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 10:48 AM To: Maven Users List Subject: Re: maven-dependency-plugin from apache snapshot repo Yes, i am behind a proxy, but i use Archiva. PS : I work with Maven 2.0.4 On 1/2/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/2/07, Antoine Véret [EMAIL PROTECTED] wrote: And when i launch the command mvn package, i got following messages : - [DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from repository FTPluginSnaphots [DEBUG] Skipping disabled repository central ... I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from http://repo1.maven.org/maven2. Looks like Maven isn't able to connect to central at all. Are you behind a proxy? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Antoine Véret Mobile : 06.20.31.14.05 Fixe : 08.73.07.73.76
Re: root project path property
Thx but that does not work ... continuum does not expand the '.' in some
valid path.
I also try -Droot.dir=`pwd` but it does not work too :(
And I try a strange var named '${curr-scm-root}' who does not work ...
Some other ideas ? :)
Emmanuel Venisse a écrit :
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir' is
managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something
like that. So I need a solution to say to maven and to my test that
the root project dir is
'continuum-install-path/apps/continuum/workingdir/1/'. For example
with a '-Droot.dir=${the.fucking.var.I.look.for}' when I define in
continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to
fix directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory.
Does it exist ? If not, have you got an idea to get this piece of
information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification,
I have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or
an existing property (to do distinction between root project and
module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
RE: maven-dependency-plugin from apache snapshot repo
Yes, when the plugin is released, we'll have to update the metadata so it uses the apache version. -Original Message- From: Antoine Véret [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 11:38 AM To: Maven Users List Subject: Re: maven-dependency-plugin from apache snapshot repo A simple mvn -U package has clean the dependencies. Thanks mister Héritier. PS : the mvn package command works with the lastest Apache version, contrary to the mvn dependency:build-classpath command which call the Codehaus plugin. On 1/2/07, Brian E. Fox [EMAIL PROTECTED] wrote: It seems like the compiler plugin is pulling in that version not the dependency plugin. I did notice this morning that ibiblio was a little slow, maybe it just timed out for you? -Original Message- From: Antoine Véret [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 10:48 AM To: Maven Users List Subject: Re: maven-dependency-plugin from apache snapshot repo Yes, i am behind a proxy, but i use Archiva. PS : I work with Maven 2.0.4 On 1/2/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/2/07, Antoine Véret [EMAIL PROTECTED] wrote: And when i launch the command mvn package, i got following messages : - [DEBUG] maven-resources-plugin: resolved to version 2.3-SNAPSHOT from repository FTPluginSnaphots [DEBUG] Skipping disabled repository central ... I doesn't understand why the maven-plugins-3.pom couldn't get retrieved from http://repo1.maven.org/maven2. Looks like Maven isn't able to connect to central at all. Are you behind a proxy? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Antoine Véret Mobile : 06.20.31.14.05 Fixe : 08.73.07.73.76 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
External repositories listed in centrally deployed poms?
Note: I know this sounds a bit like whining. As a point to generate discussion, I'd like to take a pulse of the group (and vent a tiny bit). Having profound difficulty getting maven past my companies firewall, I'm forced to jump through tiny flaming hoops in order to get even the simplest builds to work. Currently, it involves what is probably a Career Limiting Decision on my part, namely that I duplicate my internal repository setup at home using Proximity and take the source home with me to acquire the required assets using an unrestricted internet connection. I then bring the caches assets back into the office and deploy them to our internal proximity instance. Needless to say, this is cumbersome, fraught with peril, and not something I'd like to keep doing, but it's working (mostly). As a basis for discussion, I assert the following as given: 1. Maven needs to be accepted in enterprise computing environments for growth purposes. 2. Most, and all in my experience, enterprise computing environments live firmly entrenched behind firewalls. 3. Navigating beyond firewalls seems hit-and-miss (I never used to think this, until it started happening to me and I started paying attention to other peoples problems with it). 4. In a commercial environment, it is especially important to control what assets that are accessible to developers, generally for legal reasons. 5. Once a maven application's codebase reaches a certain size, it becomes even more important and difficult to control those assets due to transitive dependencies. 6. Every enterprise group I've dealt with for maven use (5 now) have no intention of allowing their developers free and open access to Internet based resources. 7. Using an inward-facing caching proxy (like Archive or Proximity or the maven-proxy) is the correct solution to the problems spawned by #3 and #4 I recently acquired a dependency from central that had a dependency (also in central), that depends on artifacts (in central) but which defines (apparently unnecessary) external repositories within the dependency's parent POM. Why is this such a big deal? Because it means that in order to prevent the build from failing (non-catastrophically), it's necessary to pick through a series of parent poms and mirror any listed repositories internally because I'm mandated to maintain a tight lockdown on assets. Since it's difficult for me to acquire these assets while I'm in the office, this isn't that big of a deal as long as I don't mind the build failing. And solving the issue (this time) was very simple, but it does mean that I'm mirroring central on the same data cache as the indicated repository (codehaus in this case), which may come back to bite my behind some day. My solution: Central's server (although not necessarily central itself) mirrors many (but not all) of the major publicly accessible repos (dev java net, eclipse, codehaus, etc). Please don't deploy poms into central that list external repositories when the dependencies they would acquire from the external repo are available on central. I'm all for making the build fully portable (even though I obviously can't do that from work), but making the build less brittle is also one of the basic drivers for using maven, IMO. If you're using a distributable dependency, send it on to central and remove other repositories from that. It minimizes the impact to those of us unfortunate enough to be forced to manually manage their dependency sets and go through reams of paperwork to attempt unhindered access to m2 repos. Is codehaus expected to be generally accessible as a repository? I seem to recall something about plugins heading off to codehaus for assets, but I can't seem to locate it right now. If so, I'll need to modify my proxy a bit. Anyone have any alternative solutions to this? Comments on my set of givens above? Good oatmeal cookie recipes?
Re: root project path property
It doesn't work?? Where do you set it? in the build definition, right?
B. De Mezzo a écrit :
Thx but that does not work ... continuum does not expand the '.' in some
valid path.
I also try -Droot.dir=`pwd` but it does not work too :(
And I try a strange var named '${curr-scm-root}' who does not work ...
Some other ideas ? :)
Emmanuel Venisse a écrit :
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir' is
managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something
like that. So I need a solution to say to maven and to my test that
the root project dir is
'continuum-install-path/apps/continuum/workingdir/1/'. For example
with a '-Droot.dir=${the.fucking.var.I.look.for}' when I define in
continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to
fix directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory.
Does it exist ? If not, have you got an idea to get this piece of
information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the modification,
I have done onto an ant-style property, is not visible back in maven.
- Using profiles to set a property according to an existing file or
an existing property (to do distinction between root project and
module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: Configure java compiler fork
I'm sorry, it looks like I didn't read your question well enough :)
If you look at the compile goal documentation, you can see the fork parameter.
You can only set something from the commandline if you see an
'expression' attribute here with value ${some.key}. Since this is not
available for fork, you're out of luck.
You could try to fake it, by configuring the compiler plugin in your
project with
fork${fork}/fork
You can also set a propertiesforktrue/fork/properties as a
default in your pom.
Then you can specify -Dfork=true|false from the commandline.
Tom
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
I read the documentation, but I didn't see the option to set it using
property.
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 3:14 PM
To: Maven Users List
Subject: Re: Configure java compiler fork
http://www.google.com/search?q=maven2+compiler+forkie=utf-8oe=utf-8rl
s=org.mozilla:en-US:officialclient=firefox-a
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
Hi,
Is there a way to set (in the java compiler plugin) the fork value to
true not through the pom.xml but using property?
(something like maven.compiler.fork=true) Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[M2] 'legacy' in repo configuration is not working as expected
Hi, I want to use our existing m1 repository with m2. I configured the repository as legacy style, but it only works with a 'flat' hierarchy, because m2 builds the downloadurl without replacing the points of the groupid. groupIdfoo.bar/groupId artifactIdbaz/artifactId version0.815/version will be computed to /reponame/foo.bar/jars/baz-0.815.jar (wrong) instead of /reponame/foo/bar/jars/baz-0.815.jar (right) Has anybody an idea how i can get this to work (if its possible)? Thanks regards, Volker -- View this message in context: http://www.nabble.com/-M2--%27legacy%27-in-repo-configuration-is-not-working-as-expected-tf2908899s177.html#a8127030 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: root project path property
I set it in a build definition on the 'argument' line: '--batch-mode
-Droot.dir=.'
In my pom.xml I put some ant code at the 'validate' phase where if do a
'echo message=root dir = ${root.dir} /' and so I get, in the root
project and its sub-project, this output: 'root dir = .'. In conclusion
it seems it does not interprete nor expand the '.' like any shell
should. This is confirmed when I put '-Droot.dir=`pwd`', the output was
'root dir = `pwd`' ... funny, no ?
Still looking for a solution ! :(
Emmanuel Venisse a écrit :
It doesn't work?? Where do you set it? in the build definition, right?
B. De Mezzo a écrit :
Thx but that does not work ... continuum does not expand the '.' in
some valid path.
I also try -Droot.dir=`pwd` but it does not work too :(
And I try a strange var named '${curr-scm-root}' who does not work ...
Some other ideas ? :)
Emmanuel Venisse a écrit :
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir'
is managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something
like that. So I need a solution to say to maven and to my test that
the root project dir is
'continuum-install-path/apps/continuum/workingdir/1/'. For example
with a '-Droot.dir=${the.fucking.var.I.look.for}' when I define in
continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to
fix directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target
directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory.
Does it exist ? If not, have you got an idea to get this piece
of information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the
modification, I have done onto an ant-style property, is not
visible back in maven.
- Using profiles to set a property according to an existing file
or an existing property (to do distinction between root project
and module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: root project path property
I don't see an other solution with an env var. For me, '.' is a valid
directory, it's isn't an absolute path, but it's correct because your in the
working directory.
What is the result if you use ${basedir} in your pom?
You can try ${project.build.directory}/..
${project.build.directory} is the target directory
Emmanuel
B. De Mezzo a écrit :
I set it in a build definition on the 'argument' line: '--batch-mode
-Droot.dir=.'
In my pom.xml I put some ant code at the 'validate' phase where if do a
'echo message=root dir = ${root.dir} /' and so I get, in the root
project and its sub-project, this output: 'root dir = .'. In conclusion
it seems it does not interprete nor expand the '.' like any shell
should. This is confirmed when I put '-Droot.dir=`pwd`', the output was
'root dir = `pwd`' ... funny, no ?
Still looking for a solution ! :(
Emmanuel Venisse a écrit :
It doesn't work?? Where do you set it? in the build definition, right?
B. De Mezzo a écrit :
Thx but that does not work ... continuum does not expand the '.' in
some valid path.
I also try -Droot.dir=`pwd` but it does not work too :(
And I try a strange var named '${curr-scm-root}' who does not work ...
Some other ideas ? :)
Emmanuel Venisse a écrit :
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This 'svn-checkouted-dir'
is managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or something
like that. So I need a solution to say to maven and to my test that
the root project dir is
'continuum-install-path/apps/continuum/workingdir/1/'. For example
with a '-Droot.dir=${the.fucking.var.I.look.for}' when I define in
continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than to
fix directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target
directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory.
Does it exist ? If not, have you got an idea to get this piece
of information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the
modification, I have done onto an ant-style property, is not
visible back in maven.
- Using profiles to set a property according to an existing file
or an existing property (to do distinction between root project
and module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
Re: [m2] any tips for site internationalization ?
Happy New Year to everyone ! Dennis, Thanks for the info. In fact I was aware of this issue already, but since it was taking too long to get it fixed, I decided to check whether anyone had a workaround. Anyway it turned out that I found why site internationalization was not working for brazilian portuguese (pt_BR) and most likely german too. That was because their properties files from maven-site-plugin and maven-project-info-reports-plugin were using UTF-8 as default encoding instead of ISO-8859-1. After updating them manually in my local repository, I could get my site internationalized. I've decided to make that change because Velocity uses ISO-8859-1 as input and output encoding. Besides if you take a look at the french and spanish properties files, you'll see their enconding are ISO-8859-1 as well. I hope this encoding issue gets fixed in the next site plugin release. Dário dennisl-2 wrote: Dário Oliveros wrote: Hi there, I've been struggling to generate a fully internationalized website and I was wondering if anyone was able to get it working. Any tips ? FYI, my site source files (located at site/xdoc directory) have ISO-8859-1 encoding and my site.xml, UTF-8. And my maven-site-plugin settings are localespt_br/locales and outputEncodingUTF-8/outputEncoding. However, every time the site is generated, the left side menu (site.xml) and the project info characters are messed up. It has something to do with encoding, but I am not able to figure it out. Any help is welcome. Dário You might find something helpful in this issue: http://jira.codehaus.org/browse/MSITE-19 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--any-tips-for-site-internationalization---tf2898463s177.html#a8127461 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven-changes-plugin - icons are not being displayed
Hi there, The maven-changes-plugin report generated by running 'mvn site' does not display any icon of add, update or fix (from changes.xml). Any clues ? Is this a known bug ? Thanks, Dário -- View this message in context: http://www.nabble.com/-m2--maven-changes-plugin---icons-are-not-being-displayed-tf2909037s177.html#a8127483 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any tips for site internationalization ?
Happy New Year to everyone ! Dennis, Thanks for the info. In fact I was aware of this issue already, but since it was taking too long to get it fixed, I decided to check whether anyone had a workaround. Anyway it turned out that I found why site internationalization was not working for brazilian portuguese (pt_BR) and most likely german too. That was because their properties files from maven-site-plugin and maven-project-info-reports-plugin were using UTF-8 as default encoding instead of ISO-8859-1. After updating them manually in my local repository, I could get my site internationalized. I've decided to make that change because Velocity uses ISO-8859-1 as input and output encoding. Besides if you take a look at the french and spanish properties files, you'll see their enconding are ISO-8859-1 as well. I hope this encoding issue gets fixed in the next site plugin release. Dário -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: sábado, 30 de dezembro de 2006 12:05 To: Maven Users List Subject: Re: [m2] any tips for site internationalization ? Dário Oliveros wrote: Hi there, I've been struggling to generate a fully internationalized website and I was wondering if anyone was able to get it working. Any tips ? FYI, my site source files (located at site/xdoc directory) have ISO-8859-1 encoding and my site.xml, UTF-8. And my maven-site-plugin settings are localespt_br/locales and outputEncodingUTF-8/outputEncoding. However, every time the site is generated, the left side menu (site.xml) and the project info characters are messed up. It has something to do with encoding, but I am not able to figure it out. Any help is welcome. Dário You might find something helpful in this issue: http://jira.codehaus.org/browse/MSITE-19 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: root project path property
The problem with 'basedir' and 'project.build.directory' is their value
change according to the sub-project. It always is the current working
dir. But in my case I need the main root dir, even in the sub-project.
If maven or ant can manage some recursive programming, I could do a
piece of code using the 'project.parent.basedir' property but it doesn't !!
Also, I can override a property value within an ant code (but the new
value is not transfered back to maven) but not in a maven part ... strange.
I fell sick of that ... see you tomorrow !
BDM.
Emmanuel Venisse a écrit :
I don't see an other solution with an env var. For me, '.' is a valid
directory, it's isn't an absolute path, but it's correct because your
in the working directory.
What is the result if you use ${basedir} in your pom?
You can try ${project.build.directory}/..
${project.build.directory} is the target directory
Emmanuel
B. De Mezzo a écrit :
I set it in a build definition on the 'argument' line: '--batch-mode
-Droot.dir=.'
In my pom.xml I put some ant code at the 'validate' phase where if do
a 'echo message=root dir = ${root.dir} /' and so I get, in the
root project and its sub-project, this output: 'root dir = .'. In
conclusion it seems it does not interprete nor expand the '.' like
any shell should. This is confirmed when I put '-Droot.dir=`pwd`',
the output was 'root dir = `pwd`' ... funny, no ?
Still looking for a solution ! :(
Emmanuel Venisse a écrit :
It doesn't work?? Where do you set it? in the build definition, right?
B. De Mezzo a écrit :
Thx but that does not work ... continuum does not expand the '.' in
some valid path.
I also try -Droot.dir=`pwd` but it does not work too :(
And I try a strange var named '${curr-scm-root}' who does not work ...
Some other ideas ? :)
Emmanuel Venisse a écrit :
You can try -Droot.dir=.
continuum start maven in the working directory so '.' is correct
Emmanuel
B. De Mezzo a écrit :
During the test phase, I need some property files located in
'svn-checkouted-dir/conf' (for example). This
'svn-checkouted-dir' is managed by continuum and is on the form :
'continuum-install-path/apps/continuum/workingdir/1/' or
something like that. So I need a solution to say to maven and to
my test that the root project dir is
'continuum-install-path/apps/continuum/workingdir/1/'. For
example with a '-Droot.dir=${the.fucking.var.I.look.for}' when I
define in continuum a 'build definition' to run maven.
Obviously, I rather prefere to use a property or an env var than
to fix directly in my pom.xml the current path used by continuum ...
Thx !
BDM.
Emmanuel Venisse a écrit :
What do you try to do exactly?
Do you want the working directory or the path of the target
directory?
Emmanuel
B. De Mezzo a écrit :
B. De Mezzo a écrit :
hello,
I am looking for a property to pass througth maven to get the
absolute path location of the current build working directory.
Does it exist ? If not, have you got an idea to get this piece
of information ?
Thx,
BDM.
update:
- ${basedir} is not a good solution because it changes for each
project in multi-module project.
- And when I use a piece of ant code within maven (in some
configurationtask.../task/configuration), the
modification, I have done onto an ant-style property, is not
visible back in maven.
- Using profiles to set a property according to an existing
file or an existing property (to do distinction between root
project and module project levels) does not work too ...
I am becoming disappointed ...
HHEEELLLPPP :)
Thx,
BDM.
[m2] maven-changes-plugin - icons are not being displayed
Hi there, The changes report generated by running 'mvn site' does not display any icon of add, update or fix (from changes.xml). Any clues ? Is this a known bug ? Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Dashboard report available?
I would like to create a multi project dashboard report like the one in m1.0.2 Is this possible? -- Thanks DJ MICK http://www.djmick.com http://www.myspace.com/mickknutson
Re: JBoss EJB3 and Maven
First of all, i want to wish you all a Happy new year and thanks for every reply!! Well, i gone after Better Builds with Maven and that helped-me to find myself how could i do this with Maven kind of deployment with Maven but, sadly, i'm still facing some issues. I've split my project into 3 modules and packaged the root-project as a POM which is inherited by every sub module in this project. So, my directory structure is something like that: project | web ( created with maven archetype webapp ) | pom.xml ejb ( created as an ordinary maven archetype project) | pom.xml ear ( empty except by the pom.xml) | pom.xml |pom.xml But when i go for /project/mvn package, the ear seems to include only a previous installed version of my web/target/project.war which must be installed previously at my local repo by project/web/mvn install. There is a way i can do this whole process by a project/mvn deploy command, or something as simple as that? Sorry about taking so long for replying but i went away for some days and about the length of this email. Thanks about every reply! Best Regards, Vitor Pellegrino - there goes project/pom.xml project modules moduleear/module moduleejb/module /modules dependencies dependency groupIdorg.apache.struts/groupId artifactIdstruts2-core/artifactId version2.0.2-SNAPSHOT/version /dependency dependency groupIdorg.apache.struts/groupId artifactIdstruts2-sitemesh-plugin/artifactId version2.0.2-SNAPSHOT/version /dependency /dependencies /project project/ejb/pom.xml ?xml version=1.0? project parent artifactIdproject/artifactId groupIdcom.project/groupId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdejb/artifactId nameejb/name ... dependencies ... /dependencies /project project/web/pom.xml project artifactIdweb/artifactId packagingwar/packaging namewebapp/name dependencies dependency groupIdcom.project/groupId artifactIdejb/artifactId version1.0-SNAPSHOT/version scopeprovided/scope exclusions exclusion groupIdjboss/groupId artifactIdjboss-ejb3x/artifactId /exclusion /exclusions /dependency ... /dependencies ... /project project/ear/pom.xml project artifactIdear/artifactId packagingear/packaging nameear/name build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration modules ejbModule groupIdcom.project/groupId artifactIdejb/artifactId bundleFileName ejb-1.0-SNAPSHOT.ejb3 /bundleFileName /ejbModule webModule groupIdcom.project/groupId artifactIdweb/artifactId contextRoot/project/contextRoot /webModule /modules /configuration /plugin /plugins /build dependencies dependency groupIdcom.project/groupId artifactIdejb/artifactId version1.0-SNAPSHOT/version typeejb/type exclusions exclusion groupIdjboss/groupId artifactIdjboss-ejb3x/artifactId /exclusion /exclusions /dependency dependency groupIdcom.project/groupId artifactIdweb/artifactId version1.0-SNAPSHOT/version typewar/type /dependency /dependencies /project On 12/28/06, Alexander Sack [EMAIL PROTECTED] wrote: I'm not following. It IS a JAR and there is nothing special about it other than the annotations which is only relevant at deployment time to the container. One of the major design goals of EJB3 is to have less overhead with respect to the number of deployment artifacts and to be more POJO centric. The current Maven EJB plugin as I understand it is written to alleviate the complexities of the side artifacts one would normally have to create when creating older version EJB based applications. There is a usage mismatch (I could be wrong) between the current Maven EJB plugin and EJB3 deployments (or at least JBoss EJB3 deployments, I won't speak for other containers). Finally, JBoss specifically treats EJB3 based applications as simple JARs (you can deploy EJB3's in JAR format without including them in an EAR and the Eclipse based EJB3 plugin is last I checked simple classpath containers pointing to the appropriate EJB3 JBoss
[M2] Adding latest version of a dependency
Hello, I am using 3.2 version of Hibernate in a project and I wish to add this to my pom. However Hibernate 3.2 isn't in the Maven repository. Is there a way I can add 3.2 to the pom and have Maven download all the dependencies? Thanks a lot. Andy Birchall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Adding latest version of a dependency
You'll need to manually add the Hibernate jar files to your local Maven repo or your corporate Maven (using install or deploy), depending on your situation. Then you can use normal dependencies. Wayne On 1/2/07, Andrew Birchall [EMAIL PROTECTED] wrote: Hello, I am using 3.2 version of Hibernate in a project and I wish to add this to my pom. However Hibernate 3.2 isn't in the Maven repository. Is there a way I can add 3.2 to the pom and have Maven download all the dependencies? Thanks a lot. Andy Birchall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-j2me-plugin support for CDC
I see that the maven-j2me-plugin supports: CLDC (connected limited device configuration) MIDP (mobile information device profile) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-j2me-plugin support for CDC
I see that the maven-j2me-plugin supports: CLDC (connected limited device configuration) MIDP (mobile information device profile ) ( http://mojo.codehaus.org/j2me-maven-plugin/introduction.html ) Are there any plans to add support for: CDC ( Connected Device Configuration ) FP ( Foundation Profile ) PBP ( Personal Basis Profile ) PP ( Personal Profile ) ( http://developers.sun.com/techtopics/mobility/personal/articles/pbp_pp/ ) -Stephen More - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configure java compiler fork
Thank you for your help,
I'm not sure I understand why the plugin doesn't support in configuring
it using a property.
In any case, I have changed both the maven-embedder and
maven-compiler-plugin (it is a matter of changing xml file. How easy ;-)
)
...and now it works
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 7:07 PM
To: Maven Users List
Subject: Re: Configure java compiler fork
I'm sorry, it looks like I didn't read your question well enough :)
If you look at the compile goal documentation, you can see the fork
parameter.
You can only set something from the commandline if you see an
'expression' attribute here with value ${some.key}. Since this is not
available for fork, you're out of luck.
You could try to fake it, by configuring the compiler plugin in your
project with fork${fork}/fork You can also set a
propertiesforktrue/fork/properties as a default in your pom.
Then you can specify -Dfork=true|false from the commandline.
Tom
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
I read the documentation, but I didn't see the option to set it using
property.
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 3:14 PM
To: Maven Users List
Subject: Re: Configure java compiler fork
http://www.google.com/search?q=maven2+compiler+forkie=utf-8oe=utf-8;
rl s=org.mozilla:en-US:officialclient=firefox-a
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
Hi,
Is there a way to set (in the java compiler plugin) the fork value
to true not through the pom.xml but using property?
(something like maven.compiler.fork=true) Thanks
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] 'legacy' in repo configuration is not working as expected
I'd look at Apache url rewriting to convert those foo.bar into foo/bar urls. Wayne On 1/2/07, fuvo [EMAIL PROTECTED] wrote: Hi, I want to use our existing m1 repository with m2. I configured the repository as legacy style, but it only works with a 'flat' hierarchy, because m2 builds the downloadurl without replacing the points of the groupid. groupIdfoo.bar/groupId artifactIdbaz/artifactId version0.815/version will be computed to /reponame/foo.bar/jars/baz-0.815.jar (wrong) instead of /reponame/foo/bar/jars/baz-0.815.jar (right) Has anybody an idea how i can get this to work (if its possible)? Thanks regards, Volker -- View this message in context: http://www.nabble.com/-M2--%27legacy%27-in-repo-configuration-is-not-working-as-expected-tf2908899s177.html#a8127030 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configure java compiler fork
Go ahead and submit a JIRA RFE if you want these changes to possibly
be reflected in a future build of those plugins...
Wayne
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
Thank you for your help,
I'm not sure I understand why the plugin doesn't support in configuring
it using a property.
In any case, I have changed both the maven-embedder and
maven-compiler-plugin (it is a matter of changing xml file. How easy ;-)
)
...and now it works
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 7:07 PM
To: Maven Users List
Subject: Re: Configure java compiler fork
I'm sorry, it looks like I didn't read your question well enough :)
If you look at the compile goal documentation, you can see the fork
parameter.
You can only set something from the commandline if you see an
'expression' attribute here with value ${some.key}. Since this is not
available for fork, you're out of luck.
You could try to fake it, by configuring the compiler plugin in your
project with fork${fork}/fork You can also set a
propertiesforktrue/fork/properties as a default in your pom.
Then you can specify -Dfork=true|false from the commandline.
Tom
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
I read the documentation, but I didn't see the option to set it using
property.
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 3:14 PM
To: Maven Users List
Subject: Re: Configure java compiler fork
http://www.google.com/search?q=maven2+compiler+forkie=utf-8oe=utf-8;
rl s=org.mozilla:en-US:officialclient=firefox-a
On 1/2/07, Rahamim, Zvi (Zvi) [EMAIL PROTECTED] wrote:
Hi,
Is there a way to set (in the java compiler plugin) the fork value
to true not through the pom.xml but using property?
(something like maven.compiler.fork=true) Thanks
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] any tips for site internationalization ?
Hi Dario, If you're reasonably convinced these encodings are invalid, please open a JIRA bug so someone can resolve them. Wayne On 1/2/07, Dário Oliveros [EMAIL PROTECTED] wrote: Happy New Year to everyone ! Dennis, Thanks for the info. In fact I was aware of this issue already, but since it was taking too long to get it fixed, I decided to check whether anyone had a workaround. Anyway it turned out that I found why site internationalization was not working for brazilian portuguese (pt_BR) and most likely german too. That was because their properties files from maven-site-plugin and maven-project-info-reports-plugin were using UTF-8 as default encoding instead of ISO-8859-1. After updating them manually in my local repository, I could get my site internationalized. I've decided to make that change because Velocity uses ISO-8859-1 as input and output encoding. Besides if you take a look at the french and spanish properties files, you'll see their enconding are ISO-8859-1 as well. I hope this encoding issue gets fixed in the next site plugin release. Dário dennisl-2 wrote: Dário Oliveros wrote: Hi there, I've been struggling to generate a fully internationalized website and I was wondering if anyone was able to get it working. Any tips ? FYI, my site source files (located at site/xdoc directory) have ISO-8859-1 encoding and my site.xml, UTF-8. And my maven-site-plugin settings are localespt_br/locales and outputEncodingUTF-8/outputEncoding. However, every time the site is generated, the left side menu (site.xml) and the project info characters are messed up. It has something to do with encoding, but I am not able to figure it out. Any help is welcome. Dário You might find something helpful in this issue: http://jira.codehaus.org/browse/MSITE-19 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--any-tips-for-site-internationalization---tf2898463s177.html#a8127461 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dashboard report available?
Yes. Go back to m1.0.2. ;-) In all seriousness, no one has created a similar dashboard (yet) for M2, at least I haven't seen it yet myself. Wayne On 1/2/07, Mick Knutson [EMAIL PROTECTED] wrote: I would like to create a multi project dashboard report like the one in m1.0.2 Is this possible? -- Thanks DJ MICK http://www.djmick.com http://www.myspace.com/mickknutson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
I believe the Maven dev team has a fairly strict all dependencies should exist on Central policy for their own artifacts (don't quote me). However it is unreasonable to expect that all artifacts in Central depend solely on other artifacts available on Central. I agree with you in principle -- I just don't see it happening in the real world. I'm not quite sure how you deal with the following issue: Artifact ABC lives in java.net repo ABC pom.xml points to java.net repo for its dependencies (X, Y, and Z) Java.net repo is mirrored to Central ABC pom.xml on Central now points to java.net repo for its dependencies, although they should generally also exist on Central due to the mirroring Or would you expect the mirror java.net to Central process to alter all the pom files and remove the java.net repo references? Wayne On 1/2/07, Mykel Alvis [EMAIL PROTECTED] wrote: Note: I know this sounds a bit like whining. As a point to generate discussion, I'd like to take a pulse of the group (and vent a tiny bit). Having profound difficulty getting maven past my companies firewall, I'm forced to jump through tiny flaming hoops in order to get even the simplest builds to work. Currently, it involves what is probably a Career Limiting Decision on my part, namely that I duplicate my internal repository setup at home using Proximity and take the source home with me to acquire the required assets using an unrestricted internet connection. I then bring the caches assets back into the office and deploy them to our internal proximity instance. Needless to say, this is cumbersome, fraught with peril, and not something I'd like to keep doing, but it's working (mostly). As a basis for discussion, I assert the following as given: 1. Maven needs to be accepted in enterprise computing environments for growth purposes. 2. Most, and all in my experience, enterprise computing environments live firmly entrenched behind firewalls. 3. Navigating beyond firewalls seems hit-and-miss (I never used to think this, until it started happening to me and I started paying attention to other peoples problems with it). 4. In a commercial environment, it is especially important to control what assets that are accessible to developers, generally for legal reasons. 5. Once a maven application's codebase reaches a certain size, it becomes even more important and difficult to control those assets due to transitive dependencies. 6. Every enterprise group I've dealt with for maven use (5 now) have no intention of allowing their developers free and open access to Internet based resources. 7. Using an inward-facing caching proxy (like Archive or Proximity or the maven-proxy) is the correct solution to the problems spawned by #3 and #4 I recently acquired a dependency from central that had a dependency (also in central), that depends on artifacts (in central) but which defines (apparently unnecessary) external repositories within the dependency's parent POM. Why is this such a big deal? Because it means that in order to prevent the build from failing (non-catastrophically), it's necessary to pick through a series of parent poms and mirror any listed repositories internally because I'm mandated to maintain a tight lockdown on assets. Since it's difficult for me to acquire these assets while I'm in the office, this isn't that big of a deal as long as I don't mind the build failing. And solving the issue (this time) was very simple, but it does mean that I'm mirroring central on the same data cache as the indicated repository (codehaus in this case), which may come back to bite my behind some day. My solution: Central's server (although not necessarily central itself) mirrors many (but not all) of the major publicly accessible repos (dev java net, eclipse, codehaus, etc). Please don't deploy poms into central that list external repositories when the dependencies they would acquire from the external repo are available on central. I'm all for making the build fully portable (even though I obviously can't do that from work), but making the build less brittle is also one of the basic drivers for using maven, IMO. If you're using a distributable dependency, send it on to central and remove other repositories from that. It minimizes the impact to those of us unfortunate enough to be forced to manually manage their dependency sets and go through reams of paperwork to attempt unhindered access to m2 repos. Is codehaus expected to be generally accessible as a repository? I seem to recall something about plugins heading off to codehaus for assets, but I can't seem to locate it right now. If so, I'll need to modify my proxy a bit. Anyone have any alternative solutions to this? Comments on my set of givens above? Good oatmeal cookie recipes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring Continuum to send email only in certain cases
Hi Is there a way to configure Continuum so it will only send email notification of a successful build *only* if the last build failed? For what I've seen so far in the documentation and the conf file, is pretty much an all-or-nothing approach. Best regards javierg
deploying to remote repository
Hi, I need a bit of help installing a third party plugin into an internal repository. I know that I need to be using some form of the following: mvn deploy:deploy-file -DpomFile= http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.pom\ -DrepositoryId=csa-repository \ -Durl=url-of-the-repositor-to-deploy \ -Dfile=jta-1.0.1B.jar a few questions about the above: 1. Can I point to jta's POM that's sitting on the central repository or do I need to create my own? 2. What is a repositor and what is its url? 3. Am I on the right track at all? thanks Dmitry
Re: [m2] maven-changes-plugin - icons are not being displayed
Dário Luís Coneglian Oliveros wrote: Hi there, The changes report generated by running 'mvn site' does not display any icon of add, update or fix (from changes.xml). Any clues ? Is this a known bug ? Thanks, Dário It's working for me. See also the Sample Changes Report that is generated for the plugin site for a working example: http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it possible to have version${cur.Version}/version
Hi All
Is that possible to have
groupIdtest/groupId
artifactIdtest/artifactId
version${cur.Version}/version
relativePath../../pom.xml/relativePath
where i define cur.Version=1.0 in properties section,
I tried to doing it, it worked but when it uploded pom to remote repsitory
pom file was not replaced by ${cur.Version}value from properties
Thanks,
Raghurajan Gurunathan
-
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
Re: Is it possible to have version${cur.Version}/version
I created a profile.xml and added a version there:
profile
idunix/id
activation
property
nameenv/name
valueunix/value
/property
/activation
properties
envqa/env
default.project.version2.1.5/default.project.version
compiler.debugtrue/compiler.debug
property.configurer.location.path${
property.configurer.location.path.unix}/property.configurer.location.path
property.configurer.location${
property.configurer.location.unix}/property.configurer.location
/properties
/profile
/profiles
On 1/2/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi All
Is that possible to have
groupIdtest/groupId
artifactIdtest/artifactId
version${cur.Version}/version
relativePath../../pom.xml/relativePath
where i define cur.Version=1.0 in properties section,
I tried to doing it, it worked but when it uploded pom to remote repsitory
pom file was not replaced by ${cur.Version}value from properties
Thanks,
Raghurajan Gurunathan
-
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
--
Thanks
DJ MICK
http://www.djmick.com
http://www.myspace.com/mickknutson
Re: External repositories listed in centrally deployed poms?
Wayne Fay wrote: Or would you expect the mirror java.net to Central process to alter all the pom files and remove the java.net repo references? I think that they should not contain explicit location references at all, relying instead on the locations defined in the poms traversed previously in your transitive dependency search. I also think that the maven proxy solution should be advocated, if not required, and that the maven proxy should be an integral part of maven, not something fabricated by third parties. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
On 1/2/07, Wayne Fay [EMAIL PROTECTED] wrote: I believe the Maven dev team has a fairly strict all dependencies should exist on Central policy for their own artifacts (don't quote me). However it is unreasonable to expect that all artifacts in Too late! GMail quoted you! It wasn't me! You're certainly right about the reality of the situation, but it has definitely come up at the last three sites I've worked as a concern of management, not of the developers. In my current case, it's the current version of the site plugin that depends on jetty that defines additional repos in it's parent's pom. It doesn't depend on them, it just defines them. All of the artifacts needed are mirrored to central, but probably not at development time and likely not at deployment time, which is probably very convenient from outside this oubliette I'm working in now. I know that I certainly haven't ever had an issue with it until I ended up behind a firewall with no way out. Finally, of course, it's a part of the overall the metadata needs to improve thread that runs through the lists occasionally. I'm not quite sure how you deal with the following issue: Artifact ABC lives in java.net repo ABC pom.xml points to java.net repo for its dependencies (X, Y, and Z) Java.net repo is mirrored to Central ABC pom.xml on Central now points to java.net repo for its dependencies, although they should generally also exist on Central due to the mirroring For my purposes, depending on how complex the issue was, I'd probably redeploy the artifact on my internal repositories with a modified pom. Much like the way I'm doing it now, it's clearly not optimal but it does allow me to limit my remote accesses. If it's a lot of stuff to host, then it's a lot of stuff to deal with and that's just that. It's not that I won't do the hosting, I just want to be able to automate the process of it. Using a proxy, I can build a locally accessible cache that doesn't need to make outside trips. Frankly, I simply don't see the need for the several multiple remotes. I undertand the motivation behind them (i.e. control), but I don't necessarily agree with it. Since there's not an Accept this pom segment of the maven build process, if the pom is off a bit (or worse, blatantly wrong) you're left with tracking down what's awry in the project metadata. This was one thing maven helps us avoid. I suppose that's whey they call it work and pay us to do it... :) Or would you expect the mirror java.net to Central process to alter all the pom files and remove the java.net repo references? I'm not sure what I expect, other than that I have ideals that I never expect to reach. :) Ideally, any artifact deployed to central would have a pom that precisely defines its dependencies and nothing else. We implicitly depend a great deal on these dependencies during the course of development, and admittedly I often took them at face value until quite recently. But my latest job has driven home the need to maintain tight control on the dependency chains and anything that opens that up is anathema to my current happiness. The focus on central is obviously because of it's implict inclusion in the super pom. Effectively, it's difficult to remove central as a repo, and therefore isn't something you'd do lightly. Thus anything unnecessary that makes an artifact from central more complex is u. an unncessary complexity. :) Mykel On 1/2/07, Mykel Alvis [EMAIL PROTECTED] wrote: Note: I know this sounds a bit like whining. As a point to generate discussion, I'd like to take a pulse of the group (and vent a tiny bit).
Re: deploying to remote repository
You first need to define your internal repository representation and how you plan to host it. This can be as simple as a file:// reference on disk, an ftp server, dav server, etc. You must first answer this question Have you determined how you plan to host this repository? I suggest using apache and DAV, since updating maven 2.0.4 to have dav-capable deployments is relatively simple. http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV The decision of how to host a 3rd party repo isn't as straightforward as it might seem, but Apache+DAV has been my preferred solution since the first time I got it working. On 1/2/07, Dmitry Beransky [EMAIL PROTECTED] wrote: Hi, I need a bit of help installing a third party plugin into an internal repository. I know that I need to be using some form of the following: mvn deploy:deploy-file -DpomFile= http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.pom\ -DrepositoryId=csa-repository \ -Durl=url-of-the-repositor-to-deploy \ -Dfile=jta-1.0.1B.jar a few questions about the above: 1. Can I point to jta's POM that's sitting on the central repository or do I need to create my own? 2. What is a repositor and what is its url? 3. Am I on the right track at all? thanks Dmitry -- I'm just an unfrozen caveman software developer. I don't understand your strange, modern ways.
Re: [M2] 'legacy' in repo configuration is not working as expected
I don't understand your problem. If you are in a legacy repo (m1), a group like foo.bar is a unique directory foo.bar. It's only with a m2 layout that you have a subdirectory bar in the directory foo. For maven 1 or maven 2 with a legacy repo a dependency : groupIdfoo.bar/groupId artifactIdbaz/artifactId version0.815/version is translated to : /reponame/foo.bar/jars/baz-0.815.jar With m2, the dependency is : /reponame/foo/bar/baz/0.815/baz-0.815.jar Arnaud On 1/2/07, Wayne Fay [EMAIL PROTECTED] wrote: I'd look at Apache url rewriting to convert those foo.bar into foo/bar urls. Wayne On 1/2/07, fuvo [EMAIL PROTECTED] wrote: Hi, I want to use our existing m1 repository with m2. I configured the repository as legacy style, but it only works with a 'flat' hierarchy, because m2 builds the downloadurl without replacing the points of the groupid. groupIdfoo.bar/groupId artifactIdbaz/artifactId version0.815/version will be computed to /reponame/foo.bar/jars/baz-0.815.jar (wrong) instead of /reponame/foo/bar/jars/baz-0.815.jar (right) Has anybody an idea how i can get this to work (if its possible)? Thanks regards, Volker -- View this message in context: http://www.nabble.com/-M2--%27legacy%27-in-repo-configuration-is-not-working-as-expected-tf2908899s177.html#a8127030 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JBoss EJB3 and Maven
helllo, my 2 cents a wild guessm ight be that your web project is not child of your com.project if your web project java files didnt change at all then it's normal that you'd have an earlier version .. try mvn clean install and see what happens otherwise.. this is what is in your ear dependency groupIdcom.project/groupId artifactIdweb/artifactId version1.0-SNAPSHOT/version typewar/type /dependency i didnt see a groupId in the pom.xml of your web.project was it an omission? or your web.project has too groupIdcom.project/groupId hth marco On 1/2/07, Vitor Pellegrino [EMAIL PROTECTED] wrote: First of all, i want to wish you all a Happy new year and thanks for every reply!! Well, i gone after Better Builds with Maven and that helped-me to find myself how could i do this with Maven kind of deployment with Maven but, sadly, i'm still facing some issues. I've split my project into 3 modules and packaged the root-project as a POM which is inherited by every sub module in this project. So, my directory structure is something like that: project | web ( created with maven archetype webapp ) | pom.xml ejb ( created as an ordinary maven archetype project) | pom.xml ear ( empty except by the pom.xml) | pom.xml |pom.xml But when i go for /project/mvn package, the ear seems to include only a previous installed version of my web/target/project.war which must be installed previously at my local repo by project/web/mvn install. There is a way i can do this whole process by a project/mvn deploy command, or something as simple as that? Sorry about taking so long for replying but i went away for some days and about the length of this email. Thanks about every reply! Best Regards, Vitor Pellegrino - there goes project/pom.xml project modules moduleear/module moduleejb/module /modules dependencies dependency groupIdorg.apache.struts/groupId artifactIdstruts2-core/artifactId version2.0.2-SNAPSHOT/version /dependency dependency groupIdorg.apache.struts/groupId artifactIdstruts2-sitemesh-plugin/artifactId version2.0.2-SNAPSHOT/version /dependency /dependencies /project project/ejb/pom.xml ?xml version=1.0? project parent artifactIdproject/artifactId groupIdcom.project/groupId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdejb/artifactId nameejb/name ... dependencies ... /dependencies /project project/web/pom.xml project artifactIdweb/artifactId packagingwar/packaging namewebapp/name dependencies dependency groupIdcom.project/groupId artifactIdejb/artifactId version1.0-SNAPSHOT/version scopeprovided/scope exclusions exclusion groupIdjboss/groupId artifactIdjboss-ejb3x/artifactId /exclusion /exclusions /dependency ... /dependencies ... /project project/ear/pom.xml project artifactIdear/artifactId packagingear/packaging nameear/name build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration modules ejbModule groupIdcom.project/groupId artifactIdejb/artifactId bundleFileName ejb-1.0-SNAPSHOT.ejb3 /bundleFileName /ejbModule webModule groupIdcom.project/groupId artifactIdweb/artifactId contextRoot/project/contextRoot /webModule /modules /configuration /plugin /plugins /build dependencies dependency groupIdcom.project/groupId artifactIdejb/artifactId version1.0-SNAPSHOT/version typeejb/type exclusions exclusion groupIdjboss/groupId artifactIdjboss-ejb3x/artifactId /exclusion /exclusions /dependency dependency groupIdcom.project/groupId artifactIdweb/artifactId version1.0-SNAPSHOT/version typewar/type /dependency /dependencies /project On 12/28/06, Alexander Sack [EMAIL PROTECTED] wrote: I'm not following. It IS a JAR and there is nothing special about it other than the annotations which is only relevant at deployment time to the container. One of the major design
unable to get latest SNAPSHOT jars
I have established our own local repository for our snapshot versions, and updates are successfully pushed to it when when we 'mvn deploy'. When we 'mvn package' the first time, we get the jars and POMs just fine. However, after that first download, we can never get updated versions of those artifacts. Here is an example dependency: dependency groupIdicentris-iliad/groupId artifactIdcore/artifactId version1.0.2007.01.02-SNAPSHOT/version /dependency Here's our repository definition in our multimodule pom.xml: repository idlocal2/id urlhttp://soa.dev.hq.icentris:10757/repository2/url snapshots enabledtrue/enabled /snapshots /repository Here's some output when I try to force an update (with 'mvn package -U')... although it doesn't acutally do anything: [INFO] snapshot icentris-iliad:legacy-bridge:1.0.2007.01.02-SNAPSHOT: checking for updates from ibiblio [INFO] snapshot icentris-iliad:legacy-bridge:1.0.2007.01.02-SNAPSHOT: checking for updates from local2 Our current workaround is to remove the whole ~/.m2/repository folder before we build. Any ideas are welcome. Thanks! Trent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
4. In a commercial environment, it is especially important to control what assets that are accessible to developers, generally for legal reasons. and I often took them at face value until quite recently. But my latest job has driven home the need to maintain tight control on the dependency chains and anything that opens that up is anathema to my current happiness. The focus on central is obviously because of it's implict inclusion in the super pom. Effectively, it's difficult to remove central as a repo, and therefore isn't something you'd do lightly. Thus anything unnecessary that makes an artifact from central more complex is u. an unncessary complexity. :) I still maintain, as I have said in other threads, you should audit not enforce lock down. By attempting to control and lock down what can and can't be downloaded you are just asking for trouble. It is far easier to assume that your developers are competent and using sanctioned versions of artifacts and to audit this fact. Only when the audit fails do you fix the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java.lang.IncompatibleClassChangeError When Running Mojo?
Hi, I have a really strange thing happening. I narrowed my mojo code down to this (This is all that is in the execute body: Model model = PomFactory.eINSTANCE.createModel(); //model.setVersion(sss); Model is just a representation of the pom root element. The mojo runs fine if all I do is create a Model. If I uncommment the model.setVersion(sss); part. And even if I turn on the stack traces with -e, all I get still is: java.lang.IncompatibleClassChangeError at org.jpackage.XML2SpecMojoImpl.execute(XML2SpecMojoImpl.java:100) If I test the model.setVersion outside of the mojo, it runs fine. I've also tried the following: - Deleted all the mojo imports and verifying them to be correct, after narrowing the code the only imports I have are: import org.apache.maven.model.Model; import org.apache.maven.model.PomFactory; import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; - Deleted the entire m2 repository, and let Maven repopulate it. Any ideas? Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
On 1/2/07, Barrie Treloar [EMAIL PROTECTED] wrote: 4. In a commercial environment, it is especially important to control what assets that are accessible to developers, generally for legal reasons. and I often took them at face value until quite recently. But my latest job has I still maintain, as I have said in other threads, you should audit not enforce lock down. Why is that? It doesn't seem a particularly valid method in my current environment, but I'm willing to listen. I think my developers are competent for the most part, given that they're a fairly large group broken into several pieces. But essentially to a (gender-nonspecific pronoun) they are not competent with maven, build processes in general or the reasons behind the controls associated with those processes. I disagree about the lockdown vs. audit question, but I don't completely disagree...except when I'm obligated to do otherwise by the terms of my employment. Like at each commercial environment that I've worked in for the last several years. I think audits usually work to handle dependency issues, and recommended them prior to release. But my current working dependency set is now over 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of times before I got here an artifact slipped through the audit cracks so caching proxies are the only choice that I can see. I'm charged with working on an accepted asset list that would scan checked in poms and report checkins that had dependencies not on the list, but that's a few steps down the to-do list. I should also note that there was no instance of distribution of disallowed artifacts at previous employers, but they had identical policies. IANAL, but I do try to keep up with the legalities associated with licensing and if you're a largish firm that sells software and somebody catches on that you've distributed something unacceptably then it's your buttocks in the fire. That fire would also, very likely, include the firing of me. :) As for locking down what can and can't be downloaded, it's a moot point. Even while I've been mandated to restrict maven's use of external repos, I can't help but do it since maven can't actually reach external repos from any build host that isn't part of the domain (which includes my entire build farm). :( -- I'm just an unfrozen caveman software developer. I don't understand your strange, modern ways.
Re: External repositories listed in centrally deployed poms?
Just would like to add my agreement with Mykel's position. The problem is that you can have the best developers in your world, and still get screwed by one guy outside accidentally including a dependency with encumbering licensing. That's the big drawback of the automatic inclusion of transitive dependencies. I am very lucky to be in an environment where I actually can download anything fron anywhere, but I still remain uncomfortable with this aspect of maven. For one, I need to trust the community that it won't change anything down the road, and furthermore I need to keep snapshots of the repository image for reliable build reproduction purposes. I believe running maven without at least some proxy setup is asking for trouble, even in the most liberal environment. -- cg Mykel Alvis wrote: I still maintain, as I have said in other threads, you should audit not enforce lock down. Why is that? It doesn't seem a particularly valid method in my current environment, but I'm willing to listen. I think my developers are competent for the most part, given that they're a fairly large group broken into several pieces. But essentially to a (gender-nonspecific pronoun) they are not competent with maven, build processes in general or the reasons behind the controls associated with those processes. I disagree about the lockdown vs. audit question, but I don't completely disagree...except when I'm obligated to do otherwise by the terms of my employment. Like at each commercial environment that I've worked in for the last several years. I think audits usually work to handle dependency issues, and recommended them prior to release. But my current working dependency set is now over 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of times before I got here an artifact slipped through the audit cracks so caching proxies are the only choice that I can see. I'm charged with working on an accepted asset list that would scan checked in poms and report checkins that had dependencies not on the list, but that's a few steps down the to-do list. I should also note that there was no instance of distribution of disallowed artifacts at previous employers, but they had identical policies. IANAL, but I do try to keep up with the legalities associated with licensing and if you're a largish firm that sells software and somebody catches on that you've distributed something unacceptably then it's your buttocks in the fire. That fire would also, very likely, include the firing of me. :) As for locking down what can and can't be downloaded, it's a moot point. Even while I've been mandated to restrict maven's use of external repos, I can't help but do it since maven can't actually reach external repos from any build host that isn't part of the domain (which includes my entire build farm). :( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
native2ascii
Hi,
I'm trying to run the native2ascii Ant task. Running 'mvn compile' I get:
java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
This suggests that tools.jar isn't added to the classpath. However, I have it
in my pom.xml:
project xmlns=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.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdclaywiki/groupId
artifactIdclaywiki-utils/artifactId
packagingjar/packaging
version0.0.4-SNAPSHOT/version
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
trimStackTracefalse/trimStackTrace
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idcompile/id
phasecompile/phase
configuration
tasks
taskdef name=native2ascii
classname=org.apache.tools.ant.taskdefs.optional.Native2Ascii
classpathref=maven.dependency.classpath
classpath
pathelement path=maven.dependency.classpath /
pathelement
location=${java.home}/../lib/tools.jar /
/classpath
/taskdef
native2ascii encoding=UTF-8 dest=src/test/resources
src=src/test/resources includes=**/*.UTF-8
ext=.properties /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdant/groupId
artifactIdant-nodeps/artifactId
version1.6.5/version
/dependency
/dependencies
/plugin
/plugins
/build
/project
Thanks,
-S.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: External repositories listed in centrally deployed poms?
I still maintain, as I have said in other threads, you should audit not enforce lock down. Why is that? It doesn't seem a particularly valid method in my current environment, but I'm willing to listen. From my understanding, Maven currently has no capabilities to lock down these artifacts so if you want such a solution you need to go through the burning hoops you are suggesting and even then I don't think you will get to the solution you desire. I often find the desire to lock down and control is a knee jerk reaction to a trust/knowledge issue and that the amount of up front effort required to put these controls in place far outweighs the benefits especially when any problems are exceptions not the norm. Your goal is to verify that your projects are using sanctioned artifacts. The reasons for this are likely: 1) to provide a stable architecture which you can test against 2) ensure license conformance Option 1) Somehow lock down maven to only use the sanctioned versions Effort: Huge Option 2) Automate the audit process to confirm that your projects use sanctioned versions Effort: Less than Huge. So I would choose to automate the audit process because it is less effort. The bonus being I have a report that shows the results of the audit, with a lock down approach there may be some way to circumvent the lock down. The only environments I can't see this working for are high security environments with trusted/untrusted networks. I don't have a solution for that. I think my developers are competent for the most part, given that they're a fairly large group broken into several pieces. But essentially to a (gender-nonspecific pronoun) they are not competent with maven, build processes in general or the reasons behind the controls associated with those processes. I have the same problem but for the most part they don't need to know this level of details. They can get away with mvn eclipse:eclipse and the dependencies correctly setup by a configuration controller or the solution architect of the project and defined in parent poms. But providing training is always a good thing because the developers really should have an appreciation of this process. I disagree about the lockdown vs. audit question, but I don't completely disagree...except when I'm obligated to do otherwise by the terms of my employment. Like at each commercial environment that I've worked in for the last several years. I think audits usually work to handle dependency issues, and recommended them prior to release. But my current working dependency set is now over 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of times before I got here an artifact slipped through the audit cracks so caching proxies are the only choice that I can see. I'm charged with working on an accepted asset list that would scan checked in poms and report checkins that had dependencies not on the list, but that's a few steps down the to-do list. An artifact slipping through the cracks is most likely the result of oversight by someone. It would take a super-human effort to manually audit 1000 artifacts with zero defects. IANAL, but I do try to keep up with the legalities associated with licensing and if you're a largish firm that sells software and somebody catches on that you've distributed something unacceptably then it's your buttocks in the fire. That fire would also, very likely, include the firing of me. :) There has been talk before about a license manager/scanner. Since all of the artifacts on the repositories are open source the only problem would be if the license was one of those that cause your developed software to also become open source and this is the type of thing that a licence report could provide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: native2ascii
There have been a few posts on this list concerning native2ascii
recently... Search the list and you might find some tips/help for your
specific troubles, or perhaps a sample pom that works.
Wayne
On 1/2/07, _Random_ [EMAIL PROTECTED] wrote:
Hi,
I'm trying to run the native2ascii Ant task. Running 'mvn compile' I get:
java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
This suggests that tools.jar isn't added to the classpath. However, I have it
in my pom.xml:
project xmlns=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.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdclaywiki/groupId
artifactIdclaywiki-utils/artifactId
packagingjar/packaging
version0.0.4-SNAPSHOT/version
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
trimStackTracefalse/trimStackTrace
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idcompile/id
phasecompile/phase
configuration
tasks
taskdef name=native2ascii
classname=org.apache.tools.ant.taskdefs.optional.Native2Ascii
classpathref=maven.dependency.classpath
classpath
pathelement path=maven.dependency.classpath /
pathelement
location=${java.home}/../lib/tools.jar /
/classpath
/taskdef
native2ascii encoding=UTF-8 dest=src/test/resources
src=src/test/resources includes=**/*.UTF-8
ext=.properties /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdant/groupId
artifactIdant-nodeps/artifactId
version1.6.5/version
/dependency
/dependencies
/plugin
/plugins
/build
/project
Thanks,
-S.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to have version${cur.Version}/version
I think the property value should be substituted properly if you
deploy the artifact to a repository, though perhaps not when it is
installed.
Give that a try and report back.
Wayne
On 1/2/07, Mick Knutson [EMAIL PROTECTED] wrote:
I created a profile.xml and added a version there:
profile
idunix/id
activation
property
nameenv/name
valueunix/value
/property
/activation
properties
envqa/env
default.project.version2.1.5/default.project.version
compiler.debugtrue/compiler.debug
property.configurer.location.path${
property.configurer.location.path.unix}/property.configurer.location.path
property.configurer.location${
property.configurer.location.unix}/property.configurer.location
/properties
/profile
/profiles
On 1/2/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi All
Is that possible to have
groupIdtest/groupId
artifactIdtest/artifactId
version${cur.Version}/version
relativePath../../pom.xml/relativePath
where i define cur.Version=1.0 in properties section,
I tried to doing it, it worked but when it uploded pom to remote repsitory
pom file was not replaced by ${cur.Version}value from properties
Thanks,
Raghurajan Gurunathan
-
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
--
Thanks
DJ MICK
http://www.djmick.com
http://www.myspace.com/mickknutson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
