generate XML file

[Alejandro . Endo]

Hello everyone,


I'm using maven-assembly-plugin to generate a zip package with some
artifacts in it. It works fine, now the only missing step is I need to
generate an XML file with some information about the artifacts. This XML
will be used by another program to basically know about the content
(version of each artifact, type, etc). Is there any way to do this in maven
and make the assembly plugin include the XML? is there a way to do this
with the assembly plugin itself? is it better to create my own plugin? the
assembly plugin does a good job creating my zip, so I am hoping i don't
need to create my own plugin from scratch





Thanks for any suggestions,





Alejandro
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

maven graph traversal in plugin

[Alejandro . Endo]

I'm writing a plugin that needs to combine a bunch of artifacts into a zip
and create an XML file of it. I am currently working on creating the XML,
for the rest i use the assembly plugin. To generate the XML i need a way
(an api) to traverse the graph of maven dependencies


Here is a normal hierarchy


the main pom A has B and C as modules. B has a dependency on 1 and 1 has a
dependency on 1.1. Equally, C has a dependency 2 and 2 a dependency 2.1





Now, to get ahold of the two modules B and C i create a member in my mojo,
i am not too happy about this way but i found it in a tutorial
@Parameter( defaultValue = "${reactorProjects}", required = true, readonly
= true )
   private List reactorProjects;


1) Is this the recommended way to get those (submodules)? i am worried that
this will include not only the two modules under A but also any and all the
other modules higher than A since A is not really the root of the
hierarchy. A itself gets aggregated by other poms


2) Now to get the dependencies of B and of C I do
 for (MavenProject module : reactorProjects) { //for every sub-module
 if (module != project) { //to ignore A
List dependencies = module.getDependencies();
for (Dependency dependency : dependencies) { //for every
dependency
   //DO STUFF
}

 }
 }

With this I can get a reference to 1 and 2 in my example. However, from a
Dependency object i can't further get the dependencies (1.1 and 2.1). What
I would like would be more like getting another MavenProject reference for
each dependency, so that on it I can continue traversing the graph




Can anyone point me on the right direction, any documentation or existing
plugin that i can look into would be appreciated








Thank you,





Alejandro
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

error in unit test

[Alejandro . Endo]

I have a problem where my maven plugin's unit tests fail ONLY when i run
them in jenkins. When i run `mvn test` locally everything passes fine

The error i get is

Tests in error:
  testGetMyModules(com.example.AnalyzerTest): (class:
org/apache/maven/project/MavenProject, method:
getSnapshotArtifactRepository signature:
()Lorg/apache/maven/artifact/repository/ArtifactRepository;) Incompatible
argument to function

Does anyone know what this is related to?

Thank you,


Alejandro
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

maven properties of dependencies

[Alejandro . Endo]

I have a plugin that uses DependencyGraphBuilder to find the dependencies
of a MavenProject. Traversing the graph I get a DependencyNode , however, I
need to access a particular maven property of the dependency's pom and this
is not possible AFAIK. Is this true? is it really not possible to access
the properties of a dependency pom using DependencyGraphBuilder component?
if so, how could I manage to grab those?

Thank you,



Alejandro
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: maven properties of dependencies

[Alejandro . Endo]

Latest maven and maven-dependency-tree 2.0

Maybe we are talking about different interfaces

org.apache.maven.shared.dependency.graph.DependencyNode.getArtifact()
returns a org.apache.maven.artifact.Artifact, which does not have a
getProperties() method

Am I missing something?

Thank you,

Alejandro



From:   Rahul Thakur 
To: Maven Users List ,
Date:   2013-03-14 07:22
Subject:Re: maven properties of dependencies




Hi Alejandro,

What version of Maven are you writing your plugin with? What's the
scenario - can you please elaborate?

I am looking through the current master, it seems you could do something
like:

DependencyNode.getDependency().getArtifact().getProperties()

I hope I understood your problem correctly...

Cheers,

Rahul



On 3/9/2013 12:56 AM, alejandro.e...@miranda.com wrote:
>
> I have a plugin that uses DependencyGraphBuilder to find the dependencies
> of a MavenProject. Traversing the graph I get a DependencyNode , however,
I
> need to access a particular maven property of the dependency's pom and
this
> is not possible AFAIK. Is this true? is it really not possible to access
> the properties of a dependency pom using DependencyGraphBuilder
component?
> if so, how could I manage to grab those?
>
> Thank you,
>
>
>
> Alejandro
> DISCLAIMER:
>
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
>
> Thank You.
>
>


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


DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

RE: merge-maven-repos problems with maven-metadata.xml

[Alejandro . Endo]

i do something similar to fix a bug in nexus
(https://issues.sonatype.org/browse/NEXUS-5525)

since it is a jenkins build, i just trigger a scheduled (manual) task to
reindex the repo on build finish.
The command i use to trigger it is

/usr/bin/wget --user=something --password=my-pass
http://url/to/repo/nexus/service/local/schedule_run/21

where 21 is the id of the reindex job

So in summary:

-create scheduled job to "repair repositories index"
-somehow (jenkins in my case) trigger a command to invoke the REST service
-enjoy

I did not find a REST service directly to trigger a reindex, thus the hack
with the scheduled job. Let me know if you find something better

hope it helps,


Alejandro



From:   Jim McCaskey 
To: Maven Users List ,
Date:   2013-03-14 14:38
Subject:RE: merge-maven-repos problems with maven-metadata.xml



It's not a Maven build.  It's an old legacy non-java (mostly) build that
takes 1.5 hours to build, but we still want to crank that whole thing when
there is a change.  I don't publish the build till it is all done.  I use a
stub pom.xml to generate the staging-repo with a bunch of deploy executions
(which I will never show anyone in the Maven community for fear of being
forever banned).  Once that whole things works, then I merge that build
into our SNAPSHOT repo.  Works great except for the maven-metadata.xml
files.

I think this is the point where folks start telling me I'm doing it
wrong. :)  Honestly, we do our pure Maven stuff "right", it's just this
clunker that we have to hack around a little.

Our non-SNAPSHOT builds work fine, I just did not know SNAPSHOT's where
treated different, so now I'll have to come up with a workaround to get the
maven-metadata.xml files rigged properly.  You can do that through the
Nexus UI by clicking on the "Rebuild Metadata" button.  Given that the
Nexus folks make a big deal about everything being available through REST,
there's got to be some way to do that programmatically.  Anyone got a hint?
(I know, go ask on the Nexus list)

-Jim

-Original Message-
From: Dan Tran [mailto:dant...@gmail.com]
Sent: Thursday, March 14, 2013 11:10 AM
To: Maven Users List
Subject: Re: merge-maven-repos problems with maven-metadata.xml

You need to reindex for both cases any way since the repository is not
aware of your changes.  Without reindexing, it may not serve your new
artifact.

Just curious, why do you want to merge snaphot repo, why not just push
the artifact directly to your snapshot repos?

-D

On Thu, Mar 14, 2013 at 6:57 AM, Jim McCaskey
 wrote:
> Ouch... Is that documented somewhere?  I checked the bug tracker and
uncle Google and couldn't find anything regarding that.  I went ahead and
opened an issue in Jira:
>
> http://jira.codehaus.org/browse/MOJO-1913
>
> I wonder what would be quicker.  Finding a hack around or fixing the
module. :) It would probably be easy to fire off a Nexus reindex of the
effected artifacts which would "fix" the problem for me.
>
> -Jim
>
> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Thursday, March 14, 2013 4:06 AM
> To: Maven Users List
> Subject: Re: merge-maven-repos problems with maven-metadata.xml
>
> merge-maven-repos mojo works with release repos ONLY.  Merging
> snapshot repos requires enhancement
>
> -Dan
>
> On Wed, Mar 13, 2013 at 11:29 AM, Jim McCaskey
>  wrote:
>> Hello all,
>>
>> Below you will find a maven-metadata.xml file from my Nexus repository
(GAV changed to protect the innocent).  What you will notice is that the
 timestamp and the  do not match. I don't think
that it's a Nexus repo issue.   Perhaps a bug in merge-maven-repos.
>>
>> I build the components to an empty directory using the
altDeploymentRepository property:
>>
>> -DaltDeploymentRepository=repo::default::file://E:\builddir\staging-repo
deploy
>>
>> I then publish this component to Nexus using this (using Maven 3.0.4):
>>
>> org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:merge-maven-repos
>>
>> This seems to work just fine for my non-SNAPSHOT builds.  But the CI
builds seem to get their maven-metadata.xml file messed up every time those
SNAPSHOT builds run.  This took a while to track down because I run "Update
Repositories Index" every night and Nexus fixes the maven-metadata.xml.
And this is a very long build.
>>
>> FWIW, this is a shim between legacy code and our newer, all Maven build
code.  As you can tell we just zip that mess up and use it whole sale in
downstream builds.
>>
>> Any thoughts on how I can fix this?  Perhaps it's just a bug in
wagon:merge-maven-repos?
>>
>> -Jim
>>
>>
>> 
>> 
>>   myGroup
>>   MyArtifact
>>   10.2.6-SNAPSHOT
>>   
>> 
>>   20130313.165705
>>   1
>> 
>> 20130313165705
>> 
>>   
>> MyClassifier
>> zip
>> 10.2.6-20130311.175410-1
>> 20130311175410
>>   
>>   
>> pom
>> 10.2.6-20130311.175410-1
>> 20130311175410
>>   
>> 
>>   
>> 
>>
>> NOTICE: All

Re: Can I force a plugin to not run during parent pom execution phase?

[Alejandro . Endo]

A trick i use, provided the plugin has a configuration to skip a run, is
having something like this in the parent


org.apache.maven.plugins
maven-assembly-plugin
2.4


my-id
package
true


config

false


single





true

false 



So as you can see, inside execution i enable inheritance and outside
execution i configure the plugin to skip the run using the skipAssembly
configuration and disable inheritance


Notice that this still starts the plugin execution, but the run will end
very early when it detects it will be skipped. This might be a problem when
e.g. the plugin has a mandatory config argument that you define in the
children. In that case, the verification for the parameter will make the
build fail before you get to skip it


I know this is limited but maybe your plugin has such a configuration. or
if you wrote it yourself you can add it



If this is not useful, take a look at this. The answer was not useful to me
but the discussion is there anyway

http://stackoverflow.com/questions/1625492/execute-maven-plugin-goal-on-child-modules-but-not-on-parent




Alejandro Endo | Software Designer/Concepteur de logiciels




From:   laredotornado-3 
To: users@maven.apache.org,
Date:   02/04/2013 02:07 PM
Subject:Can I force a plugin to not run during parent pom execution
phase?



Hi,

I'm using Maven 3.0.3.  I've included this plugin in a profile in my parent
pom, however, when I run my parent pom, I don't want this to be executed as
part of the parent pom being built (I do want it executed for each of the
child modules).  How can I make this plugin not run during the parent
execution phase?

 4.0.0
 org.mainco.subco
 subco
 12.0.0-SNAPSHOT
 
 moduleA
 moduleB
 moduleC
 pom

 
 
 ...

 

org.liquibase

liquibase-maven-plugin

2.0.1



 

 mysql

 mysql-connector-java

 5.1.18

 





 

 build-database

 process-test-resources

 

 com.mysql.jdbc.Driver


jdbc:mysql://${test.mysql.db.host}:${test.mysql.db.port}/$
{test.mysql.db.sid}

 
${test.mysql.db.user}

 $
{test.mysql.db.password}


$
{project.build.directory}/db.changelog-master.xml


false

 

 

 update

 

 



 

Thanks, - Dave




--
View this message in context:
http://maven.40175.n5.nabble.com/Can-I-force-a-plugin-to-not-run-during-parent-pom-execution-phase-tp5752479.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


DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: release plugin, different executable name ('mvn3')

[Alejandro . Endo]

What about just a simple symlink (mvn --> mvn3) on your own account? you
don't need any system (root) permission, you create it yourself in your
account in one of your folders in your PATH



Alejandro Endo | Software Designer/Concepteur de logiciels




From:   José Manuel Castroagudín Silva 
To: Maven Users List ,
Date:   14/05/2013 04:38 AM
Subject:Re: release plugin, different executable name ('mvn3')



@Graham: If you remember anything you may have changed, or any tweaking to
this plugin, I'll be very interested in knowing about it.

@Stephen : That's my "backup plan". However, I don't have permissions to
change anything on that machine, and any change would have to be requested
to a different team. This would take some time (bureaucracy can sometimes
be quite slow, hehe). As I'm just doing some tests, I would rather try
different approaches.

well, thank you all. Any tip is welcome.


2013/5/14 José Manuel Castroagudín Silva 

> This is what I'm seeing:
>
> [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare (default-cli)
on project : Failed to invoke Maven build. Error configuring
command-line. Reason: Maven executable not found at: /bin/mvn
-> [Help 1]
>
> (some specific details edited out)
>
> I was assuming that was the default behavior (as seen on
> http://jira.codehaus.org/browse/MRELEASE-428 ).
>
>
>
> 2013/5/14 Graham Leggett 
>
>> On 14 May 2013, at 08:31, José Manuel Castroagudín Silva <
>> chavescesu...@gmail.com> wrote:
>>
>> > I've started doing some testing about maven-release plugin, and
>> everything
>> > went fine until the moment of trying it in our existing CI platform.
Due
>> > to, I think, "historical reasons", the maven executable is in this
>> machine
>> > named 'mvn3' and not 'mvn'.
>> >
>> > I've been looking around, and as for now, I would say there's no way
of
>> > telling the release plugin which executable to use. Is this so?
>>
>> Can you confirm what problem you are seeing?
>>
>> In theory, the release plugin shouldn't need to care what the name of
the
>> executable is. In our ci environment maven is also called mvn3, and it
just
>> works.
>>
>> Regards,
>> Graham
>> --
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Saúde,
>
> J. M. Castroagudín
>



--
Saúde,

J. M. Castroagudín

DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

maven-surefire-plugin

[Alejandro . Endo]

Hello everyone

I'm wondering about forkedProcessTimeoutInSeconds  in the test mojo of the
maven-surefire-plugin. What is not clear from the docs is, is this timeout
reset per test? is it affected by the number of forks?
e.g.
if i have only 1 fork and i have 300 tests @ 1s each and I set the timeout
at 20s, will it fail the tests because the combined time is > 20s or as
long as one single test doesn't go over 20s they will all pass?

Thank you


Alejandro Endo | Software Designer/Concepteur de logiciels
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

RC and SNAPSHOT dependencies

[Alejandro . Endo]

Is there a maven way to have an artifact of version SNAPSHOT with
dependencies of type SNAPSHOT that when doing a release via the
maven-release-plugin can be changed to non-snapshot dependencies, in
particular actually a **range** of RCs?

what I want is a POM like this

...
1.0.0-SNAPSHOT

...

   ...
   ...
   2.1.0-SNAPSHOT


that when doing a release build with the maven-release-plugin becomes

1.0.0.0 

   ...
   ...
   [2.1.0.0, 2.1.0.999]


So the versioning scheme i'm following is that all snapshot builds of this
artifact depend on a snapshot dependency version (2.1.0-SNAPSHOT in my
example) but that RCs contain a fourth digit that is just an RC counter.
All this because i can't redeploy a single RC 2.1.0 and the numerical
quality of a fourth digit seems simpler than an "RC" qualifier which is
treated lexicographically in a range and which causes a -SNAPSHOT to be
deemed newer than an -RC

What I'm trying to avoid is having to update all  tags  to a
particular RC count every time there is a new RC of the 2.1.0 dependency.
This is why i use a range for all the RCs

At a higher level, what I'm trying to do is simply to have snapshots depend
on snapshots and RCs depend on the latest RC within a branch, not just the
newest RC. Feel free to suggest a completely different (correct?) way to do
this

Thank you,



Alejandro Endo | Software Designer/Concepteur de logiciels
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: RC and SNAPSHOT dependencies

[Alejandro . Endo]

Interesting

I see the point of non-reproducibility; however, if one follows a semantic
versioning scheme then 1.2.2 and 1.2.3 are both completely compatible. Even
better between 1.2.2.1 and 1.2.2.2, which is the case where the 4th digit
is just an RC counter

But back to your point, so the recommended way is to do an RC 1.2.2.2 of
the dependency and then update the 50 poms that have it as a dependency to
use the new 1.2.2.2 instead of 1.2.2.1? sometimes, like in my case, the
dependency is developed by another team so it's not even easy to know when
a new RC has been created. And because the changing digit is just an RC
counter, then it will change relatively often right before a release

Then add to all that a CI server, which increases the requirement of a
non-interactive scheme.

Any guidelines for this (seemingly) common scenario?




Alejandro Endo | Software Designer/Concepteur de logiciels
Miranda Technologies | Tel: (514) 333-1772 Ext: 3789
3499 Douglas-B.-Floreani, Montréal, QC  H4S 2C6  Canada
Miranda Technologies is a brand of Belden Inc.



From:   Stephen Connolly 
To: Maven Users List ,
Date:   16/05/2013 06:20 AM
Subject:Re: RC and SNAPSHOT dependencies



Aside: in my experience using version ranges in released poms is a serious
anti-pattern. I can just about accept arguments for their use in
development poms, but at release time it is my experience that they should
be pinned to the specific version that the release is performed with
(otherwise the release build is not reproducible)

Dependency version ranges are a seductive siren, one that Maven listened
to, and I think in retrospect it was a mistake to listen to that siren.


On 15 May 2013 21:38,  wrote:

>
>
> Is there a maven way to have an artifact of version SNAPSHOT with
> dependencies of type SNAPSHOT that when doing a release via the
> maven-release-plugin can be changed to non-snapshot dependencies, in
> particular actually a **range** of RCs?
>
> what I want is a POM like this
>
> ...
> 1.0.0-SNAPSHOT
>
> ...
> 
>...
>...
>2.1.0-SNAPSHOT
> 
>
> that when doing a release build with the maven-release-plugin becomes
>
> 1.0.0.0 
> 
>...
>...
>[2.1.0.0, 2.1.0.999]
> 
>
> So the versioning scheme i'm following is that all snapshot builds of
this
> artifact depend on a snapshot dependency version (2.1.0-SNAPSHOT in my
> example) but that RCs contain a fourth digit that is just an RC counter.
> All this because i can't redeploy a single RC 2.1.0 and the numerical
> quality of a fourth digit seems simpler than an "RC" qualifier which is
> treated lexicographically in a range and which causes a -SNAPSHOT to be
> deemed newer than an -RC
>
> What I'm trying to avoid is having to update all  tags  to a
> particular RC count every time there is a new RC of the 2.1.0 dependency.
> This is why i use a range for all the RCs
>
> At a higher level, what I'm trying to do is simply to have snapshots
depend
> on snapshots and RCs depend on the latest RC within a branch, not just
the
> newest RC. Feel free to suggest a completely different (correct?) way to
do
> this
>
> Thank you,
>
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
> DISCLAIMER:
>
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
>
> Thank You.
>
>

DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: Call a custom plugin from another project

[Alejandro . Endo]

IIUC, you are trying to bind a plugin execution to a phase?

Check this link

http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Configuring_Build_Plugins

Basically, you need an "" tag with the configuration for the
plugin and a  that the plugin is bound to

so if you bind it to "package" for example, your plugin will be executed
when you run "mvn package"



Alejandro Endo | Software Designer/Concepteur de logiciels




From:   alesky 
To: users@maven.apache.org,
Date:   04/06/2013 01:17 PM
Subject:Re: Call a custom plugin from another project



ok Stephen thanks

specifying an execution to the plugin it works



but i would like to injects an execution in the packaging for the specified
plugin project
in the way that i can use the plugin in this way, and don't have to force
the user to specific the execution



but i didn't found any documentation on-line or in the reference guide
regarding this point
or at list I'm not able to find a correct on-line document to do it

what i i found is that in the plugin annotation there is the @execute
annotation,
but from my understand this annotation is complete different from what i
want to do

@execute goal=""
This will execute the given goal before execution of this one. The goal
name
is specified using the prefix:goal notation.
@execute phase=""
This will fork an alternate build lifecycle up to the specified phase
before
continuing to execute the current one. If no lifecycle is specified, Maven
will use the lifecycle of the current build.
@execute lifecycle="" phase=""
This will execute the given alternate lifecycle. A custom lifecycle can be
defined in META-INF/maven/lifecycles.xml.








--
View this message in context:
http://maven.40175.n5.nabble.com/Call-a-custom-plugin-from-another-project-tp5758214p5758242.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


DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: Filter dependencies based on OSGi bundle detection during assembly

[Alejandro . Endo]

I don't think you will find such a thing, but if you do, let us know

What we do is exclude particular dependencies, since most of them are osgi
and are to be included; but this probably isn't your case. Some of our osgi
dependencies have an "osgi" classifier but not all so we can't use that to
decide. Maybe you can make all of yours have that classifier and then
includeClassifiers in the copy-dependencies goal?

I don't know if this would be too specific of a setting for the
maven-dependency-plugin (perhaps someone else can clear this up) but it
would be very useful to have an include/excludeBundles that checks the
manifest to detect if the dependency is a bundle. Then again, maybe it
should be a copy-dependencies goal in the maven-bundle-plugin instead.
Either way, it shouldn't be too hard to implement. If you don't write it I
might give it a try, but don't count on it, it won't be soon





Alejandro Endo | Software Designer/Concepteur de logiciels



From:   Tang Kin Chuen 
To: users@maven.apache.org,
Date:   2013-07-04 09:42
Subject:Filter dependencies based on OSGi bundle detection during
assembly



Hi,

I am creating a Maven assembly that copies required dependencies to a "lib"
directory. Since it is an OSGi based application, I would like to exclude
non-OSGi based (transitive) dependencies automatically when my module's
assembly is processed.

>From maven dependency plugin and assembly descriptors configuration, does
not seem to be a way to do this other than specifying includes/excludes
manually for each dependency.

Appreciate if someone can provide advise on a better way to achieve this.

I am looking for something like "if a dependency/transitive dependency does
not include the required OSGi manifest information, exclude it".

Regards,
Kin Chuen



DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.


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

Re: introducing maven-proguard-plugin

[Alejandro . Endo]

if i'm not mistaken, maven-*-plugin is reserved for plugins developed by
the maven team, so you will probably be asked to rename your plugin

I can't find a reference to this claim, hence why so many people
unknowingly violate this convention. I wish it was mentioned in all the
main plugin-howto's

Hopefully someone else will complement this info



Alejandro Endo | Software Designer/Concepteur de logiciels



From:   "Richard Sand" 
To: "'Maven Users List'" ,
Date:   2013-07-15 01:09 PM
Subject:introducing maven-proguard-plugin



Hi all,

I've published version 0.8 of my obfuscation plugin, which can be used to
invoke ProGuard to obfuscate Maven artifacts. It is a Maven3 plugin and
requires Java6. I've tried to integrate it as well as possible into the
maven world to minimize the amount of configuration needed for it to
automatically find the proper files to obfuscate and create a nice usable
output.

The plugin website is
http://mavenproguard.sourceforge.net/project-summary.html. I've opened a
ticket to create a Sonatype project for it, so it can be included in the
central repository, but for now if you want to try it out you can download
it from SourceForge directly:
https://sourceforge.net/projects/mavenproguard/files/. The source code,
SVN,
tickets etc. can also be found there.

I've still got one major maven integration issue, and that's with adding
the
result of the obfuscator back into maven via attachArtifact. If you use the
plugin, leave the "attach" property as false (the default) and use the
resulting jar(s) from the obfuscator via maven assembly. I e-mailed the
list
about that issue a few days ago so if anyone has any insight into that I'd
appreciate any advice!

Anyway I hope someone finds this plugin helpful. Thanks!

Best regards,

Richard





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




DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.


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

maven-release-plugin with github project

[Alejandro . Endo]

I'm  trying to release a multimodule maven project cloned in github. My  
project has the parent pom as a submodule of the root aggregator. if i  run the 
release in dryRun mode it works fine, however if I run it for  real this is 
what i get near the end


...
[INFO] Checking in modified POMs...
[INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
 && git add -- jrobocom-parent/pom.xml jrobocom-core/pom.xml  
jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml  
jrobocom-samples/legends/pom.xml jrobocom-samples/simple/pom.xml  
jrobocom-samples/simple/4Lunch/pom.xml  
jrobocom-samples/simple/black-jacks/pom.xml  
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git status
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
 && git commit --verbose -F /tmp/maven-scm-646807004.commit  
jrobocom-parent/pom.xml jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml 
jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml 
jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
jrobocom-samples/simple/black-jacks/pom.xml  
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git symbolic-ref HEAD
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
 && git push  https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
master:master
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Parent POM  SKIPPED
...
[INFO] Bank-jumper ... SKIPPED
[INFO] The overall aggregator  FAILURE [3:30.447s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3:32.658s
[INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
[INFO] Final Memory: 9M/44M
[INFO] 
[ERROR]  Failed to execute goal  
org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  (default-cli) on 
project jrobocom-aggregator: Unable to commit files
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR]  fatal:  
https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  not 
found: did you run git update-server-info on the server?
[ERROR] -> [Help 1]


If  I run that same git push command by hand it does give me that error,  
however, if i run the push with the url just up to .git and remove the 
/jrobocom-aggregator it works fine

Where  does the MRP take the push url from? i'm running mvn from the root  
aggregator since i want to release all submodules together but i don't  see why 
the push url should include the aggregator's artifact id

What am i doing wrong? this seems like the canonical release procedure

This  is the aggregator POM (before running the release) in case anyone is  
interested https://github.com/theHilikus/JRoboCom/blob/master/pom.xml  and from 
there you can find all the other poms

Thank you,
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: maven-release-plugin with github project

[Alejandro . Endo]

 Thank you Robert
I tried MRP 2.3.2 and i got the exact same result. I also have the same setup 
referenced in the OP's comment on the accepted answer (aggregator inherits from 
parent, parent is a submodule of aggregator and actual code modules depend on 
their sibling parent) but somehow it doesn't work for me. The only difference i 
see is git.

Arnaud, in the SO question referenced by Robert and in the blog post referenced 
in it at least 2 other people managed to make it work with an explicit relative 
path. Here is the referenced blog
http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
i'm sure adding git submodules makes everything much more complex. This is why 
i'm surprised mine doesn't work, my setup is very vanilla so i'm sure there's 
hundreds of people trying to do the same thing

Thanks for your help

Any other ideas?

i would still like to know why the push url contains the artifactId of the 
aggregator. I'm not sure if this is MRP or the scm plugin's doing



-"Robert Scholte"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
Date: 07/27/2013 12:29PM
Subject: Re: maven-release-plugin with github project

http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef :

>
>
> I'm  trying to release a multimodule maven project cloned in github. My  
> project has the parent pom as a submodule of the root aggregator. if i  
> run the release in dryRun mode it works fine, however if I run it for  
> real this is what i get near the end
>
>
> ...
> [INFO] Checking in modified POMs...
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git add -- jrobocom-parent/pom.xml  
> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
> jrobocom-samples/simple/black-jacks/pom.xml  
> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom" && git status
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git commit --verbose -F  
> /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
> jrobocom-samples/simple/black-jacks/pom.xml  
> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom" && git symbolic-ref HEAD
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git push  
> https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
> master:master
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Parent POM  SKIPPED
> ...
> [INFO] Bank-jumper ... SKIPPED
> [INFO] The overall aggregator  FAILURE  
> [3:30.447s]
> [INFO]  
> 
> [INFO] BUILD FAILURE
> [INFO]  
> 
> [INFO] Total time: 3:32.658s
> [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
> [INFO] Final Memory: 9M/44M
> [INFO]  
> 
> [ERROR]  Failed to execute goal  
> org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  
> (default-cli) on project jrobocom-aggregator: Unable to commit files
> [ERROR] Provider message:
> [ERROR] The git-push command failed.
> [ERROR] Command output:
> [ERROR]  fatal:  
> https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  
> not found: did you run git update-server-info on the server?
> [ERROR] -> [Help 1]
>
>
> If  I run that same git push command by hand it does give me that  
> error,  however, if i run the push with the url just up to .git and  
> remove the /jrobocom-aggregator it works fine
>
> Where  does the MRP take the push url from? i'm running mvn from the  
> root  aggregator since i want to release all submodules together but i  
> don't  see why the push url should include the aggregator's artifact id
>
> What a

[CAUTION: Suspicious URL content] Re: maven-release-plugin with github project

[Alejandro . Endo]

from the root of the project, which is the same level as the aggregator pom. 
But instead of putting the scm section there like you suggest, I just made the 
aggregator inherit from its submodule (jrobocom-parent). Maybe this is what's 
confusing the release plugin. i will try duplicating the SCM section on the 
aggregator (not great, DRY principle, but i need to be able to have a defined 
SCM on the code modules so I cannot just move the scm section from 
jrobocom-parent to jrobocom-aggregator)





-"Robert Scholte"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
Date: 07/27/2013 03:49PM
Subject: [CAUTION: Suspicious URL content]  Re: maven-release-plugin with 
github project

Hi,

 From which location are you releasing, from master or from jrobocom-parent?

If it's the first, then the scm section should be placed here.
If it's the latter, I think your scm-connections are wrong(not sure) and  
you must use m-release-p 2.3.2 due to the SCM-709 issue.

Robert


Op Sat, 27 Jul 2013 21:35:48 +0200 schreef :

>  Thank you Robert
> I tried MRP 2.3.2 and i got the exact same result. I also have the same  
> setup referenced in the OP's comment on the accepted answer (aggregator  
> inherits from parent, parent is a submodule of aggregator and actual  
> code modules depend on their sibling parent) but somehow it doesn't work  
> for me. The only difference i see is git.
>
> Arnaud, in the SO question referenced by Robert and in the blog post  
> referenced in it at least 2 other people managed to make it work with an  
> explicit relative path. Here is the referenced blog
> http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
> i'm sure adding git submodules makes everything much more complex. This  
> is why i'm surprised mine doesn't work, my setup is very vanilla so i'm  
> sure there's hundreds of people trying to do the same thing
>
> Thanks for your help
>
> Any other ideas?
>
> i would still like to know why the push url contains the artifactId of  
> the aggregator. I'm not sure if this is MRP or the scm plugin's doing
>
>
>
> -"Robert Scholte"  wrote: -
> To: "Maven Users List" 
> From: "Robert Scholte" 
> Date: 07/27/2013 12:29PM
> Subject: Re: maven-release-plugin with github project
>
> http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
> will help you.
>
> Robert
>
> Op Sat, 27 Jul 2013 18:13:28 +0200 schreef :
>
>>
>>
>> I'm  trying to release a multimodule maven project cloned in github. My  
>>  project has the parent pom as a submodule of the root aggregator. if i  
>> run the release in dryRun mode it works fine, however if I run it for  
>> real this is what i get near the end
>>
>>
>> ...
>> [INFO] Checking in modified POMs...
>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
>> workspace/JRoboCom"  && git add -- jrobocom-parent/pom.xml  
>> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
>> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
>> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
>>  jrobocom-samples/simple/black-jacks/pom.xml  
>> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
>> workspace/JRoboCom" && git status
>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
>> workspace/JRoboCom"  && git commit --verbose -F  
>> /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
>> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
>> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
>> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
>>  jrobocom-samples/simple/black-jacks/pom.xml  
>> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
>> workspace/JRoboCom" && git symbolic-ref HEAD
>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
>> workspace/JRoboCom"  && git push  
>> https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
>> master:master
>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>> [INFO]  
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Parent POM  SKIPPED
>> ...
>> [INFO] Bank-jumper ... SKIPPED
>> [INFO] The overall aggregator  FAILURE  
>> [3:30.447s]
>> [INFO]  
>> 
>> [INFO] BUILD F

[CAUTION: Suspicious URL content] Re: maven-release-plugin with github project

[Alejandro . Endo]

 There seem to be some differences to my case. The bug says "It seems to think 
for some reason that I am at the root of my scm tree". In my case i AM in the 
root of my scm tree. Also, in his problem, the build fails on the git commit. 
in my case it fails on the git push after the commit succeeds. Some comments 
also mention it happens in windows/cygwin. I'm running mine in linux


-Arnaud Héritier  wrote: -
To: Maven Users List 
From: Arnaud Héritier 
Date: 07/27/2013 04:16PM
Subject: [CAUTION: Suspicious URL content]  Re: maven-release-plugin with 
github project

The issue I was referring to was this one :
https://jira.codehaus.org/browse/MRELEASE-581

Arnaud


On Sat, Jul 27, 2013 at 9:49 PM, Robert Scholte wrote:

> Hi,
>
> From which location are you releasing, from master or from jrobocom-parent?
>
> If it's the first, then the scm section should be placed here.
> If it's the latter, I think your scm-connections are wrong(not sure) and
> you must use m-release-p 2.3.2 due to the SCM-709 issue.
>
> Robert
>
>
> Op Sat, 27 Jul 2013 21:35:48 +0200 schreef :
>
>
>   Thank you Robert
>> I tried MRP 2.3.2 and i got the exact same result. I also have the same
>> setup referenced in the OP's comment on the accepted answer (aggregator
>> inherits from parent, parent is a submodule of aggregator and actual code
>> modules depend on their sibling parent) but somehow it doesn't work for me.
>> The only difference i see is git.
>>
>> Arnaud, in the SO question referenced by Robert and in the blog post
>> referenced in it at least 2 other people managed to make it work with an
>> explicit relative path. Here is the referenced blog
>> http://warpedjavaguy.**wordpress.com/2011/08/08/how-**
>> i-defeated-the-maven-release-**plugin-in-a-flat-structured-**
>> multi-module-project/
>> i'm sure adding git submodules makes everything much more complex. This
>> is why i'm surprised mine doesn't work, my setup is very vanilla so i'm
>> sure there's hundreds of people trying to do the same thing
>>
>> Thanks for your help
>>
>> Any other ideas?
>>
>> i would still like to know why the push url contains the artifactId of
>> the aggregator. I'm not sure if this is MRP or the scm plugin's doing
>>
>>
>>
>> -"Robert Scholte"  wrote: -
>> To: "Maven Users List" 
>> From: "Robert Scholte" 
>> Date: 07/27/2013 12:29PM
>> Subject: Re: maven-release-plugin with github project
>>
>> http://stackoverflow.com/**questions/17766247/maven-**
>> release-plugin-pushing-tags-**to-wrong-repo/17771493#**17771493
>> will help you.
>>
>> Robert
>>
>> Op Sat, 27 Jul 2013 18:13:28 +0200 schreef :
>>
>>
>>>
>>> I'm  trying to release a multimodule maven project cloned in github. My
>>>  project has the parent pom as a submodule of the root aggregator. if i run
>>> the release in dryRun mode it works fine, however if I run it for real this
>>> is what i get near the end
>>>
>>>
>>> ...
>>> [INFO] Checking in modified POMs...
>>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse
>>> workspace/JRoboCom"  && git add -- jrobocom-parent/pom.xml
>>> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
>>>  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
>>>  jrobocom-samples/simple/**4Lunch/pom.xml
>>>  jrobocom-samples/simple/black-**jacks/pom.xml
>>> jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
>>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>>> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse
>>> workspace/JRoboCom" && git status
>>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse
>>> workspace/JRoboCom"  && git commit --verbose -F /tmp/maven-scm-646807004.
>>> **commit  jrobocom-parent/pom.xml jrobocom-core/pom.xml
>>>  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
>>>  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
>>>  jrobocom-samples/simple/**4Lunch/pom.xml
>>>  jrobocom-samples/simple/black-**jacks/pom.xml
>>> jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
>>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>>> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse
>>> workspace/JRoboCom" && git symbolic-ref HEAD
>>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>>> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse
>>> workspace/JRoboCom"  && git push https://github.com/theHilikus/**
>>> JRoboCom.git/jrobocom-**aggregatormaster:master
>>> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
>>> [INFO] --*

Re: maven-release-plugin with github project

[Alejandro . Endo]

 Ok, removing the dependency to the parent in the aggregator seemed to fix the 
problem. now the push url makes sense:
git push https://github.com/theHilikus/JRoboCom.git master:master

However, now I encounter a problem i've always had in the past when releasing 
and never bothered to troubleshoot. After running git push I am asked for the 
username and pass of github. After I enter them, the release just hangs there

This is the output using -X

...
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git commit --verbose -F /tmp/maven-scm-1784899634.commit 
jrobocom-parent/pom.xml jrobocom-core/pom.xml jrobocom-simple-gui/pom.xml 
jrobocom-samples/pom.xml jrobocom-samples/legends/pom.xml 
jrobocom-samples/simple/pom.xml jrobocom-samples/simple/4Lunch/pom.xml 
jrobocom-samples/simple/black-jacks/pom.xml 
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git symbolic-ref HEAD
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git push https://github.com/theHilikus/JRoboCom.git master:master
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
Username for 'https://github.com': theHilikus
Password for 'https://thehili...@github.com':
//hangs here forever after i press enter

the only way i have been able to fix this is by cancelling the release 
(ctrl-c), running "git push https://github.com/theHilikus/JRoboCom.git 
master:master" by hand (no maven) which completes without a problem, then 
undoing the manual push and then rerunning the release-plugin, which now 
doesn't block after i enter my credentials; pretty annoying and long procedure.

Any ideas what could be wrong this time?

Thanks again,

Alejandro

-"Robert Scholte"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
Date: 07/27/2013 12:29PM
Subject: Re: maven-release-plugin with github project

http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef :

>
>
> I'm  trying to release a multimodule maven project cloned in github. My  
> project has the parent pom as a submodule of the root aggregator. if i  
> run the release in dryRun mode it works fine, however if I run it for  
> real this is what i get near the end
>
>
> ...
> [INFO] Checking in modified POMs...
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git add -- jrobocom-parent/pom.xml  
> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
> jrobocom-samples/simple/black-jacks/pom.xml  
> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom" && git status
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git commit --verbose -F  
> /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
> jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
> jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
> jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
> jrobocom-samples/simple/black-jacks/pom.xml  
> jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom" && git symbolic-ref HEAD
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse  
> workspace/JRoboCom"  && git push  
> https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
> master:master
> [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
> [INFO]  
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Parent POM  SKIPPED
> ...
> [INFO] Bank-jumper ... SKIPPED
> [INFO] The overall aggregator  FAILURE  
> [3:30.447s]
> [INFO]  
> 
> [INFO] BUILD FAILURE
> [INFO]  
> 
> [INFO] Total time: 3:32.658s
> [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
> [INFO] Final Memory: 9M/44M
> [INFO]  
> 

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

[Alejandro . Endo]

This is exactly what I needed a couple of weeks ago. I came up with the
same procedure but discovered that the versions plugin doesn't support
unresolving ranges. Is this something that's in the works or it's just
something you wish  were there?



Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Stephen Connolly 
To: Maven Users List ,
Date:   2013-08-01 04:56 AM
Subject:Re: continuous releasing: versions:set and/or
release:update-version to release an aggregator project



How I want this to work is to have versions-maven-plugin have a way to undo
versions:resolve-ranges (
http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) -
it would need to ensure that the lower bound of any unresolved range is the
resolved version... [see below]

We'd need to split preparationGoals in the release plugin... either into
preparationGoals + verificationGoals or into initiationGoals +
preparationGoals (I favour the latter as it preserves the semantics of
preparationGoals... but the first one maps more correctly with what each
set should be doing)

Then this would become super easy...

You develop with version ranges for your dependencies...

The release plugin would have
initiationGoals = versions:resolve-ranges versions:commit
preparationGoals = clean verify
completionGoals = versions:unresolve-ranges versions:commit

So say your development pom has


  ...
  foo
  [1.0,2.0)


and the latest version of foo is 1.2

When you kick off the release, the range gets resolved to


  ...
  foo
  1.2


(My current thought is to use an XML PI to stash the old range)

Then we invoke Maven again (because Maven doesn't re-read the poms) and do
a "clean verify" to make sure that this all builds

Then we tag the release

Then we run completionGoals and versions:unresolve-ranges puts the version
range back, but upping the lower bound


  ...
  foo
  [1.2,2.0)


Maven ups the pom version to next development snapshot and commits the pom

That will give you the ability to develop on ranges (which is nice and
flexible) but release on pinned versions (which is exactly what you should
be doing)

If we cannot deliver something like that, then I think we should just drop
ranges from the next major version of Maven.




On 1 August 2013 06:19, Nestor Urquiza  wrote:

> Hi,
>
> Let me give more information,
>
> I use an aggregator project for war1 project:
> 
> ../jar1
> ../jar2
> ../war-inc
> ../war1
> 
>
> Another aggregator project for war2 project:
> 
> ../jar1
> ../war-inc
> ../war1
> 
>
> Notice they both depend on jar1. The jar2 project in fact depends also on
> jar1. The war-inc project is used to keep common web resources for war1
and
> war2. We use maven overlay to marge those shared resources in a final war
> for each project.
>
> This is working like a charm. It has been working in fact now for 3
years.
> However everytime we need a release we need to start updating version
> unmbers in dependencies, doing prepare, then perform, you know the story.
> This is great when the team releases every once in a while. This is an
> issue
> if you want to release several times a day. About resources needed and so
> on
> that is something we are tackling via idempotent scripts so we are
> literally
> ready to make sure we increase the version number for all projects at
once
> every time new code is committed to the version control server. We can
> handle that last part with jenkins, that is not a problem either. The
only
> problem is how can I leverage on an existing tool (without building it
> myself) that would allow to release all modules from just one command.
>
> So back to Roger suggestion I added the version override dependency as
per
> the github project, updated the version tag to point to 0.2.0 and run the
> below command (including actually the very same example from github):
> mvn clean install -Dversion.override=1.2.3-RC-5
>
> However none of the modules were changed including no change to the
> aggregator project either.
>
> Roger, have you used this plugin with aggregator projects as I am trying?
> Could you provide some further guidance?
>
> My option is looking more and more like I will need to do something like:
> foreach module
>   replace module version
>   for each dependency
> if it is a module
>   replace module version
>
> Then find out if mvn:prepare and mvn:perform will work after from the
> aggregator project releasing all necessary projects correctly. At this
> point
> I am already facing another issue. Let us suppose I update my two war
> multi-pom aggregator projects, all the modules and the dependencies to be
> version 2.2000.0-SNAPSHOT.
>

release-plugin versions

[Alejandro . Endo]

Is it possible with the m-release-p to release a multi module project where
each submodule has a different version?
The releaseVersion  property applies to all modules equally. Moreover,
since i have over 300 poms, i can't use the interactive mode that asks for
each module.
I know I can use a properties file with a list of the version of each
module, but I would need to write some script to generate said file, so
before I do that I was wondering if there's a simpler way

All the poms have already their correct version number with the SNAPSHOT
qualifier; why doesn't the m-r-p just drop the SNAPSHOT and use the version
that's left (3.0.0-SNAPSHOT -> 3.0.0), or even better, allow to replace the
SNAPSHOT qualifier with another specified qualifier, e.g. 3.0.0-SNAPSHOT ->
3.0.0-RC-1

Alternative solutions are also welcomed

 thank you



Alejandro Endo | Software Designer/Concepteur de logiciels


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

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

Re: mvn-eclipse-plugin problem with pde projects and linked resources

[Alejandro . Endo]

I use pde + maven-bundle-plugin + osgi framework launcher but i don't use 
mvn-eclipse-plugin. You should be using m2e, which works completely 
different than m-eclipse-p. Just do a final eclipse:clean and forget about 
that plugin. 

Then make sure that your eclipse has m2e (comes by default with any recent 
eclipse) and do a File > import > maven > Existing Maven project if your 
project is already in the filesystem. If not choose "checkout maven 
project from SCM" instead

good luck
Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Jennifer Vendetti 
To: users@maven.apache.org, 
Date:   2013-10-23 03:49 PM
Subject:mvn-eclipse-plugin problem with pde projects and linked 
resources



Hello,

I just took over the maintenance of several OSGi bundles.  I added the 
mvn-eclipse-plugin to the POM files for each of the bundles because I'd 
like to generate the necessary Eclipse project files to work with the 
source code and use the OSGi Framework launcher in the Eclipse IDE:


maven-eclipse-plugin
2.9

true



For reasons I don't understand, running "mvn eclipse:eclipse" generates 
a .project file with an incomplete set of linked resources.  For 
example, I have a POM file for one of the bundles that has the following 
3 dependencies:


  log4j
  log4j
  1.2.17
  


org.apache.felix
org.apache.felix.main
4.2.1



com.jgoodies
looks
2.2.2


The generated .project file for this bundle only has one linked resource 
to one of the artifacts:



   org.protege.common
   Core Protege Libraries. NO_M2ECLIPSE_SUPPORT: Project files 
created with the maven-eclipse-plugin are not supported in 
M2Eclipse.
   
   
 
   org.eclipse.jdt.core.javabuilder
 
 
   org.eclipse.pde.ManifestBuilder
 
 
   org.eclipse.pde.SchemaBuilder
 
   
   
 org.eclipse.jdt.core.javanature
 org.eclipse.pde.PluginNature
   
   
 
   looks-2.2.2.jar
   1
C:/Users/vendetti/.m2/repository/com/jgoodies/looks/2.2.2/looks-2.2.2.jar
 
   


When I try to import the existing PDE project into Eclipse, I get 
compiler errors since the other two artifacts aren't listed as linked 
resources.

Is there something I'm missing about how to properly use this plug-in? 
I'm using Maven version 3.1.0.  Any help and/or advice would be very 
much appreciated.

Jennifer




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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: mvn-eclipse-plugin problem with pde projects and linked resources

[Alejandro . Endo]

it all depends if you are going the maven bundle plugin route (which is 
POM-centric and the manifest is auto generated) or manifest first, where 
the manifest is generated by hand (eclipse tooling helps with this though) 
and the pom is also generated by hand but it has a much smaller role (to 
be exact, there is a way to generate the pom, but you generate it once and 
manage it by hand after, whereas in the first way you never manage the 
manifest and it gets regenerated every time you build, in fact, you don't 
even commit the manifest in your VCS). The major difference is where are 
the dependencies managed. So this is the first decision you will need to 
make, if you haven't already made it
https://docs.sonatype.org/display/TYCHO/OSGiDevelopmentWithMaven
http://stackoverflow.com/questions/11373009/should-i-use-pom-first-or-manifest-first-when-developing-osgi-application-with-m

For the launcher to recognize the project as a bundle I think you just 
need the META-INF folder in the root of the project with an osgi-friendly 
MANIFEST.MF inside

I'm not sure what you mean by Runnables, you mean a new launcher? the fact 
that you capitalise it makes me think of the java interface, but i don't 
see the connection

good luck,
Alejandro Endo | Software Designer/Concepteur de logiciels
Miranda Technologies is a brand of Belden Inc. 



From:   Jennifer Vendetti 
To: Maven Users List , 
Date:   2013-10-23 04:20 PM
Subject:Re: mvn-eclipse-plugin problem with pde projects and 
linked resources



Hello Alejandro,

Thank you very much for the reply, but there is something I don't 
understand.

I'm using Eclipse Kepler, which has m2e.  I tried what you suggested. 
Importing as existing Maven projects works very well, with all 
dependencies detected and no compilation errors.  However, since Eclipse 
sees these as Maven projects rather than PDE projects, I'm unable to 
create a new Runnable of type OSGi Framework in the Run Configurations 
dialog.  Eclipse doesn't detect my projects as bundles.

How are you able to create Runnables with the OSGi Framework launcher? 
Any guidance is very much appreciated.

Best,
Jennifer


On 10/23/2013 12:56 PM, alejandro.e...@miranda.com wrote:
> I use pde + maven-bundle-plugin + osgi framework launcher but i don't 
use
> mvn-eclipse-plugin. You should be using m2e, which works completely
> different than m-eclipse-p. Just do a final eclipse:clean and forget 
about
> that plugin.
>
> Then make sure that your eclipse has m2e (comes by default with any 
recent
> eclipse) and do a File > import > maven > Existing Maven project if your
> project is already in the filesystem. If not choose "checkout maven
> project from SCM" instead
>
> good luck
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
> From:   Jennifer Vendetti 
> To: users@maven.apache.org,
> Date:   2013-10-23 03:49 PM
> Subject:mvn-eclipse-plugin problem with pde projects and linked
> resources
>
>
>
> Hello,
>
> I just took over the maintenance of several OSGi bundles.  I added the
> mvn-eclipse-plugin to the POM files for each of the bundles because I'd
> like to generate the necessary Eclipse project files to work with the
> source code and use the OSGi Framework launcher in the Eclipse IDE:
>
> 
> maven-eclipse-plugin
> 2.9
> 
> true
> 
> 
>
> For reasons I don't understand, running "mvn eclipse:eclipse" generates
> a .project file with an incomplete set of linked resources.  For
> example, I have a POM file for one of the bundles that has the following
> 3 dependencies:
>
> 
>log4j
>log4j
>1.2.17
>
>
> 
> org.apache.felix
> org.apache.felix.main
> 4.2.1
> 
>
> 
> com.jgoodies
> looks
> 2.2.2
> 
>
> The generated .project file for this bundle only has one linked resource
> to one of the artifacts:
>
> 
> 
> org.protege.common
> Core Protege Libraries. NO_M2ECLIPSE_SUPPORT: Project files
> created with the maven-eclipse-plugin are not supported in
> M2Eclipse.
> 
> 
>   
> org.eclipse.jdt.core.javabuilder
>   
>   
> org.eclipse.pde.ManifestBuilder
>   
>   
> org.eclipse.pde.SchemaBuilder
>   
> 
> 
>   org.eclipse.jdt.core.javanature
>   org.eclipse.pde.PluginNature
> 
> 
>   
> looks-2.2.2.jar
> 1
> 
C:/Users/vendetti/.m2/repository/com/jgoodies/looks/2.2.2/looks-2.2.2.jar
>   
> 
> 
>
> When I try to import the existing PDE project into Eclipse, I get
> compiler errors since the other two artifacts aren't listed as linked
> resources.
>
> Is there something 

deplot at end not working

[Alejandro . Endo]

I'm using m-d-p 2.8.1 using the new deploy at end config. I also use 
install at end in the m-i-p. However, what I see is that sometimes the 
artifacts are not installed nor deployed at all.
I see the normal execution of the plugins with the ** will be deployed at 
end in both cases. But comparing the cases when it does work and when it 
doesn't, when it does I see a final invocation to m-d-p where the deploy 
happens. This last invocation sometimes doesn't happen. I have -X logs for 
both cases but the case where it doesn't work, the build is like 
200modules so the log is 150MB

I'm using differential builds in jenkins (mvn -amd -pl ) in the one that 
worked, and it built and deployed like 10artifacts that changed. But when 
I run it without -amd -pl, i.e. a full build, it never deploys nor 
installs at end


This is the last part of when it doesn't work (some obfuscations done)

[DEBUG]   (f) retryFailedDeploymentCount = 1
[DEBUG]   (f) skip = false
[DEBUG]   (f) updateReleaseInfo = false
[DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @ 
/var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
[DEBUG] -- end configuration --
[INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
sessionEnded
[INFO] 

[INFO] Reactor Summary:
[INFO]



when it does work i see at the end the deploy plugin running

Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
mojoSucceeded 
org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
sessionEnded
[INFO] 

[INFO] Reactor Summary:
...


Is this a known issue or am I doing something wrong?

Let me know if someone needs more details

Thank you, 
Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: deplot at end not working

[Alejandro . Endo]

Thank you Andreas and Robert. That was probably the problem. That also 
explains why there were like 4 artifacts (our of ~300) that did get 
deployed.

Two questions:
1) is there an open bug already for this known issue? i would like to 
follow it
2) Why is this the current behaviour? shouldn't it just fail the build as 
soon as it detects a version mismatch? i've never seen a similar behaviour 
in maven where you ask it to do something (deploy), it doesn't do it, but 
finishes successfully

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   "Robert Scholte" 
To: "Maven Users List" , 
Date:   2013-11-08 12:42 PM
Subject:Re: deplot at end not working



There are still a small number of cases where the *AtEnd doesn't work, so 
I'm still glad I didn't made it the default behavior.
Most important is that all modules must use exactly the same version of 
either the maven-install-plugin or maven-deploy-plugin, otherwise the 
plugin can't keep track of the number of processed projects.
If it is still an issue and you can reproduce it with a small multimodule 
example, upload it with a new JIRA issue, just like MINSTALL-102[1]
Other examples of integration tests can be found in subversion[2]

Robert

[1] https://jira.codehaus.org/browse/MINSTALL-102
[2] 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/


Op Fri, 08 Nov 2013 18:21:20 +0100 schreef :

> I'm using m-d-p 2.8.1 using the new deploy at end config. I also use
> install at end in the m-i-p. However, what I see is that sometimes the
> artifacts are not installed nor deployed at all.
> I see the normal execution of the plugins with the ** will be deployed 
at
> end in both cases. But comparing the cases when it does work and when it
> doesn't, when it does I see a final invocation to m-d-p where the deploy
> happens. This last invocation sometimes doesn't happen. I have -X logs 
> for
> both cases but the case where it doesn't work, the build is like
> 200modules so the log is 150MB
>
> I'm using differential builds in jenkins (mvn -amd -pl ) in the one that
> worked, and it built and deployed like 10artifacts that changed. But 
when
> I run it without -amd -pl, i.e. a full build, it never deploys nor
> installs at end
>
>
> This is the last part of when it doesn't work (some obfuscations done)
>
> [DEBUG]   (f) retryFailedDeploymentCount = 1
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) updateReleaseInfo = false
> [DEBUG]   (f) project = MavenProject: com.tools:blah:1.0.0-SNAPSHOT @
> /var/lib/jenkins/workspace/blah/tools/upgrade/pom.xml
> [DEBUG] -- end configuration --
> [INFO] Deploying com.tools:blah:1.0.0-SNAPSHOT at end
> projectSucceeded com.tools:blah:1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> 
>
>
> when it does work i see at the end the deploy plugin running
>
> Uploaded: http://someUrl/maven-metadata.xml (415 B at 1.0 KB/sec)
> mojoSucceeded
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1(default-deploy)
> projectSucceeded com.tools.other:foo.1.0.0-SNAPSHOT
> sessionEnded
> [INFO]
> ----
> [INFO] Reactor Summary:
> ...
>
>
> Is this a known issue or am I doing something wrong?
>
> Let me know if someone needs more details
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.

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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

downloading artifacts from maven repo

[Alejandro . Endo]

I am trying to create a maven project that needs to package a bunch of 
maven artifacts to finally invoke jwrapper using the exec-maven-plugin. 
Because this project is mostly an integration task (jars are already 
compiled and deploy in a maven repo) i am wondering what are the tools 
available to download artifacts from a repo. Something like 
dependency:copy-dependencies or dependency:get but that would let me work 
in a more generic way such as "download every jar under 
com.mycompany.projectA.* and put it in target/libA"
Having an explicit list of dependencies in the pom itself is not an option 
since 1) there are hundreds of jars 2) it introduces having to maintain a 
list of jars to use. I want to use instead "coordinate wildcards" to 
download whole areas of the repo.

I was planning on writing such a library (which later could be easily made 
into a maven plugin) but i wanted to know if there is something similar 
already in existence.

Apart from the question of whether such a thing exists, I also want to 
know what are the philosophical arguments against it, if any. I have heard 
here talk about anything remotely touching integration should not be a job 
for maven, is that really the case? in this case i am still building an 
application, just not by compiling code but by integrating multiple jars

Any thoughts?

Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

property relative to pom

[Alejandro . Endo]

I am trying to create a property  in a parent pom since I
want all children modules to use a single output folder. What i tried
first was defining this property in the parent pom
${project.build.directory}

And then in a child, something like

${outputFolder}


However, the property outputFolder gets defined differently based on where
it is used, so basically, it's the same as if I used this in the children

${project.build.directory}

i.e. the children end up using their own output folder like maven does by
default. Is there any way to "anchor" that property to be resolved to the
build directory of the pom where it is defined (the parent pom) and not
where it is accessed?
Alejandro Endo | Software Designer/Concepteur de logiciels
Miranda Technologies | Tel: (514) 333-1772 Ext: 3789
3499 Douglas-B.-Floreani, Montréal, QC  H4S 2C6  Canada
Miranda Technologies is a brand of Belden Inc.
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: Searching for artifacts which are used as a dependency by other artifacts

[Alejandro . Endo]

Another workaround if you want to do this only for projects in your
current reactor and it is done sporadically + not programatically would be
to use the maven-graph-plugin. From the image you will see the incoming
arrows.

Just an extra idea...

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   "Lyons, Roy" 
To: Maven Users List ,
Date:   2013-12-19 10:21
Subject:Re: Searching for artifacts which are used as a dependency
by other artifacts



I can say that Sonatype has a solution for this in CLM - as long as you
scan everything it will maintain the relationships for the reverse
dependency lookup.

I think I heard that they were thinking about bringing this capability to
Nexus (by querying CLM in the backend).

Other than that, I ended up writing a perl script that would parse the
following out of every branch in every repository:
mvn help:effective-pom
mvn dependency:list
pom.xml

I then read that into a wonderful hash structure which I used to create a
reverse hash, and then create a nice csv file from that data which I can
use in and excel-like program to search for the dependency - and see the
results.  I created a forward-dependency.csv and a reverse-dependency.csv
with my hash structures to present the data in different ways.

Either way, its totally possible to do.

On 12/19/13 8:36 AM, "Karl Heinz Marbaise"  wrote:

>Hi,
>
>currently i'm searching for a solution to the given problem:
>
>Given maven coordinates: GAV
>
>I would like to know of which other artifacts (GAV) this given GAV is
>used by. Or in other words which artifacts having a dependency to the
>above artifact.
>
>I've found in the meantime the maven-indexer project which uses the
>repository index (central or others like from Nexus). But it looks like
>it can't solve this...may be i miss something in relationship with
>maven-indexer ..
>
>
>Does someone have an idea how to solve the above problem ?
>
>I appreciate any hints etc. links or so...
>
>Kind regards
>Karl-Heinz Marbaise
>--
>SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
>Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
>Hauptstrasse 177 USt.IdNr: DE191347579
>52146 Würselen   http://www.soebes.de
>
>-
>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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: property relative to pom

[Alejandro . Endo]

Thank you for the reply Curtis.

But I'm not sure I understand. I don't see the point of overwriting the
property in every child pom, the whole point of having the property is to
define it only once in the parent pom. If i have to define the property in
every child i will just configure the plugin without properties in each
child pom like this


   ${basedir}/../target


Did I misunderstand your comment about overriding the property in every
child?

Thanks again,
Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Curtis Rueden 
To: Maven Users List ,
Date:   2013-12-19 18:01
Subject:Re: property relative to pom
Sent by:ctrueden.w...@gmail.com



Hi Alejandro,

> I am trying to create a property  in a parent pom since
> I want all children modules to use a single output folder.

This is a variation of the "${basedir}/.." hack.

See this thread:
http://mail-archives.apache.org/mod_mbox/maven-users/201304.mbox/%3CCADN69ymQJsxB16e=grt63ucr_zx72rkpxkegcfw4k5-0rd8...@mail.gmail.com%3E


In short, you have to override your outputDirectory property in every
child
POM.

Doing this is considered somewhat bad practice, but does the job.

Regards,
Curtis

P.S. For a Maven plugin which implements this feature, see:
https://github.com/imagej/imagej-maven-plugin

If others find the set-rootdir feature of imagej-maven-plugin useful, we
could potentially isolate it into its own dedicated plugin.


On Mon, Dec 16, 2013 at 10:54 AM,  wrote:

> I am trying to create a property  in a parent pom since I
> want all children modules to use a single output folder. What i tried
> first was defining this property in the parent pom
> ${project.build.directory}
>
> And then in a child, something like
> 
> ${outputFolder}
> 
>
> However, the property outputFolder gets defined differently based on
where
> it is used, so basically, it's the same as if I used this in the
children
> 
> ${project.build.directory}
> 
> i.e. the children end up using their own output folder like maven does
by
> default. Is there any way to "anchor" that property to be resolved to
the
> build directory of the pom where it is defined (the parent pom) and not
> where it is accessed?
> Alejandro Endo | Software Designer/Concepteur de logiciels
> Miranda Technologies | Tel: (514) 333-1772 Ext: 3789
> 3499 Douglas-B.-Floreani, Montréal, QC  H4S 2C6  Canada
> Miranda Technologies is a brand of Belden Inc.
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Maven Jarsigner plugin vs Apache Maven Shared Jarsigner

[Alejandro . Endo]

Can someone explain what is the difference between these two plugins. 
Based on the description, they do the same

This plugin signs and verifies the project artifacts using the jarsigner
tool. See the plugin's site for more details:
vs
This component provides some utilities to sign/verify jars/files in your 
Mojos.

What I am actually looking for is a way in maven to UNsign jars. In the 
"release notes" of maven shared jarsigner i see a fixed bug [MSHARED-314] 
- Unsigning a jar is not correct
This gives me hope that there is already a way to unsign jars but i can't 
find how to do it


Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: Maven Jarsigner plugin vs Apache Maven Shared Jarsigner

[Alejandro . Endo]

Ok, forget about the first question. I get know what is meant by "shared". 
i usually call this "common" so i missed it.
But still, the second question remains: how to just clear all signatures 
from a jar. The removeExistingSignatures parameter states that "the 
resulting JAR will appear as being signed only once. " whereas i just want 
to remove any existing signature

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Alejandro Endo/MontrealMIR/BeldenCDT
To: users@maven.apache.org, 
Date:   2014-01-06 03:58 PM
Subject:Maven Jarsigner plugin vs Apache Maven Shared Jarsigner


Can someone explain what is the difference between these two plugins. 
Based on the description, they do the same

This plugin signs and verifies the project artifacts using the jarsigner
tool. See the plugin's site for more details:
vs
This component provides some utilities to sign/verify jars/files in your 
Mojos.

What I am actually looking for is a way in maven to UNsign jars. In the 
"release notes" of maven shared jarsigner i see a fixed bug [MSHARED-314] 
- Unsigning a jar is not correct
This gives me hope that there is already a way to unsign jars but i can't 
find how to do it


Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

[Alejandro . Endo]

If you do open a ticket, please let me/us know. I will +1 it. I am also 
interested in this feature

Alejandro Endo | Software Designer/Concepteur de logiciels



From:   Anders Hammar 
To: Maven Users List , 
Date:   2014-01-15 02:47 PM
Subject:Re: Maven2/Maven3 plugin development: Ensuring only the 
available parameters are allowed
Sent by:anders.g.ham...@gmail.com



It doesn't work with the way Maven plugins currently are configured.
But there will soon be discussions around a new version of the pom, so you
could file a ticket to get this wish on the board.

/Anders (mobile)
Den 15 jan 2014 19:22 skrev "S. Ali Tokmen" :

> Hi Andreas
>
> You are right - this makes a lot of sense.
>
> Shall I still raise a JIRA entry for this functionality; or is this
> close to impossible to implement?
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
>
> My IM, GSM, PGP and other contact details
> are on http://contact.ali.tokmen.com
>
> On 14/01/14 21:16, Anders Hammar wrote:
> > Don't think that's doable as the user could configure the params for
> > different goals in the same configuration section (on plugin level, 
not
> > execution level).
> >
> > /Anders
> >
> >
> > On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen 
 >wrote:
> >
> >> Hi Baptiste, Thomas
> >>
> >> I guess you all got a point :) The reason why I want to check the
> >> configuration is indeed something that would have to be done in each
> goal.
> >>
> >> My remaining question would be whether there is a way to read the
> >>  XML definition from the MOJO - I could then manually
> >> implement such a verification in the different MOJOs.
> >>
> >> Please advise
> >>
> >> Thank you
> >>
> >> S. Ali Tokmen
> >> http://ali.tokmen.com/
> >>
> >> My IM, GSM, PGP and other contact details
> >> are on http://contact.ali.tokmen.com
> >>
> >> On 14/01/14 14:24, Baptiste Mathus wrote:
> >>> Hi,
> >>> Stephen already answered along those lines. What are you missing?
> >>> Cheers
> >>>
> >>>
> >>> 2014/1/9 S. Ali Tokmen 
> >>>
> >>>> Hi Anders
> >>>>
> >>>> Thanks for your reply - and happy new year :)
> >>>>
> >>>> Is there any way I can inject / read the whole plugin configuration
> from
> >>>> the plugin?
> >>>>
> >>>> Best regards
> >>>>
> >>>> S. Ali Tokmen
> >>>> http://ali.tokmen.com/
> >>>>
> >>>> My IM, GSM, PGP and other contact details
> >>>> are on http://contact.ali.tokmen.com
> >>>>
> >>>> On 08/01/14 20:00, Anders Hammar wrote:
> >>>>> AFAIK there is no support for this. If you think there should be,
> >> please
> >>>>> file a ticket [1].
> >>>>>
> >>>>> /Anders
> >>>>>
> >>>>> [1] http://jira.codehaus.org/browse/MNG/
> >>>>>
> >>>>>
> >>>>> On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen <
> nos...@alishomepage.com
> >>>>> wrote:
> >>>>>
> >>>>>> Dear Maven users
> >>>>>>
> >>>>>> I am one of the owners of Codehaus CARGO, which has a 
Maven2/Maven3
> >>>>>> plugin; and would have a question with regards to how parameters 
are
> >>>>>> managed.
> >>>>>>
> >>>>>> We defined our MOJOs with parameters (you can see
> >>>>>>
> >>>>>>
> >>
> 
http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java

> >>>>>> for example), but what happens is that if a user unwillingly puts 
a
> >>>>>> parameter in the wrong place then the plugin execution doesn't 
stop.
> >>>>>>
> >>>>>> As an example, I can write the below POM and build still works 
(even
> >>>>>> thought the MOJO has no parameter called "foo"):
> >>>>>>
> >>>>>>   
> >>>>>> org.codehaus.cargo
> >>>>>> cargo-maven2-plugin
> >>>>>> 1.4.6
> >>>>>> 
> >>>>>>   
> >>>>>>

versions maven plugin

[Alejandro . Endo]

Not sure if this is the right list for codehaus plugins. If not I 
apologize

I have a pom with this



foo.blah
bar
1.2.0-RC-7-SNAPSHOT



I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the 
version we actually released of the code, which is 1.2.0-RC-6. Looking at 
the available mojos, it seems like versions:use-latest-releases is the 
right one to use. In the matrix here it says that this goal will modify 
-SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 
1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 
1.2.0-RC-6 so I don't know if this is just the documentation being wrong. 
I also tried use-latest-versions without success

Any idea how to do this? I just want to change the dependencies (which are 
currently SNAPSHOT due to the m-release-p) to the latest released versions

Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: versions maven plugin

[Alejandro . Endo]

Thank you Stephen. Are there any other ways to stabilize my dependencies 
then?

i have > 300 poms all depending on the released+1 development version. 
This must be a common use-case when using RCs, no? you increase all your 
versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but 
if that RC-1 happens to be released, then all your poms will be depending 
on the SNAPSHOT of an RC-2 that will never be made so you have to 
"downgrade" your dependency versions

Am I doing something out of the ordinary here?




Alejandro Endo | Software Designer/Concepteur de logiciels



From:   Stephen Connolly 
To: Maven Users List , 
Date:   2014-01-20 12:34
Subject:Re: versions maven plugin



v-m-p does not roll back version numbers


On 20 January 2014 16:59,  wrote:

> Not sure if this is the right list for codehaus plugins. If not I
> apologize
>
> I have a pom with this
>
> 
> 
> foo.blah
> bar
> 1.2.0-RC-7-SNAPSHOT
> 
> 
>
> I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with 
the
> version we actually released of the code, which is 1.2.0-RC-6. Looking 
at
> the available mojos, it seems like versions:use-latest-releases is the
> right one to use. In the matrix here it says that this goal will modify
> -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version 
to
> 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> 1.2.0-RC-6 so I don't know if this is just the documentation being 
wrong.
> I also tried use-latest-versions without success
>
> Any idea how to do this? I just want to change the dependencies (which 
are
> currently SNAPSHOT due to the m-release-p) to the latest released 
versions
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: versions maven plugin

[Alejandro . Endo]

I didn't. QA is not happy about rebuilding the system once it's been 
approved so we have to release the RC as approved.

So all our versions are always RC-X-SNAPSHOT or RC-X

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Stephen Connolly 
To: Maven Users List , 
Date:   2014-01-20 13:50
Subject:Re: versions maven plugin



How did you turn your RC into a released version? (I would do it with the
release plugin and just verify the SCM changelog is unchanged)

On Monday, 20 January 2014,  wrote:

> Thank you Stephen. Are there any other ways to stabilize my dependencies
> then?
>
> i have > 300 poms all depending on the released+1 development version.
> This must be a common use-case when using RCs, no? you increase all your
> versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
> if that RC-1 happens to be released, then all your poms will be 
depending
> on the SNAPSHOT of an RC-2 that will never be made so you have to
> "downgrade" your dependency versions
>
> Am I doing something out of the ordinary here?
>
>
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
> From:   Stephen Connolly >
> To: Maven Users List >,
> Date:   2014-01-20 12:34
> Subject:Re: versions maven plugin
>
>
>
> v-m-p does not roll back version numbers
>
>
> On 20 January 2014 16:59, >
> wrote:
>
> > Not sure if this is the right list for codehaus plugins. If not I
> > apologize
> >
> > I have a pom with this
> >
> > 
> > 
> > foo.blah
> > bar
> > 1.2.0-RC-7-SNAPSHOT
> > 
> > 
> >
> > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
> the
> > version we actually released of the code, which is 1.2.0-RC-6. Looking
> at
> > the available mojos, it seems like versions:use-latest-releases is the
> > right one to use. In the matrix here it says that this goal will 
modify
> > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
> to
> > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > 1.2.0-RC-6 so I don't know if this is just the documentation being
> wrong.
> > I also tried use-latest-versions without success
> >
> > Any idea how to do this? I just want to change the dependencies (which
> are
> > currently SNAPSHOT due to the m-release-p) to the latest released
> versions
> >
> > Thank you,
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


-- 
Sent from my phone


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

maven-dependency-plugin:copy-dependencies snapshots

[Alejandro . Endo]

It seems there is no way in the copy-dependencies goal to exclude snapshot 
dependencies. Can anyone think of a way to accomplish this using some kind 
of workaround? I want to copy all the released dependencies only. I'm 
using OSGi+pde and I want to create my target platform with released 
dependencies only while using the snapshot dependencies from the workspace

Thank you

Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: [ANN] flatten-maven-plugin 1.0.0-beta-1 Released

[Alejandro . Endo]

I have a pretty deep hierarchy of poms, ~ 4 or 5 levels where each level
contains certain parameters. Sometimes when I want to change one of the
root parameters and then release I am forced to release 4 or 5 poms, one
at a time, before I can release the artifact we actually ship, otherwise
the m-release-p will complain about snapshots. Can this plugin help with
that? i.e help in releasing a chain of poms in one shot where some of the
parents have SNAPSHOT dependencies. I cannot release from the higher
levels because they aggregate the lower levels so this would release a lot
of artifacts when I am trying to release only one of the leaf ones. To be
clear, when I release only the higher level poms, I have to disable
aggregation to avoid releasing too much

In other words, I would need this plugin to basically only flatten when
doing a release, but i am not sure if the switcheroo happens only at
deploy time or early on so the snapshot-to-release changes in the pom done
by the release-plugin would happen in the flattened version

Anyone knows?

Alejandro Endo | Software Designer/Concepteur de logiciels




From:   Jörg Hohwiller 
To: annou...@mojo.codehaus.org, d...@mojo.codehaus.org,
u...@mojo.codehaus.org, users@maven.apache.org,
Date:   2014-05-01 11:56 AM
Subject:[ANN] flatten-maven-plugin 1.0.0-beta-1 Released



Hi,

The Mojo team is pleased to announce the release of the
flatten-maven-plugin version 1.0.0-beta-1.

Flatten Maven Plugin generates a flattened version of your pom.xml and
makes maven to install
and deploy this one instead of the original pom.xml.

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

To get this update, simply specify the version in your project's plugin
configuration:


 org.codehaus.mojo
 flatten-maven-plugin
 1.0.0-beta-1


All you need to do is add the plugin to the plugins in your build section.

This is the initial release.

Enjoy,

The Mojo team.

Jörg




DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

move data from pom to class or class to pom

[Alejandro . Endo]

I have a java class that has a constant in it (static final String). This 
string is a version number, e.g. "1.3.2-test". I need to have this same 
value in a maven plugin configuration (the jaxb plugin) so I am wondering, 
is it better to keep the actual declaration in the code and somehow tell 
maven to take it from the code, or is it better to declare it in the pom 
and tell java to take the literal value to define the constant from the 
pom??

I don't know how to do either so I would also like to hear some ideas. I 
am hoping i don't have to use resource filtering since having a source 
file as a resource is kind of problematic to me. It has to be ONLY that 
file that gets filtered, it would need to be in a non-standard location 
not src/main/java (maybe this is not true), and in general, it seems to me 
that treating source code as resource is counter-intuitive

Has anyone else solved this issue with the DRY principle across behaviour 
and build system?

The short background is that maven generates an XML schema via jaxb and 
this schema file is then made available at runtime via a service

Thank you,

Alejandro Endo | Software Designer/Concepteur de logiciels 


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: move data from pom to class or class to pom

[Alejandro . Endo]

Hi Curtis,

I *think* i see you point, but wouldn't that happen ONLY if the constant 
is public and referenced in a separate jar?? where it would be inlined in 
the referring class (right?). In my case the constant is package protected 
(it would be private if it wasn't because i need it in unit tests)

The problem with defining it in the manifest is that I use this constant 
in the property of an annotation of the class

@StaticServiceProperty(mandatory = true, type = "java.lang.String", name = 
"schemaVersion", value = SchemaProviderServiceImpl.SCHEMA_VERSION, 
immutable = true)
public class SchemaProviderServiceImpl

so I can't grab it from the manifest at runtime. I guess the way I phrased 
it in the original email implied the opposite, sorry about that

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   Curtis Rueden 
To: Maven Users List , 
Date:   2014-07-16 14:27
Subject:Re: move data from pom to class or class to pom
Sent by:ctrueden.w...@gmail.com



Hi Alejandro,

> I have a java class that has a constant in it (static final String).
> This string is a version number, e.g. "1.3.2-test".

Beware: the Java compiler often inlines constants, _including String
constants_, into classes that reference the value. So if you compile a
class "Foo" against version 1 of library "bar", then run with version 2 of
"bar" in the classpath, Foo will still see the constant value as 1 instead
of 2.

http://javasplitter.blogspot.com/2011/10/static-final-inline-trap.html

Much, much better to embed the version number into the JAR manifest, 
and/or
read it out of the Maven POM which the maven-jar-plugin embeds in the JAR
file.

Regards,
Curtis


On Wed, Jul 16, 2014 at 1:18 PM,  wrote:

> I have a java class that has a constant in it (static final String). 
This
> string is a version number, e.g. "1.3.2-test". I need to have this same
> value in a maven plugin configuration (the jaxb plugin) so I am 
wondering,
> is it better to keep the actual declaration in the code and somehow tell
> maven to take it from the code, or is it better to declare it in the pom
> and tell java to take the literal value to define the constant from the
> pom??
>
> I don't know how to do either so I would also like to hear some ideas. I
> am hoping i don't have to use resource filtering since having a source
> file as a resource is kind of problematic to me. It has to be ONLY that
> file that gets filtered, it would need to be in a non-standard location
> not src/main/java (maybe this is not true), and in general, it seems to 
me
> that treating source code as resource is counter-intuitive
>
> Has anyone else solved this issue with the DRY principle across 
behaviour
> and build system?
>
> The short background is that maven generates an XML schema via jaxb and
> this schema file is then made available at runtime via a service
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: mvn release with pom.xml not in root of git repo

[Alejandro . Endo]

I've been tracking this bug for a while now
Still no progress

You can track it here. There is a workaround there that i haven't tried

Let us know if you try it and whether it works

https://jira.codehaus.org/browse/MRELEASE-875

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   "d...@fortysix.ch" 
To: Maven Users List , 
Date:   2014-07-18 00:39
Subject:mvn release with pom.xml not in root of git repo



Hi,

This question has been asked quite a couple of times already, but I never 
found a real solution nor do I know if this should really be supported:
Is it possible to do a release with the maven-release-plugin when the 
parent pom.xml is not in the root of the git repo?
This is no problem with Subversion, but with git I have never managed to 
get this working.

so layout is like this:

repo-dir
|_.git
|_subdir/pom.xml
|_subdir/subsubdir/pom.xml

has anyone done this? how?

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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

RE: mvn release with pom.xml not in root of git repo

[Alejandro . Endo]

i do have the latest m-release-p, but the git version i don't know how to
set that nor what it currently is. How can i check that?

Thank you Martin

Alejandro Endo | Software Designer/Concepteur de logiciels





From:   Martin Gainty 
To: "users@maven.apache.org" ,
Date:   2014-07-18 10:26
Subject:RE: mvn release with pom.xml not in root of git repo




> To: users@maven.apache.org
> Subject: Re: mvn release with pom.xml not in root of git repo
> From: alejandro.e...@miranda.com
> Date: Fri, 18 Jul 2014 09:53:50 -0400
>
> I've been tracking this bug for a while now
> Still no progress
>
> You can track it here. There is a workaround there that i haven't tried
>
> Let us know if you try it and whether it works
>
> https://jira.codehaus.org/browse/MRELEASE-875
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
MG>Alejando-
MG>did you try latest maven-release-plugin with GIT 2.5 (as robert
suggested) ?
MG>Saludos desde EEUU/Salutations aux États-Unis
MG>Martin
>
>
>
>
> From:   "d...@fortysix.ch" 
> To: Maven Users List ,
> Date:   2014-07-18 00:39
> Subject:mvn release with pom.xml not in root of git repo
>
>
>
> Hi,
>
> This question has been asked quite a couple of times already, but I
never
> found a real solution nor do I know if this should really be supported:
> Is it possible to do a release with the maven-release-plugin when the
> parent pom.xml is not in the root of the git repo?
> This is no problem with Subversion, but with git I have never managed to

> get this working.
>
> so layout is like this:
>
> repo-dir
> |_.git
> |_subdir/pom.xml
> |_subdir/subsubdir/pom.xml
>
> has anyone done this? how?
>
> Domi
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

release of git folder

[Alejandro . Endo]

Hi guys, now that https://jira.codehaus.org/browse/MRELEASE-875 has been 
fixed we are trying to release from a non-root module in a git repo but 
encounter a problem at the git push stage of release:prepare. The url for 
the git repo where it tries to push is wrong. Maven is appending the name 
of the submodule's artifactId to the path of developerConnection that it 
inherited from its parent; this behaviour was fine when we were in CVS, 
but now in git it doesn't make sense. I found some people on SO (
http://stackoverflow.com/questions/6727450/releasing-a-multi-module-maven-project-with-git
) having the same issue but none of the workarounds I tried work.

Is there an official fix or workaround for this?
we're using maven 3.0.4 and m-release-p 2.5.1


Thank you,

Alejandro Endo | Software Designer/Concepteur de logiciels 

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: release of git folder

[Alejandro . Endo]

That's what we figured...

we were trying to not pollute our hundreds of poms with the exact same 
declaration of the scm

Thank you Robert

Alejandro Endo | Software Designer/Concepteur de logiciels 
Grass Valley, A Belden Brand | Tel: (514) 333-1772 Ext: 3789
3499 Douglas-B.-Floreani, St-Laurent, Quebec Canada H4S 2C6




From:   "Robert Scholte" 
To: "Maven Users List" , 
Date:   2014-10-25 06:05
Subject:Re: release of git folder



Hi,

the only workaround I can think of is specifying the developerConnection 
in this project as well.
The root cause of appending the artifactId to the inherited connection is 
in Maven Core, where as it should actually be SCM independent. That's a 
huge change with a huge impact. It requires a lot plugins to be prepared 
for that.
So as said: always specify the developerConnection in you release root 
project.

thanks,
Robert

Op Fri, 24 Oct 2014 16:58:34 +0200 schreef 
:

> Hi guys, now that https://jira.codehaus.org/browse/MRELEASE-875 has been
> fixed we are trying to release from a non-root module in a git repo but
> encounter a problem at the git push stage of release:prepare. The url 
for
> the git repo where it tries to push is wrong. Maven is appending the 
name
> of the submodule's artifactId to the path of developerConnection that it
> inherited from its parent; this behaviour was fine when we were in CVS,
> but now in git it doesn't make sense. I found some people on SO (
> 
http://stackoverflow.com/questions/6727450/releasing-a-multi-module-maven-project-with-git

> ) having the same issue but none of the workarounds I tried work.
>
> Is there an official fix or workaround for this?
> we're using maven 3.0.4 and m-release-p 2.5.1
>
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.

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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: release of git folder

[Alejandro . Endo]

Mark, we are using maven 3.0.4 and encounter the same issue, it must have 
been introduced before

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   "Mark Derricutt" 
To: "Maven Users List" , 
Date:   2014-10-27 17:50
Subject:Re: release of git folder



On 25 Oct 2014, at 23:05, Robert Scholte wrote:

> the only workaround I can think of is specifying the developerConnection 
in this project as well.

I was meaning to post about this bug the other week - which we came across 
when working on the tiles-maven-plugin - this was introduced in the 
DefaultInheritanceAssemble somewhere in 3.1.x cycle.

For some reason - for every parent in the chain it appends the artifactId 
to the parents SCM section fields ( connection, developerConnection etc. 
).

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
[attachment "signature.asc" deleted by Alejandro 
Endo/MontrealMIR/BeldenCDT] 

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Maven use for integration

[Alejandro . Endo]

Hello everyone,

I wanted to ask what you guys though about using maven as an integration 
tool. Is it out of the scope of maven? is anyone else doing this? What I 
mean by integration is that the artifacts are built (also by maven but in 
other jobs) and deployed to nexus, but I still need to download them all 
to a server for deployment. 
The build of this server invokes maven and I hooked to it via a pom that 
points to some artifacts that serve as an entry point to the dependency 
graph and then use the dependency:copy-dependencies goal. The point of 
this was to leverage the dependency information available in poms so I 
didn't have to keep a list of ALL the artifacts needed (osgi bundles BTW), 
just of an entry point for maven to crawl the graph and pull everything. 
The problem I'm encountering that tells me maybe Maven is not meant for 
this is that I need to pull two artifacts where only the version is 
different (since in OSGi both can coexist just fine) but maven chooses 
only one and the other one doesn't get integrated. So, are there ways to 
force maven to not drop the second version when resolving its model or am 
I just stretching what maven can do? if so, are there any other tools that 
leverage pom information to download artifacts from a maven repo? i don't 
want to have to maintain that dependency information in two different 
places

Thank you,

Alejandro Endo | Software Designer/Concepteur de logiciels 

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: Maven use for integration

[Alejandro . Endo]

Hi Ron,
#1. I don't understand your question. You mean the poms of the artifacts 
deployed in nexus? they each have their own pom and instructions on how to 
build itself, just like a regular maven artifact
So I have an artifact A that gets deployed to nexus with groupId foo.bar 
and artifactId A and version 1.0 and then six months later A gets updated 
to version 2.0
All this has nothing to do with integration

Now the integration job will say, bring all the artifacts and their 
dependencies to be able to run. One of them will be A 1.0.
Once a 2.0 is released, i don't want to integrate ONLY 2.0. I want to 
integrate 1.0 and 2.0. So in my integration pom i have two dependencies, 
one foo.bar:A:1.0 and another dependency foo.bar:A:2.0. This is were maven 
core complains and ends up resolving one over the other, hence when i do a 
copy-dependencies it only ends up integrating one of them

#2. Yes, I am. The problem is that via the nexus API there's no way to 
have a list of ONLY entry points where i can say explicitly in a list 
(that i'm trying to keep as small as possible) integrate A and that would 
imply B and C if A depends on B and C. When I do it with maven, in my 
integration pom I only declare a dependency on A and the dependency plugin 
will copy transitive dependencies. This allows me to keep the manually 
maintained list as small as possible and never forgetting to update it 
when i introduce new dependencies since those new dependencies will be 
pulled by the dependency plugin just because the POM already contains the 
relationship information

I hope everything is clearer now, let me know

Thanks for replying


Alejandro Endo | Software Designer/Concepteur de logiciels 




From:   Ron Wheeler 
To: users@maven.apache.org, 
Date:   2014-11-25 01:33 PM
Subject:Re: Maven use for integration



Since you are not getting any responses, let me ask some questions to 
get some more details on the table.

1) Where is the definitive single source of dependency info that you use 
to create the GAV ids for Nexus? How can a single pom reference 2 
versions of an artifact?

2) Are you aware of the API for Nexus? Can you use this to get the 
artifacts once you have the list of artifacts?

Perhaps these answers will stimulate some ideas.
Ron

On 25/11/2014 10:55 AM, alejandro.e...@grassvalley.com wrote:
> Hello everyone,
>
> I wanted to ask what you guys though about using maven as an integration
> tool. Is it out of the scope of maven? is anyone else doing this? What I
> mean by integration is that the artifacts are built (also by maven but 
in
> other jobs) and deployed to nexus, but I still need to download them all
> to a server for deployment.
> The build of this server invokes maven and I hooked to it via a pom that
> points to some artifacts that serve as an entry point to the dependency
> graph and then use the dependency:copy-dependencies goal. The point of
> this was to leverage the dependency information available in poms so I
> didn't have to keep a list of ALL the artifacts needed (osgi bundles 
BTW),
> just of an entry point for maven to crawl the graph and pull everything.
> The problem I'm encountering that tells me maybe Maven is not meant for
> this is that I need to pull two artifacts where only the version is
> different (since in OSGi both can coexist just fine) but maven chooses
> only one and the other one doesn't get integrated. So, are there ways to
> force maven to not drop the second version when resolving its model or 
am
> I just stretching what maven can do? if so, are there any other tools 
that
> leverage pom information to download artifacts from a maven repo? i 
don't
> want to have to maintain that dependency information in two different
> places
>
> Thank you,
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such even

Re: Maven use for integration

[Alejandro . Endo]

No, not a zip. I just need the bundles to be in the file system so that 
when the server packaging starts, they get packaged.

The job of the integrator is just to download the artifacts from nexus and 
leave them in the filesystem of the server's image. The fact that i want 
to use the info in the poms to minimize maintenance of the integration 
list is kind of orthogonal, i could do everything just with wget, but i 
would need a list of every single bundle to download.

Maybe a bit of description of how building the server work will make it 
clearer. We download all the bundles from nexus (this is the part I do 
with maven), compile kernel drivers unrelated to the bundles, prepare OS 
configuration scripts, etc etc and then the whole system is packaged into 
an image that gets deployed to the client. This packaging into an image 
has nothing to do with maven, only the artifact download is done by maven 
at the server creation job (and not even for all the artifacts, just for 
OSGi bundle artifacts)

And yes, you're right that for non-osgi artifacts this wouldn't work due 
to the classloader, so I definitely understand the default behaviour of 
maven, but this is in an OSGi context. Is there any way to bypass this 
core behaviour? a system property, flag?? it is very convenient to do 
integrations with maven due to the rich info in the poms. But obviously, 
the pom data could be used outside of maven so maybe what I'm missing is a 
different tool altogether.

Another option would be a maven-plugin that creates its own dependency 
graph and doesn't rely on the one provided by maven core, which supports 
only a single version of a given artifact (at least that's what it looks 
like)


Alejandro Endo | Software Designer/Concepteur de logiciels 




From:   Ron Wheeler 
To: users@maven.apache.org, 
Date:   2014-11-25 03:07 PM
Subject:Re: Maven use for integration



It is still a bit unclear about what you will end up with if your idea 
works.
Are you just hoping to get a zip file of OSGi artifacts that you can 
unzip to deploy?

Multiple versions of non-OSGi artifacts will not work since the 
classloader will only load the first version that it finds.


On 25/11/2014 1:45 PM, alejandro.e...@grassvalley.com wrote:
> Hi Ron,
> #1. I don't understand your question. You mean the poms of the artifacts
> deployed in nexus? they each have their own pom and instructions on how 
to
> build itself, just like a regular maven artifact
> So I have an artifact A that gets deployed to nexus with groupId foo.bar
> and artifactId A and version 1.0 and then six months later A gets 
updated
> to version 2.0
> All this has nothing to do with integration
>
> Now the integration job will say, bring all the artifacts and their
> dependencies to be able to run. One of them will be A 1.0.
> Once a 2.0 is released, i don't want to integrate ONLY 2.0. I want to
> integrate 1.0 and 2.0. So in my integration pom i have two dependencies,
> one foo.bar:A:1.0 and another dependency foo.bar:A:2.0. This is were 
maven
> core complains and ends up resolving one over the other, hence when i do 
a
> copy-dependencies it only ends up integrating one of them
So the 2 versions of A are on a list that you manually maintain in an 
integration file.
Could you not keep that outside a pom and just get each version from the 
repo and use the pom of foo.bar:A:1.0 and foo.bar:A:2.0 to get their 
respective dependencies to build a list of the other artifacts. As long 
as you are talking about OSGi, you are OK.
>
> #2. Yes, I am. The problem is that via the nexus API there's no way to
> have a list of ONLY entry points where i can say explicitly in a list
> (that i'm trying to keep as small as possible) integrate A and that 
would
> imply B and C if A depends on B and C. When I do it with maven, in my
> integration pom I only declare a dependency on A and the dependency 
plugin
> will copy transitive dependencies. This allows me to keep the manually
> maintained list as small as possible and never forgetting to update it
> when i introduce new dependencies since those new dependencies will be
> pulled by the dependency plugin just because the POM already contains 
the
> relationship information
So once you have resolved the dependencies, you can get the Artifacts 
and repeat the resolution using these new dependencies eliminating 
duplicates if you find any.

> I hope everything is clearer now, let me know
You can use the Maven code to build the dependency resolution but you 
will have to glue this together with some top level code that reads your 
list of "seed" artifacts including the multiple versions of the ones 
that you care about and probably something to eliminate duplicate 
transitive dependencies and resolve version conflicts for non-OSGi 
artifacts if these are part of your requirement.

It 

Re: Maven use for integration

[Alejandro . Endo]

Ok, I might give that a try

Thank you for your help Ron

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   Ron Wheeler 
To: users@maven.apache.org, 
Date:   2014-11-25 09:39 PM
Subject:Re: Maven use for integration



On 25/11/2014 4:26 PM, alejandro.e...@grassvalley.com wrote:
> No, not a zip. I just need the bundles to be in the file system so that
> when the server packaging starts, they get packaged.
>
> The job of the integrator is just to download the artifacts from nexus 
and
> leave them in the filesystem of the server's image. The fact that i want
> to use the info in the poms to minimize maintenance of the integration
> list is kind of orthogonal, i could do everything just with wget, but i
> would need a list of every single bundle to download.
>
> Maybe a bit of description of how building the server work will make it
> clearer. We download all the bundles from nexus (this is the part I do
> with maven), compile kernel drivers unrelated to the bundles, prepare OS
> configuration scripts, etc etc and then the whole system is packaged 
into
> an image that gets deployed to the client. This packaging into an image
> has nothing to do with maven, only the artifact download is done by 
maven
> at the server creation job (and not even for all the artifacts, just for
> OSGi bundle artifacts)
>
> And yes, you're right that for non-osgi artifacts this wouldn't work due
> to the classloader, so I definitely understand the default behaviour of
> maven, but this is in an OSGi context. Is there any way to bypass this
> core behaviour? a system property, flag?? it is very convenient to do
> integrations with maven due to the rich info in the poms. But obviously,
> the pom data could be used outside of maven so maybe what I'm missing is 
a
> different tool altogether.
>
> Another option would be a maven-plugin that creates its own dependency
> graph and doesn't rely on the one provided by maven core, which supports
> only a single version of a given artifact (at least that's what it looks
> like)



Yes. that is what I was suggesting or build something that uses the core 
bits of Maven that you need.

Ron

>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
> From:   Ron Wheeler 
> To: users@maven.apache.org,
> Date:   2014-11-25 03:07 PM
> Subject:Re: Maven use for integration
>
>
>
> It is still a bit unclear about what you will end up with if your idea
> works.
> Are you just hoping to get a zip file of OSGi artifacts that you can
> unzip to deploy?
>
> Multiple versions of non-OSGi artifacts will not work since the
> classloader will only load the first version that it finds.
>
>
> On 25/11/2014 1:45 PM, alejandro.e...@grassvalley.com wrote:
>> Hi Ron,
>> #1. I don't understand your question. You mean the poms of the 
artifacts
>> deployed in nexus? they each have their own pom and instructions on how
> to
>> build itself, just like a regular maven artifact
>> So I have an artifact A that gets deployed to nexus with groupId 
foo.bar
>> and artifactId A and version 1.0 and then six months later A gets
> updated
>> to version 2.0
>> All this has nothing to do with integration
>>
>> Now the integration job will say, bring all the artifacts and their
>> dependencies to be able to run. One of them will be A 1.0.
>> Once a 2.0 is released, i don't want to integrate ONLY 2.0. I want to
>> integrate 1.0 and 2.0. So in my integration pom i have two 
dependencies,
>> one foo.bar:A:1.0 and another dependency foo.bar:A:2.0. This is were
> maven
>> core complains and ends up resolving one over the other, hence when i 
do
> a
>> copy-dependencies it only ends up integrating one of them
> So the 2 versions of A are on a list that you manually maintain in an
> integration file.
> Could you not keep that outside a pom and just get each version from the
> repo and use the pom of foo.bar:A:1.0 and foo.bar:A:2.0 to get their
> respective dependencies to build a list of the other artifacts. As long
> as you are talking about OSGi, you are OK.
>> #2. Yes, I am. The problem is that via the nexus API there's no way to
>> have a list of ONLY entry points where i can say explicitly in a list
>> (that i'm trying to keep as small as possible) integrate A and that
> would
>> imply B and C if A depends on B and C. When I do it with maven, in my
>> integration pom I only declare a dependency on A and the dependency
> plugin
>> will copy transitive dependencies. This allows me to keep the manually
>> maintained list as small as possible and never forgetting to update it
>> when i int

release plugin issue

[Alejandro . Endo]

I'm using the release-plugin v2.5.1 and I'm often encountering two 
recurring stories with failed releases

1) Now the release can fail due to errors in the javadoc. This is not a 
problem, the problem is that IF there are problems in the javadoc the 
release doesn't complete but the two commits and the tag has been done so 
after fixing the javadoc I need to reset the git repo to right before the 
failed released AND I have to remove the tag to try again. I am releasing 
from jenkins so the resume flag is set to false. if something fails we 
start from the beginning, which makes sense in a build server IMO. My 
suggestion here would be to generate all those artifacts (javadoc and 
source) before committing and tagging the code, that way if they fail, the 
repo is not in an invalid state. Another option would be improvement #2

2) Very often the dryRun succeeds but the real release fails, to the point 
where the dryRun is meaningless. This defeats the whole purpose of a 
dry-run. The problem is that the dry run is over simplified. For example, 
again, if there are javadoc problems they won't be spotted because the 
dry-run doesn't run javadoc generation. Anything that's part of the real 
build should be run on the dry-run except for things that make persistent 
changes. Another problem I encounter often is that the real release fails 
because the tag already exists in SCM (leftover from a previous failed 
release). This should also be validated by the dryRun. If a real release 
can fail because a tag is already present then the dry run should fail if 
the tag is already present

What do you guys think? If these points are considered valid I will open a 
ticket at least for the second one, which is the worse of the two


Alejandro Endo | Software Designer/Concepteur de logiciels 


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: release plugin issue

[Alejandro . Endo]

Hi Stephen,

We are not using any preparationGoals. So it's not that my preparation 
goals are not mimicking a full release. It is that the default dry run is 
not mimicking a default full release. 
We are talking about completely vanilla release:prepare. The only 
non-default value is the resume=false.
And about the tradeoff, I see your point, but IMO the defaults should not 
make those tradeoff decisions for you. The default should be the safest 
setting, not the fastest

Here are the two goals we run for full and for dry-run respectively

-Dresume=false release:prepare release:perform
-Dresume=false -DdryRun=true release:prepare

I will try to play with the preparationGoals, but again, the default 
behaviour seems flawed to me

Thanks for your help


Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   Stephen Connolly 
To: Maven Users List , 
Date:   2014-11-27 07:44 PM
Subject:Re: release plugin issue



On Thursday, 27 November 2014,  wrote:

> I'm using the release-plugin v2.5.1 and I'm often encountering two
> recurring stories with failed releases
>
> 1) Now the release can fail due to errors in the javadoc. This is not a
> problem, the problem is that IF there are problems in the javadoc the
> release doesn't complete but the two commits and the tag has been done 
so
> after fixing the javadoc I need to reset the git repo to right before 
the
> failed released AND I have to remove the tag to try again. I am 
releasing
> from jenkins so the resume flag is set to false. if something fails we
> start from the beginning, which makes sense in a build server IMO. My
> suggestion here would be to generate all those artifacts (javadoc and
> source) before committing and tagging the code, that way if they fail, 
the
> repo is not in an invalid state. Another option would be improvement #2


It sounds like your preparationGoals are not mimicing a full release...
Very often people set them up that way because they are willing to trade
off a failed perform against a faster prepare.

Typically if you are doing the trade-off you go all the way and make
preparationGoals be `initialize`... Sure version numbers are free don't 
you
know


>
> 2) Very often the dryRun succeeds but the real release fails, to the 
point
> where the dryRun is meaningless. This defeats the whole purpose of a
> dry-run. The problem is that the dry run is over simplified. For 
example,
> again, if there are javadoc problems they won't be spotted because the
> dry-run doesn't run javadoc generation. Anything that's part of the real
> build should be run on the dry-run except for things that make 
persistent
> changes.


Again I wonder have you (or somebody else) tweaked the defaults


> Another problem I encounter often is that the real release fails
> because the tag already exists in SCM (leftover from a previous failed
> release). This should also be validated by the dryRun.


Or by prepare before it starts the build... I think that should be a valid
complaint


>  If a real release
> can fail because a tag is already present then the dry run should fail 
if
> the tag is already present
>
> What do you guys think? If these points are considered valid I will open 
a
> ticket at least for the second one, which is the worse of the two
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>


-- 
Sent from my phone


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

Re: release plugin issue

[Alejandro . Endo]

But the problem has nothing to do with Jenkins

You can manually type mvn release:prepare release:perform -DdryRun=true 
and it will pass and then dryRun=false and it will fail

My point is about the default behaviour of a dry run not being realistic 
compared to a full release, which will make you miss problems that WILL 
fail the real release. And to make matters worse, if a real release fails, 
it leaves the repo in disarray. IMO it should really clean up to the same 
state as it was when the release was started. If this is not possible 
because you cannot easily revert changes in a SCM (or in other words, you 
cannot do the WHOLE release as a transaction) then at least there should 
be a realistic, non-persistent check for those operations that will give 
you a high degree of certainty that a real release will succeed. That's 
what a dry run is supposed to do. It will never be 100% sure (example, 
what if while deploying the release artifact the internet connection 
drops. This can't be checked by a successful dryRun) but it should be as 
real as possible, and right now the dryRun is so much simpler than the 
real release that it becomes meaningless. 

There are so many steps in a release (which is what makes this plugin so 
necessary) that there's many opportunities for failures: unstable 
dependencies, unstable parents, artifacts not being SNAPSHOTs, missing SCM 
tags (which are needed everywhere since SCM inheritance doesn't work well 
with git), errors in javadoc (that only since recently started failing the 
build), no write access in SCM repo, tag already existing in SCM repo, 
artifacts already existing in remote maven repo (i.e. accidental 
redeploys). All these I have actually encountered in real life in an 
enterprise setting. And i'm not saying all these are not detected by a 
default dryRun, some of them are. I just wanted to make the point that 
releasing has many potential failure points


Alejandro Endo | Software Designer/Concepteur de logiciels 




From:   Stephen Connolly 
To: Maven Users List , 
Date:   2014-11-28 12:52 PM
Subject:Re: release plugin issue



O wait a sec you're using the evil job type...

http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html


Well all bets are off then that will most likely royally screw you 
over

On 28 November 2014 at 17:45, Robert Scholte  wrote:

> Op Fri, 28 Nov 2014 00:54:29 +0100 schreef 
 >:
>
>
>  I'm using the release-plugin v2.5.1 and I'm often encountering two
>> recurring stories with failed releases
>>
>> 1) Now the release can fail due to errors in the javadoc. This is not a
>> problem, the problem is that IF there are problems in the javadoc the
>> release doesn't complete but the two commits and the tag has been done 
so
>> after fixing the javadoc I need to reset the git repo to right before 
the
>> failed released AND I have to remove the tag to try again. I am 
releasing
>> from jenkins so the resume flag is set to false. if something fails we
>> start from the beginning, which makes sense in a build server IMO. My
>> suggestion here would be to generate all those artifacts (javadoc and
>> source) before committing and tagging the code, that way if they fail, 
the
>> repo is not in an invalid state. Another option would be improvement #2
>>
>> 2) Very often the dryRun succeeds but the real release fails, to the 
point
>> where the dryRun is meaningless. This defeats the whole purpose of a
>> dry-run. The problem is that the dry run is over simplified. For 
example,
>> again, if there are javadoc problems they won't be spotted because the
>> dry-run doesn't run javadoc generation. Anything that's part of the 
real
>> build should be run on the dry-run except for things that make 
persistent
>> changes. Another problem I encounter often is that the real release 
fails
>> because the tag already exists in SCM (leftover from a previous failed
>> release). This should also be validated by the dryRun. If a real 
release
>> can fail because a tag is already present then the dry run should fail 
if
>> the tag is already present
>>
>> What do you guys think? If these points are considered valid I will 
open a
>> ticket at least for the second one, which is the worse of the two
>>
>>
> It's also possible to do a dryrun for the release:perform since version
> 2.3 [1]
> That's still not the default of the jenkins m2-release-plugin, but it
> works.
>
> Robert
>
> [1] https://jira.codehaus.org/browse/MRELEASE-736
>
>
>> Alejandro Endo | Software Designer/Concepteur de logiciels
>>
>>
>> DISCLAIMER:
>> Privileged and/or Confidential information may be contained in this
>

Re: release plugin issue

[Alejandro . Endo]

That's good to know Robert, thank you

I will add that to our release dryrun and hopefully it will catch more of 
the uncaught problems early on

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   "Robert Scholte" 
To: "Maven Users List" , 
Date:   2014-11-28 12:46 PM
Subject:Re: release plugin issue



Op Fri, 28 Nov 2014 00:54:29 +0100 schreef 
:

> I'm using the release-plugin v2.5.1 and I'm often encountering two
> recurring stories with failed releases
>
> 1) Now the release can fail due to errors in the javadoc. This is not a
> problem, the problem is that IF there are problems in the javadoc the
> release doesn't complete but the two commits and the tag has been done 
so
> after fixing the javadoc I need to reset the git repo to right before 
the
> failed released AND I have to remove the tag to try again. I am 
releasing
> from jenkins so the resume flag is set to false. if something fails we
> start from the beginning, which makes sense in a build server IMO. My
> suggestion here would be to generate all those artifacts (javadoc and
> source) before committing and tagging the code, that way if they fail, 
> the
> repo is not in an invalid state. Another option would be improvement #2
>
> 2) Very often the dryRun succeeds but the real release fails, to the 
> point
> where the dryRun is meaningless. This defeats the whole purpose of a
> dry-run. The problem is that the dry run is over simplified. For 
example,
> again, if there are javadoc problems they won't be spotted because the
> dry-run doesn't run javadoc generation. Anything that's part of the real
> build should be run on the dry-run except for things that make 
persistent
> changes. Another problem I encounter often is that the real release 
fails
> because the tag already exists in SCM (leftover from a previous failed
> release). This should also be validated by the dryRun. If a real release
> can fail because a tag is already present then the dry run should fail 
if
> the tag is already present
>
> What do you guys think? If these points are considered valid I will open 
 
> a
> ticket at least for the second one, which is the worse of the two
>

It's also possible to do a dryrun for the release:perform since version 
2.3 [1]
That's still not the default of the jenkins m2-release-plugin, but it 
works.

Robert

[1] https://jira.codehaus.org/browse/MRELEASE-736

>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.

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



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.