Buen producto!!
Estimado amigo, ?Cómo está usted recientemente? decirte una gran sorpresa! Ktpshop compa?ía es una empresa de comercio electrónico de productos que ha clasificado superior Asia --- (www.ktpshop.info) y cuenta con la cooperación con Nokia, Sony, HP, etc durante muchos a?os, la calidad del producto es muy bueno. Ellos tienen una buena reputación, buena reacción muchas, y la entrega rápida. Ahora, la empresa (ktpshop.com) amplía su alcance. Gracias por los nuevos y antiguos clientes de apoyo, estos productos se venden a un descuento., un montón de amigos ya han comprado los productos de la empresa, y se elogió a los bienes, He ordenado una computadoras portátiles de Apple, Espero que no te lo pierdas. saludos! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: SNAPSHOT for parent pom versioning
I managed to get this working by having the artifactory name artifacts uniquely (with timestamp). Don't know if this is the proper way, but it's working so far. 2009/5/18 Anders Hammar > Could it be an Artifactory bug? What's the content of the > maven-metadata.xml file of the > seta.config:seta-general-configuration:1.0-SNAPSHOT artifact? > > On Mon, May 18, 2009 at 09:24, Bocalinda wrote: > > Hi Anders, > > > > Thanks a lot.. You are right, I need to specifically specify to update on > > each build. > > When I do so, I can see from Maven's output that it's trying to download > my > > POM again, but it actually isn't. > > The POM changed in the remote repository, but it remained the same local > > repository. I'm guessing this is a problem with my remote repository not > > telling Maven that the file has changed. > > > > Just in case it would be useful in some way, here is the Maven output: > > > > [INFO] Scanning for projects... > > [DEBUG] Searching for parent-POM: > > seta.config:seta-general-configuration:pom:1.0-SNAPSHOT of project: > > derivacion:Derivacion:pom:1.0 > > in relative path: ../pom.xml > > [DEBUG] Parent-POM: > seta.config:seta-general-configuration:pom:1.0-SNAPSHOT > > not found in relative path: ../pom.xml > > [DEBUG] Retrieving parent-POM: > > seta.config:seta-general-configuration:pom:1.0-SNAPSHOT for project: > > derivacion:Derivacion:pom:1.0 f > > rom the repository. > > [INFO] snapshot seta.config:seta-general-configuration:1.0-SNAPSHOT: > > checking for updates from releases > > [DEBUG] Checking for pre-existing User-Agent configuration. > > [DEBUG] Adding User-Agent configuration. > > [DEBUG] Connecting to repository: 'releases' with url: ' > > http://172.18.0.78:/artifactory/releases/< > http://172.18.0.78:/artifactory/sadiel-releases/> > > '. > > [DEBUG] Skipping disabled repository central > > [DEBUG] seta-general-configuration: using locally installed snapshot > > [DEBUG] Trying repository releases > > [DEBUG] Checking for pre-existing User-Agent configuration. > > [DEBUG] Adding User-Agent configuration. > > [DEBUG] Connecting to repository: 'releases' with url: ' > > http://172.18.0.78:/artifactory/releases/< > http://172.18.0.78:/artifactory/sadiel-releases/> > > '. > > Downloading: > > > http://172.18.0.78:/artifactory/sadiel-releases//seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0 > < > http://172.18.0.78:/artifactory/sadiel-releases//es/sadiel/seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0 > > > > -SNAPSHOT.pom > > [DEBUG] Artifact resolved > > > > It says "Downloading" but it didn't actually download anything. > > > > 2009/5/15 Anders Hammar > > > >> I think SNAPSHOTs are only updated once a day or so, not for every > >> build. You can force it through "mvn -U" or by settings updatePolicy > >> in your settings.xml: > >> > >> > http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_releases > >> > >> Here's a blog about this: > >> > >> > http://jlorenzen.blogspot.com/2008/07/maven-not-downloading-latest-snapshots.html > >> > >> /Anders > >> > >> On Fri, May 15, 2009 at 12:14, Bocalinda wrote: > >> > Hi List, > >> > > >> > According to the documentation, when specifying a version as > -SNAPSHOT, > >> > Maven downloads the artifact on each build. > >> > > >> > I specify: > >> > > >> > > >> >config > >> >seta-general-configuration > >> >1.0-SNAPSHOT > >> > > >> > > >> > and expected Maven to download the parent pom again from the > repository, > >> > however, this doesn't seem to be the case. > >> > Is this a bug, or is it not supported? > >> > > >> > I manage the parent pom, which is used in many different projects. The > >> > problem is that I am not the developer of all those projects, so if I > >> would > >> > change something in the parent pom, then I have no control over > whether > >> > people are updating the parant pom version in order to fetch te latest > >> > version. It would be much easier if I could leave it as SNAPSHOT, and > >> have > >> > Maven download it each time a build is executed. > >> > > >> > I'm using Maven 2.1.0. > >> > > >> > Thanks. > >> > > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: SNAPSHOT for parent pom versioning
Hi Anders, Thanks a lot.. You are right, I need to specifically specify to update on each build. When I do so, I can see from Maven's output that it's trying to download my POM again, but it actually isn't. The POM changed in the remote repository, but it remained the same local repository. I'm guessing this is a problem with my remote repository not telling Maven that the file has changed. Just in case it would be useful in some way, here is the Maven output: [INFO] Scanning for projects... [DEBUG] Searching for parent-POM: seta.config:seta-general-configuration:pom:1.0-SNAPSHOT of project: derivacion:Derivacion:pom:1.0 in relative path: ../pom.xml [DEBUG] Parent-POM: seta.config:seta-general-configuration:pom:1.0-SNAPSHOT not found in relative path: ../pom.xml [DEBUG] Retrieving parent-POM: seta.config:seta-general-configuration:pom:1.0-SNAPSHOT for project: derivacion:Derivacion:pom:1.0 f rom the repository. [INFO] snapshot seta.config:seta-general-configuration:1.0-SNAPSHOT: checking for updates from releases [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'releases' with url: ' http://172.18.0.78:/artifactory/releases/<http://172.18.0.78:/artifactory/sadiel-releases/> '. [DEBUG] Skipping disabled repository central [DEBUG] seta-general-configuration: using locally installed snapshot [DEBUG] Trying repository releases [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'releases' with url: ' http://172.18.0.78:/artifactory/releases/<http://172.18.0.78:/artifactory/sadiel-releases/> '. Downloading: http://172.18.0.78:/artifactory/sadiel-releases//seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0<http://172.18.0.78:/artifactory/sadiel-releases//es/sadiel/seta/config/seta-general-configuration/1.0-SNAPSHOT/seta-general-configuration-1.0> -SNAPSHOT.pom [DEBUG] Artifact resolved It says "Downloading" but it didn't actually download anything. 2009/5/15 Anders Hammar > I think SNAPSHOTs are only updated once a day or so, not for every > build. You can force it through "mvn -U" or by settings updatePolicy > in your settings.xml: > > http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_releases > > Here's a blog about this: > > http://jlorenzen.blogspot.com/2008/07/maven-not-downloading-latest-snapshots.html > > /Anders > > On Fri, May 15, 2009 at 12:14, Bocalinda wrote: > > Hi List, > > > > According to the documentation, when specifying a version as -SNAPSHOT, > > Maven downloads the artifact on each build. > > > > I specify: > > > > > >config > >seta-general-configuration > >1.0-SNAPSHOT > > > > > > and expected Maven to download the parent pom again from the repository, > > however, this doesn't seem to be the case. > > Is this a bug, or is it not supported? > > > > I manage the parent pom, which is used in many different projects. The > > problem is that I am not the developer of all those projects, so if I > would > > change something in the parent pom, then I have no control over whether > > people are updating the parant pom version in order to fetch te latest > > version. It would be much easier if I could leave it as SNAPSHOT, and > have > > Maven download it each time a build is executed. > > > > I'm using Maven 2.1.0. > > > > Thanks. > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
SNAPSHOT for parent pom versioning
Hi List, According to the documentation, when specifying a version as -SNAPSHOT, Maven downloads the artifact on each build. I specify: config seta-general-configuration 1.0-SNAPSHOT and expected Maven to download the parent pom again from the repository, however, this doesn't seem to be the case. Is this a bug, or is it not supported? I manage the parent pom, which is used in many different projects. The problem is that I am not the developer of all those projects, so if I would change something in the parent pom, then I have no control over whether people are updating the parant pom version in order to fetch te latest version. It would be much easier if I could leave it as SNAPSHOT, and have Maven download it each time a build is executed. I'm using Maven 2.1.0. Thanks.
Re: Referencing plugin properties
Hi Brian,
I don't want to set the value, I want to get the value.
According to the Maven webpage, it seems that was possible in Maven 1.
2009/5/14 Brian Fox
> You can't reference it from another property. Why don't you just set it to
> the new value?
>
> On Thu, May 14, 2009 at 11:08 AM, Bocalinda wrote:
>
> > Hi List,
> >
> > It is possible to reference pom properties with ${project.version} for
> > example.
> > But how can I reference plugin properties?
> >
> > I would like to reference the webapp directory. The property is called
> > webappDirectory, but I can't seem to get it's value.
> >
> > Thanks.
> >
>
Profile activation on project property
Hi List,
I have been struggling since a few days now with the following problem.
I want a profile to be enabled based on a project property, in my case
project.packaging.
I've tried doing this in the following way:
project.packaging
war
Unfortunately the profile is not being activated at all.
I also tried an example from the Maven Definitive Guide:
mavenVersion
2.1.0
"The property element tells Maven to activate this profile if the property
mavenVersion is set to the value 2.0.5.
mavenVersion is an implicit property that is available to all Maven
builds."
Unfortunately this isn't working either. (I changed the version to the Maven
build I am using).
I'm wondering whether it's actually possible to use project properties to
activate profiles.
According to the Maven Definitive Guide it is. This is a quote from the
books appendix:
"property
The profile will activate if Maven detects a property (a value which can be
dereferenced within the POM by ${name})
of the corresponding name=value pair."
Thinking that this could be a Maven bug, I tried versions 2.0.8, 2.0.9,
2.0.10 and 2.1.0. All show the same behavior.
I'm stuck at this and would really appreciate any input.
Thanks in advance.
Referencing plugin properties
Hi List,
It is possible to reference pom properties with ${project.version} for
example.
But how can I reference plugin properties?
I would like to reference the webapp directory. The property is called
webappDirectory, but I can't seem to get it's value.
Thanks.
Re: Cargo and multi-module projects
Btw, your solution didn't work for me (activating based on a property set in
another module). It seems that the profiles are being parsed before the
property is set in my module.
2009/5/12 Bocalinda
> Hi Jesse,
>
> As a workaround for the profile activation by packaging type, it may be an
> option to use:
>
>
>
> ${project.packaging}
> war
>
>
>
> Cheers,
>
> Pieter
>
> 2009/5/11
>
>> Hi Pieter,
>>
>>
>> On Mon, May 11, 2009 at 11:47 AM, Bocalinda wrote:
>> >
>> > What exactly do you mean by "attachment to a life cycle phase"?
>> > You mean like this:
>> >
>> >
>> >
>> >start-container
>> >pre-integration-test
>> >
>> >start
>> >deploy
>> >
>> >
>> >
>> >stop-container
>> >post-integration-test
>> >
>> >stop
>> >
>> >
>> >
>> >
>>
>> Yes, that's exactly right. Inside a profile in your super pom.xml.
>> -jesse
>>
>> --
>> There are 10 types of people in this world, those
>> that can read binary and those that can not.
>>
>
>
Re: Cargo and multi-module projects
Hi Jesse,
As a workaround for the profile activation by packaging type, it may be an
option to use:
${project.packaging}
war
Cheers,
Pieter
2009/5/11
> Hi Pieter,
>
> On Mon, May 11, 2009 at 11:47 AM, Bocalinda wrote:
> >
> > What exactly do you mean by "attachment to a life cycle phase"?
> > You mean like this:
> >
> >
> >
> >start-container
> >pre-integration-test
> >
> >start
> >deploy
> >
> >
> >
> >stop-container
> >post-integration-test
> >
> >stop
> >
> >
> >
> >
>
> Yes, that's exactly right. Inside a profile in your super pom.xml.
> -jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
Profile activation using multiple properties
Hi List, Stating from the Maven Definitive Guide: "Activations can contain one of more selectors including JDK versions, Operating System parameters, files, and properties. A profile is activated when all activation criteria has been satisfied." Unfortunately, it seems that is is not possible to specify the same criteria twice, i.e.: integracion_continua env.HUDSON_SERVER launch_cargo true It complains that there is a duplicate tag 'property'. Although this is more a suggestion than a question, I'm open for alternative solutions for what I want to do TIA.
Re: Cargo and multi-module projects
Hi Jesse, What exactly do you mean by "attachment to a life cycle phase"? You mean like this: start-container pre-integration-test start deploy stop-container post-integration-test stop P.D. Thanks for creating the JIRA case, would definitely be useful! Cheers, Pieter 2009/5/11 > Hi Bocalinda, > > On Mon, May 11, 2009 at 11:28 AM, Bocalinda wrote: > > > > Glad I'm not the only one who is trying such thing. > > Great solution you just gave me, I hope this works for me as well. > > > > Big thanks! > > You picked up on it, but, just to clearly state it this time (as I > didn't previously), the profile would contain the configuration and > attachment to a life cycle phase, of the Cargo plugin. > > Also, I've gone ahead and created a new JIRA[1] for the profile > activation by packaging type I mentioned before. I found where I > commented inside another JIRA[2], but this is worthy of its own > ticket. > > [1] http://jira.codehaus.org/browse/MNG-4154 > [2] http://jira.codehaus.org/browse/MNG-1753 > > You're welcome, :-) > -jesse > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Cargo and multi-module projects
Hi Jesse, Glad I'm not the only one who is trying such thing. Great solution you just gave me, I hope this works for me as well. Big thanks! 2009/5/11 > Hi Bocalinda, > > On Mon, May 11, 2009 at 10:28 AM, Bocalinda wrote: > > > > In order to achieve automatic testing of my projects, I use Cargo to > > automatically deploy newly generated war files to a Tomcat server. > > All the specifics to the automatic testing (depedencies, plugin > > configuration, etc) are contained inside of a super pom. > > Yep, I find myself in the same position. I don't think the Cargo > plugin is behaving badly here. Instead, you can create a profile in > your super pom which will be automatically activated by a property. > Then, in your Maven modules which are packaging=war, you can set that > property. Ideally, Maven would support profile activation by packaging > type (I believe I created a JIRA for this, or commented in an existing > Profile Enhancement type JIRA) but unfortunately it can not, yet.. > > Anyhow, the solution I propose requires the least amount of specific > per-Maven module configuration and allows the greatest amount > configuration reusability. I have had it working in my environment for > about 6 months of active development for several projects.. > > Good luck! > -jesse > > -- > There are 10 types of people in this world, those > that can read binary and those that can not. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Cargo and multi-module projects
Hi List,
In order to achieve automatic testing of my projects, I use Cargo to
automatically deploy newly generated war files to a Tomcat server.
All the specifics to the automatic testing (depedencies, plugin
configuration, etc) are contained inside of a super pom.
Because I have multitudes of projects, the super pom is quite general, thus
no specific info can be specified, such as exact war names, etc. as this
depends on the project that is being build.
Now, each project that I have specifies the super pom as it's parent, and
until now this was working great.
However, I got a project that consists out of different modules:
1. DAO jar
2. Manager jar
2. Webapp (which includes the DAO and the manager)
Now, to not have to invoke the creation of the DAO, manager and the webapp
manually, I created a parent pom which specifies out of which modules (the
dao, manager and the webapp) the project consists. This works great as well
(Really love Maven).
However, in this parent pom (which is of the type "pom") I also wanted to
include my super pom (with the generic settings for automatic testing).
And this is where the problem lies. The Cargo plugin is complaining that it
cannot create a deployable because the project is of the type "pom". Exact
error:
org.codehaus.cargo.container.ContainerException: Cannot create deployable.
There's no registered deployable for the parameters (container [id =
[default]], deployable type [pom]). Valid types for this deployable are:
- ear
- rar
- ejb
- sar
- file
- war
org.codehaus.cargo
cargo-maven2-plugin
1.0
false
tomcat5x
http://172.18.0.78/containers/apache-tomcat-5.5.27.tar.gz
${project.build.directory}
${project.build.directory}/container.log
${project.build.directory}/cargo.log
4
${project.build.directory}/container
high
${env.SERVER_PORT}
${env.SERVER_SHUTDOWN_PORT}
"-DXms=128M
-DXmx=128M"
installed
http://localhost:
${env.SERVER_PORT}/${pom.build.finalName}
3
Explicitely specifying the deployable as WAR wouldn't change a thing.
A solution I thought of was including the generic super pom in the pom which
creates the WAR, instead of the parent pom of the project.
However, the problem is that I already have a parent pom specified in the
pom which creates the WAR. And it's not possible to specify two.
I'm kind kinda out of options on this (as I am not an experienced used of
Maven), and I was hoping whether somebody could share some alternative
solutions.
TIA
