Re: windows 10 scm git authentication

2018-12-18 Thread domi
Actually, it has been forked to here: https://gitlab.com/ultreiaio/jgit-flow 
<https://gitlab.com/ultreiaio/jgit-flow>
/Domi

> On 18 Dec 2018, at 13:39, Olivier Lamy  wrote:
> 
> Hi
> The jgitflow plugin is not maintained here.
> You should ask here
> https://bitbucket.org/atlassian/jgit-flow
> 
> HTH
> Olivier
> 
> On Tue, 18 Dec 2018 at 8:35 pm, Matthew Broadhead
>  wrote:
> 
>> i have recently switched from ubuntu to windows 10 and i am having
>> problems authenticating the scm from either a command prompt or git shell.
>> mvn jgitflow:release-start
>> 
>> it fails with
>> [ERROR] Failed to execute goal
>> external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start
>> (default-cli) on project case-management: Error starting release: Error
>> starting release: org.eclipse.jgit.api.errors.TransportException:
>> g...@www.kissy.me.uk:matthew.broadhead/case-management.git: Auth fail ->
>> [Help 1]
>> 
>> if i run with the -X switch it shows it is using my settings.xml
>> [DEBUG] Reading global settings from
>> C:\Java\apache-maven-3.6.0\conf\settings.xml
>> [DEBUG] Reading user settings from C:\Users\Matthew
>> Broadhead\.m2\settings.xml
>> [DEBUG] Reading global toolchains from
>> C:\Java\apache-maven-3.6.0\conf\toolchains.xml
>> [DEBUG] Reading user toolchains from C:\Users\Matthew
>> Broadhead\.m2\toolchains.xml
>> [DEBUG] Using local repository at C:\Users\Matthew Broadhead\.m2\repository
>> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0
>> for C:\Users\Matthew Broadhead\.m2\repository
>> 
>> in settings.xml i have added a link to my private key like the below.  i
>> have tried every combination i can think of for this including passwords
>> etc.
>> 
>> www.kissy.me.uk
>> git -->
>> ${user.home}/.ssh/id_rsa
>> 
>> 
>> the debugging doesn't give me much information as to what is actually
>> failing
>> Caused by: com.jcraft.jsch.JSchException: Auth fail
>> at com.jcraft.jsch.Session.connect (Session.java:512)
>> at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession
>> (JschConfigSessionFactory.java:116)
>> at org.eclipse.jgit.transport.SshTransport.getSession
>> (SshTransport.java:136)
>> at
>> org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.
>> (TransportGitSsh.java:262)
>> at org.eclipse.jgit.transport.TransportGitSsh.openFetch
>> (TransportGitSsh.java:161)
>> at org.eclipse.jgit.transport.FetchProcess.executeImp
>> (FetchProcess.java:136)
>> at org.eclipse.jgit.transport.FetchProcess.execute
>> (FetchProcess.java:122)
>> at org.eclipse.jgit.transport.Transport.fetch (Transport.java:1138)
>> at org.eclipse.jgit.api.FetchCommand.call (FetchCommand.java:130)
>> 
>> 
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>> 
> -- 
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy



Re: Welcome Christian Stein to the Apache Maven Team

2018-05-08 Thread domi
Welcome Christian!!
/Domi

> On 7 May 2018, at 22:01, Robert Scholte  wrote:
> 
> Hi,
> 
> On behalf of the Apache Maven PMC I am pleased to announce that Christian 
> Stein (sor) has been voted in as a new Apache Maven committer.
> 
> Christian, welcome on board and have a lot of fun!
> 
> thanks,
> Robert
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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



Re: How do you manage your settings.xml for enterprise build??

2015-05-22 Thread domi
I’m sorry to say, but unfortunately Stephen is right… sorry...
The credentials plugin is integrated, but not up to the folder and user level. 
Reasons where different ones,
one for sure was time, but i also did not get my head around the way how to 
integrate the folders plugin (I just did not understand the folder API)
/Domi


On 22 May 2015, at 10:48, Stephen Connolly  
wrote:

> So domi was supposed to be integrating my credentials plugin into his
> config files provider plugin...
> 
> If he did that the way I was suggesting then you could have the user
> submitting the build select the credentials to use as a build parameter
> (from a list of global credentials and their own user credentials store) -
> or picking the best match automatically based on the credentials domains
> for prompt-free builds - and those credentials would be injected into the
> settings.xml that are provided to the maven build.
> 
> That was well over a year ago and domi and I were playing ships in the
> night on IRC... I haven't see those changes land in his config-file
> provider plugin, so I can only assume it got pushed off his radar.
> 
> -Stephen
> 
> On 22 May 2015 at 08:28, Anders Hammar  wrote:
> 
>> The issue I've been strungling with is that I would like to use the creds
>> of the person performing a Maven release when deploying to the Maven repo.
>> Not possible right now out-of-the-box, as the server creds in settings.xml
>> (possibly handled by Config File Provider Plugin) is "static". So it will
>> always be the same user/creds.
>> At one former customer that forced us to always to the releases from
>> command line. Snapshot builds were handled by Jenkins though and deployed
>> to the repo.
>> The limitation is how the creds are handled within Maven core. And as that
>> part is not easily replaceable (it's not a component that can be repalced)
>> a change is required in core. There are a few JIRA tickets around this
>> (MNG-5615, MNG-5356) and I have looked into it a bit. I even had a
>> developer work on a solution, which I think she completed, but the more I
>> dug into it I found more parts in core than needed/should be improved at
>> the same time. And then I simply ran out of time.
>> The work that was done by a dev collegue can be found here:
>> https://github.com/devoteam-se (som changes to core, in a branch, and then
>> one extension that would be current behavior if I remember correctly)
>> For a current customer I'm looking at going down an easier, but less
>> flexible, way where I will create a wagon instead that will use the creds
>> provided in a some other way than from Maven core (could be env variables
>> for example). The idea is to use this together with the release builds in
>> Jenkins where the creds would then be the one of the user triggering the
>> release build.
>> 
>> /Anders
>> 
>> On Fri, May 22, 2015 at 9:07 AM, Dan Tran  wrote:
>> 
>>> Thanks Domi
>>> 
>>> @Thomas, mine still not stat large yet but will grow.  However, the
>>> in-house RelEng seems to crank our new VM slaves very fast. But we also
>>> looking into puppet too
>>> 
>>> -Dan
>>> 
>>> On Thu, May 21, 2015 at 11:32 PM, Thomas Broyer 
>>> wrote:
>>> 
>>>> So you have a "large number of Jenkins slaves" and no configuration
>>>> management system? (Puppet, Chef, Ansible, whatever) Isn't that asking
>>> for
>>>> trouble?
>>>> 
>>>> Le ven. 22 mai 2015 06:31, Dan Tran  a écrit :
>>>> 
>>>>> Hi
>>>>> 
>>>>> As you already know place settings.xml under ~/.m2 with NFS is unsafe
>>>>> 
>>>>> How do you manage Maven credential for your enterprise build with
>> large
>>>>> number jenkins slave
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> -Dan
>>>>> 
>>>> 
>>> 
>> 


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



Re: How do you manage your settings.xml for enterprise build??

2015-05-21 Thread domi
We use the “Config File Provider Plugin”:
https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin
/Domi

On 22 May 2015, at 06:31, Dan Tran  wrote:

> Hi
> 
> As you already know place settings.xml under ~/.m2 with NFS is unsafe
> 
> How do you manage Maven credential for your enterprise build with large
> number jenkins slave
> 
> Thanks
> 
> -Dan


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



Re: deployAtEnd really works?

2015-05-14 Thread domi
I think to remember that I had the same problem when a module was included via 
profile, deployAtEnd seems not to work in that case 
Domi



> Am 14.05.2015 um 09:01 schrieb Cintia Del Rio :
> 
> I was able to achieve similar results using this plugin:
> 
> https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin
> 
> It's possible to disable the 'remote' staging and use only local staging -
> it's called 'Deferred deploy'. Effectively it's the same as deployAtEnd.
> 
> 
> The nexus staging plugin works with files to keep the state, so it's not
> affected by the customised lifecycles.
> 
>> On 14 May 2015 at 16:48, Dan Tran  wrote:
>> 
>> Darn, I am using rpm-maven-plugin, and it has its own build lifecycle.
>> 
>> what a bug.  It is  a very good feature
>> 
>> Thanks
>> 
>> -Dan
>> 
>> On Wed, May 13, 2015 at 11:19 PM, Cintia Del Rio 
>> wrote:
>> 
>>> Do you have a customised lifecycle plugin in your reactor?
>>> 
>>> https://jira.codehaus.org/browse/MDEPLOY-176
>>> 
>>> 
>>>> On 14 May 2015 at 16:12, Dan Tran  wrote:
>>>> 
>>>> Hi Bernd ,
>>>> 
>>>> I dont configure or execute any maven-deploy-plugin at my top level
>>> parent
>>>> pom.
>>>> 
>>>> The only thing that I have which may not be very conventional:
>>>> 
>>>> all of my modules are conditional activated by profile looking for
>>> existing
>>>> existing pom
>>>> 
>>>>
>>>>  enable-compX
>>>>  
>>>>
>>>>  components/compX/pom.xml
>>>>
>>>>  
>>>>  
>>>>components/compX
>>>>  
>>>>
>>>> 
>>>> 
>>>> I am using Maven 3.2.3
>>>> 
>>>> -Dan
>>>> 
>>>> 
>>>> On Wed, May 13, 2015 at 10:56 PM, Bernd Eckenfels <
>>> e...@zusammenkunft.net>
>>>> wrote:
>>>> 
>>>>> Am Wed, 13 May 2015 22:47:15 -0700
>>>>> schrieb Dan Tran :
>>>>> 
>>>>>> I am using this feature the first time and it does not seem to work
>>>>>> 
>>>>>>  mvn clean deploy -DdeployAtEnd=true
>>>>>> 
>>>>>> Each module displays this string at deploy phase
>>>>>> 
>>>>>> [INFO] *--- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
>>>>>> x*
>>>>>> 
>>>>>> [INFO] Deploying x:0.0.1-SNAPSHOT at end
>>>>>> 
>>>>>> 
>>>>>> Once the whole build is done, no deploy activity
>>>>>> 
>>>>>> 
>>>>>> Am I missing any thing?
>>>>> 
>>>>> Do you have a deploy plugin invocation in the aggregator pom?
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>>> 
>>> --
>>> ---
>>> Sent from TARDIS. Typos might be a timey whyney thingy.
>>> Enviado da TARDIS, podem existir erros devido à diferenças de
>> espaço-tempo.
>>> 
>>> Cintia Del Rio
> 
> 
> 
> -- 
> ---
> Sent from TARDIS. Typos might be a timey whyney thingy.
> Enviado da TARDIS, podem existir erros devido à diferenças de espaço-tempo.
> 
> Cintia Del Rio

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



Re: [VOTE] Change project logo and adopt owl as mascot

2014-11-25 Thread domi
+1

On 25.11.2014, at 11:57, Stephen Connolly  
wrote:

> 


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



Re: [DISCUSS] Adopt Mr Couché-Tard as our mascot, change the logo font to Alte Haas Grotesk, change the colour letter to "v"

2014-11-20 Thread domi
+1 A

On 20.11.2014, at 16:17, Stephen Connolly  
wrote:

> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-selection.png
> 
> Well if people like "shotgun owl" I will offer this choice:
> 
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-selection.png
> 
> A, B or C
> 
> My vote is for B if we don't mind the "shotgun owl" comments... I initially
> liked the red of C but after trying blue I favour B as it is closest to my
> original vision with the colour scheme I now prefer.
> 
> On 20 November 2014 14:54, Paul Benedict  wrote:
> 
>> I found the "shotgun owl" to be pretty funny and unique. Part of choosing a
>> trademark is uniqueness and that is more valuable than something standard.
>> I think the white belly should return for that return.
>> 
>> 
>> Cheers,
>> Paul
>> 
>> On Thu, Nov 20, 2014 at 8:41 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>> 
>>> For Ron!
>>> 
>>> http://people.apache.org/~stephenc/maven-logo-contest/ron.png
>>> 
>>> (note quick and dirty using a shotgun.svg from the interwebs)
>>> 
>>> On 20 November 2014 14:00, Ron Wheeler 
>>> wrote:
>>> 
 Add the shotgun and the slogan "Resistance is futile".
 If you have trouble with the shotgun, perhaps a dead mouse in the claws
 might foster the right mindset.:-)
 
 Ron
 
 
 On 20/11/2014 7:51 AM, Stephen Connolly wrote:
 
> On 20 November 2014 12:05, Kristian Rosenvold <
> kristian.rosenv...@gmail.com>
> wrote:
> 
> Might be careful with the name; http://corpo.couche-tard.com/en/
>> 
>> But shotgun owl will probably stick :)
>> 
>> See if we call him shotgun owl I'll have to draw a shotgun so that
>> we
> can
> use him for threats...
> 
> "I see you are not following the Maven way... be careful, or Shotgun
>> Owl
> will be after you"
> 
> ;-)
> 
> OTOH if people really object to Couché-Tard we can just call him
> "Sleeps-Late" instead... but I am sure there is probably an insult in
>>> some
> language or other if we go with "Sleeps-Late"!
> 
> Note: I am not sure my [skills of an artist][1] are up to drawing a
> shotgun.
> 
>   [1]: https://www.youtube.com/watch?v=7gz1DIIxmEE
> 
> 
> I like it a lot :)
>> 
>> K
>> 
>> 
>> 2014-11-20 11:49 GMT+01:00 Stephen Connolly <
>> stephen.alan.conno...@gmail.com>:
>> 
>>> The closest thing to a mascot that we have is
>>> 
>>> http://maven.apache.org/images/maven-logo-2.gif
>>> "Arse on desk behind laptop while waiting for Maven to finish
>>> downloading
>>> the interwebs"
>>> 
>>> I would like to call a vote in a couple of days to adopt M.
>>> Couché-Tard
>>> 
>> (my
>> 
>>> own creation) as our mascot
>>> 
>>> 
>>> http://people.apache.org/~stephenc/maven-logo-contest/
>> maven-owl-5-large.png
>> 
>>> "M. Couché-Tard"
>>> 
>>> In addition I am suggesting that we change the logo font to Alte
>> Haas
>>> Grotesk Bold with italic applied by Inkscape
>>> 
>>> I am also suggesting that we change the emphasis colour letter to
>> the
>>> 
>> v...
>> 
>>> as in version... and we all know that Maven helps manage versions of
>>> things... versions are very important to Maven.
>>> 
>>> The emphasis colour would be #cc to match the scarf worn by "M.
>>> Couché-Tard"
>>> 
>>> My proposal would be to make these changes as a single vote, i.e.
>> not
>>> 
>> three
>> 
>>> separate votes, the vote would be for all these changes in one go...
>>> in
>>> order to avoid design by committee.
>>> 
>>> Having said that, community is more important than a new logo or
>> even
>>> having a mascot, so hence this discuss thread before actually
>> calling
>>> a
>>> vote.
>>> 
>>> This is something that not just the developers of Maven should have
>> a
>>> say
>>> in... if we have a mascot and a refreshed logo we can use these as
>> aid
>>> to
>>> help drive a site refresh that makes Maven easier to understand for
>>> newcomers and helps existing users find what they are looking for
>>> easier
>>> and faster.
>>> 
>>> For anyone not following the dev list, here is my reasons for
>> picking
>>> "M.
>>> Couché-Tard" as a mascot...
>>> 
>>> The definition of a maven is "an expert or connoisseur"... in the
>>> context
>>> of Apache Maven, the idea is that Maven knows the conventions for
>>> 
>> different
>> 
>>> types of software projects and is an expert in applying those
>>> 
>> conventions.
>> 
>>> M. Couché-Tard is a wise fellow, sleeping-in while he waits for the
>>> interwebs to finish downloading... he may look cute but if crossed
>> or
>>> 
>> used
>> 
>>> incorrectly he will bite a chunk off your hand... but do righ

Re: generate maven dependency difference between two Jenkins builds

2014-11-03 Thread domi
Please be aware, changing the code of a released library (not SNAPSHOT) is not 
allowed and maven can not take any responsibility for any errors this will 
cause.
Thats why nexus/artifactory do not allow to change the artifact of a released 
version once its uploaded. 
Only SNAPSHOT versions are allowed to be changed.
Domi

On 04.11.2014, at 08:10, Irfan Sayed  wrote:

> thanks.
> what i figured out is , nexus / artifactory will not download the
> dependency unless there is change in the version.
> if dependency x  refers version 1.1 , then maven will see if
> nexus/artifactory has this version along with local maben repo of build
> machine
> if it does both, maven will not download the dependency even if developer
> changes the code keeping the version same
> 
> regards
> 
> 
> On Mon, Oct 20, 2014 at 5:55 AM, Bernd Eckenfels 
> wrote:
> 
>> Hello,
>> 
>> I was looking a bit deeper into making the dependency plugin to print
>> out the resolved timestamps. I noticed there is already an option
>> -DoutputAbsoluteArtifactFilename=true which would give me the path of
>> the files in the local directory. This is all good for released
>> versions, but it still points to the non-unique snapshot version files.
>> 
>> I am not wondering, is there a way to configure the maven
>> resolver/dependency management to actually not do that. When I look at
>> the build output, it does download the meta data and a specific
>> timestamped version:
>> 
>> Downloaded: https://.../2.1-SNAPSHOT/maven-metadata.xml (2 KB at 0.6
>> KB/sec)
>> Downloaded:
>> https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.pom (12 KB
>> at 22.1 KB/sec)
>> Downloading:
>> https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar
>> Downloaded:
>> https://.../2.1-SNAPSHOT/commons-vfs2-2.1-20141016.153538-385.jar
>> (423 KB at 209.7 KB/sec)
>> 
>> But it still creates a copy of that version without timestamp.
>> 
>> I can imagine this is not really the best situation, why does it not
>> stick to the uniquely named file?
>> 
>> BTW: whats the best API way to get the snapshot timestamp from a
>> Artifact object after it was resolved? I tried getDownloadURL(), but it
>> is null for the Artifacts which are present in the list of
>> 
>> 
>> org.apache.maven.plugin.dependency.utils.DependencyStatusSets.buildArtifactListOutput(Set,
>> boolean, boolean, boolean)
>> 
>> Gruss
>> Bernd
>> 
>> Am Sun, 19 Oct 2014 19:11:50 +0200
>> schrieb Bernd Eckenfels :
>> 
>>> Ah another thing, I always wished there is an option to archive the
>>> effective POM instead of the tear downed POM with the
>>> maven-archiver (addMavenDesciptor).
>>> 
>>> Especially when the effective pom also contains the resolved snapshot
>>> timestamps (which it currently not does).
>>> 
>>> Speaking of effective pom, you can create and archive it, then you
>>> have at least all expressions and profiles locked down.
>>> 
>>> Gruss
>>> Bernd
>>> 
>>> Am Sun, 19 Oct 2014 22:17:45 +0530
>>> schrieb Irfan Sayed :
>>> 
>>>> thanks bernd.
>>>> anyone has any other suggestions please?
>>>> 
>>>> regards
>>>> 
>>>> 
>>>> On Sun, Oct 19, 2014 at 9:49 PM, Bernd Eckenfels
>>>>  wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I dont have a good method for that (especially not if all
>>>>> dependencies arent fully version-specified. You can use and add
>>>>> dependencies:list as a target to the maven build, then the
>>>>> resolved list will be printed in the build log. This list can
>>>>> change depending on what is available at build time.
>>>>> 
>>>>> Gruss
>>>>> Bernd
>>>>> 
>>>>>  Am Sun, 19 Oct 2014 20:57:29 +0530
>>>>> schrieb Irfan Sayed :
>>>>> 
>>>>>> hello,
>>>>>> 
>>>>>> we have java project and using maven to build the same. we are
>>>>>> using Jenkins. in Jenkins ,  we can generate the delta of source
>>>>>> code changes between two builds.
>>>>>> in the same way, do we have any way wherein , we can generate
>>>>>> the delta of maven dependencies changed between two builds.
>>>>>> 
>>>>>> please suggest
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>> 
>>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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



Re: usage with Jenkins

2014-09-25 Thread domi
I fully agree with James, I never used the module reporting and I the action to 
remove undefined Modules does not add any added value either.
The less configuration required the better and thats where this type really 
shines. 
Also its integration with the m2release plugin is what cuts down the number of 
required Jobs a lot.
Domi

On 25.09.2014, at 09:53, James Nord (jnord)  wrote:

> Hi Stephen,
> 
> I'm not sure why you think that per module reporting is the killer feature.
> 
> For me I couldn’t give a hoot if I saw all reports from maven modules munged 
> in a single report or spread across 100 different pages (in fact I generally 
> use the top level aggregate anyway).
> 
> What's the killer feature is 
> 1) automatic (zero conf) finding of artifacts / test reports / findbugs 
> report pickup etc etc...
> 
> And also being able to lock down what the CI system will run to deploy...  
> That is if some devs have control of their own builds when an enforcer rule 
> fails (your build is not repeatable) they will look up enforcer and add 
> -Denforcer.skip  
> Yes they could add none to the enforcer config - but the ones 
> that are intelligent enough to do that know better and fix the issue rather 
> than hide it!
> Neither of the above are possible with the literate job type.
> 
> /James
> 
> 
>> -Original Message-
>> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
>> Sent: 23 September 2014 19:44
>> To: Maven Users List
>> Subject: Re: usage with Jenkins
>> 
>> FYI my aim is to supersede the evil job type with some enhanced reporting in
>> what is currently called the literate job type.
>> 
>> That would mean you'd get the per-module reporting.
>> 
>> The current evil job type's other "killer" feature is automatic downstream 
>> job
>> triggering... Which is actually broken as it does not take into account the 
>> local
>> repo that the -SNAPSHOTs may or may not have been deployed into and
>> assumes that `package` is the same as `deploy` as far as triggering is
>> concerned as well as ignoring that deployment might be to a staging repo, so
>> the artifacts may not be available downstream... However, despite being
>> fundamentally broken at every level, you would be surprised how many
>> people feel locked into the evil job type because of this...
>> 
>> In short, there is so many issues with it that I cannot recommend its use...
>> The only semi useful feature from my PoV is per module reporting.
>> 
>> (Sadly my day job has me having to support the evil job type from time to
>> time... Though usually those tickets get picked up by Kohsuke if I start
>> another "evil job type" tirade ;-) )
>> 
>> On Tuesday, 23 September 2014, Curtis Rueden 
>> wrote:
>> 
>>> Hi James,
>>> 
>>>> I can no longer see "Deploy artifacts to Maven repository"
>>>> as a post-build action.
>>> 
>>> Just add a build step that does "mvn deploy" or similar.
>>> 
>>>> Dare I ask what I'm missing having chosen the full-fat option..?
>>> 
>>> If you're asking what you cannot do with freeform jobs: I don't know
>>> of anything. I think the Maven-style job is just a convenience to get
>>> very basic CI set up as quickly as possible, for people without much
>>> technical know-how.
>>> 
>>> If you're asking for more details on limitations of the Maven-style job:
>>> it's been awhile, but IIRC my group had several problems. One such was
>>> that the Jenkins Git plugin did not fire Maven-style jobs upon
>>> receiving the push notification from GitHub. Another really serious
>>> problem is that you can't add arbitrary shell script as a post-build
>>> step. And needing to do this is, in my experience, extremely common.
>>> 
>>> It wouldn't be that big of an issue if there were an easy way to later
>>> "convert" a Maven-style job to a freestyle job should the need arise.
>>> But try a web search on that topic and you'll see what I mean about it
>>> being a highly non-trivial problem.
>>> 
>>> Regards,
>>> Curtis
>>> 
>>> On Tue, Sep 23, 2014 at 8:56 AM, James Green
>> >> >
>>> wrote:
>>> 
>>>> News to me. Ironically I'm just setting up a new Jenkins job so
>>>> tried the freeform style - I can no longer see "Deploy artifacts to
>>>> Maven
>>> repository"
>>>> as a post-

Re: Adding comments to dependencies in POM

2014-08-27 Thread domi
+1
I think this would be a good idea, let us know about the issue, so we can vote 
on it.
Domi

On 27.08.2014, at 09:12, James Green  wrote:

> I have in the past wasted hours of effort trying to weed out dependency
> issues where something has been added for reasons unknown. Removal leads to
> breakage.
> 
> It would be helpful if, inside a POM, it were possible to add a comment
> element to a dependency. I realise this is possible as an XML comment,
> however having a POM field would let documentation engines record the
> comment.
> 
> The same could be said for dependencies inside dependencyManagement.
> 
> It would of course have the side effect of auto completion within IDEs
> showing authors how to "officially" comment on the reason for that work.
> 
> An idea.
> 
> James


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



Re: maven-dependency-plugin unpacking aar format?

2014-07-22 Thread domi
I think to recall a thread on the dev list about plans to remove the unpack 
goal from the dependency plugin, but I can’t find it anymore…
regards Domi

On 22.07.2014, at 16:29, William Ferguson  
wrote:

> I totally agree that it makes sense for the dependency plugin to unpack the
> AAR just like all other archives.
> 
> I just don't understand why you need the MDP to do so.
> 
> 
> On Tue, Jul 22, 2014 at 10:58 PM, David Hoffer  wrote:
> 
>> No that was just an example so I could create a sample project.  Don't read
>> too much into this.  They are just AAR dependencies (in my case they come
>> from our build not public).  The maven dependency plugin should handle
>> these no different than it handles jars/etc.
>> 
>> 
>> 
>> 
>> On Mon, Jul 21, 2014 at 11:32 PM, William Ferguson <
>> william.fergu...@xandar.com.au> wrote:
>> 
>>> So an Android library is packaging WSDL inside itself and is expecting
>> you
>>> to use it at build time?
>>> 
>>> 
>>> On Tue, Jul 22, 2014 at 8:53 AM, Martin Gainty 
>>> wrote:
>>> 
>>>> Here is an aar straight from Axis version example:
>>>> 
>>>> //layout of version.aar:
>>>> 
>>>>   created: META-INF/
>>>>  inflated: META-INF/MANIFEST.MF
>>>>   created: sample/
>>>>   created: sample/axisversion/
>>>>  inflated: sample/axisversion/Version.class
>>>>  inflated: META-INF/services.xml
>>>> 
>>>> 
>>>> //org.apache.axis2.deployment.DeploymentEngine axis code used to
>>>> populateService with .aar contents:
>>>> 
>>>>protected ArrayList populateService(AxisServiceGroup serviceGroup,
>>>>URL servicesURL,
>>>>String serviceName) throws
>>>> DeploymentException {
>>>>try {
>>>>serviceGroup.setServiceGroupName(serviceName);
>>>>ClassLoader serviceClassLoader = Utils.createClassLoader(
>>>>new URL[]{servicesURL},
>>>>axisConfig.getServiceClassLoader(),
>>>>true,
>>>>(File)
>>>> 
>> axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR),
>>>>axisConfig.isChildFirstClassLoading());
>>>>String metainf = "meta-inf";
>>>> 
>> serviceGroup.setServiceGroupClassLoader(serviceClassLoader);
>>>>//processing wsdl.list
>>>>InputStream wsdlfilesStream =
>>>> 
>>>> serviceClassLoader.getResourceAsStream("meta-inf/wsdl.list");
>>>>if (wsdlfilesStream == null) {
>>>>wsdlfilesStream =
>>>> serviceClassLoader.getResourceAsStream("META-INF/wsdl.list");
>>>>if (wsdlfilesStream != null) {
>>>>metainf = "META-INF";
>>>>}
>>>>}
>>>>HashMap servicesMap = new HashMap();
>>>>if (wsdlfilesStream != null) {
>>>>ArchiveReader reader = new ArchiveReader();
>>>>BufferedReader input = new BufferedReader(new
>>>> InputStreamReader(wsdlfilesStream));
>>>>String line;
>>>>while ((line = input.readLine()) != null) {
>>>>line = line.trim();
>>>>if (line.length() > 0 && line.charAt(0) != '#') {
>>>>line = metainf + "/" + line;
>>>>try {
>>>>List services =
>>> reader.getAxisServiceFromWsdl(
>>>> 
>>>> serviceClassLoader.getResourceAsStream(line),
>>>>serviceClassLoader, line);
>>>>if (services != null) {
>>>>for (Object service : services) {
>>>>AxisService axisService =
>>>> (AxisService) service;
>>>> 
>>> servicesMap.put(axisService.getName(),
>>>> axisService);
>>>>}
>>>>}
>>>> 
>>>>} catch (Ex

[ANN] Apache Maven SCM Plugin 1.9 Released

2014-01-11 Thread domi
The Apache Maven team is pleased to announce the release of the Apache Maven 
SCM Plugin, version 1.9

The SCM Plugin offers vendor independent access to common scm commands by 
offering a set of command mappings for the configured scm.

http://maven.apache.org/scm/maven-scm-plugin/
You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-scm-plugin
  1.9


Release Notes - Maven SCM Plugin - Version 1.9

Bug

[SCM-435] - can not work with local copy
[SCM-503] - create a native Java GIT provider using JGit
[SCM-650] - HgChangeLogConsumer generates phantom 'null' changeset at the 
end
[SCM-681] - Git blame fails to report line authors on windows with 
core.autocrlf = true
[SCM-702] - Incorrect documentation for parameter "skip" of goal 
"check-local-modification" of the plugin
[SCM-705] - Git pushes tag ambigiously
[SCM-709] - REGRESSION: git status doesn't work if repository root is not 
the working directory
[SCM-733] - Bugfixes to mercurial changelog
[SCM-737] - can't build CVS provider from source release zip file due to 
missing CVS test repository

Improvement

[SCM-487] - support --parents option for svn copy (tag commands) (svn 1.5 
required)
[SCM-565] - scm:validate should not fork the build
[SCM-636] - Provide documentation about connection and developerConnection
[SCM-736] - update plugin to use plugin-tools java 5 annotations

New Feature

[SCM-727] - integrate scm-provider based on jgit


Enjoy,

-The Apache Maven team
--
Dominik Bartholdi