beans circular dependency

[valery_antonov]

Digging stack traces, I found that IMHO there is circular dependency between alfresco beans:

permissionService
permissionServiceImpl
permissionsModelDAO
nodeService
mlPropertyInterceptor
multilingualContentService
permissionService

Yes, I understand that somehow it works, but I dont understand - how Anyway IMHO it is not a good architecture, it looks like a mess. And this is not the only example - look, alfresco-core module depends on spring-surf (positioned as a 3rd party UI library), so you cant create headless alfresco server without this huge bunch of libraries

[mrogers]

Are you sure its a "circular dependency",  I wouldn't expect a circular dependency to work.  What you have posted may be a multiple dependency.   I can't tell from what you have posted.

Agreed that there is a lot that needs to be cleaned up.   Including the dependencies upon things which should not be in the surf libs.   As I've said before on these forums someone needs to take a big axe to alfresco and smash it to bits :twisted:

On a more practical note if you can identify enhancements to improve things then please contribute them via JIRA.    What is important is a clear focus, saying vague things like the architecture is a mess will go nowhere.

[valery_antonov]

Ok, I'll try

permissionService targets permissionServiceImpl (of course), it references permissionsModelDAO, it references nodeService, it has interceptor mlPropertyInterceptor, it references multilingualContentService, and wow - it references permissionService I cant imagine how Spring resolves that

Well, I could post issue "please use maven for building alfresco", but I doubt it is to be fixed in the next release And IMHO it is really helpfull to have dependency tree explicitly declared - may be after that your architect will say "hmmm… something has to be done"

Share isnt suitable for us, so we have completely new UI, and I have to build war myself - everything is tightly coulped, you cant get ride of modules you dont need. And the idea of subsystems complicates the things heavily - all beans are created, all references are resolved, and after that it just dont calls init… Colud I post issue "kill subsystems, use standard Spring approach with @Lazy"?

One more thing - alfresco depends on patched 3rd parties. I guess it would be stupid to post issue like "please contribute back your patches", but it is not the way open source works…

[mrogers]

We are very reluctant to patch third partly libraries because its painful for many reasons.  And I think in general we do contribute back the patches, diagnosis etc.   In many cases it will be an Alfrescan wearing a different hat working on the third party projects 😎   However there are timing and version issues with the third party libs, or our changes may not be picked up for various reasons     We also make the modified source and diffs public.

Again if there are any specific third party patches that need to be contributed please raise them in JIRA or the other project's bug system.     We would gladly get rid of all the patched versions.

We can but hope about the change to Maven, its very overdue.  The first priority was I think to get the Alfresco Maven Repository built correctly and automatically and that should be just about there from what I read on JIRA.    The good news is that we now have a full time build engineer to do that sort of stuff.

[valery_antonov]

Good luck for him!

Yes, alfresco artifacts now in repository, it is a good start

There is 10 patched libs in 4.0.d, some of them are completely outdated (like acegi security - it became spring security many years ago ), plus many artifacts you cant find in central repo, I dont think there is need to bother your support with list again… Dependencies are always pain in the neck, yeah

Meanwhile, I gave up transitioning to 4.0 - it is incompatible with the old apps, so I have to think…