Ok, I have a clean AS trunk tree plus I deleted the whole of my m2 repo (to avoid a ridiculous numbers of failed downloads due to checksum errors -- that's not supposed to happen with maven is it?). I still get a build error: /ssd/home/adinn/jboss/jbossas/trunk/build/build.xml:1415: /ssd/home/adinn/jboss/jbossas/trunk/tomcat/target/deploy/jsf.deployer does not exist/. Any explanation? regards, Andrew Dinn ----------- _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> Some of us had seen the checksum errors (there's a mail in this dev > list) too. It kept slowing down the build, but I ignored it. As for the > other error you are seeing, could you post the build logs? And what > command do you use to build the trunk? From what I know, the recommended > way is to mvn clean install from the trunk root. > > P.S: I think we should really have the hudson.qa instances build the AS > trunk against a clean repo using the *public* repo. Right now, it's just > a false impression that the AS trunk is building fine. I initially used bash build.sh in the build directory. However, after posting I retried using mvn clean install and the source of the problem became more evident: [INFO] [dependency:unpack {execution: unpack}] [INFO] Configured Artifact: org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Unable to find artifact. Embedded error: Unable to download the artifact from any repository I assume this is why the deployer was not found. regards, Andrew Dinn -----------

As an aside, are SNAPSHOT dependencies of non-AS modules, like this one, allowed in AS trunk?

-Jaikiran Stan Silvert wrote: > Just a guess, but maybe your settings.xml is not set up for the JBoss > snapshot repo? > http://community.jboss.org/wiki/MavenGettingStarted-Developers > > Andrew Dinn wrote: >> > Some of us had seen the checksum errors (there's a mail in this dev >> > list) too. It kept slowing down the build, but I ignored it. As >> for the >> > other error you are seeing, could you post the build logs? And what >> > command do you use to build the trunk? From what I know, the >> recommended >> > way is to mvn clean install from the trunk root. >> > >> > P.S: I think we should really have the hudson.qa instances build >> the AS >> > trunk against a clean repo using the *public* repo. Right now, >> it's just >> > a false impression that the AS trunk is building fine. >> >> I initially used bash build.sh in the build directory. However, >> after posting I retried using mvn clean install and the source of >> the problem became more evident: >> >> [INFO] [dependency:unpack {execution: unpack}] >> [INFO] Configured Artifact: >> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >> [INFO] >> ------------------------------------------------------------------------ >> >> [ERROR] BUILD ERROR >> [INFO] >> ------------------------------------------------------------------------ >> >> [INFO] Unable to find artifact. >> >> Embedded error: Unable to download the artifact from any repository >> >> I assume this is why the deployer was not found. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >> > >

Hi Stan, Stan Silvert wrote: > This is an AS module. Is there some reason I need to do a release at > this point in development? That's rather time-consuming. I wasn't > planning to do a release until we get closer to code freeze. By AS module, I meant, a module within the AS/trunk project hierarchy. The jboss-jsf-int appears to be a separate project with its own release cycle http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk. The reason, that I am aware of, for restricting (non-timestamped) SNAPSHOT dependencies of such artifacts is because they are not reliable. You never really know which SNAPSHOT you are testing against. I however don't know if this policy has changed now. regards, -Jaikiran >> >> -Jaikiran >> Stan Silvert wrote: >>> Just a guess, but maybe your settings.xml is not set up for the >>> JBoss snapshot repo? >>> http://community.jboss.org/wiki/MavenGettingStarted-Developers >>> >>> Andrew Dinn wrote: >>>> > Some of us had seen the checksum errors (there's a mail in this dev >>>> > list) too. It kept slowing down the build, but I ignored it. As >>>> for the >>>> > other error you are seeing, could you post the build logs? And what >>>> > command do you use to build the trunk? From what I know, the >>>> recommended >>>> > way is to mvn clean install from the trunk root. >>>> > >>>> > P.S: I think we should really have the hudson.qa instances build >>>> the AS >>>> > trunk against a clean repo using the *public* repo. Right now, >>>> it's just >>>> > a false impression that the AS trunk is building fine. >>>> >>>> I initially used bash build.sh in the build directory. However, >>>> after posting I retried using mvn clean install and the source of >>>> the problem became more evident: >>>> >>>> [INFO] [dependency:unpack {execution: unpack}] >>>> [INFO] Configured Artifact: >>>> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> >>>> [ERROR] BUILD ERROR >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> >>>> [INFO] Unable to find artifact. >>>> >>>> Embedded error: Unable to download the artifact from any repository >>>> >>>> I assume this is why the deployer was not found. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> >>>> >>> >>> >> > > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Just a guess, but maybe your settings.xml is not set up for the JBoss snapshot repo? http://community.jboss.org/wiki/MavenGettingStarted-Developers

No they are most definitely NOT! On Jun 4, 2010, at 7:44 AM, Jaikiran Pai wrote: > As an aside, are SNAPSHOT dependencies of non-AS modules, like this one, > allowed in AS trunk? > > -Jaikiran > Stan Silvert wrote: > >> Just a guess, but maybe your settings.xml is not set up for the JBoss >> snapshot repo? >> http://community.jboss.org/wiki/MavenGettingStarted-Developers >> >> Andrew Dinn wrote: >> >>>> Some of us had seen the checksum errors (there's a mail in this dev >>>> list) too. It kept slowing down the build, but I ignored it. As >>>> >>> for the >>> >>>> other error you are seeing, could you post the build logs? And what >>>> command do you use to build the trunk? From what I know, the >>>> >>> recommended >>> >>>> way is to mvn clean install from the trunk root. >>>> >>>> P.S: I think we should really have the hudson.qa instances build >>>> >>> the AS >>> >>>> trunk against a clean repo using the *public* repo. Right now, >>>> >>> it's just >>> >>>> a false impression that the AS trunk is building fine. >>>> >>> I initially used bash build.sh in the build directory. However, after >>> posting I retried using mvn clean install and the source of the >>> problem became more evident: >>> >>> [INFO] [dependency:unpack {execution: unpack}] >>> [INFO] Configured Artifact: >>> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >>> [INFO] >>> ------------------------------------------------------------------------ >>> [ERROR] BUILD ERROR >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] Unable to find artifact. >>> >>> Embedded error: Unable to download the artifact from any repository >>> >>> I assume this is why the deployer was not found. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> >>> >>> >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

One main reason: it makes test suite failures impossible to replicate reliably. Unless you create *versioned* snapshots (e.g. with a specific version like -20100604 or something) then the same AS revision can yield different results depending on what snapshot is out there at the moment. If you use fixed versions, and something breaks, you can point to the diff and say "this change cause it to break". With a snapshot, it can work initially and then break later, causing the wrong changes to be scrutinized. On 06/04/2010 10:48 AM, Stan Silvert wrote: > Let's talk about this then. > > It seems to me that this is exactly what snapshots are for. Releases > are a pain. Snapshots are quick and easy. When you are doing > development and things are changing rapidly, use a snapshot. When you > have something stable that's ready for an AS release, do a release. > > What was the reason for making snapshots verboten? I understand that we > can't have snapshots in a release, and we obviously can't use > third-party snapshots. But using them for sub-modules is beneficial in > the development phase. That's what snapshots are for, right? > > If I had know this I probably would have done all the development in > trunk. Maybe I should move it there? > > Stan > > Jason Greene wrote: >> No they are most definitely NOT! >> >> On Jun 4, 2010, at 7:44 AM, Jaikiran Pai wrote: >> >> >>> As an aside, are SNAPSHOT dependencies of non-AS modules, like this >>> one, >>> allowed in AS trunk? >>> >>> -Jaikiran >>> Stan Silvert wrote: >>> >>>> Just a guess, but maybe your settings.xml is not set up for the JBoss >>>> snapshot repo? >>>> http://community.jboss.org/wiki/MavenGettingStarted-Developers >>>> >>>> Andrew Dinn wrote: >>>> >>>>>> Some of us had seen the checksum errors (there's a mail in this dev >>>>>> list) too. It kept slowing down the build, but I ignored it. As >>>>>> >>>>> for the >>>>> >>>>>> other error you are seeing, could you post the build logs? And what >>>>>> command do you use to build the trunk? From what I know, the >>>>>> >>>>> recommended >>>>> >>>>>> way is to mvn clean install from the trunk root. >>>>>> >>>>>> P.S: I think we should really have the hudson.qa instances build >>>>>> >>>>> the AS >>>>> >>>>>> trunk against a clean repo using the *public* repo. Right now, >>>>>> >>>>> it's just >>>>> >>>>>> a false impression that the AS trunk is building fine. >>>>>> >>>>> I initially used bash build.sh in the build directory. However, >>>>> after >>>>> posting I retried using mvn clean install and the source of the >>>>> problem became more evident: >>>>> >>>>> [INFO] [dependency:unpack {execution: unpack}] >>>>> [INFO] Configured Artifact: >>>>> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> >>>>> [ERROR] BUILD ERROR >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> >>>>> [INFO] Unable to find artifact. >>>>> >>>>> Embedded error: Unable to download the artifact from any repository >>>>> >>>>> I assume this is why the deployer was not found. >>>>> >>>>> regards, >>>>> >>>>> >>>>> Andrew Dinn >>>>> ----------- >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development

Yes exactly. To them you just do a release following the milsestone timestamp version convention e.g jboss-jsf-3.4.5-20100603-M3 etc On Jun 4, 2010, at 11:03 AM, Stan Silvert wrote: > So am I OK if I use versioned snapshots? Sounds like that's the best of both worlds. > > David M. Lloyd wrote: >> One main reason: it makes test suite failures impossible to replicate reliably. Unless you create *versioned* snapshots (e.g. with a specific version like -20100604 or something) then the same AS revision can yield different results depending on what snapshot is out there at the moment. >> >> If you use fixed versions, and something breaks, you can point to the diff and say "this change cause it to break". With a snapshot, it can work initially and then break later, causing the wrong changes to be scrutinized. >> >> On 06/04/2010 10:48 AM, Stan Silvert wrote: >>> Let's talk about this then. >>> >>> It seems to me that this is exactly what snapshots are for. Releases >>> are a pain. Snapshots are quick and easy. When you are doing >>> development and things are changing rapidly, use a snapshot. When you >>> have something stable that's ready for an AS release, do a release. >>> >>> What was the reason for making snapshots verboten? I understand that we >>> can't have snapshots in a release, and we obviously can't use >>> third-party snapshots. But using them for sub-modules is beneficial in >>> the development phase. That's what snapshots are for, right? >>> >>> If I had know this I probably would have done all the development in >>> trunk. Maybe I should move it there? >>> >>> Stan >>> >>> Jason Greene wrote: >>>> No they are most definitely NOT! >>>> >>>> On Jun 4, 2010, at 7:44 AM, Jaikiran Pai wrote: >>>> >>>> >>>>> As an aside, are SNAPSHOT dependencies of non-AS modules, like this one, >>>>> allowed in AS trunk? >>>>> >>>>> -Jaikiran >>>>> Stan Silvert wrote: >>>>> >>>>>> Just a guess, but maybe your settings.xml is not set up for the JBoss >>>>>> snapshot repo? >>>>>> http://community.jboss.org/wiki/MavenGettingStarted-Developers >>>>>> >>>>>> Andrew Dinn wrote: >>>>>> >>>>>>>> Some of us had seen the checksum errors (there's a mail in this dev >>>>>>>> list) too. It kept slowing down the build, but I ignored it. As >>>>>>>> >>>>>>> for the >>>>>>> >>>>>>>> other error you are seeing, could you post the build logs? And what >>>>>>>> command do you use to build the trunk? From what I know, the >>>>>>>> >>>>>>> recommended >>>>>>> >>>>>>>> way is to mvn clean install from the trunk root. >>>>>>>> >>>>>>>> P.S: I think we should really have the hudson.qa instances build >>>>>>>> >>>>>>> the AS >>>>>>> >>>>>>>> trunk against a clean repo using the *public* repo. Right now, >>>>>>>> >>>>>>> it's just >>>>>>> >>>>>>>> a false impression that the AS trunk is building fine. >>>>>>>> >>>>>>> I initially used bash build.sh in the build directory. However, after >>>>>>> posting I retried using mvn clean install and the source of the >>>>>>> problem became more evident: >>>>>>> >>>>>>> [INFO] [dependency:unpack {execution: unpack}] >>>>>>> [INFO] Configured Artifact: >>>>>>> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >>>>>>> [INFO] >>>>>>> ------------------------------------------------------------------------ >>>>>>> [ERROR] BUILD ERROR >>>>>>> [INFO] >>>>>>> ------------------------------------------------------------------------ >>>>>>> [INFO] Unable to find artifact. >>>>>>> >>>>>>> Embedded error: Unable to download the artifact from any repository >>>>>>> >>>>>>> I assume this is why the deployer was not found. >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> >>>>>>> Andrew Dinn >>>>>>> ----------- >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> > >

Sorry, versioned SNAPs are generally not OK. :D Ill clarify: it *may* be OK, maybe, if the AS component-matrix/pom accounts for all transitive dependencies and locks them to fixed snapshot versions. "mvn deploy" on a SNAPSHOT will not require/ask you to resolve all transitive dependencies, so even if you have jboss-jsf-3.4.5-20100603-M3 declared, it could leak in something like jboss-common:1.0.0-SNAPSHOT. Unless the depMgt of AS is set to lock in jboss-common to a real version, the unversioned SNAP leaks in. In short, ensure nothing leaks before committing. :) In practice the AS component-matrix should be defining *all* versions for everything anyway. depchain> mvn dependency:tree |grep SNAPSHOT S, ALR On 06/04/2010 12:12 PM, Jason Greene wrote: > Yes exactly. To them you just do a release following the milsestone timestamp version convention e.g > > jboss-jsf-3.4.5-20100603-M3 etc > > On Jun 4, 2010, at 11:03 AM, Stan Silvert wrote: > > >> So am I OK if I use versioned snapshots? Sounds like that's the best of both worlds. >> >> David M. Lloyd wrote: >> >>> One main reason: it makes test suite failures impossible to replicate reliably. Unless you create *versioned* snapshots (e.g. with a specific version like -20100604 or something) then the same AS revision can yield different results depending on what snapshot is out there at the moment. >>> >>> If you use fixed versions, and something breaks, you can point to the diff and say "this change cause it to break". With a snapshot, it can work initially and then break later, causing the wrong changes to be scrutinized. >>> >>> On 06/04/2010 10:48 AM, Stan Silvert wrote: >>> >>>> Let's talk about this then. >>>> >>>> It seems to me that this is exactly what snapshots are for. Releases >>>> are a pain. Snapshots are quick and easy. When you are doing >>>> development and things are changing rapidly, use a snapshot. When you >>>> have something stable that's ready for an AS release, do a release. >>>> >>>> What was the reason for making snapshots verboten? I understand that we >>>> can't have snapshots in a release, and we obviously can't use >>>> third-party snapshots. But using them for sub-modules is beneficial in >>>> the development phase. That's what snapshots are for, right? >>>> >>>> If I had know this I probably would have done all the development in >>>> trunk. Maybe I should move it there? >>>> >>>> Stan >>>> >>>> Jason Greene wrote: >>>> >>>>> No they are most definitely NOT! >>>>> >>>>> On Jun 4, 2010, at 7:44 AM, Jaikiran Pai wrote: >>>>> >>>>> >>>>> >>>>>> As an aside, are SNAPSHOT dependencies of non-AS modules, like this one, >>>>>> allowed in AS trunk? >>>>>> >>>>>> -Jaikiran >>>>>> Stan Silvert wrote: >>>>>> >>>>>> >>>>>>> Just a guess, but maybe your settings.xml is not set up for the JBoss >>>>>>> snapshot repo? >>>>>>> http://community.jboss.org/wiki/MavenGettingStarted-Developers >>>>>>> >>>>>>> Andrew Dinn wrote: >>>>>>> >>>>>>> >>>>>>>>> Some of us had seen the checksum errors (there's a mail in this dev >>>>>>>>> list) too. It kept slowing down the build, but I ignored it. As >>>>>>>>> >>>>>>>>> >>>>>>>> for the >>>>>>>> >>>>>>>> >>>>>>>>> other error you are seeing, could you post the build logs? And what >>>>>>>>> command do you use to build the trunk? From what I know, the >>>>>>>>> >>>>>>>>> >>>>>>>> recommended >>>>>>>> >>>>>>>> >>>>>>>>> way is to mvn clean install from the trunk root. >>>>>>>>> >>>>>>>>> P.S: I think we should really have the hudson.qa instances build >>>>>>>>> >>>>>>>>> >>>>>>>> the AS >>>>>>>> >>>>>>>> >>>>>>>>> trunk against a clean repo using the *public* repo. Right now, >>>>>>>>> >>>>>>>>> >>>>>>>> it's just >>>>>>>> >>>>>>>> >>>>>>>>> a false impression that the AS trunk is building fine. >>>>>>>>> >>>>>>>>> >>>>>>>> I initially used bash build.sh in the build directory. However, after >>>>>>>> posting I retried using mvn clean install and the source of the >>>>>>>> problem became more evident: >>>>>>>> >>>>>>>> [INFO] [dependency:unpack {execution: unpack}] >>>>>>>> [INFO] Configured Artifact: >>>>>>>> org.jboss.jsf.integration:jboss-jsf-deployer:1.0.0-SNAPSHOT:jar >>>>>>>> [INFO] >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> [ERROR] BUILD ERROR >>>>>>>> [INFO] >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> [INFO] Unable to find artifact. >>>>>>>> >>>>>>>> Embedded error: Unable to download the artifact from any repository >>>>>>>> >>>>>>>> I assume this is why the deployer was not found. >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> >>>>>>>> Andrew Dinn >>>>>>>> ----------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

On Jun 4, 2010, at 12:12 PM, Andrew Lee Rubinger wrote: > Sorry, versioned SNAPs are generally not OK. :D Sure they are, just dont ever make them depend on the broken thing maven calls snapshots :)

After the Maven update, I get this error trying to build:

I stand by it. Just because there's no guard to prevent transitive unversioned SNAPSHOT deps. I say "generally" because you can manually

certify your stuff OK for inclusion into AS trunk, a valid exception. S, ALR

Aleksandar Kostadinov wrote: > Andrew Lee Rubinger wrote, On 06/04/2010 09:54 PM (EEST): >> I stand by it. Just because there's no guard to prevent transitive >> unversioned SNAPSHOT deps. I say "generally" because you can manually > > Not a maven expert but it shouldn't be hard to write a plug-in to > validate there are no unversioned snapshot dependencies if it really > causes so much hassle. Perhaps fail the build if an artifact's version > ends with "SNAPSHOT". > > Or perhaps it will be possible to have the plug-in look at an xml file > (in our case the component-matrix) and compare all dependencies defined > in that file to the project dependencies. In case there are project > dependencies not defined in the component-matrix (or with a different > version), the build should fail with a descriptive error message. > > Not sure if it will be worth the effort though. > >> certify your stuff OK for inclusion into AS trunk, a valid exception. >> >> S, >> ALR >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development The Maven enforcer plugin can already prevent snapshot dependencies [1]. I'm not sure if this would mess up the inter-module snapshot dependencies though. [1]http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html