Re: Incremental build API

2014-03-25 Thread Mauri, Richard
Thanks, I’ll take a look
One of these days I was going to attempt a port of an incremental build system 
we developed to Maven.
Some concepts include a post compile artifact byte code analyzer and comparator 
that classifies the nature of change to help optimize away (in some cases) the 
dependent transient rebuilds
Of course using mvn clean would defeat this, we have a smarter clean that 
executes its goal only if the scm system has detected deletes…
Anyway, I’ll use your announcement to try to engage.
Thanks!

From: Jason van Zyl ja...@takari.iomailto:ja...@takari.io
Reply-To: Maven Users List 
users@maven.apache.orgmailto:users@maven.apache.org
Date: Tuesday, March 25, 2014 at 10:44 AM
To: Maven Users List users@maven.apache.orgmailto:users@maven.apache.org
Subject: Incremental build API

Hi,

For those who are interested in incremental builds we, at Takari, have released 
a general purpose incremental build API with an initial focus on Maven. We've 
created a short, high-level description of the framework[1] and we've opened up 
our Git repository with the code[2]. We also have a some demos that people can 
look at[3]. We are, and have been, running this code in production for a few 
months but it is still a work in progress. We have implemented a Maven 
lifecycle that integrates this API but we've just started using it ourselves. 
We will open this lifecycle up shortly for people to try but for now, if you're 
interested in incremental builds take a look and let us know what you think!

A note to those interested that the use of the API in Maven requires 3.2.1+.

[1]: http://takari.io/2014/03/25/incremental-build.html
[2]: https://github.com/takari/io.takari.incrementalbuild
[3]: 
https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementalbuild/src/test/java/io/takari/incremental/demo

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

I never make the mistake of arguing with people for whose opinions I have no 
respect.

-- Edward Gibbon












Re: maven won't resolve from central log4j:log4j:1.2.8 through 1.2.15

2014-03-12 Thread Mauri, Richard
Hi, any word on how to fix the maven central repo so we can proceed with
resolving (mvn dependency:tee) log4j:log4j:[1.2.8] ?

It¹s curious why we can request with soft version 1.2.8 but not absolute
[1.2.8]

What has to happen to fix the maven central repos?

On 3/10/14, 9:32 AM, Anders Hammar and...@hammar.net wrote:

Yes, something seems wrong with the metadata file. It should list all
versions.

/Anders (mobile)
Den 10 mar 2014 17:25 skrev Adrien Rivard adrien.riv...@gmail.com:

 Does'nt seem to work for me either when hitting maven central directly.
 Works ok when using my usual MRM.

 If I'm not wrong
 http://repo.maven.apache.org/maven2/log4j/log4j/maven-metadata.xml
should
 return all versions while it returns only 2 .




 On Mon, Mar 10, 2014 at 4:37 PM, Mauri, Richard richard.ma...@sap.com
 wrote:

  I am still having trouble.
  It certainly should be easy to reproducee no?
  It is a trivial settings.xml and pom.xml and mvn dependency:tree goal
 
  Thanks for helping, but please keep at it :-)
 
  On 3/10/14, 6:15 AM, Wayne Fay wayne...@gmail.com wrote:
 
   Where did this repo.maven.apache.org url come from?
  
   Wayne, it's a correct URL for the central repository. It's the one
we
   define in the super-POM since Maven 3.0.something.
  
  Doh, well ignore that then. I should have done 30 seconds of
searching
  before sending that one. :)
  
  But just FYI, when I myself tried accessing that URL last night, I
had
  problems in my browser. First it was HTTPS problems as the URL did
not
  match the server name being reported (I have the HTTPS Everywhere
  plugin turned on). I clicked ignore and went to the site and got
  HTTP 404 errors at /log4j/log4j/maven-metadata.xml so I moved up to
  /log4j/log4j and had the same errors. I did not grab the error but it
  was something related to Varnish cache - when I cause a 404 now, the
  error appears different.
  
  So at the very least, the mirror I was on (fastly.net) was having
  issues - and potentially this was mirrored to others, possibly
  explaining the troubles (??). I had no such trouble hitting the old
  standby of repo1.maven.org and resolving the files etc. These errors
  made me question the URL entirely.
  
  I hit it again just now and dns sends me to fastly.net again but this
  time the files are there.
  
  So, I would ask Richard to try again and see if things work better
  today, or if he is having the same troubles.
  
  Wayne
  
  -
  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
 
 


 --
 Adrien Rivard



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



Re: maven won't resolve from central log4j:log4j:1.2.8 through 1.2.15

2014-03-11 Thread Mauri, Richard
Yes Wayne, I rm -rf ~/.m2/repository

Your questioning implies my test case is not reproducible for you; really


On 3/10/14, 9:19 AM, Wayne Fay wayne...@gmail.com wrote:

 I am still having trouble.
 It certainly should be easy to reproducee no?
 It is a trivial settings.xml and pom.xml and mvn dependency:tree goal

Have you used mvn -U lately?
Have you deleted ~/.m2/repository lately? I rarely do this myself, but
occasionally we hear this solves problems for some users. I might
suggest a slightly more surgical deletion of ~/.m2/repository/log4j
rather than the entire repo in this case.

Wayne

-
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: maven won't resolve from central log4j:log4j:1.2.8 through 1.2.15

2014-03-10 Thread Mauri, Richard
I am still having trouble.
It certainly should be easy to reproducee no?
It is a trivial settings.xml and pom.xml and mvn dependency:tree goal

Thanks for helping, but please keep at it :-)

On 3/10/14, 6:15 AM, Wayne Fay wayne...@gmail.com wrote:

 Where did this repo.maven.apache.org url come from?

 Wayne, it's a correct URL for the central repository. It's the one we
 define in the super-POM since Maven 3.0.something.

Doh, well ignore that then. I should have done 30 seconds of searching
before sending that one. :)

But just FYI, when I myself tried accessing that URL last night, I had
problems in my browser. First it was HTTPS problems as the URL did not
match the server name being reported (I have the HTTPS Everywhere
plugin turned on). I clicked ignore and went to the site and got
HTTP 404 errors at /log4j/log4j/maven-metadata.xml so I moved up to
/log4j/log4j and had the same errors. I did not grab the error but it
was something related to Varnish cache - when I cause a 404 now, the
error appears different.

So at the very least, the mirror I was on (fastly.net) was having
issues - and potentially this was mirrored to others, possibly
explaining the troubles (??). I had no such trouble hitting the old
standby of repo1.maven.org and resolving the files etc. These errors
made me question the URL entirely.

I hit it again just now and dns sends me to fastly.net again but this
time the files are there.

So, I would ask Richard to try again and see if things work better
today, or if he is having the same troubles.

Wayne

-
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



maven won't resolve from central log4j:log4j:1.2.8 through 1.2.15

2014-03-09 Thread Mauri, Richard
Using mvm 3.1.1 with a pom.xml with a dependency on log4j version [1.2.8]
- it will not resolve
Similar for required versions up to and including [1.2.15]

It¹s not an option for us to just go to the later log4j like [1.2.17]

What¹s going on here?
If we request an open ended 1.2.8 then it resolves ok !

Here¹s an example session

i836228@SJCM00561975A mvn dependency:tree
[INFO] Scanning for projects...
[INFO] 

[INFO] Building testlog4j 1.0-SNAPSHOT
[INFO] 

Downloading: 
http://repo.maven.apache.org/maven2/log4j/log4j/maven-metadata.xml
Downloading: http://repo1.maven.org/maven2/log4j/log4j/maven-metadata.xml
Downloaded: http://repo1.maven.org/maven2/log4j/log4j/maven-metadata.xml
(352 B at 0.7 KB/sec)
Downloaded: 
http://repo.maven.apache.org/maven2/log4j/log4j/maven-metadata.xml (352 B
at 0.6 KB/sec)
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 1.025s
[INFO] Finished at: Fri Mar 07 12:31:54 PST 2014
[INFO] Final Memory: 6M/81M
[INFO] 

[ERROR] Failed to execute goal on project testlog4j: Could not resolve
dependencies for project ariba.testlog4j:testlog4j:jar:1.0-SNAPSHOT:
Failed to collect dependencies at log4j:log4j:jar:[1.2.8,1.2.8]: No
versions available for log4j:log4j:jar:[1.2.8,1.2.8] within specified
range - [Help 1]



Here is a pom.xml

project xmlns=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;
  modelVersion4.0.0/modelVersion

  groupIdariba.testlog4j/groupId
  artifactIdtestlog4j/artifactId
  version1.0-SNAPSHOT/version
  packagingjar/packaging

  dependencies
dependency
  groupIdlog4j/groupId
  artifactIdlog4j/artifactId
  version[1.2.8]/version
/dependency
  /dependencies
/project


Here is a .m2/settings.xml

?xml version=1.0 encoding=UTF-8?

settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;

  proxies
proxy
  idsap/id
  activetrue/active
  protocolhttp/protocol
  hostproxy.ariba.com/host
  port8080/port
/proxy
  /proxies

  profiles
profile
  idalwaysActiveProfile/id

  repositories
repository
  idMavenCentralRepo1/id
  namemaven Central Repo1/name
  urlhttp://repo1.maven.org/maven2/url
  layoutdefault/layout
/repository
  /repositories
/profile
  /profiles

  activeProfiles
activeProfilealwaysActiveProfile/activeProfile
  /activeProfiles
/settings




On 3/6/14, 9:16 AM, Venkata Suresh Kumar Pamidipati
suresh.pamidip...@oracle.com wrote:

Hi mgainty,

Thanks for the response and information. I will contact the number given
below.

Thanks  Regards,
Suresh


- Original Message -
From: mgai...@hotmail.com
To: users@maven.apache.org, suresh.pamidip...@oracle.com
Sent: Thursday, March 6, 2014 6:39:54 PM GMT +05:30 Chennai, Kolkata,
Mumbai, New Delhi
Subject: RE: Invalid signature file digest for Manifest main attributes

Hi Suresh

 

Your best solution will come from  Oracle Support India
They are supposed to know this information and will be able to assist you
with your problem
Oracle India Support Line number is +91.22.66796200
If  Oracle India is unable to assist you ..we can find a resource on this
side of the planet to help you


Warm Regards

  



 Date: Wed, 5 Mar 2014 19:19:44 -0800
 From: suresh.pamidip...@oracle.com
 To: users@maven.apache.org
 Subject: Invalid signature file digest for Manifest main attributes
 
 Hi,
 
 I am trying to build our project using maven. I have included multiple
dependency jars in pom.xml and I am trying to build distribution jar
using assembly:assembly goal. The command mvn assembly:assembly
resulted in the below error.
 
 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:assembly
(default-cli) on project my-plugin: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:assembly failed:
Invalid signature file digest for Manifest main attributes - [Help 1]
 
 Two of the dependency jars when present together was causing this
issue. I tried commenting one of them and mvn assembly:assembly command
worked fine. To make it work with both the jars present together, I
tried by adding excludes in dependency, assembly and even shade plugin
configuration in pom.xml to exclude MANIFEST files of one of those two
jars as shown below, but still the same error exists.
 
 configuration
 filters