Looking for org.apache.poi 3.10-FINAL
Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven-repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko -- Sent from my mobile On Feb 16, 2014 9:43 AM, David Law m2ecli...@apconsult.de wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen
skrive...@gmail.com:
Thanks for the advice on how to restructure.
Could you have a look at the deploy-plugin project and the file
org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in
version 2.8.1 ? I would really like to understand the following:
1) What controls which artifacts are attached the model for the given
project?
The plugin creating that artifact controls the attaching. For example:
http://maven.apache.org/plugins/maven-source-plugin/xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307
Here the -sources.jar is attached to the project.
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
The plugin creating that artifact
3) Is it really the intended behaviour of the deploy:file goal to also
deploy the attached artifacts? To me that is a very non-intuitive
behaviour.
Yes. If there are attachments created and these are attached, they are
uploaded as well. So if you don't want this, solve it at the source, i.e
the plugin creating the artifact. (for the maven-source-plugin: skip it
(best option) or just don't attach (acceptable option) )
For the same reason you won't find delete options in any of the plugins.
It is a matter of excluding the correct files.
Robert
I Basically have a working setup which deploys the zip file I generate to
repo with the name I have specified. But the only thing that bothers me
is
that for some unclear reason the same zip is deployed again with the name
of the project in the same deploy:file goal. To me - that is a bug.
Should I open an issue instead somewhere and provide the patch which
fixes
this??
I already mailed the email listed in the top of the java file in question
but he does not reply.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote:
You should really restart with the module 2 pom.
Your multi-module structure is good. You have a separate projekt/module
which creates your distro. What you should do is to create the distro
(zip or whatever) to be created as part of the normal build and then
deployed as the project's artifact it is.
This is done in many projects and you could for example have a look at
the
Maven core project where we create a zip and a tar file.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;hb=HEAD
So in the end, you will not use deploy:deploy-file. Also, your pom will
be
very small with pretty much only the m-assembly-p being bound to the
build
lifecycle.
/Anders
On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi Anders
I have a multi-module project with this structure:
A (root and parent pom project)
- module 1 - builds a jar as artifact
- module 2 - uses module 1 jar artifact in assembly tries to deploy
the
assembled zip file to artifactory.
This is the module 2 pom file with inserted to replace project
specific names.
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
parent
groupId/groupId
artifactId/artifactId
version1.1-SNAPSHOT/version
/parent
artifactIdscripts/artifactId
packagingpom/packaging
namescripts/name
description/description
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding
main.basedir${project.parent.basedir}/main.basedir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.5.1/version
configuration
skiptrue/skip
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.4/version
configuration
skiptrue/skip
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.8.1/version
configuration
skiptrue/skip
/configuration
/plugin
/plugins
/build
profiles
profile
iddeployprofile/id
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
version1.2.1/version
executions
execution
idCopy into target folder and copy service jar into
files/default
/id
phasepackage/phase
goals
goalexec/goal
/goals
configuration
executable${project.basedir}/build_cookbook.sh/executable
arguments
argument${project.parent.artifactId}/argument
argument${project.parent.version}/argument
/arguments
/configuration
/execution
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Robert
Thank you for your answer.
I would like to figure out how to simple skip the generation of the given
extra zip file because I do not know how now.
Any way to see during debug which goal will result in which artifact? Any
help on finding out when running my build will be appreciated.
I can not omit what I do not know to control nor can I not attach it when I
do no what generates it.
Not creating or attaching the artifact solves the problem - but still, as
user of maven I still say that it is counter intuitive to have the
deploy-file goal not only deploy the specified file.
The deploy goal should deploy all - but not the deploy-file goal. :)
I know that is a different discussion about meaningful naming of APIs and
frankly I don't care now that I know.
But maven developers should care about simplifying and make maven APIs
intuitive since maven is not exactly gaining ground due to it's simplicity
and transparency. ;)
That being said, I have been using maven for a looong time and enjoy it
most of the time - so keep up the good work!
regards
Henrik Skriver Rasmussen
On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte rfscho...@apache.orgwrote:
Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen
skrive...@gmail.com:
Thanks for the advice on how to restructure.
Could you have a look at the deploy-plugin project and the file
org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in
version 2.8.1 ? I would really like to understand the following:
1) What controls which artifacts are attached the model for the given
project?
The plugin creating that artifact controls the attaching. For example:
http://maven.apache.org/plugins/maven-source-plugin/
xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307
Here the -sources.jar is attached to the project.
2) Is it possible to state that no artifacts except explicitly stated
should be created/attached?
The plugin creating that artifact
3) Is it really the intended behaviour of the deploy:file goal to also
deploy the attached artifacts? To me that is a very non-intuitive
behaviour.
Yes. If there are attachments created and these are attached, they are
uploaded as well. So if you don't want this, solve it at the source, i.e
the plugin creating the artifact. (for the maven-source-plugin: skip it
(best option) or just don't attach (acceptable option) )
For the same reason you won't find delete options in any of the plugins.
It is a matter of excluding the correct files.
Robert
I Basically have a working setup which deploys the zip file I generate to
repo with the name I have specified. But the only thing that bothers me is
that for some unclear reason the same zip is deployed again with the name
of the project in the same deploy:file goal. To me - that is a bug.
Should I open an issue instead somewhere and provide the patch which fixes
this??
I already mailed the email listed in the top of the java file in question
but he does not reply.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote:
You should really restart with the module 2 pom.
Your multi-module structure is good. You have a separate projekt/module
which creates your distro. What you should do is to create the distro
(zip or whatever) to be created as part of the normal build and then
deployed as the project's artifact it is.
This is done in many projects and you could for example have a look at
the
Maven core project where we create a zip and a tar file.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;
f=apache-maven;hb=HEAD
So in the end, you will not use deploy:deploy-file. Also, your pom will
be
very small with pretty much only the m-assembly-p being bound to the
build
lifecycle.
/Anders
On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi Anders
I have a multi-module project with this structure:
A (root and parent pom project)
- module 1 - builds a jar as artifact
- module 2 - uses module 1 jar artifact in assembly tries to deploy
the
assembled zip file to artifactory.
This is the module 2 pom file with inserted to replace project
specific names.
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
parent
groupId/groupId
artifactId/artifactId
version1.1-SNAPSHOT/version
/parent
artifactIdscripts/artifactId
packagingpom/packaging
namescripts/name
description/description
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
project.reporting.outputEncodingUTF-8/project.
reporting.outputEncoding
main.basedir${project.parent.basedir}/main.basedir
Re: Looking for org.apache.poi 3.10-FINAL
Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven-repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - 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 deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Henrik, IMHO deploy-file (just like install-file) should *never* be a part of a lifecycle, but should be run standalone and should only be used for unavailable third party artifacts. Looking back at your pom-fragment, you should do the following: * if deploymentfile is being created by a Maven plugin, try to make that plugin attach that file to the project. * Use http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html and remove the deploy-file asap. This plugin does it's work as part of the build lifecycle as it should be. Robert Op Sun, 16 Feb 2014 11:20:39 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Hi Robert Thank you for your answer. I would like to figure out how to simple skip the generation of the given extra zip file because I do not know how now. Any way to see during debug which goal will result in which artifact? Any help on finding out when running my build will be appreciated. I can not omit what I do not know to control nor can I not attach it when I do no what generates it. Not creating or attaching the artifact solves the problem - but still, as user of maven I still say that it is counter intuitive to have the deploy-file goal not only deploy the specified file. The deploy goal should deploy all - but not the deploy-file goal. :) I know that is a different discussion about meaningful naming of APIs and frankly I don't care now that I know. But maven developers should care about simplifying and make maven APIs intuitive since maven is not exactly gaining ground due to it's simplicity and transparency. ;) That being said, I have been using maven for a looong time and enjoy it most of the time - so keep up the good work! regards Henrik Skriver Rasmussen On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte rfscho...@apache.orgwrote: Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Thanks for the advice on how to restructure. Could you have a look at the deploy-plugin project and the file org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in version 2.8.1 ? I would really like to understand the following: 1) What controls which artifacts are attached the model for the given project? The plugin creating that artifact controls the attaching. For example: http://maven.apache.org/plugins/maven-source-plugin/ xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307 Here the -sources.jar is attached to the project. 2) Is it possible to state that no artifacts except explicitly stated should be created/attached? The plugin creating that artifact 3) Is it really the intended behaviour of the deploy:file goal to also deploy the attached artifacts? To me that is a very non-intuitive behaviour. Yes. If there are attachments created and these are attached, they are uploaded as well. So if you don't want this, solve it at the source, i.e the plugin creating the artifact. (for the maven-source-plugin: skip it (best option) or just don't attach (acceptable option) ) For the same reason you won't find delete options in any of the plugins. It is a matter of excluding the correct files. Robert I Basically have a working setup which deploys the zip file I generate to repo with the name I have specified. But the only thing that bothers me is that for some unclear reason the same zip is deployed again with the name of the project in the same deploy:file goal. To me - that is a bug. Should I open an issue instead somewhere and provide the patch which fixes this?? I already mailed the email listed in the top of the java file in question but he does not reply. Med venlig hilsen Henrik Skriver Rasmussen On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote: You should really restart with the module 2 pom. Your multi-module structure is good. You have a separate projekt/module which creates your distro. What you should do is to create the distro (zip or whatever) to be created as part of the normal build and then deployed as the project's artifact it is. This is done in many projects and you could for example have a look at the Maven core project where we create a zip and a tar file. https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree; f=apache-maven;hb=HEAD So in the end, you will not use deploy:deploy-file. Also, your pom will be very small with pretty much only the m-assembly-p being bound to the build lifecycle. /Anders On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote: Hi Anders I have a multi-module project with this structure: A (root and parent pom project) - module 1 - builds a jar as artifact - module 2 - uses module 1 jar artifact in assembly tries to deploy the assembled zip file to artifactory. This is the module 2 pom file with inserted to replace project specific names. project
RE: Possible build collision between CI snapshot build and Release build
From: bmat...@batmat.net Date: Sat, 15 Feb 2014 22:07:26 +0100 Subject: Re: Possible build collision between CI snapshot build and Release build To: users@maven.apache.org OK, so this has to be CVCS (svn and so on) specific? I didn't check if the release-plugin commits + push each time. If this is so, it should be fixed so that this cannot happen. I would say that though this is a valid technical concern, it's very unlikely to happen in real life. Let's take an example with a well known CI server, and specifically with svn: * You start a release. At the end of the release:prepare, the release-plugin commits the poms just before copying the path to the tags directory, then reverting the poms to the next snapshot development version. MGwhile release:prepare is working to output release ArtifactId-1.1-RC1 MGthen the POMs are reverted to ArtifactId=1.0-SNAPSHOT? MGPlease clarify * Unfortunately, the CI kicks in just there, just after that commit, and before the trunk comes back to snapshot. with Jenkins (and Hudson), there's a default delay of some seconds, historically to support VCS like CVS that wouldn't commit files in an atomic manner * So, Jenkins is gonna wait those seconds before actually starting the build. Then it asks the VCS once more if a new change occurred. So, the probability to encounter this issue is even lower... So, all in all, if that's the issue you're talking about. Not sure it's worth to worry a lot :-). Btw, if you use a repo manager with a staging area, then at worse you're gonna create a staging repo from the CI build in addition to your release build. MGso in the case of Nexus the staging repo would input SNAPSHOTS from CI and based on MGStaging artifacts pass each one of predefined and custom rulesets Nexus would release them to PROD as RC MGrelease has a separate build? MGwhat would happen if the RC doesnt build..revert it and send it back to SNAPSHOTS? MGplease clarify So, in the end you won't be able to push many releases under the same names MGthe artifact name changes? MGor is it the version changes? MGplease clarify and your release should still be able to proceed. HTH 2014-02-15 16:51 GMT+01:00 Thomas Broyer t.bro...@gmail.com: On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus bmat...@batmat.net wrote: Hi Dan, Not sure what you mean. You say CI, are you taking about a specific server? If Jenkins for example, wouldn't it then be more a Jenkins user ml question? And I don't see how a snapshot build could interfere with another build with a release version. Could you give details about your issue so that we can help you? mvn release:prepare does a first commit with the POM modified with the no-SNAPSHOT version, then another commit with the POM modified with the next SNAPSHOT version. If a build is triggered for the first commit and basically does a mvn install or, worse, a mvn deploy, then it'll end up deploying your release version, the very same that mvn release:perform will deploy too (very same version information, not necessarily the same artifact: might not deploy javadoc and sources for example, or the artifact might be slightly different because you have plugins in a profile triggered only on, or never on, release builds). I think that what Dan referred to as a CI snapshot build is the kind of build triggered by a commit (which generally builds snapshots). Cheers Le 15 févr. 2014 07:01, Dan Tran dant...@gmail.com a écrit : Hello It is possible that while release:prepare cutting the tag and CI for snapshot build wakeup at the same time. Is there a way to prevent this? like a a profile to fail the build if the version happen to be a release version. Ie is there a way to detect this in a profile? MGprofile is a snapshot of state information of the maven lifeycle at that particular point in time MGsome typical uses for profiles: MGdid JVM change? MGdid OS change? MGis this test only (dry run)? MGwill we enable logging? MGdo we need to enable security? MGif your artifact version is assigned to a property and property changes yes then you can detect it and then run it thru another MGplugin MGif the version is appended (as in the typical structure of a GAV) then no maven will not detect any property change MG(since no property has changed) I currently have to keep remind my self to turn off CI snapshot build while release is in progress, MGcompile and release plugins should *not* be executing at same time MGsnapshots are typically built earlier on during 'compile' phase MGif the snapshot build does fail you want to exit the lifecycle (and not continue on to pre-site) MGrelease is built later during pre-site phase (as seen in this pom illustrated below) MG build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Hi Robert Thanks - that sounds interesting and I will look into that Monday. But what is the right way to deploy a zip file build in the project to the artifactory repository then? Is it to only use deploy? Regards Henrik Skriver Rasmussen On Feb 16, 2014, at 14:47, Robert Scholte rfscho...@apache.org wrote: Hi Henrik, IMHO deploy-file (just like install-file) should *never* be a part of a lifecycle, but should be run standalone and should only be used for unavailable third party artifacts. Looking back at your pom-fragment, you should do the following: * if deploymentfile is being created by a Maven plugin, try to make that plugin attach that file to the project. * Use http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html and remove the deploy-file asap. This plugin does it's work as part of the build lifecycle as it should be. Robert Op Sun, 16 Feb 2014 11:20:39 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Hi Robert Thank you for your answer. I would like to figure out how to simple skip the generation of the given extra zip file because I do not know how now. Any way to see during debug which goal will result in which artifact? Any help on finding out when running my build will be appreciated. I can not omit what I do not know to control nor can I not attach it when I do no what generates it. Not creating or attaching the artifact solves the problem - but still, as user of maven I still say that it is counter intuitive to have the deploy-file goal not only deploy the specified file. The deploy goal should deploy all - but not the deploy-file goal. :) I know that is a different discussion about meaningful naming of APIs and frankly I don't care now that I know. But maven developers should care about simplifying and make maven APIs intuitive since maven is not exactly gaining ground due to it's simplicity and transparency. ;) That being said, I have been using maven for a looong time and enjoy it most of the time - so keep up the good work! regards Henrik Skriver Rasmussen On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte rfscho...@apache.orgwrote: Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Thanks for the advice on how to restructure. Could you have a look at the deploy-plugin project and the file org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in version 2.8.1 ? I would really like to understand the following: 1) What controls which artifacts are attached the model for the given project? The plugin creating that artifact controls the attaching. For example: http://maven.apache.org/plugins/maven-source-plugin/ xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307 Here the -sources.jar is attached to the project. 2) Is it possible to state that no artifacts except explicitly stated should be created/attached? The plugin creating that artifact 3) Is it really the intended behaviour of the deploy:file goal to also deploy the attached artifacts? To me that is a very non-intuitive behaviour. Yes. If there are attachments created and these are attached, they are uploaded as well. So if you don't want this, solve it at the source, i.e the plugin creating the artifact. (for the maven-source-plugin: skip it (best option) or just don't attach (acceptable option) ) For the same reason you won't find delete options in any of the plugins. It is a matter of excluding the correct files. Robert I Basically have a working setup which deploys the zip file I generate to repo with the name I have specified. But the only thing that bothers me is that for some unclear reason the same zip is deployed again with the name of the project in the same deploy:file goal. To me - that is a bug. Should I open an issue instead somewhere and provide the patch which fixes this?? I already mailed the email listed in the top of the java file in question but he does not reply. Med venlig hilsen Henrik Skriver Rasmussen On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote: You should really restart with the module 2 pom. Your multi-module structure is good. You have a separate projekt/module which creates your distro. What you should do is to create the distro (zip or whatever) to be created as part of the normal build and then deployed as the project's artifact it is. This is done in many projects and you could for example have a look at the Maven core project where we create a zip and a tar file. https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree; f=apache-maven;hb=HEAD So in the end, you will not use deploy:deploy-file. Also, your pom will be very small with pretty much only the m-assembly-p being bound to the build lifecycle. /Anders On Thu, Feb 13, 2014 at 11:36 AM, Henrik Skriver Rasmussen skrive...@gmail.com wrote:
Re: Looking for org.apache.poi 3.10-FINAL
On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote: Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. FWIW, I did a search today for org.apache.poi:poi in my local m2e and 3.10-FINAL appeared - so it's definitely in the index from the 15th (which is the index downloaded on my local computer according to the file under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it was indexed... You could always post a question on https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive answer of what happened, when, and why. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw -- Cheers, Stuart
RE: Looking for org.apache.poi 3.10-FINAL
Date: Sun, 16 Feb 2014 10:49:48 +0100 Subject: Re: Looking for org.apache.poi 3.10-FINAL From: mfriedenha...@gmail.com To: users@maven.apache.org David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko -- Sent from my mobile On Feb 16, 2014 9:43 AM, David Law m2ecli...@apconsult.de wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi 3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw MGI think whats happening is when you say add repository ..Eclipse assumes you want to add a CVS repo MG(where repo.maven.apache.org is not a a CVS repo) MGI was able to coax Exlipse to add repo host = central.maven.org MGas far as authentication to central.maven.org I tried MG1)ssh ...no MG2)pserver..no MG3)pserverssh2..no MG4)ext..no MGsince the built in hooks to IBM repositories seem to confine to one of the 4 authentication schemes MGto a *known* CVS repo maybe use IDEA instead? MGMartin- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven deploy plugin 2.8.1 - deploy-file goal - unable to avoid attachedArtifacts from being deployed in execute
Yes. Use a pom project and bind the assembly plugin to the build lifecycle. Did you take a look at the project I linked to earlier? Just copy that solution. /Anders (mobile) Den 16 feb 2014 14:37 skrev Henrik Skriver Rasmussen skrive...@gmail.com : Hi Robert Thanks - that sounds interesting and I will look into that Monday. But what is the right way to deploy a zip file build in the project to the artifactory repository then? Is it to only use deploy? Regards Henrik Skriver Rasmussen On Feb 16, 2014, at 14:47, Robert Scholte rfscho...@apache.org wrote: Hi Henrik, IMHO deploy-file (just like install-file) should *never* be a part of a lifecycle, but should be run standalone and should only be used for unavailable third party artifacts. Looking back at your pom-fragment, you should do the following: * if deploymentfile is being created by a Maven plugin, try to make that plugin attach that file to the project. * Use http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.htmland remove the deploy-file asap. This plugin does it's work as part of the build lifecycle as it should be. Robert Op Sun, 16 Feb 2014 11:20:39 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Hi Robert Thank you for your answer. I would like to figure out how to simple skip the generation of the given extra zip file because I do not know how now. Any way to see during debug which goal will result in which artifact? Any help on finding out when running my build will be appreciated. I can not omit what I do not know to control nor can I not attach it when I do no what generates it. Not creating or attaching the artifact solves the problem - but still, as user of maven I still say that it is counter intuitive to have the deploy-file goal not only deploy the specified file. The deploy goal should deploy all - but not the deploy-file goal. :) I know that is a different discussion about meaningful naming of APIs and frankly I don't care now that I know. But maven developers should care about simplifying and make maven APIs intuitive since maven is not exactly gaining ground due to it's simplicity and transparency. ;) That being said, I have been using maven for a looong time and enjoy it most of the time - so keep up the good work! regards Henrik Skriver Rasmussen On Sun, Feb 16, 2014 at 2:03 PM, Robert Scholte rfscho...@apache.org wrote: Op Sun, 16 Feb 2014 08:15:25 +0100 schreef Henrik Skriver Rasmussen skrive...@gmail.com: Thanks for the advice on how to restructure. Could you have a look at the deploy-plugin project and the file org.apache.maven.plugin.deploy.DeployFileMojo execute method line 376 in version 2.8.1 ? I would really like to understand the following: 1) What controls which artifacts are attached the model for the given project? The plugin creating that artifact controls the attaching. For example: http://maven.apache.org/plugins/maven-source-plugin/ xref/org/apache/maven/plugin/source/AbstractSourceJarMojo.html#307 Here the -sources.jar is attached to the project. 2) Is it possible to state that no artifacts except explicitly stated should be created/attached? The plugin creating that artifact 3) Is it really the intended behaviour of the deploy:file goal to also deploy the attached artifacts? To me that is a very non-intuitive behaviour. Yes. If there are attachments created and these are attached, they are uploaded as well. So if you don't want this, solve it at the source, i.e the plugin creating the artifact. (for the maven-source-plugin: skip it (best option) or just don't attach (acceptable option) ) For the same reason you won't find delete options in any of the plugins. It is a matter of excluding the correct files. Robert I Basically have a working setup which deploys the zip file I generate to repo with the name I have specified. But the only thing that bothers me is that for some unclear reason the same zip is deployed again with the name of the project in the same deploy:file goal. To me - that is a bug. Should I open an issue instead somewhere and provide the patch which fixes this?? I already mailed the email listed in the top of the java file in question but he does not reply. Med venlig hilsen Henrik Skriver Rasmussen On Thu, Feb 13, 2014 at 2:54 PM, Anders Hammar and...@hammar.net wrote: You should really restart with the module 2 pom. Your multi-module structure is good. You have a separate projekt/module which creates your distro. What you should do is to create the distro (zip or whatever) to be created as part of the normal build and then deployed as the project's artifact it is. This is done in many projects and you could for example have a look at the Maven core project where we create a zip and a tar file.
Re: Looking for org.apache.poi 3.10-FINAL
Hi Stuart, thanks for that very useful information. Are you using the default repo? (http://repo.maven.apache.org/maven2) All the best, DaveLaw On 16.02.2014 14:36, Stuart McCulloch wrote: On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote: Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. FWIW, I did a search today for org.apache.poi:poi in my local m2e and 3.10-FINAL appeared - so it's definitely in the index from the 15th (which is the index downloaded on my local computer according to the file under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it was indexed... You could always post a question on https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive answer of what happened, when, and why. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why does Maven fail to compile my project occasionally?
Thanks for your suggestion. But I don't think it's the Jenkins fault because: I've written a Windows batch file to invoke Maven to build the project before I choose Jenkins as my daily build system. And at that time I got the same Maven error as I described in this thread. I'll post some other source code and POM files later. Please help me to diagnose my problem then. Thanks. P.S: I'll diagnose my POM configuration of package dependency, and I'll post the result here tomorrow. On Sun, Feb 16, 2014 at 2:59 AM, stephenconnolly [via Maven] ml-node+s40175n5785002...@n5.nabble.com wrote: http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html Using the evil one makes Maven behave in ways that it doesn't intend to... Please try with a FreeStyle job using a Maven Build step to see if it is the evil job type causing issues for you -- Levski Weng -- View this message in context: http://maven.40175.n5.nabble.com/Why-does-Maven-fail-to-compile-my-project-occasionally-tp5784849p5785057.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Looking for org.apache.poi 3.10-FINAL
On 16 February 2014 14:36, David Law m2ecli...@apconsult.de wrote: Hi Stuart, thanks for that very useful information. Are you using the default repo? (http://repo.maven.apache.org/maven2) I switch depending what workspace I'm using, as I have a corporate repo as well as a local nexus instance (enabled to download remote indexes) But I just tried from a fresh installation with the default repo to confirm and it is in the latest index with nexus.index.timestamp=20140216125157.106 All the best, DaveLaw On 16.02.2014 14:36, Stuart McCulloch wrote: On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote: Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. FWIW, I did a search today for org.apache.poi:poi in my local m2e and 3.10-FINAL appeared - so it's definitely in the index from the 15th (which is the index downloaded on my local computer according to the file under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it was indexed... You could always post a question on https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive answer of what happened, when, and why. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw -- Cheers, Stuart
Re: Why does Maven fail to compile my project occasionally?
I've written a Windows batch file to invoke Maven to build the project before I choose Jenkins as my daily build system. And at that time I got the same Maven error as I described in this thread. Maven calls out to your system JDK to do the compilation step. With the [ERROR] lines you provided previously, Maven is simply passing along the error that was reported by javac. I bet, if you constructed the proper javac call (which can be seen in Maven's logs if you use -X for debug mode), you would see the same error produced without involving Maven (or Jenkins) at all. IIRC you had some cannot find symbol errors. What do you expect Maven to do about code defects reported by the Java compiler? Why are you blaming Maven for this? I'll post some other source code and POM files later. Please help me to diagnose my problem then. Thanks. Please don't try to send attachments or huge logs, source code, pom files to the list. Instead post it to Pastebin or Gist and send us a link. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why does Maven fail to compile my project occasionally?
Is it possible that you have more than 1 version of Java installed? I use Eclipse/STS, have all the Maven tools that I need to build with Maven so I may suggest some things that you may not have, with m2 installed separately. 1) Look in the project properties and make sure that you have nothing specified as a library besides Maven dependencies. (libraries might be configured in Eclipse that you are not setting in other builds) 2) Make sure that you do not allow Eclipse to use other project workspaces for resolution of dependencies.(Eclipse will look in other eclipse projects to find dependencies). 3) Make sure that you are using the right java compiler from Eclipse. It is easy to get different compilers in play. If you do all this, you may find that your Eclipse build fails in the same way that your other builds fail. You can then fix them both up to be the same. I hope that this helps. Ron n 16/02/2014 10:15 AM, LevskiWeng wrote: Thanks for your suggestion. But I don't think it's the Jenkins fault because: I've written a Windows batch file to invoke Maven to build the project before I choose Jenkins as my daily build system. And at that time I got the same Maven error as I described in this thread. I'll post some other source code and POM files later. Please help me to diagnose my problem then. Thanks. P.S: I'll diagnose my POM configuration of package dependency, and I'll post the result here tomorrow. On Sun, Feb 16, 2014 at 2:59 AM, stephenconnolly [via Maven] ml-node+s40175n5785002...@n5.nabble.com wrote: http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html Using the evil one makes Maven behave in ways that it doesn't intend to... Please try with a FreeStyle job using a Maven Build step to see if it is the evil job type causing issues for you -- Levski Weng -- View this message in context: http://maven.40175.n5.nabble.com/Why-does-Maven-fail-to-compile-my-project-occasionally-tp5784849p5785057.html Sent from the Maven - Users mailing list archive at Nabble.com. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
Hi Stuart, thanks once again! The only person to supply useful information. I checked the Nexus Index Timestamp from the repo this morning 05:39 CET and: nexus.index.timestamp=20140209134945.568 + Over 6 days old!! Just checked it again and: nexus.index.timestamp=20140216125157.106 + And, not surprisingly, my m2eclipse can now find the artifact. So that means maven central took over 6 days to index this content. That is quite incredible! This is in my opinion a bug, or at least a fundamental design error. Thank you once again. All the best, DaveLaw On 16.02.2014 16:20, Stuart McCulloch wrote: On 16 February 2014 14:36, David Law m2ecli...@apconsult.de wrote: Hi Stuart, thanks for that very useful information. Are you using the default repo? (http://repo.maven.apache.org/maven2) I switch depending what workspace I'm using, as I have a corporate repo as well as a local nexus instance (enabled to download remote indexes) But I just tried from a fresh installation with the default repo to confirm and it is in the latest index with nexus.index.timestamp=20140216125157.106 All the best, DaveLaw On 16.02.2014 14:36, Stuart McCulloch wrote: On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote: Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. FWIW, I did a search today for org.apache.poi:poi in my local m2e and 3.10-FINAL appeared - so it's definitely in the index from the 15th (which is the index downloaded on my local computer according to the file under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it was indexed... You could always post a question on https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive answer of what happened, when, and why. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
On Sunday, 16 February 2014, David Law m2ecli...@apconsult.de wrote: Hi Stuart, thanks once again! The only person to supply useful information. I checked the Nexus Index Timestamp from the repo this morning 05:39 CET and: nexus.index.timestamp=20140209134945.568 + Over 6 days old!! Just checked it again and: nexus.index.timestamp=20140216125157.106 + And, not surprisingly, my m2eclipse can now find the artifact. So that means maven central took over 6 days to index this content. That is quite incredible! I would suggest you take this issue up with Sonatype, who maintain central and it's indexing Also before completely blaming Sonatype I would suggest you find out exactly when POI released the staging repo on repository.a.o as it only gets synced to central IIRC up to 8h after being promoted on the ASF nexus instance This is in my opinion a bug, or at least a fundamental design error. Thank you once again. All the best, DaveLaw On 16.02.2014 16:20, Stuart McCulloch wrote: On 16 February 2014 14:36, David Law m2ecli...@apconsult.de wrote: Hi Stuart, thanks for that very useful information. Are you using the default repo? (http://repo.maven.apache.org/maven2) I switch depending what workspace I'm using, as I have a corporate repo as well as a local nexus instance (enabled to download remote indexes) But I just tried from a fresh installation with the default repo to confirm and it is in the latest index with nexus.index.timestamp= 20140216125157.106 All the best, DaveLaw On 16.02.2014 14:36, Stuart McCulloch wrote: On 16 February 2014 10:31, David Law m2ecli...@apconsult.de wrote: Hi Mirko, I think though 6 days!!! should be adequate for that. In fact, I think 6 minutes should be adequate. So I really need someone to explain how I can move forward with this issue. FWIW, I did a search today for org.apache.poi:poi in my local m2e and 3.10-FINAL appeared - so it's definitely in the index from the 15th (which is the index downloaded on my local computer according to the file under .metadata/.plugins/org.eclipse.m2e.core/nexus), but not sure when it was indexed... You could always post a question on https://issues.sonatype.org/browse/MVNCENTRAL if you want a definitive answer of what happened, when, and why. All the best, DaveLaw On 16.02.2014 10:49, Mirko Friedenhagen wrote: David, just guessing: - indexing takes it's time, there are only two hours difference between the commit (??l and end of indexing. - commit (tag creation), artifact creation (jar build), deployment (upload to staging), promotion (move of staged to released) and synchronization from oss.sonatype.org to repo1 add delays :-) Regards Mirko On 16.02.2014 09:43, David Law wrote: Hi, I'm new to maven thought I'd try it out on the recently checked-in: org.apache.poi3.10-FINAL I'm using m2eclipse standard config with Eclipse Kepler. Repo defaults to: http://repo.maven.apache.org/maven2 The Problem: m2eclipse does not know the org.apache.poi 3.10-FINAL artifact. Now, I guess the problem could be any combination of: a) me b) POI c) maven d) m2eclipse e) eclipse? QUESTION) Can anyone help to localise it? Here's what I've found out so far: 0) repo is: http://repo.maven.apache.org/maven2 1) org.apache.poi 3.10-FINAL was committed @ 09-Feb-2014 11:50 2) as of now repo Timestamp is: 09-Feb-2014 13:50 (nexus.index.timestamp=20140209134945.568 +) (found in http://repo.maven.apache.org/maven2/.index/nexus-maven- repository-index.properties) 3) - so repo has been reindexed since org.apache.poi 3.10-FINAL commit (6 days ago). 4) exit eclipse 5) deleted the index C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse. m2e.core\nexus 6) start eclipse - updating index 7) org.apache.poi 3.10-FINAL is still not there (that is: here) in my list of artifacts All the best, DaveLaw - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Sent from my phone
Re: Looking for org.apache.poi 3.10-FINAL
thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
And it's just an index. You can always download the artifact without it. And as far as I know, the downloadable central index has always only been updated once a week. Have a look here: http://repo1.maven.org/maven2/.index/ /Anders On Sun, Feb 16, 2014 at 9:52 PM, Wayne Fay wayne...@gmail.com wrote: thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
Anders, Tack för det. Dave On 16.02.2014 22:03, Anders Hammar wrote: And it's just an index. You can always download the artifact without it. And as far as I know, the downloadable central index has always only been updated once a week. Have a look here: http://repo1.maven.org/maven2/.index/ /Anders On Sun, Feb 16, 2014 at 9:52 PM, Wayne Fay wayne...@gmail.com wrote: thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. 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: Looking for org.apache.poi 3.10-FINAL
Hi Wayne, I would suggest someone documents the behaviour in the FAQ with a tip that a not-yet-indexed artifact can be proactively retrieved by entering its Group Id, Artifact Id Version. That way we all save time. All the best, DaveLaw On 16.02.2014 21:52, Wayne Fay wrote: thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. 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
[ANN] Apache Maven Plugin Testing 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Plugin Testing, version 3.1.0 The Maven Plugin Testing contains the necessary tools to be able to test Maven Plugins. http://maven.apache.org/plugin-testing/ You should specify the version in your project's dependency configuration: dependency groupIdorg.apache.maven.plugin-testing/groupId artifactIdmaven-plugin-testing-harness/artifactId version3.1.0/version /dependency Release Notes - Maven Plugin Testing - Version 3.1.0 ** Improvement * [MPLUGINTESTING-36] - Helpers to manage test projects * [MPLUGINTESTING-37] - Provide convenince methods to work with MavenProject Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
adding repository url
Hi there , I have this dependency present in my pom.xml . dependency groupIdorg.apache.solr/groupId artifactIdsolr-cell/artifactId version4.0/version /dependency However , while trying to mvn install results in buil error because this dependency isn't resolved successfully. I tried hunting for the respository url which can fetch this dependency for me, but all was in vain. However, i found pm.xml files for this dependency.I don't know, but can I link this pom with my pom.xml which is present in my code to resolve dependency ? Or what i should do ? -- View this message in context: http://maven.40175.n5.nabble.com/adding-repository-url-tp5784961.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: adding repository url
On 15 February 2014 11:13, 454329 abhi454...@gmail.com wrote: Hi there , I have this dependency present in my pom.xml . dependency groupIdorg.apache.solr/groupId artifactIdsolr-cell/artifactId version4.0/version Did a quick search for solr-cell on http://search.maven.org/ and I suspect the version above should be 4.0.0, not 4.0... /dependency However , while trying to mvn install results in buil error because this dependency isn't resolved successfully. I tried hunting for the respository url which can fetch this dependency for me, but all was in vain. However, i found pm.xml files for this dependency.I don't know, but can I link this pom with my pom.xml which is present in my code to resolve dependency ? Or what i should do ? -- View this message in context: http://maven.40175.n5.nabble.com/adding-repository-url-tp5784961.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Cheers, Stuart
Re: Looking for org.apache.poi 3.10-FINAL
Sure, but which FAQ should this go in - a generic Maven faq, a faq specific to m2eclipse (bear in mind, this group has zero control over m2e), or a FAQ related to Central? Or all of those places? Where did you look (in the Maven website docs) for such information, prior to posting your email to this list? It may not sound like it but I am genuinely curious where this information should go to ensure the right people can see/find it when they need to know such information. Wayne On Sun, Feb 16, 2014 at 4:43 PM, David Law m2ecli...@apconsult.de wrote: Hi Wayne, I would suggest someone documents the behaviour in the FAQ with a tip that a not-yet-indexed artifact can be proactively retrieved by entering its Group Id, Artifact Id Version. That way we all save time. All the best, DaveLaw On 16.02.2014 21:52, Wayne Fay wrote: thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Looking for org.apache.poi 3.10-FINAL
http://stackoverflow.com/questions/10600576/nexus-index-of-maven-central-is-not-up-to-date-new-installation The problem appears to be well known but is not something that one expects and it will be hard to know where people are most likely to look. It is not really a Maven problem and as I understand it, if you just set your dependencies and build, you will not see the problem or be affected by it. If you are trying to use your own repository's proxy to Maven Central to quickly find the latest version rather than visiting the website of the developer of the library, you will have trouble. If you go to directly to searching Maven Central, you will not have the problem. It seems that you need to separate the problem from the point where the user will run into it. The most likely place to look for it is in Maven since that is where one might read documentation about setting up dependencies, even if it has nothing to do with Maven. http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_external_dependencies is probably the most likely place to see a note about browsing Maven Central It most likely could go somewhere in this paragraph: quote What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the various plugins used to build the project). By default, the remote repository Maven uses can be found (and browsed) athttp://repo.maven.apache.org/maven2/. You can also set up your own remote repository (maybe a central repository for your company) to use instead of or in addition to the default remote repository. For more information on repositories you can refer to theIntroduction to Repositories http://maven.apache.org/guides/introduction/introduction-to-repositories.html. /quote It would still be an odd notation and might still be hard to find, given the initial analysis that a new Maven user would have of the apparent problem. I am not sure what the cost of creating a new index is, but perhaps it could be done more frequently. I also do not understand how the index is propagated to my proxy for Maven Central in my Nexus repo but I still don't see the latest POI either ( my Nexus is very old so perhaps the problem is at my end) Ron On 16/02/2014 6:31 PM, Wayne Fay wrote: Sure, but which FAQ should this go in - a generic Maven faq, a faq specific to m2eclipse (bear in mind, this group has zero control over m2e), or a FAQ related to Central? Or all of those places? Where did you look (in the Maven website docs) for such information, prior to posting your email to this list? It may not sound like it but I am genuinely curious where this information should go to ensure the right people can see/find it when they need to know such information. Wayne On Sun, Feb 16, 2014 at 4:43 PM, David Law m2ecli...@apconsult.de wrote: Hi Wayne, I would suggest someone documents the behaviour in the FAQ with a tip that a not-yet-indexed artifact can be proactively retrieved by entering its Group Id, Artifact Id Version. That way we all save time. All the best, DaveLaw On 16.02.2014 21:52, Wayne Fay wrote: thanks once again! The only person to supply useful information. ... Over 6 days old!! ... So that means maven central took over 6 days to index this content. That is quite incredible! ... This is in my opinion a bug, or at least a fundamental design error. Also before completely blaming Sonatype I would suggest you find out You may also want to lose some of the attitude. No one here is getting paid (by you) to do what we're doing -- in fact Sonatype has spent a considerable amount of money building and maintaining Central over the years. Attacking them (or those on this list) because you couldn't use the latest POI immediately after it was released seems like a bad move. You catch more flies with honey and all that. 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Why does Maven fail to compile my project occasionally?
Robert Scholte-4 wrote
My code is correct because I could successfully build the whole project
in Eclipse again and again.
This is 100% true. Within Eclipse you can manually add libraries.
Actually, if you create your first JUnit test, Eclipse will ask if the
JUnit4 library should be added. If you do so, it's added as an Eclipse
library, but your Maven build won't have junit as a dependency, resulting
in uncompilable tests.
I'm add all necessary dependent libraries that I know in pom.xml. It looks
weird and I've no idea about it. Could you help me to diagnose the problem
further?
Robert Scholte-4 wrote
Did you open this file?
AgentIdResourceMapIpHandle.java:[36,24] refers to line 36, column 24. Just
open that file with notepad (copy/paste the fully qualified path to ensure
you're picking up the correct file, not some copy)
Where is that symbol/Class coming from? It seems to be on the classpath
of your Eclipse, but it is not a dependency for Maven.
Robert
I guess I've declared all dependent packages in the pom.xml.
The content of AgentIdResourceMapIpHandle.java is: (I omit the unimportant
lines)
package com.xxx.system.devicecenter.network;
import com.xxx.system.common.ResourceTypeDef;
import com.xxx.system.network.IResourceMapIpHandle;
// Imports some other packages...
public class AgentIdResourceMapIpHandle implements IResourceMapIpHandle {
@Override
public Integer getType() {
return ResourceTypeDef.TYPE_AGENT_ID;
}
// Implements other methods declared in interface
IResourceMapIpHandle...
}
And the content of the pom.xml for com.xxx.system.devicecenter is:
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;
modelVersion
4.0.0
/modelVersion
parent
artifactId
systempom
/artifactId
groupId
com.xxx.system
/groupId
version
1.0.0
/version
/parent
groupId
com.xxx.system
/groupId
artifactId
devicecenter
/artifactId
version
1.0.0-SNAPSHOT
/version
dependencies
dependency
groupId
com.xxx.system
/groupId
artifactId
network
/artifactId
version
1.1.0
/version
/dependency
/dependencies
build
plugins
plugin
artifactId
maven-release-plugin
/artifactId
version
2.3.1
/version
configuration
tagBase
https://192.168.49.48:8443/svn/cms/tag/cdms_plugins/com.xxx.core/com.xxx.core.jettyweb
/tagBase
useReleaseProfile
false
/useReleaseProfile
/configuration
/plugin
plugin
artifactId
maven-antrun-plugin
/artifactId
/plugin
plugin
artifactId
maven-dependency-plugin
/artifactId
/plugin
plugin
artifactId
maven-source-plugin
/artifactId
/plugin
plugin
groupId
org.apache.maven.plugins
/groupId
artifactId
maven-jar-plugin
/artifactId
version
2.3.1
/version
executions
execution
phase
package
/phase
/execution
/executions
configuration
archive
manifestEntries
Active
com.xxx.core.web.PluginActive
/Active
/manifestEntries
/archive
/configuration
/plugin
/plugins
resources
resource
directory
src/main/java/
/directory
includes
include
**/*.xml
/include
/includes
/resource
resource
directory
src/main/resources/
/directory
includes
Re: Looking for org.apache.poi 3.10-FINAL
Ron, Wayne, this wasted several days (elapsed) of my time: I spent ages trying out options trying to figure out what I'd done wrong... ...rebuilding updating indices, hacking through to workspace\.metadata\.plugins\org.eclipse.m2e.logback.configuration, to set logging to ALL, but even ALL was somewhat sparse. I tried Google found loads of hits that had nothing to do with it. I found nothing at apache maven or maven central or m2eclipse. I tried the POI Forum, but it became clear that wasn't the problem. As Wayne rightly points out where is the right place to document it?. With a complex issue like this with multiple components where do you start? But thats all the more reason to document it somewhere... Right now it seems to me not to be a maven problem as such. Its about how maven central creates its indices how m2e uses them. So in theory it needs to be documented in both, correspondingly cross-referenced. But as the m2e FAQ is subscription-only it would seem the only place is the maven central FAQ. And its so important, it should be a point in its own right: Why can't I see new artifacts in my client (e.g. m2eclipse)? (Tip - you can get as-yet-unindexed artifacts explicitly...blah, blah) And then there's the question, why does m2e use the high-latency index? If its performance/server-load, then it could be a rethink of the index-structure is necessary. Is that a maven issue? I have some ideas there... All the best, DaveLaw On 17/02/2014 00:56, Ron Wheeler wrote: http://stackoverflow.com/questions/10600576/nexus-index-of-maven-central-is-not-up-to-date-new-installation The problem appears to be well known but is not something that one expects and it will be hard to know where people are most likely to look. It is not really a Maven problem and as I understand it, if you just set your dependencies and build, you will not see the problem or be affected by it. If you are trying to use your own repository's proxy to Maven Central to quickly find the latest version rather than visiting the website of the developer of the library, you will have trouble. If you go to directly to searching Maven Central, you will not have the problem. It seems that you need to separate the problem from the point where the user will run into it. The most likely place to look for it is in Maven since that is where one might read documentation about setting up dependencies, even if it has nothing to do with Maven. http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_external_dependencies is probably the most likely place to see a note about browsing Maven Central It most likely could go somewhere in this paragraph: quote What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the various plugins used to build the project). By default, the remote repository Maven uses can be found (and browsed) athttp://repo.maven.apache.org/maven2/. You can also set up your own remote repository (maybe a central repository for your company) to use instead of or in addition to the default remote repository. For more information on repositories you can refer to theIntroduction to Repositories http://maven.apache.org/guides/introduction/introduction-to-repositories.html. /quote It would still be an odd notation and might still be hard to find, given the initial analysis that a new Maven user would have of the apparent problem. I am not sure what the cost of creating a new index is, but perhaps it could be done more frequently. I also do not understand how the index is propagated to my proxy for Maven Central in my Nexus repo but I still don't see the latest POI either ( my Nexus is very old so perhaps the problem is at my end) Ron On 16/02/2014 6:31 PM, Wayne Fay wrote: Sure, but which FAQ should this go in - a generic Maven faq, a faq specific to m2eclipse (bear in mind, this group has zero control over m2e), or a FAQ related to Central? Or all of those places? Where did you look (in the Maven website docs) for such information, prior to posting your email to this list? It may not sound like it but I am genuinely curious where this information should go to ensure the right people can see/find it when they need to know such information. Wayne On Sun, Feb 16, 2014 at 4:43 PM, David Law m2ecli...@apconsult.de wrote: Hi Wayne, I would suggest someone documents the behaviour in the FAQ with a tip that a not-yet-indexed artifact can be proactively retrieved by entering its Group Id, Artifact Id Version. That way we all save time. All the best, DaveLaw On 16.02.2014 21:52, Wayne Fay wrote: thanks once again! The only person to supply useful information. ...
