Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

2017-06-02 Thread Dan Tran 
Just want to share our final outcomes

1. Use snapshot build during development phase

2. At release candidate phase, switch jenkinsfile to release mode

* For small projects, use version less Maven continuous deliver
friendly,

* For large projects, use  versions-maven-plugin to change version in
all poms at pre-build

* Automate the process to tag the final RC (we deploy a
build.properties to maven repo at each build, use its info to tag the SCM)

Whenever, the startup performance issue for large project is fixed, we will
switch to full version less build

-Dan

On Sun, May 14, 2017 at 7:23 PM, Dan Tran  wrote:

> I also noticed it takes about a minute for the build to roll after this
>
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
>
> This is not a good news for local dev build
>
> here are 2 time summaries running 250+ modules with skipTests and 4 thread
> smart builder. The first one does not use ${revision}
>
> [INFO] 
> 
> [INFO] Total time: 04:05 min (Wall Clock)
> [INFO] Finished at: 2017-05-14T19:16:32-07:00
> [INFO] Final Memory: 680M/2078M
>
> [INFO] 
> 
> [INFO] Total time: 05:56 min (Wall Clock)
> [INFO] Finished at: 2017-05-14T19:11:00-07:00
> [INFO] Final Memory: 1726M/3561M
>
>
> -D
>

Re: Transitive dependency question

2017-06-02 Thread Stephen Connolly 
I think that is a bug that is in scope for 3.5.1 or 3.6.0

On 31 May 2017 at 22:30, Laird Nelson  wrote:

> (I've been working with Maven since at least 2004 and I think I *still*
> don't
> get transitive dependencies.)
>
> I have a pom.xml file of type pom that has some compile-scoped dependencies
> in it.  (P1 -> A(compile), B(compile))
>
> I have another project that depends on this pom in provided scope (I'm just
> playing around for now).  The intention is that I will "get" all the
> transitive compile-scoped dependencies of the pom artifact I'm depending
> on, but in provided scope.  (P2 -> P1(provided); result is effectively: P2
> -> P1(provided) -> A(provided), B(provided))
>
> If that's all I have, then indeed, that's the result I observe: when I run
> the maven-dependency-plugin's dependency-tree goal, I see these transitive
> dependencies and they are all marked as being in provided scope, not
> compile.  I see, in other words, the tree representation of P2 ->
> P1(provided) -> A(provided), B(provided).  So far so good.
>
> Now I pull in another (jar) dependency in runtime scope.  It has some
> transitive dependencies in compile scope.  Fine.  They don't include any of
> the dependencies mentioned in my second paragraph. (P2 -> (P1(provided) ->
> A(provided),B(provided)), (P3(runtime) -> C(compile),D(compile)))  Note
> that this pseudo-language is what I *expect* to see.
>
> When I run dependency:tree on this hairy mess, it does *not* show the
> representation of my pseudo-language above.  Instead, it shows the
> transitive dependencies from my third paragraph as direct "children" of the
> pom-type artifact I'm pulling in in provided scope (P1), but they all have
> a scope of runtime.  So, for just this part of the tree: P2 -> P1(provided)
> -> A(runtime(!)), B(runtime(!))
>
> What the…?  In other words, somebody in the tree is "promoting" my A and B
> dependencies to runtime scope.  But I can't tell from the tree output who
> it is, because A and B (that are now apparently runtime-scoped
> dependencies) are still showing as children of my pom artifact (P1,
> mentioned in my second paragraph).
>
> Is this all according to plan?  I'm using version 3.0.0 of the
> maven-dependency-plugin and version 3.5.0 of Maven itself.
>
> Best,
> Laird
>

Re: Work-around for antrun AttachArtifact not working in external Ant build file

2017-06-02 Thread Jürgen Weber 
Hi,

no, still does not work.

Where is your changed source? I could run it in the debugger..

Juergen

Maven project reference not found: maven.project.ref

at
org.apache.maven.ant.tasks.AttachArtifactTask.execute(AttachArtifactTask.java:80)

Am 01.06.2017 19:17 schrieb "Guillaume Boué" :

> It's currently in Apache snapshot repository located at
> https://repository.apache.org/content/repositories/snapshots. You can add
> this repository as a plugin repository to your settings or POM for the test.
>
> 
>   apache-snapshots-plugin
>   https://repository.apache.org/content/repositories/snapshots/
> 
>   
> true
>   
> 
>
>
> Le 01/06/2017 à 16:25, Jürgen Weber a écrit :
>
>> There is no 3.0.0-SNAPSHOT of maven-antrun-plugin, is it?
>> org/apache/maven/ant/tasks/AttachArtifactTask.class is in
>> maven-antrun-plugin-1.8.jar
>>
>>
>> Am 31.05.2017 19:57 schrieb "Guillaume Boué" :
>>
>> Hi,
>>
>> I looked into this issue and committed a fix for it. The core problem was
>> that the 'attachartifact' task launched from the external Ant build was
>> working from a clone of the Maven project, instead of the project itself.
>> Can you try the latest 3.0.0-SNAPSHOT and report back?
>>
>>
>>
>> Le 31/05/2017 à 19:14, Jürgen Weber a écrit :
>>
>> Hi,
>>>
>>> I found a solution, not pretty, but it actually works:
>>>
>>> in an pom-inline antrun task call a Javascript function with the
>>> project as parameter, in Javascript one can do all interesting things
>>> (loop over properties from an ant property file) and call the
>>> attachartifact task.
>>>
>>> Cheers,
>>> Juergen
>>>
>>> 
>>>  >> load("script.js");
>>> runtaskf(self.getProject());
>>> ]]>
>>> 
>>> 
>>>
>>> script.js:
>>>
>>> var runtaskf = function(project) {
>>> aa = project.createTask("attachartifact");
>>> f = new java.io.File("my.jar");
>>> aa.setFile(f);
>>> aa.setType("jar");
>>> aa.setClassifier("test");
>>> aa.perform();
>>> }
>>>
>>> 2017-05-31 18:32 GMT+02:00 Karl Heinz Marbaise :
>>>
>>> Hi,

 if i correctly understand you have a property file for each environment
 and
 maybe some other files and a base artifact (jar/war?) now it sounds you
 have
 to build for each environment a different jar/war ?

 Maybe something like this could help here:

 https://github.com/khmarbaise/multienv-maven-plugin/

 or:

 https://github.com/khmarbaise/iterator-maven-plugin/


 Kind regards
 Karl Heinz Marbaise


 On 31/05/17 11:42, Jürgen Weber wrote:

 Hi Jörg,
> problem is, I have to build message driven beans, some 20, only
> difference
> is the queue name in the deployment descriptor. Queue names are listed
> in
> a
> property file.
> I know that Maven wants no environment specific properties in
> artifacts,
> but Sun defined the activation spec for MDBs. And the activation spec
> is
> in
> code or in ejb-jar.xml, both in the mdb jar. So I have to build a
> different
> MDB for each queue. And I have to iterate over the queues (which is
> possible in ant + JavaScript. Yuck).
> So I'd need to attach n artefacts, wherea in a Maven pom I have to list
> each artefact individually.
> Greetings, Jürgen
>
> Am 30.05.2017 08:45 schrieb "Jörg Schaible"
> 
> :
>>
>> Hi Jürgen,
>
> Jürgen Weber wrote:
>
> What is the recommended work-around for attaching artifacts created by
>
>> antrun?
>>
>> * forward target directory as variable to ant ?
>>
>> That helps if the created files should be removed in a normal "clean"
> phase.
>
> * build-helper-maven-plugin attach-artifact ?
> Definitely the proper action.
>
> http://technotes.khitrenovich.com/attach-maven-artifact-
> external-build-xml-file/
>
> https://issues.apache.org/jira/browse/MANTRUN-181
>>
>> Thx,
>> Juergen
>>
>> Cheers,
> Jörg
>
> -
>
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>