Re: Enforce rules defined outside the pom.xml or its parent

2019-03-27 Thread Anthony Whitford
Personally, I have done this with a Parent POM.  Every corporate project must 
directly, or indirectly, inherit a Corporate Parent POM.  This is generally 
useful because you can define common properties that Maven can leverage, even 
for local builds.  For example, one can declare properties for your JIRA host 
or Git host to avoid hard coding.  Most valuable is that POMs need to be 
explicit with plugin versions to ensure repeatable and reliable builds, and 
doing that for every project is very tedious, so a common Corporate Parent POM 
can define specific plugin versions and settings to minimize the burden for 
each project.

The alternate way is to use Profiles 
.  
You can configure settings on your CI/CD servers — see “global Maven-settings.”

Pro tip:  think about evolution!  Things will change; assuming that ONE set of 
standards will apply universally will usually lead to issues.  
(Incompatibilities will arise, and assuming that ALL projects can evolve 
instantly is unrealistic when you have more than a handful of projects.)  The 
nice thing about a Corporate Parent POM is that it can be versioned like any 
other Maven Artifact, so each Project can evolve at its own pace.  (If you are 
going with the Profile approach on your CI/CD server(s), you may need to 
leverage Project Metadata maintained at the CI/CD solution.)

Hope this helps,

Anthony


> On Mar 26, 2019, at 7:04 AM, Martin D'Aloia  wrote:
> 
> Hello,
> 
> Is it possible to enforce a set of rules defined outside the pom.xml being
> built (i.e. not defined in the current pom or in a parent pom)?
> 
> Ideally, I would like to define maven-enforcer-plugin rules in an external
> pom.xml and evaluate them over the pom.xml being build in order to not
> force to use a specific parent pom.
> 
> *CONTEXT:*
> I'm defining a CI/CD pipeline and I would like to enforce a set of rules
> over the pom.xml in order to be deployed to our internal repository (sort
> of validations performed to publish to Maven Central).
> 
> Thanks in advance for any suggestions!



Re: Enforce rules defined outside the pom.xml or its parent

2019-03-27 Thread Bernd Eckenfels
It’s not what you where asking, but many rules can  and should be put into a 
common parent - helps with local builds as well.

Maven enforcer can use rules on the command line it seems: 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MENFORCER-142

Besides that some static analysis with your own plugin or tools like jqassist 
can be run in CI Jobs also.

Gruß
Bernd

--
https://Bernd.eckenfels.net


Von: Martin D'Aloia 
Gesendet: Mittwoch, März 27, 2019 6:46 PM
An: users@maven.apache.org
Betreff: Enforce rules defined outside the pom.xml or its parent

Hello,

Is it possible to enforce a set of rules defined outside the pom.xml being
built (i.e. not defined in the current pom or in a parent pom)?

Ideally, I would like to define maven-enforcer-plugin rules in an external
pom.xml and evaluate them over the pom.xml being build in order to not
force to use a specific parent pom.

*CONTEXT:*
I'm defining a CI/CD pipeline and I would like to enforce a set of rules
over the pom.xml in order to be deployed to our internal repository (sort
of validations performed to publish to Maven Central).

Thanks in advance for any suggestions!


Enforce rules defined outside the pom.xml or its parent

2019-03-27 Thread Martin D'Aloia
Hello,

Is it possible to enforce a set of rules defined outside the pom.xml being
built (i.e. not defined in the current pom or in a parent pom)?

Ideally, I would like to define maven-enforcer-plugin rules in an external
pom.xml and evaluate them over the pom.xml being build in order to not
force to use a specific parent pom.

*CONTEXT:*
I'm defining a CI/CD pipeline and I would like to enforce a set of rules
over the pom.xml in order to be deployed to our internal repository (sort
of validations performed to publish to Maven Central).

Thanks in advance for any suggestions!


Re: A import B and B should import A where it is included

2019-03-27 Thread Matthieu BROUILLARD
As Anthony said as you have a chicken-egg problem and you need to break the
cycle somehow.

To cut the loop I would eventually either:

Solution 1: split the projects into:
   1. the library itself without tests
   2. the test library, depending on the lib
   3. the library tests depending on both the lib and the test library

Solution 2: use a previous version of test lib
Here your framework could depend on your test lib in version N-1. The
layout would be:
1. library version N and its tests depending on test-lib version N-1
2. test framework library version N


The first solution is easier I think and allows to develop & use new
features (in both lib & test lib) without having to release to be able to
use them.

Matthieu


On Mon, Mar 25, 2019 at 10:44 PM Anthony Whitford 
wrote:

> You can specify a dependency version using an expression like this:
> ${project.version}
>
> ${project.version} refers to the POM’s project/version value.
>
> Note that you can declare project properties, and use those in expressions
> too.  See this for more details:
>  -
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> <
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> >
>
>
> Having said that…. It sounds like you have a chicken-egg problem and that
> really needs to be fixed.  While Maven certainly supports dynamic
> dependency management, it will highlight and prevent poor software
> engineering practices such as cyclic dependencies.  You will discover that
> even if you can get a cyclic build working, the release process will be
> broken.  And, you will undoubtedly run into build race conditions and other
> bad things.
>
> So, you need to figure out how to isolate the common dependencies into a
> third library to break the cyclic dependency.  Instead of something like
> this:
>  -  A depends on B, B depends on A (BAD!)
> How about:
>  -  A depends on C, B depends on C (OK!)
>
> C may be just Interfaces — maybe no implementation.
> Your Tess can depend on A — but A should not depend on the Tests — it
> defeats the value of isolating the Tests.
>
>
> Hope this helps,
>
> Anthony
>
>
> > On Mar 25, 2019, at 11:28 AM, Philipp Kraus <
> philipp.kr...@tu-clausthal.de> wrote:
> >
> > Hello,
> >
> > I am building an additional testing framework for my framework. I now
> have the following cyclic import of the dependencies "MyFramework imports
> MyTestingFramework" and "MyTestingFramework imports MyFramework".
> > For example, if MyFramework is version 0.2.1-SNAPSHOT, then
> MyTestingFramework should use the version 0.2.1-SNAPSHOT. Is there a way to
> get the dependency dynamically?
> >
> > I hope it was understandable
> > Thanks a lot
> >
> > Phil
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>


Maven sure fire report skip count issue

2019-03-27 Thread Atul Hake
Dear team,

I am re running failed TC using IRetryAnalyzer.
If i have 3 TC . 1st pass 2nd fail..retried.again fail.
so run count is 3   , pass=1,fail =1 , skip =1.   Its correct.
now i want to remove skip count from report so i have written code at
OnFinish method [see attachmen] to remove skip count...so individual Test-
.xml [Target/junitreport] does not contain any skip count.
but final Test-Testsuit.xml [target] contains skip count .   which is
obstacle.

what is the way to remove skip count from final Test-Testsuit.xml ?
is it any version issue?
[i want to remove skip count because it disturbing success percentage of
report]






Thanks & regards
Atul Hake
http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  TideTestSuite
  TideTestSuite
  0.0.1-SNAPSHOT
  TideTestSuite
  
  
			
			org.yaml
			snakeyaml
			1.10
			
		
			
			org.seleniumhq.selenium.grid
			selenium-grid-hub
			1.0.5
			
		
		
   	 	org.seleniumhq.selenium
	selenium-server
	3.4.0
		
		
			
			org.testng
			testng
			6.11
			
			
			
			org.apache.maven.surefire
			surefire-testng
			2.21.0
			
			
			
			junit
			junit
			4.12
			
			
			
			org.seleniumhq.selenium
			selenium-java
			3.4.0
			
	
			
		com.sun.mail
		javax.mail
		1.6.0
			
			
			
		javax.activation
		activation
		1.1
			
			
			
			org.apache.poi
			poi
			3.8
			
			
			
			net.sourceforge.jexcelapi
			jxl
			2.6.12
			

			
			org.bouncycastle
			bcprov-jdk16
			1.46
			
			
			
			net.schmizz
			sshj
			0.7.0
			
			
			
			ch.qos.logback
			logback-classic
			0.9.27
			
			
			
			ch.qos.logback
			logback-core
			0.9.27
			
			
			
			org.slf4j
			slf4j-api
			1.7.2
			
			
			
			mysql
			mysql-connector-java
			5.1.6
			

			
			commons-lang
			commons-lang
			2.6
			
			
  			
			
   		com.opera
   	 	operadriver
	1.5
		
		
		
	org.seleniumhq.selenium
	selenium-firefox-driver
   		3.4.0
   		
   		   
   		
   		com.paulhammant
  		ngwebdriver
  		1.0
   	 		
   	 		
   	 		
 		com.jprotractor
 		jprotractor
 		1.0-SNAPSHOT
 		system
 		${project.basedir}/src/main/resources/jprotractor-1.0-SNAPSHOT.jar
		
		
		
 		org.monte
  		screen-recorder
  		0.7.7
  		system
   		${project.basedir}/src/main/resources/MonteScreenRecorder.jar
   			
		 
 
  

  
  
org.apache.maven.plugins
maven-surefire-report-plugin
3.0.0-M3
  

  
  



	
		
		target
target/classes
TideTestSuite-0.0.1-SNAPSHOT
target/test-classes
src/main/java
src/test/java


src/main/resources




src/test/resources



		
		
		org.apache.maven.plugins
		maven-compiler-plugin
		3.3
		
		1.8
		1.8
		false
		
		
		
		
		org.apache.maven.plugins
		maven-surefire-plugin
		2.21.0
		
		
		src/test/resources/testng.xml
		
		
		
		
		
org.apache.maven.plugins
maven-failsafe-plugin
2.18.1



integration-test
verify



  	





 
  

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

Maven Release Plugin : SCM- Jazz

2019-03-27 Thread Anisha Rahamathullah (RBEI/ETB2)

Hello,

We use Maven release plugin with Jazz repository for automated release. While 
performing deliver operation below command is used.

"scm deliver --repository-uri  --username  --password * 
--source  --target  --overwrite-uncommitted"

Internally we have configured commit rules in our repository, where deliver 
would fail, if the particular changeset is not associated with any workitem or 
comment.
Below is the error message:
Error: Process Reports:
  Name: Deliver
  Participant Reports:
Name: Require Work Items and Comments
  A work item or change request must be associated with the change set or a 
comment must be set.
  At least one of the associated work items must specify that the work is 
planned for the current iteration.
  At least one of the associated work items must be assigned to you.
Problem running 'deliver':
'Deliver' failed. Preconditions have not been met: A work item or change 
request must be associated with the change set or a comment must be set.

Since the changeset is generated automatically, changeset id cannot be 
captured, without which associating workitem/comment to changeset is impossible.


To overcome the above issue, we can perform deliver with " -C/--components" 
argument, will consider the outgoing changeset currently available for deliver 
operation.
Link for reference: 
https://jazz.net/forum/questions/217830/how-to-checkin-and-deliver-changes-from-local-workspace-automatically

Is there any options available to override the above command with the inbuilt 
command available in Release Plugin? Or is there any possible way available 
using maven release plugin?

Let us know for options if any.
Thanks!


Best regards,

Rahamathullah Anisha
RBEI/ETB2

Tel. +91 422 676-2621



Continuous Delivery / Continuous Deployment with the Maven Release Plugin

2019-03-27 Thread Stephen Connolly
So I wrote a blog post on how we use the Maven Release Plugin with Jenkins
to do Continuous Delivery and Continuous Deployment in the DevOptics team
of CloudBees.

If you are interested it's at:

https://www.cloudbees.com/blog/apache-maven-continuous-deliverydeployment-devoptics-teams-approach

There's also a video remix available (if you prefer watching video to
reading blogs)

https://www.youtube.com/watch?v=P6kce5blnJA

Share and Enjoy

-Stephen