Re: maven-enforcer-plugin

2014-06-29 Thread Karl Heinz Marbaise

Hi Martin,


>

some situations I found for doxia (that you pointed out yesterday):

1)Tests wont compile clean e.g. Cast to (LinkItem) was never completed on 
return from parent.getBody().getBreadcrumbs().get(0);
  parentHref = "scp://parent.com/index.html";
 linkItem =(LinkItem)parent.getBody().getBreadcrumbs().get(0);
 linkItem.setHref( parentHref );

2)some of the testcases seem to hang?
Running 
org.apache.maven.doxia.site.decoration.inheritance.DecorationModelInheritenceAssemblerTest
DecorationModelInheritenceAssemblerTest seems to hang for about an hour?


So why didn't you raise a hand during the release vote of DOXIA ? Or why 
didn't you create an issue for that and add log files for further analysis ?





3)doxias  was set to MaxJdkVersion of 5 here are the 
rules for maxJdkVersion
  
   maven-enforcer-plugin
   
 
   enforce-bytecode-version
   
 enforce
   
   
 
   
 1.5
I have not used Java5 in about 5 years so Im wondering why is doxia hardgated 
to Java 1.5 ?


You answered that question already yourself...in the other thread about 
the VOTE for Maven ChangeLog Plugin 2.3 where you wrote (Unfortunately 
you didn't answer my questions):


As far as deprecating ..be mindful that Maven is used by over 100,000 
shops for production builds


which means simply upgrading an requirement is not that simple...and 
currently there is not really a requirement to drop 1.5 support...



Kind regards
Karl-Heinz Marbaise

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



RE: maven-enforcer-plugin

2014-06-29 Thread Martin Gainty
Afternoon Karl!
dreading going out in the hot sun without SPF 1000 so Im dallying on the puter 
for as long as I can 

some situations I found for doxia (that you pointed out yesterday):

1)Tests wont compile clean e.g. Cast to (LinkItem) was never completed on 
return from parent.getBody().getBreadcrumbs().get(0);
 parentHref = "scp://parent.com/index.html";
linkItem =(LinkItem)parent.getBody().getBreadcrumbs().get(0);
linkItem.setHref( parentHref );

2)some of the testcases seem to hang?
Running 
org.apache.maven.doxia.site.decoration.inheritance.DecorationModelInheritenceAssemblerTest
DecorationModelInheritenceAssemblerTest seems to hang for about an hour?

3)doxias  was set to MaxJdkVersion of 5 here are the 
rules for maxJdkVersion
 
  maven-enforcer-plugin
  

  enforce-bytecode-version
  
enforce
  
  

  
1.5
I have not used Java5 in about 5 years so Im wondering why is doxia hardgated 
to Java 1.5 ?

Thanks
Martin-
Mexico vs Netherlands 12:00 PM (on Telly) ..in south america ..Estádio 
Castelão, Fortaleza Brasil

> Date: Sun, 29 Jun 2014 14:11:13 +0200
> From: khmarba...@gmx.de
> To: dev@maven.apache.org
> Subject: maven-enforcer-plugin
> 
> Hi,
> 
> i wan't to go with a release (presumably 1.4) within the next two weeks...
> 
> Is there something which you would like to integrate that release...so 
> please raise your hand...
> 
> Kind regards
> Karl-Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
  

maven-enforcer-plugin

2014-06-29 Thread Karl Heinz Marbaise

Hi,

i wan't to go with a release (presumably 1.4) within the next two weeks...

Is there something which you would like to integrate that release...so 
please raise your hand...


Kind regards
Karl-Heinz Marbaise

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



Re: [PROPOSAL] Advanced Lifecycle Handling

2014-06-29 Thread Robert Scholte
Since no discussion started after this proposal, I have to assume that the  
base of this proposal is good.
I'll translate it into a Jira issue as part of the next Major Maven  
release.


thanks,
Robert

Op Mon, 23 Jun 2014 23:11:46 +0200 schreef Robert Scholte  
:



PROPOSAL 1: PerProject and PerPhase Executions

I've recently introduced the installAtEnd/deployAtEnd as an experimental  
feature which should improve the behavior of Maven without having to  
wait for the implementation in Maven Core, which would have a huge  
impact.
The reason is that you only want to install and/or deploy only after all  
modules have been build and verified successfully.
This feature works for most projects, however there are cases which  
cannot be solved by the plugin solution and require a change in the  
handling of lifecycles in Maven Core.
Up unto the verify-phase you want to execute all phases per project,  
whereas the install and deploy should be executed per phase.
Consider a root project with 2 modules, these should be executed like  
this


root   : validate ... verify
module1: validate ... verify
module2: validate ... verify
root   : install
module1: install
module2: install
root   : deploy
module1: deploy
module2: deploy

PROPOSAL 2: Either install or deploy
In general one should either run 'mvn verify' or 'mvn deploy', there's  
often no reason to run 'mvn install'. The only reason I can think of is  
when you have 2 separate projects (not part of the same multimodule),  
one depending on the other and you want to test this.
To ensure that your projects build the same as your co-workers, you  
should always try to deploy it. However, there are several reasons why a  
deploy could fail: network problems, authentication/authorization  
issues, repository manager policies, etc. However, this is still after  
every install-phase, so the local repository is polluted.
This is as unpleasant as for a developer local repository as for a  
CI-server local repo.


The proposal is to "branch" the final phases.
Calling any phase up until the verify will stay the same.
Calling 'mvn install' would call these phases: validate ... verify,  
install (nothing new here)
Calling 'mvn deploy' would call these phases: validate ... verify,  
deploy   (no more install)


Both proposals should have a generic implementation, since it's not just  
a problem of the default/build lifecycle. Also the site lifecycle  
requires the same type of handling.


PROPOSAL 3: post- should always be executed after 
There are right now 3 phases which also have a pre- and  
post-, namely integration-test, clean and site. However, even if  
one has bound goals to the post-phases, they're probably never called.
When there's an integration-test starting up some server, you'd probably  
always want to kill it no matter what happens during the IT (let say a  
NPE).
The proposal is to execute the post- as the finally block in  
Java. If you really want to execute only the integration-test without  
the post, the phase should be marked, e.g. 'mvn [integration-test]',  
where the brackets lock the phase.


thanks,
Robert

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


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