RE: Creating an exploded ear file.

[a.prabhu]

I also want to know how to deploy to auto-deploy of weblogic in exploded
format using maven.

Presently we run 'mvn clean install' which creates ear. We run a batch file
to explode this ear and copy this exploded ear to the autodeploy directory.
If we have java changes, we do 'mvn compile' on java source files and then
copy the java files ('com') into the autodeploy and touch the REDEPLOY file
to trigger auto-deploy.

I would like to improve/automat this as lot of steps above are manual (like
running batch file to explode, copying, touching the file etc.)

Any help on this ?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Creating-an-exploded-ear-file-tp80817p3330081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Copying dependencies' binaries (dlls) for runtime

[Brett Porter]

Resources are for things packaged and to be used at runtime - that doesn't 
sound like what you want here.

This is typically done with a combination of the dependecy & assembly plugin.

You might also be interested in NPanday (http://incubator.apache.org/npanday/) 
which provides several .NET specific plugins if that's the flavour of DLL you 
are dealing with.

- Brett

On 06/01/2011, at 11:22 AM, Phillip Hellewell wrote:

> On Wed, Jan 5, 2011 at 4:32 PM, Phillip Hellewell  wrote:
>> 
>> My question now is, if I want to define the  in a separate
>> stand-alone xml file (actually there will be more than one), rather
>> than in the pom.xml, what code/class do I use to read an xml file into
>> a java.util.List of org.apache.maven.model.Resource?
> 
> Would it work to take read the  tag from my XML, surround
> it with or whatever to make it a
> valid pom, and then use the MavenXpp3Reader to parse that?
> 
> I think I found the code where it parses a Resource, and obviously I
> don't want to duplicate that code in my own plugin:
> 
> http://maven.apache.org/ref/2.0.11/xref/org/apache/maven/model/io/xpp3/MavenXpp3Reader.html#4474
> 
> Phillip
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: mvn deploy and password encryption

[Steve Cohen]

I figured that that must be the case.

Do you have any idea why this would fail?  Could the 3.0.1 vs. 2.2.1 
thing be involved or MUST it be that I'm making a mistake I just can't see?




On 01/05/2011 05:04 PM, Benjamin Bentmann wrote:

Steve Cohen wrote:


Another thing I notice is that

mvn -ep {password}

when run several times in succession generates different encryptions
each time.


This is correct/expected, the encrypted value is also based on a random
salt.


Benjamin

-
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: Copying dependencies' binaries (dlls) for runtime

[Phillip Hellewell]

On Wed, Jan 5, 2011 at 4:32 PM, Phillip Hellewell  wrote:
>
> My question now is, if I want to define the  in a separate
> stand-alone xml file (actually there will be more than one), rather
> than in the pom.xml, what code/class do I use to read an xml file into
> a java.util.List of org.apache.maven.model.Resource?

Would it work to take read the  tag from my XML, surround
it with or whatever to make it a
valid pom, and then use the MavenXpp3Reader to parse that?

I think I found the code where it parses a Resource, and obviously I
don't want to duplicate that code in my own plugin:

http://maven.apache.org/ref/2.0.11/xref/org/apache/maven/model/io/xpp3/MavenXpp3Reader.html#4474

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Copying dependencies' binaries (dlls) for runtime

[Phillip Hellewell]

On Wed, Jan 5, 2011 at 4:24 PM, khaido  wrote:
>
> You might want to look at the 
> maven-dependency-plugin(http://maven.apache.org/plugins/maven-dependency-plugin/).
>   Nice if you also need the transitive dependencies.  Also unpack makes it 
> nice to work with zip files.

Thanks.  I'm actually already using the dependency plugin to copy and
unpack the dependencies from the local repo to below
target\dependency.  But now I need to take a subset of those (the dlls
needed for runtime) and copy them from target\dependency\bin to
target\bin.

I'm thinking of writing my own plugin to do the copying, because I
need some additional logic.  Looking at the mojos in the
maven-resources-plugin, it looks like I can use shared code from
org.apache.maven.shared.filtering to do most of the work for me.

My question now is, if I want to define the  in a separate
stand-alone xml file (actually there will be more than one), rather
than in the pom.xml, what code/class do I use to read an xml file into
a java.util.List of org.apache.maven.model.Resource?

Thanks,
Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Copying dependencies' binaries (dlls) for runtime

[khaido]

You might want to look at the 
maven-dependency-plugin(http://maven.apache.org/plugins/maven-dependency-plugin/).
  Nice if you also need the transitive dependencies.  Also unpack makes it nice 
to work with zip files.



From: Phillip Hellewell [via Maven] 
[mailto:ml-node+3329689-622232288-147...@n5.nabble.com]
Sent: Wednesday, January 05, 2011 2:52 PM
To: Khai Do
Subject: Copying dependencies' binaries (dlls) for runtime

Is it appropriate / best practice to use the maven-resources-plugin to
copy dlls from target\dependency\bin to target\bin so they will be
where I need them for runtime?

Thanks,
Phillip

-
To unsubscribe, e-mail: [hidden 
email]
For additional commands, e-mail: [hidden 
email]



View message @ 
http://maven.40175.n5.nabble.com/Copying-dependencies-binaries-dlls-for-runtime-tp3329689p3329689.html
To start a new topic under Maven - Users, email 
ml-node+40176-907978382-147...@n5.nabble.com
To unsubscribe from Maven - Users, click 
here.

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Copying-dependencies-binaries-dlls-for-runtime-tp3329689p3329746.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: mvn deploy and password encryption

[Benjamin Bentmann]

Steve Cohen wrote:


Another thing I notice is that

mvn -ep {password}

when run several times in succession generates different encryptions
each time.


This is correct/expected, the encrypted value is also based on a random 
salt.



Benjamin

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Copying dependencies' binaries (dlls) for runtime

[Phillip Hellewell]

Is it appropriate / best practice to use the maven-resources-plugin to
copy dlls from target\dependency\bin to target\bin so they will be
where I need them for runtime?

Thanks,
Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: mvn deploy and password encryption

[Steve Cohen]

On 01/05/2011 04:36 PM, Steve Cohen wrote:

I am, for the first time, trying to use a nexus repository. I have read
all the information here:
http://maven.apache.org/guides/mini/guide-encryption.html on password
encryption and to the best of my knowledge, have followed it correctly
and set up my setting.xml, settings-security.xml and pom file correctly
to enable deployment.

And yet, when I try to deploy something to my repository, I get 401 errors.

The one question I am having is that I am using maven 3.0.1, whereas the
repo may be expecting 2.2.1. Would this make a difference here, and how
can I debug the situation?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




Another thing I notice is that

mvn -ep {password}

when run several times in succession generates different encryptions 
each time.  Yet the instructions tell you to add the encrypted value to 
the settings file.  Can this be right, or will several different 
encryptions yield the same unencrypted pw when decrypted?




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

mvn deploy and password encryption

[Steve Cohen]

I am, for the first time, trying to use a nexus repository.  I have read 
all the information here: 
http://maven.apache.org/guides/mini/guide-encryption.html on password 
encryption and to the best of my knowledge, have followed it correctly 
and set up my setting.xml, settings-security.xml and pom file correctly 
to enable deployment.


And yet, when I try to deploy something to my repository, I get 401 errors.

The one question I am having is that I am using maven 3.0.1, whereas the 
repo may be expecting 2.2.1.  Would this make a difference here, and how 
can I debug the situation?


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One project depends on another, how to declare dependency, again...

[Zac Thompson]

Since you say "I always want bar to use the latest release of foo"
then you might as well release them together.

http://www.sonatype.com/books/mvnex-book/reference/multimodule.html

Or, if you feel it's not appropriate to have them be part of the same
project (for example, if 'foo' changes infrequently but 'bar' changes
frequently), you may want to automate use of the
versions-maven-plugin, which will seek out updates for you.

http://mojo.codehaus.org/versions-maven-plugin/

Zac

On Tue, Jan 4, 2011 at 4:59 AM, Leon Rosenberg  wrote:
> On Tue, Jan 4, 2011 at 12:11 PM, Anders Hammar  wrote:
>> I recommend "1.0.1", as I dislike ranges (might break reproducible builds
>> and is just to much automagic in my taste).
>> "RELEASE", "LATEST" is depracted and should not be used.
>>
>> When ever a new release is available you need to update the bar pom.
>
> Well in practice I have like 10 projects, so I will probably have to
> update 9 poms in worst case. For now I moved dependency management
> into parent.pom.
>
>>
>> Or, you could keep both projects together with an aggregating project and
>> have one release lifecycle for them (same version in both,
>> "${project.version}").
>
>  ${project.version} ?
> I tried it in a module in an aggregated project (another one) and get
>
> Project build error: Resolving expression: '${project.version}':
> Detected the following recursive expression cycle:
> []      pom.xml /distributeme-runtime   line 1  Maven Problem
> Project build error: Resolving expression: '${version}': Detected the
> following recursive expression cycle:
> [version]       pom.xml /distributeme-runtime   line 1  Maven Problem
>
> regards
> Leon
>
>
>>
>> /Anders
>>
>> On Tue, Jan 4, 2011 at 11:46, Leon Rosenberg wrote:
>>
>>> Hi,
>>>
>>> say I have two projects,
>>> foo and bar, and bar depends on foo. My question is how should I
>>> properly declare this dependency.
>>> From the maintainers point of view (and I'm the maintainer of both) I
>>> always want bar to use the newest release of foo.
>>> So, I have a released version of foo - 1.0.1, which is known to me at
>>> the moment I'm writing the pom for bar.
>>> Do I reference foo in bar as:
>>>
>>> 1.0.1
>>> or
>>> [1.0.1,)
>>> or
>>> [1.0.1]
>>> or
>>> RELEASE
>>> or
>>> ... ?
>>>
>>> regards
>>> Leon
>>>
>>> -
>>> 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
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: can i change the name of the uploaded/installed artifact?

[Wayne Fay]

> The webapp have to be accessed by a specific context-path, e.g.
> http://host:port/distributeme/registry/list
>
> The easiest way to achieve it, is to name the war distributeme.war.

Each app server has its own way of handling this -- context.xml,
weblogic, xml, etc. You could also just include all those
configuration files in your war file directly.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[PLEASE TEST] Apache Maven 3.0.2-RC1

[Benjamin Bentmann]

Hi,

we're aiming at a bugfix release of Maven 3 in the next week and 
following tradition we invite interested users in taking the RC for a 
test drive in order to detect and fix potential regressions since 
version 3.0.1 before the actual release of 3.0.2.


For the duration of the RC testing, sources and binaries are staged at:
https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/

As usual, the changes since the previous release are listed in JIRA:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16952

Thanks,


-The Maven Team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: can i change the name of the uploaded/installed artifact?

[Reynald Borer]

 Understood. So you want your users to download the WAR directly from either 
your m2repo (weird) or from a Maven repository tool like Nexus, right?


In that case, I don't think it's a Maven problem. You should consider deploying 
your generated war file to a web server like Apache (through 
maven-resources-plugin for example). Or you might also have an Apache in front 
of your Nexus server that is correctly configured to rewrite 
"/xyz/distributeme.war" to the correct location of the latest war in Nexus, and 
then it'll be downloaded as distributeme.war.


Regards,
Reynald

On Wednesday, January 5, 2011 at 21:00 , Leon Rosenberg wrote:

> Hello Reynald,
> 
> I posted it in my original post.
> The webapp have to be accessed by a specific context-path, e.g.
> http://host:port/distributeme/registry/list
> 
> The easiest way to achieve it, is to name the war distributeme.war.
> 
> In other words, for external users its easier to understand:
> "Download distributeme.war from xyz and place it under webapps in your
> app container "
> as
> "Download version-x from xyz, rename it to distributeme.war and than
> place it under webapps in your app container"
> 
> regards
> Leon
> 
> 
> On Wed, Jan 5, 2011 at 7:52 PM, Reynald Borer  wrote:
> 
> > Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)
> > 
> > 
> > Leon, why do you explicitly need to install the war file in your m2repo 
> > with a custom name? Couldn't you simply use the one you can find in the 
> > target/ folder? Or you can always use the maven-resources-plugin to copy 
> > the generated war to a given specific folder.
> > 
> > 
> > Cheers,
> > Reynald
> > 
> > 
> > On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:
> > 
> > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: Reynald Borer [mailto:reynald.bo...@gmail.com]
> > > > 
> > > > You can modify the finalName tag to change the name of artifact. By 
> > > > default
> > > > it is defined like the following:
> > > > 
> > > > 
> > > > ${artifactId}-${version}
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > That only affects what gets created in your "target" directory. Once the 
> > > artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus 
> > > repo) the "standard" naming is enforced.
> > > 
> > > The finalName tag is really only useful if you skip the deploy step and 
> > > use the output artifact directly. (e.g. as part of a larger, non-maven 
> > > build, or emailing it to a customer, etc...)
> > > 
> > > eric
> > > 
> > > -
> > > 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: can i change the name of the uploaded/installed artifact?

[Leon Rosenberg]

Hello Reynald,

I posted it in my original post.
The webapp have to be accessed by a specific context-path, e.g.
http://host:port/distributeme/registry/list

The easiest way to achieve it, is to name the war distributeme.war.

In other words, for external users its easier to understand:
"Download distributeme.war from xyz and place it under webapps in your
app container "
as
"Download version-x  from xyz, rename it to distributeme.war and than
place it under webapps in your app container"

regards
Leon


On Wed, Jan 5, 2011 at 7:52 PM, Reynald Borer  wrote:
>  Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)
>
>
> Leon, why do you explicitly need to install the war file in your m2repo with 
> a custom name? Couldn't you simply use the one you can find in the target/ 
> folder? Or you can always use the maven-resources-plugin to copy the 
> generated war to a given specific folder.
>
>
> Cheers,
> Reynald
>
>
> On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:
>
>>
>> > -Original Message-
>> > From: Reynald Borer [mailto:reynald.bo...@gmail.com]
>> >
>> > You can modify the finalName tag to change the name of artifact. By default
>> > it is defined like the following:
>> > 
>> > 
>> > ${artifactId}-${version}
>> > 
>> > 
>> >
>> >
>>
>> That only affects what gets created in your "target" directory. Once the 
>> artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo) 
>> the "standard" naming is enforced.
>>
>> The finalName tag is really only useful if you skip the deploy step and use 
>> the output artifact directly. (e.g. as part of a larger, non-maven build, or 
>> emailing it to a customer, etc...)
>>
>> eric
>>
>> -
>> 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: can i change the name of the uploaded/installed artifact?

[Reynald Borer]

 Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)


Leon, why do you explicitly need to install the war file in your m2repo with a 
custom name? Couldn't you simply use the one you can find in the target/ 
folder? Or you can always use the maven-resources-plugin to copy the generated 
war to a given specific folder.


Cheers,
Reynald


On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:

> 
> > -Original Message-
> > From: Reynald Borer [mailto:reynald.bo...@gmail.com]
> > 
> > You can modify the finalName tag to change the name of artifact. By default
> > it is defined like the following:
> > 
> > 
> > ${artifactId}-${version}
> > 
> > 
> > 
> > 
> 
> That only affects what gets created in your "target" directory. Once the 
> artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo) 
> the "standard" naming is enforced.
> 
> The finalName tag is really only useful if you skip the deploy step and use 
> the output artifact directly. (e.g. as part of a larger, non-maven build, or 
> emailing it to a customer, etc...)
> 
> eric
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> 
> 

Re: Exclusion does not work when using dependencies generated using assembly plug in

[Benjamin Bentmann]

Anand HS wrote:


4. Now when I invoke mvn install from the ROOT pom, I see that ModuleA and
ModuleA-distribution.jar get build with no issues. Now when ModuleB is
built, in spite of explicit exclusion of ModuleA's dependencies , those
dependencies do not get excluded.


Could be http://jira.codehaus.org/browse/MNG-4872.


Benjamin

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Exclusion does not work when using dependencies generated using assembly plug in

[Anand HS]

Hi,
Apologize for not providing more details.

Here are more details -

1. The ROOT is a ROOT pom that builds both ModuleA and ModuleB.
2. ModuleA uses assembly plug in to generate a Distribution jar. Here is the
distribution XML that builds this jar -



  distribution
  
jar
  
  false
  

${basedir}/target/classes
/

com/psi/common/*.class


com/psi/common/ErrorConstants.class


  


3. Now ModuleB uses this Distribution.jar as a dependency. The POM of
ModuleB is given below . -


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";>
4.0.0
com.psi.lc
psi-lc-ops
war
psi-lc-ops

com.psi
lc
${lc.version}



scm:svn:
https://cobasvn01.coreobjects.com/svn/PSI/products/LC/apps/Atlas/trunk/atlas-web





jstl
jstl
1.1.2


xmlparser
xmlparser
2.0


javax.mail
mail
1.4


javax.activation
activation




standard
standard
1.0




org.testng
testng
5.12.1
test


org.mockito
mockito-all
1.8.5
test




com.psi.lc
ModuleA
${lc.version}
distribution
jar


quartz
quartz


psistatefunctions
psistatefunctions


corecccejb
corecccejb


anttex
anttex


treeapplet
treeapplet


Verisign
Verisign


reportgenfiles
reportgenfiles


commons-digester
commons-digester


javax.xml.bind
jaxb-api


org.apache.cxf
cxf-rt-frontend-jaxws


com.psi
contentservice


org.apache.cxf
cxf-rt-ws-security


org.apache.ws.security
wss4j


org.apache.xmlgraphics
fop


com.psi
FOReportGenerator


org.freemarker
freemarker


org.apache.avalon.framework
avalon-framework-impl





psi-lc-ops


maven-war-plugin
2.0.2



 true




 ${env.COMPUTERNAME}









maven-central
http://repo1.maven.org/maven2





org.apache.maven.plugins
maven-jxr-plugin


org.apache.maven.plugins
maven-pmd-plugin
2.5


rulesets/basic.xml
rulesets/braces.xml
rulesets/codesize.xml
rulesets/coupling.xml


true
true
utf-8
5
20
1.5



 target/generated-sources/stubs




 

org.codehaus.mojo
cobertura-maven-plugin
2.1


false


com.psi.ops.services.*
90
90







 com/psi/ops/services/**/*.class








4. Now when I invoke mvn install from the ROOT pom, I see that ModuleA and
ModuleA-distribution.jar get bui

RE: can i change the name of the uploaded/installed artifact?

[Haszlakiewicz, Eric]

>-Original Message-
>From: Reynald Borer [mailto:reynald.bo...@gmail.com]
>
>You can modify the finalName tag to change the name of artifact. By default
>it is defined like the following:
>
>
>${artifactId}-${version}
>
>

That only affects what gets created in your "target" directory.  Once the 
artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo) 
the "standard" naming is enforced.

The finalName tag is really only useful if you skip the deploy step and use the 
output artifact directly.  (e.g. as part of a larger, non-maven build, or 
emailing it to a customer, etc...)

eric

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Accessing the version of a dependency

[Kalle Korhonen]

On Wed, Jan 5, 2011 at 9:33 AM, juranta  wrote:
> Thanks, that's a simple solution that might even work in most of the
> situations (perhaps excepting the release plugin, etc).

The release plugin is surprisingly good at dealing with versions
declared in properties, try it, might just work out of the box for
your use case.

Kalle

>
>  I also found a more complex way to access the versions of a dependency
> using Groovy plugin. For those who are interested:
>
>
>         
>                
>                    org.codehaus.groovy.maven
>                    gmaven-plugin
>                    1.0-rc-5
>                    
>                        
>                            validate
>                            
>                                execute
>                            
>                            
>                                
>                                                        print 
> project.dependencies;
>                                                        for ( i in 
> project.dependencies ) {
>                                                                
> project.properties[ 'depinfo.' + i['groupId'] + '.' +
> i['artifactId'] + '.version' ] = i['version'];
>                                                        }
>                                
>
>                            
>                        
>                    
>                
>
> Then you can access ${depinfo.mygroup.myartifact.version}... But I'll try to
> go with your suggestion.
>
> Juha
>
>> Right, and the rest of your build needs to know that version as well,
>> right? Put that version in a property and use it in the dependency as
>> well as resource filtering, i.e.
>>       
>>                2
>>        
>>
>> Kalle
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3329171.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> 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: Is there any way to stop the same version of pom file/build being built more than once?

[Nick Stolwijk]

And use the Maven Release Plugin to create the branch[1][2] in the
first place. This will change the version numbers back to snapshot.

[1] http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html
[2] http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html

Hth,

Nick Stolwijk
~Senior Java Developer~

iPROFS
Wagenweg 208
2012 NM Haarlem
T +31 23 547 6369
F +31 23 547 6370
I www.iprofs.nl



On Wed, Jan 5, 2011 at 6:58 PM, Thiessen, Todd (Todd)
 wrote:
> Configure your Nexus server to not allow artifacts to get overwritten. You 
> can't stop the build from happening, but you can stop the artifact from being 
> deployed.
>
>> -Original Message-
>> From: baz themail [mailto:bazthem...@gmail.com]
>> Sent: Wednesday, January 05, 2011 12:55 PM
>> To: Maven Users List
>> Subject: Re: Is there any way to stop the same version of pom file/build
>> being built more than once?
>>
>> Wendy, thanks for your reply.
>>
>> Here is the example:
>>
>> 1. Someone need to fix a bug in production.
>> 2. Create a new branch for bug fix based on a label.
>> 3. The newly created branch will contain older pom files with older
>> version that already released in Nexus (or any Maven based
>> repository).
>> 4. Logically, once the branch is created from an older label, in order
>> to avoid redeploying the old version numbers, the version number
>> should be changed.
>> 5. Say, if #4 is skipped, then the same version number that exist in
>> Nexus will be overwritten after performing a release build.
>> 6. This is to assume that we should keep the old release version even
>> if it is buggy.
>>
>> So, my question is: Is there any way to skip #4 by having some Maven
>> type mechanism to check and stop a release build if the version
>> already exist in maven repo?
>>
>> Thanks.
>>
>> B.
>>
>> On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak  wrote:
>> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail 
>> wrote:
>> >> Hi,
>> >> Is there any way to stop the same version of pom file/build being
>> >> built more than once?
>> >
>> > Being _built_?  Probably not... anyone can check out a tag and
>> > re-build that version locally, nothing to prevent that from happening.
>> >  (Nor should there be.)
>> >
>> > What's the real underlying problem?
>> >
>> > My guess is that it's about not overwriting released versions.  In
>> > which case... are you using -SNAPSHOT version numbers and going
>> > through a release process?  A repository manager to store your
>> > artifacts?
>> >
>> > Tell us more about your situation and most likely someone will have
>> > some advice for you.
>> >
>> > --
>> > Wendy
>> >
>> > -
>> > 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
>
>
> -
> 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: Is there any way to stop the same version of pom file/build being built more than once?

[Wendy Smoak]

On Wed, Jan 5, 2011 at 12:54 PM, baz themail  wrote:
> 1. Someone need to fix a bug in production.
> 2. Create a new branch for bug fix based on a label.
> 3. The newly created branch will contain older pom files with older
> version that already released in Nexus (or any Maven based
> repository).

How is the branch being created?  Either the release plugin or the scm
plugin has a branch goal that will change the version number, though
iirc it modifies the tag to do it, which I don't like.  Or, you can
use the versions plugin to easily set the new version.

> 4. Logically, once the branch is created from an older label, in order
> to avoid redeploying the old version numbers, the version number
> should be changed.
> 5. Say, if #4 is skipped, then the same version number that exist in
> Nexus will be overwritten after performing a release build.

It shouldn't -- isn't there a setting to make it disallow this?

> 6. This is to assume that we should keep the old release version even
> if it is buggy.

Released artifacts should never change, so yes, you should keep the
old buggy version separate from the new fixed version.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Is there any way to stop the same version of pom file/build being built more than once?

[Thiessen, Todd (Todd)]

Configure your Nexus server to not allow artifacts to get overwritten. You 
can't stop the build from happening, but you can stop the artifact from being 
deployed.

> -Original Message-
> From: baz themail [mailto:bazthem...@gmail.com]
> Sent: Wednesday, January 05, 2011 12:55 PM
> To: Maven Users List
> Subject: Re: Is there any way to stop the same version of pom file/build
> being built more than once?
> 
> Wendy, thanks for your reply.
> 
> Here is the example:
> 
> 1. Someone need to fix a bug in production.
> 2. Create a new branch for bug fix based on a label.
> 3. The newly created branch will contain older pom files with older
> version that already released in Nexus (or any Maven based
> repository).
> 4. Logically, once the branch is created from an older label, in order
> to avoid redeploying the old version numbers, the version number
> should be changed.
> 5. Say, if #4 is skipped, then the same version number that exist in
> Nexus will be overwritten after performing a release build.
> 6. This is to assume that we should keep the old release version even
> if it is buggy.
> 
> So, my question is: Is there any way to skip #4 by having some Maven
> type mechanism to check and stop a release build if the version
> already exist in maven repo?
> 
> Thanks.
> 
> B.
> 
> On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak  wrote:
> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail 
> wrote:
> >> Hi,
> >> Is there any way to stop the same version of pom file/build being
> >> built more than once?
> >
> > Being _built_?  Probably not... anyone can check out a tag and
> > re-build that version locally, nothing to prevent that from happening.
> >  (Nor should there be.)
> >
> > What's the real underlying problem?
> >
> > My guess is that it's about not overwriting released versions.  In
> > which case... are you using -SNAPSHOT version numbers and going
> > through a release process?  A repository manager to store your
> > artifacts?
> >
> > Tell us more about your situation and most likely someone will have
> > some advice for you.
> >
> > --
> > Wendy
> >
> > -
> > 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


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Is there any way to stop the same version of pom file/build being built more than once?

[baz themail]

Wendy, thanks for your reply.

Here is the example:

1. Someone need to fix a bug in production.
2. Create a new branch for bug fix based on a label.
3. The newly created branch will contain older pom files with older
version that already released in Nexus (or any Maven based
repository).
4. Logically, once the branch is created from an older label, in order
to avoid redeploying the old version numbers, the version number
should be changed.
5. Say, if #4 is skipped, then the same version number that exist in
Nexus will be overwritten after performing a release build.
6. This is to assume that we should keep the old release version even
if it is buggy.

So, my question is: Is there any way to skip #4 by having some Maven
type mechanism to check and stop a release build if the version
already exist in maven repo?

Thanks.

B.

On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak  wrote:
> On Tue, Jan 4, 2011 at 12:28 PM, baz themail  wrote:
>> Hi,
>> Is there any way to stop the same version of pom file/build being
>> built more than once?
>
> Being _built_?  Probably not... anyone can check out a tag and
> re-build that version locally, nothing to prevent that from happening.
>  (Nor should there be.)
>
> What's the real underlying problem?
>
> My guess is that it's about not overwriting released versions.  In
> which case... are you using -SNAPSHOT version numbers and going
> through a release process?  A repository manager to store your
> artifacts?
>
> Tell us more about your situation and most likely someone will have
> some advice for you.
>
> --
> Wendy
>
> -
> 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: Accessing the version of a dependency

[juranta]

Thanks, that's a simple solution that might even work in most of the
situations (perhaps excepting the release plugin, etc).

 I also found a more complex way to access the versions of a dependency
using Groovy plugin. For those who are interested:


 

org.codehaus.groovy.maven
gmaven-plugin
1.0-rc-5


validate

execute



print 
project.dependencies;
for ( i in 
project.dependencies ) {

project.properties[ 'depinfo.' + i['groupId'] + '.' +
i['artifactId'] + '.version' ] = i['version'];
}







Then you can access ${depinfo.mygroup.myartifact.version}... But I'll try to
go with your suggestion.

Juha

> Right, and the rest of your build needs to know that version as well, 
> right? Put that version in a property and use it in the dependency as 
> well as resource filtering, i.e. 
>
>2 
> 
>
> Kalle 
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3329171.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Our IP Was blocked

[Richard Seddon]

File an issue at https://issues.sonatype.org under the "Community Support - 
Maven Central" to get removed from the blacklist.

Rich

On Jan 5, 2011, at 8:05 AM, Ron Wheeler wrote:

> If you have Nexus installed, you can find any dependency available in any 
> repository that you configure either by looking at the full list or by 
> searching for it .
> That is the right way to manage dependencies.
> It is a really big help in making your management of dependencies much less 
> painful and provides a sound foundation for managing your own artifacts.
> 
> 
> Nexus will not get you banned.
> 
> I gather that you will get banned again if you run your program.
> 
> Ron
> 
> On 05/01/2011 5:34 AM, Faruk Can Kaya wrote:
>> 
>> Hello;
>> 
>> I was working on a project for our custom needs about dependency management. 
>> I have written a program that traverses the repo1.maven.org and list all the 
>> available artifacts. Unfortunately I'm not able access repo1.maven.org any 
>> more. Our company uses maven in many projects for build scripting. Hence it 
>> is essential for our company. I'm sorry for causing any problems. Can anyone 
>> restore our ip address or addresses.
>> 
>> Our IP addresses are below:
>> 
>> 95.9.74.92
>> 88.249.20.72
>> 78.187.132.76
>> 
>> Thank You
>> Best Regards.
>> 
>> -
>> 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
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Our IP Was blocked

[Ron Wheeler]

If you have Nexus installed, you can find any dependency available in 
any repository that you configure either by looking at the full list or 
by searching for it .

That is the right way to manage dependencies.
It is a really big help in making your management of dependencies much 
less painful and provides a sound foundation for managing your own 
artifacts.



Nexus will not get you banned.

I gather that you will get banned again if you run your program.

Ron

On 05/01/2011 5:34 AM, Faruk Can Kaya wrote:


Hello;

I was working on a project for our custom needs about dependency management. I 
have written a program that traverses the repo1.maven.org and list all the 
available artifacts. Unfortunately I'm not able access repo1.maven.org any 
more. Our company uses maven in many projects for build scripting. Hence it is 
essential for our company. I'm sorry for causing any problems. Can anyone 
restore our ip address or addresses.

Our IP addresses are below:

95.9.74.92
88.249.20.72
78.187.132.76

Thank You
Best Regards.

-
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: Our IP Was blocked

[Anders Hammar]

You do know that there is an index that should be used for these purposes,
yes?

/Anders
On Wed, Jan 5, 2011 at 11:34, Faruk Can Kaya  wrote:

>
>
> Hello;
>
> I was working on a project for our custom needs about dependency
> management. I have written a program that traverses the repo1.maven.organd 
> list all the available artifacts. Unfortunately I'm not able access
> repo1.maven.org any more. Our company uses maven in many projects for
> build scripting. Hence it is essential for our company. I'm sorry for
> causing any problems. Can anyone restore our ip address or addresses.
>
> Our IP addresses are below:
>
> 95.9.74.92
> 88.249.20.72
> 78.187.132.76
>
> Thank You
> Best Regards.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Indirect dependency of sub modules problem.

[Hayarobi Park]

Thank you Anders and Zac.

The project was originally managed by Ant (by other man), and I'm 
porting that project to maven now. I don't change module structure yet, 
but probably the time to change will come soon.


The manager is standalone data server that manage whole configurations 
of the system. Other subsystems get their initual configs from manager 
by using manager's clientAPI. The utils:config is a library that 
integrate config values from manager, local config file, VM arguements 
or environmental variables, so depend on manager:clientAPI.


I found that other modules of utils don't depend on config, and it's 
possible to wipe out dependency on config from manager:*. I'll pick 
config out from utils.



2011년 01월 05일 13:27, Zac Thompson 쓴 글:

I agree with Anders that your structure should probably be modified.
I am also suspicious of the "utils/config" component.  I highly doubt
that it should be dependent on clientAPI.  I find myself questioning
if it should exist at all.

1) I think utils/config should not be dependent on clientAPI, or ...
2) ... else config does not belong as a utils component and is really
part of mid/manager, or ...
3) ... else clientAPI does not belong as part of mid/manager and
should be in its own project at the same level as utils and mid

However, if you change your hierarchy to be completely flat (all
modules become siblings at the same level), then your problems will go
away for now.

On Mon, Jan 3, 2011 at 11:20 PM, Anders Hammar  wrote:

What version of Maven are you using? Have you tried 3.0.1?

Out of a module design perspective, I find your structure strange and I
think that you should try to re-arrange. In some sense you do have cyclic
dependencies, as utils depends on mid, while mid depends on utils.

/Anders

On Tue, Jan 4, 2011 at 03:19, Hayarobi Park  wrote:


Hello,

I'm managing maven project of my team, and having truble in module
dependencies..

The root project has some sub modules.
A submodule named "utils" has a few submodule; config, logger, json and
etc.
Another submodule "mid" has "manager" submodule, which are pom project and
has core, clientAPI and protocol sub modules.

The problem is that utils:config depends on mid:manager:clientAPI,
mid:manager:clientAPI depends on utils:logger and utils:json, and the other
modules in mid:manager depend on submodules utils, including config. There
are not cyclic, but twisted dependencies, and maven can't solve the
dependency well.

I have to do tedius steps to build whole project in the new configuration.
1. install utils first, maven complains and stop building utils:config
since mid:manager:clientAPI was not installed yet, just after installing
utils pom project.
2. go to utils:logger and install, and for utils:json respectively.
3. go to mid directory and install mid, maven will install mid and stop
further install caused by dependeny on utils:config of some other submodules
of mid.
4. go to mid:manager and install it.
5. go to mid:manager:clientAPI and install it.
6. go to utils:config and install it.
7. Finally, go  to top level and install whole modules.

How to solve this situation?

-
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




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Our IP Was blocked

[Faruk Can Kaya]

Hello;

I was working on a project for our custom needs about dependency management. I 
have written a program that traverses the repo1.maven.org and list all the 
available artifacts. Unfortunately I'm not able access repo1.maven.org any 
more. Our company uses maven in many projects for build scripting. Hence it is 
essential for our company. I'm sorry for causing any problems. Can anyone 
restore our ip address or addresses.

Our IP addresses are below:

95.9.74.92
88.249.20.72
78.187.132.76

Thank You
Best Regards.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Exclusion does not work when using dependencies generated using assembly plug in

[Anders Hammar]

What do you mean when you say that the exclusions don't get excluded when
you build from the root?
The subject mentions the assembly plugin, but I don't see that mentioned in
your structure.

More info, please!

/Anders

On Wed, Jan 5, 2011 at 01:36, Anand HS  wrote:

> Hi,
> I have a project with the following structure
>
> - ROOT
>  - ModuleA
>  - GeneratedDistribution.jar
>  - Several Dependencies
>  - ModuleB
> - Several Dependencies
> - Depends on GeneratedDistribution.jar
> - 
>
> Now When i build from ROOT, the exclusions do not really get excluded.
> However, when i build from inside ModuleB, the exclusions get excluded.
>
> I use Maven 2.0.9 but have also tried on 2.0.10 and the problem exists.
>
> Any solution on  how to ensure a uniform behavior of ModuleA's dependencies
> to be excluded from ModuleB.  would be appreciated
>
> Thanks,
> Anand
>

Re: The master password

[Anders Hammar]

OK, will likely soon be included in a plugin coming to a repo close to
you...:-)

/Anders

On Tue, Jan 4, 2011 at 23:21, Brett Porter  wrote:

> I believe if you regenerated another settings-security.xml file with the
> same master password, while the hash would be different it would effectively
> decrypt the passwords.
>
> However, you make a good point - automatically generating it would be a
> nice additional feature.
>
> - Brett
>
> On 04/01/2011, at 7:40 PM, Anders Hammar wrote:
>
> > Is there any reason why I would need to remember my master password (used
> > for encrypting my server passwords in settings.xml)? I haven't found any
> and
> > I'm thinking that it could be auto-generated (by some tool) when creating
> > settings-security.xml, instead of specified by the user.
> >
> > /Anders
>
> --
> Brett Porter
> br...@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: assembly plugin sign all dependented jars

[Stephen Connolly]

On 5 January 2011 08:22, xtonic  wrote:

>
> I would like to produce a tar with my project artifact and all its
> dependents
> jars jarsigned. Also, I would like to deploy the tar as attachment.
>
> I used assembly plugin and write my own descriptor. However, I don’t know
> how to sign all the jars before the tar is created.
>
> I did try create the assemble as "dir"(instead of tar), call antrun to sign
> and create the final tar. However, Maven will not include the tar as
> attachment.
>

use
http://maven.apache.org/plugins/maven-antrun-plugin/tasks/attachArtifact.htmlto
attach the artifact


> Thanks
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/assembly-plugin-sign-all-dependented-jars-tp3328397p3328397.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Where is the global settings.xml for built-in (embedded) Maven in Eclipse?

[Manuel Doninger]

Eclipse says:
Embedded Runtime is always used for dependency resolution, but does
not use global settings when it is used to launch Maven.

So i think, there is just no global configuration file for this
runtime, because it doesn't use one.
You have to use the user configuration file or an external Maven.

Manuel

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

assembly plugin sign all dependented jars

[xtonic]

I would like to produce a tar with my project artifact and all its dependents
jars jarsigned. Also, I would like to deploy the tar as attachment.

I used assembly plugin and write my own descriptor. However, I don’t know
how to sign all the jars before the tar is created. 

I did try create the assemble as "dir"(instead of tar), call antrun to sign
and create the final tar. However, Maven will not include the tar as
attachment.

Thanks

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/assembly-plugin-sign-all-dependented-jars-tp3328397p3328397.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org