> Specifically, one of the failures I'm getting is: > > Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: > Could > not find artifact > org.apache.camel:camel-core:jar:2.15.1.redhat-620129 > in redhat-techpreview-all-repository > (http://maven.repository.redhat.com/techpreview/all/) --> 129 used to be the GA build number for Fuse 6.2. They changed recently to 133 and the old 129 is probably no longer available from the repository. I will fix it asap.

> We've (Nick and I) taken a quick glance in the techpreview and > early-access nexus repos and have been unable to locate the version > the > build is looking for. So it makes sense the build would fail... My > question is, how does the fuse team build this, and why does it work > for > them and not for me? --> we don't build master at the moment and if you had an eye on this list you would have seen several fails of the Jenkins job.

> It's very difficult for me to offer help with various topics > (terminal > migration, other) to the fuse side if their code can't be built and > plugins cannot be imported. > > I'm not sure if this comes off as rude, but I suggest you make a > habit > of ensuring that your code can be actually built and imported by > others. > If it doesn't work for me, it most likely also doesn't work for other > possible external contributors. One way to test this is to wipe your > .m2 > folder and try to build your stuff and make sure it works. --> the only way to make the build work again is to exclude the whole JMX and Servers stuff. I will do that asap.

> One other thing: I also suggest you clean up the repo a bit and > remove > folders such as "old" that are not to be included in the build. Maybe > I'm alone on this one, but, the purpose of having a good SCM tool is > that you only need to have what's actually used in master. When I do > an > import on your repo, it's importing plugins that will never be used, > and > this is definitely confusing. --> I am confused. I don't see any "old" folder in my repository. Are you sure your fork is clean?

> Either way, I can't make any progress offering to rewrite your > terminal > if I can't import your code. Build is fsck'd. Plz to fix at earliest > convenience. --> working on it today.

Ah right, thought thats the fuse mailing list :D

Am 02.07.2015 um 11:54 schrieb Max Rydahl Andersen: > >>> Specifically, one of the failures I'm getting is: >>> >>> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could >>> not find artifact org.apache.camel:camel-core:jar:2.15.1.redhat-620129 >>> in redhat-techpreview-all-repository >>> (http://maven.repository.redhat.com/techpreview/all/) >> >> --> 129 used to be the GA build number for Fuse 6.2. They changed >> recently to 133 and the old 129 is probably no >> longer available from the repository. I will fix it asap. > > eh - what maven repository are we relying on where they remove > releases ?! > >>> We've (Nick and I) taken a quick glance in the techpreview and >>> early-access nexus repos and have been unable to locate the version the >>> build is looking for. So it makes sense the build would fail... My >>> question is, how does the fuse team build this, and why does it work >>> for >>> them and not for me? >> --> we don't build master at the moment and if you had an eye on this >> list you would have seen several fails of the >> Jenkins job. > > This list does not contain build errors. > > I assume you mean jbosstools-fuse-dev(a)lists.jboss.org :) > > If we are not maintaining master could we stop the builds so it does > not generate noise ? > > Which branch are being built/used instead ? > >>> It's very difficult for me to offer help with various topics (terminal >>> migration, other) to the fuse side if their code can't be built and >>> plugins cannot be imported. >>> >>> I'm not sure if this comes off as rude, but I suggest you make a habit >>> of ensuring that your code can be actually built and imported by >>> others. >>> If it doesn't work for me, it most likely also doesn't work for other >>> possible external contributors. One way to test this is to wipe your >>> .m2 >>> folder and try to build your stuff and make sure it works. >> --> the only way to make the build work again is to exclude the whole >> JMX and Servers stuff. I will do that asap. > > Did we break API already ? :) >> >>> One other thing: I also suggest you clean up the repo a bit and remove >>> folders such as "old" that are not to be included in the build. Maybe >>> I'm alone on this one, but, the purpose of having a good SCM tool is >>> that you only need to have what's actually used in master. When I do an >>> import on your repo, it's importing plugins that will never be used, >>> and >>> this is definitely confusing. >> --> I am confused. I don't see any "old" folder in my repository. Are >> you sure your fork is clean? > > I don't see it either. > >>> Either way, I can't make any progress offering to rewrite your terminal >>> if I can't import your code. Build is fsck'd. Plz to fix at earliest >>> convenience. >> --> working on it today. > > /max > http://about.me/maxandersen