I wish to join this project to help get it going again #144
Comments
|
I am available to contribute. I have used Spring.NET for a while and like it a lot. |
|
At the moment I have included Core, AOP, Web, and Mvc5 into my solution and am attempting to work through a couple minor issues that I have encountered. I am maintaining the existing Spring.NET solution structure by storing it under a folder in my project tree, and am selectively referencing projects into the solution. I think this will go a long way with regards to testing integration with my application, while being able to debug issues that I encounter. I will also be sure to push changes I make to my fork on GitHub. Until I can get further direction on things to do this will have to do for now. I think there is a JIRA for this project over at Spring Source, so I will have to take a look at that, too. |
|
I can assist in code review, accepting PRs related to the project, etc.
…-Steve B.
On Oct 27, 2017 4:40 PM, "Jeffrey Schultz" ***@***.***> wrote:
Reopened #144 <#144>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALX4I-IJZHfZPL_umiHdAUCh4vGOafSks5swj-sgaJpZM4QJfhy>
.
|
|
I am starting a new job at the moment using C#, ASP.Net and IIS. The current website I am responsible for is 8-10 years old and the new version of it will be in Wordpress.
I need to look into whether Spring and Wordpress will work together. If they do or can then it will be in my best interests to help out on this project.
Chris Tully, M.S., Java and .Net Developer and Image Analysis Expert
t 240.475.9753 f 419.831.0527 | cptully@gmail.com
Sent from my iPhone please excuse typos.
… On Oct 27, 2017, at 4:46 PM, Steve Bohlen ***@***.***> wrote:
I can assist in code review, accepting PRs related to the project, etc.
-Steve B.
On Oct 27, 2017 4:40 PM, "Jeffrey Schultz" ***@***.***> wrote:
> Reopened #144 <#144>.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#144 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AALX4I-IJZHfZPL_umiHdAUCh4vGOafSks5swj-sgaJpZM4QJfhy>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Maybe I'll try to invest some time too. As I've said earlier I have some branches collecting dust that should be completed in the way forward. At least converting from Rhino.Mocks to FakeItEasy will allow as cleaner road towards .NET Core. |
|
Hey this sounds really exciting, "Spring.NET" was a synonym of "best practice" for me for about 10 years and it was a really hard decision to move to another IoC container. But we had to do it as Spring.NET really outdated. It would be great if you guys get project back to life. But if to talk about actual project tasks, Core support is cool, but honestly, there are a lot of other things that should be done to get Spring.NET back to track. For example, XML looks just ridiculous our days, no one would use it. Modern applications register dozens of dependencies and a preferred way is to do it in code (using lambdas) and to do it automatically everywhere, where it's possible. Also, I think supporting of ancient .NET versions is a road to nowhere as even MS abandoned them. I'm saying that because Spring tried to support .NET 1 and 2 for so long blocking usages of 3.5 features in core modules. |
|
I am one of those people that’s loves XML. Sorry, but I think XML really has a place in Spring.NET, and I would really like to see more support for generalized XML authoring and consumption. That being said, any way of configuring a container should be nothing more than a source of configuration definitions. The XML config factory, or fluent configuration, shouldn’t be an intrinsic component of the container. Use what you need and leave the rest behind. As for me, not supporting XML is a no-go. I think the reason that XML isn’t bigger in the .NET community is because suppor for it is kind of crappy, which means that you end up with crappy implementations that add more of a burden to developers and end consumers. I would like to see this change. |
|
I've used both XML and code configuration and they both have their merits. My Msc work was about product lines and XML played key role when defining readable variation points. Now using CodeConfig mostly to wire things up. XML is not going away and I wonder how the current CodeConfig would not meet requirements. A fee more lines to write compared to some fluent interfaces or auto scanning, I prefer the explicit wiring via CodeConfig, no guesses what is being used. |
|
I have used both as well, but I feel that configuration stops being "configuration" once you write it in code. That's kind of the point of external declarative configuration schemes, there is already a lot of code to deal with, so the goal is to have a separate representation of it that is focused on the task at hand, configuration. I feel that Spring.NET provides a pretty good mechanism for accomplishing this, but it still leaves a lot of room for developers to muddle it, hence what everyone has experienced before when dealing with large amounts of declarative configuration. With that said, I do believe that you should have the option to use either, and that they should be able to be used together. There are some parts of applications configuration that I want left internal, which could accomplished by embedded the XML in the assembly, or using code config, but when thinking about it from an end-users perspective, there is some that I want to expose. I think a lot of these mechanisms are for the people that consume our products, rather than the ones that develop using them, even though the developers do benefit from them. Now, besides the obvious steps that need to be taken to get this project back on track, such as ensuring unit tests correctly represent expected behavior and are passing, and establishing platforms that will be supported in the way forward (and how to better structure the project to support that), I think a little life needs to be injected into some of the public facing parts of this project, such as updating the website to announce a call for contributors, etc. Whatever we can do to wake people up needs to be done. I also have some ideas for other Spring.NET initiatives. The way that I look at the Java version of Spring is that it provides a foundational framework for structuring your applications, while attempting to smooth over differences that are encountered when using the various application servers that are used, and then providing a lot of integrations using those same concepts that become available to your application out of the box. With Microsoft's divergence from a couple of frameworks for .NET that are pretty much the same in general, to now with several frameworks to choose from, each having their own caveats and restrictions on usage of accepted .NET features, there needs to be some middle ground project that provides a solid base to build off while minimizing effort required by developers to support as many targets as possible. That can be the new niche that Spring.NET aims to fill. There have been so many new developments in the .NET ecosystem over the past few years that it can make your head spin. Now with the shift in efforts to self-host services within your own process, there could be an initiative to provide guidance and frameworks to support these developers. Spring.NET could become that set of abstractions and default implementations to ensure best practices are present from the beginning. I personally love OSGi and Apache Karaf, and would like to see something like those available for .NET. Yes, I know there are some aspects of .NET that make OSGi for .NET not completely feasible, but you could capitalize on the benefits while accounting for limitations in the platform. Also, I think a few of things are extremely critical for the longevity of the project (those will be described later), and one of them is Project Alliances. Spring.NET should position itself as an integration platform where developers can opt-out of default implementations to integrate another project's implementation. Spring.NET should be more than just an IoC/DI framework. Yes, I know there are other projects, but the focal point has always been the container for me. I think we should also evaluate where the Java Spring project has gone in relation to where Spring.NET currently is, and see if there is anything else that could be taken from that set of projects. I am serious about this, and I hope that anyone interested in being a part of this would join me. |
|
I would also like to help move the .NET community towards an old idea, but what I think could be a new paradigm for .NET.
Pretty self explanatory, but it shifts the perspective of how application configuration is handled. It should not be an after thought where classes grab needed values from AppSettings (ick!). An objects configuration should be a definition of that class for a particular instance, and that is addressed with composition. |
|
It looks like there is a lot of good stuff in JIRA, along with some Futures tasks. Are these still valid? Is JIRA available for us to use? Or have ties been severed? I am not really sure how the current Spring.NET projects tie in with the original project that used to be available from the Spring Source site. |
|
As for porting to other platforms, would it be a better bet to aim for the .NET Standard targets, rather than .NET Core itself? As an update, I have found a few issues while developing my prototypes for a new project we are working on at work, and will be creating corresponding issues to be worked. I have also updated my GitHub profile to show my email address, so that anybody interested can contact me directly and assist. I think there is another effort to port to the .NET Standard 2.0 platform, called Summer, so I will also be reaching out to that developer in an attempt to combine our efforts if they are still interested. |
|
Hi guys, i've working with spring.net since ~2007/2008 and a really appreciate this project. What i didAt september 26 i've started a independently and unpretentious port of Spring.Core and Spring.AOP to .NET Standard. This port is a success, i'm working with this port on production, using misc of code and xml configuration, AOP and some daily features as well. The port that i did is based on 4 solid steps: 1 - New ProjectsCreate a new projects based on .NET Standard 2.0, copying all code files to new project mantaining the assembly name, namespaces. 2 - Switch and AdaptAddind nuget packages for known dependencies and creating a fake classes to replace some behavior that not portable, like Common.Logging and System.Runtime.Remoting and System.Runtime.Remoting.Messaging. These fake classes was created to garantee that i don't add a new issues or mistakes during remove your utilization, instead that, i create a fake implementations to maintain codebase intact. The only not ported thing is registry32, that was removed. 3 - TestsThe third step is make tests working. About first and second step, i'm talking exclusively about the Spring.Core and Spring.AOP projects, without your test projects. At third step and this is a most dificult on this port, is make tests working fine and Rhino.Mocks has maked it mor dificult. I really had some dificults to mantain same contract, wrapping other framework to do that using NSubstitute. But, on my work plan, i'm still here. 4 - Growing upThe last continuous step is make this project live! what i will doIf anybody ask me about work on this project. My answer is yes! i Will be glad to contribute! |
|
@luizcarlosfaria Wonderful! I got excited when I saw that I had a new GitHub notification. I would certainly appreciate your help in getting this going. Perhaps, we can start taking a look at the changes you made to get the core projects onto .NET Standard 2.0, and then create a new branch for this work that only contains the source code for those projects that are being migrated to .NET Standard 2.0. This way we can selectively bring over projects as their dependencies become available, leading to an eventual merge back into master. Did you work out of your GitHub repo so that all commits are available, instead of one dump to GitHub? It would be great if we had diffs against the individual files to be able to see each and every change. |
|
I Eventually, once we have a stable team structure, we can move to the pull-request model of contributing. I just wanted to make sure that a number of people were included from the start. If things change or issues pop up, we can adjust to address it. The organization is spring-net-futures. |
|
Great @jeffreyschultz ! Sorry, i've talk so much but "where's the code?" https://github.com/luizcarlosfaria/summer-net This name is a joke! Ok?! don't judge me about that! |
|
Summer makes sense, since Summer is after Spring, but I intend to stick with the Spring name for historical purposes, since this isn't a true fork of the project and just a continuation that hopefully will be merged back into this repository. |
|
Also, just so that everyone knows, we will be using the Git Flow methodology. That means that you do not directly work in master or develop, but that you create feature branches that will be merged into develop, and eventually develop into master. This important as we should be establishing a baseline to work against. |
|
GitFlow is a standard, it's ok for me. |
|
Yeah, I like using git modules, too. I was contemplating doing this as well at some point, but wanted to talk it over with the team first. It has my vote. |
|
@jeffreyschultz , I can assist too. My current need is upgrading the current 2.0 release to NHibernate 5. After that, I can continue supporting this effort. |
|
Would love to see this support .NET Standard. It's one of the only dependencies left holding us back. |
|
@Salgat, In my tests, only default configuration model (using app.config or web.config) stay broken. XML and Code configurations still working fine, side-by-side, nested contexts are working fine too. The port of core and aop projects are very simple, but port of test projects still need a lot workhours. |
|
I have been playing around with Spring.NET under Mono and majority of the tests throw a fault when executing. I am still looking into the issue, and am considering just doing this work on Windows. It might be too much to try and develop from another platform while trying to port it to .NET Standard 2.0. |
|
I have migrated the Core project to netstandard 2.0 as a test and have been looking through your project, @luizcarlosfaria. I am exploring the possibility of creating a Spring.Logging namespace that defines an container-level ILogger interface to be used and managed by the container. It would be available to Spring.NET consumers as well, and would provide an abstraction to develop against, while allowing for developers to configure logging implementations. I would like to eliminate as many external dependencies as possible. |
|
I had to revert some changes because I had ran a Resharper Clean Code against the entire solution, and it really made it hard to tell what had changed in the diffs because it moved things around. Too many file changes for this task to properly track what is going on, so I reverted my initial commit in hopes to make the future pull request more easily accepted. So I backed out those changes, and made the changes to Spring.Core again to get it to compile on .NET Standard 2.0. https://github.com/spring-net-futures/spring-net/commits/feature/netstandard-2.0 |
|
I just committed changes to Spring.Aop to get it to compile with .NET Standard 2.0. At this point, I really don't know if the code works, just that it compiles. I have also broken the build configuration where it used to copy files to certain folders, and now only produces the artifacts under the project folder, so this will need to be revisited when looking to merge changes back into original repository. There is also the potential for us to handle builds differently... really don't know at this point. What is a good build system to use for .NET these days? I would really like a maven or gradle alternative for .NET with good dependency management where a local repo is maintained with build artifacts from recent builds so that these projects could easily be split up and developed separately instead of being tied to a single solution. Does anything like that exist for .NET yet? Nuget doesn't really hit the mark, and I don't see it as a viable dependency management tool, and is more like an "app store" for released libraries--what about a nightly build that was just ran and not yet uploaded to Nuget? I have some ideas for a new build system that would accomplish this for .NET that I have dubbed "mason", but haven't begun any work on it other than the name. |
I think that we have decisions to make, and my first tradoff is solved looking around asp.net core, .net core and some open source projects designed for the community today. They have myget, still using nuget, runnig under jenkins... some big annd simple deals. |
|
@sbalhoff, that is currently something I plan to do when I have verified all of the behavior of the new port. I will be upgrading all technologies used within Spring.NET to the latest versions as long as there are no significant issues. |
|
I still need to come up with a solution to integrate .NET Remoting back into the container. I have a couple of ideas, such as attempting to resolve .NET Remoting support classes using reflection, or extending the container with additional interfaces and constructs that allow you plug additional object handling behavior into the container so that .NET Remoting could be supported without the Core project having to understand it. Is .NET Remoting supported on non-Windows platforms? I don't know off the top of my head, and will have to look that up. Anyone? |
|
@jeffreyschultz Let me know if you encounter significant issues with antlr. I took a compiler course recently and wouldn't mind the extra exposure. The grammar looks simple enough though, so I don't expect that it will be a problem. Do you have a time range goal for releasing the next version yet? I'm working on a project that is deciding whether to abandon spring.net or wait for a new version. |
|
I am hoping to have the .NET Standard 2.0 port wrapped up by the end of the month given my current rate. I do have some more free time coming up, so it could be sooner. You can certainly help out with the ANTLR upgrade. I have no problem with that at all. Was that compiler course any good? I love working with compilers. I started programming when I was 7 years old, and had a deep interest in operating systems and language/compilers, and took quite an interest in them and database management systems during college. |
|
Ok. I'll pull down the project this weekend after my classes are over. I learned a lot from the course. I wish we'd gone further into parsing than we did, and we didn't cover any optimization. We wrote a Pascal -> C compiler, which was a nice experience. |
|
Just reporting back. I got the antlr4 book (I can use it for personal projects anyway and online docs were not very helpful) and read through the reference chapter. v4 is pretty different from v2, summed up as so:
My preference is using the visitor pattern over the listener pattern so that the AST nodes can be returned by the visitor functions. Let me know if anyone has opinions. The antlr4 grammar is pretty different, so a large percentage of lines in the file will be modified. A few relevant changes are: options such as "k" and "buildAST" are no longer used, some options will be added at the command line (e.g. -visitor vs -no-visitor), and token values aren't specified in the "tokens" section anymore. I haven't looked into differences in error reporting yet. I'm on vacation for the next couple weeks, so I don't think I'll get much done on this in that time frame. |
|
I like the visitor pattern approach in most cases, so that is fine with me. It sounds good, to be honest. I haven't looked into antlr4 all that much yet. I am about to pick this back up since the last couple of weeks have been hectic, so you should be seeing more activity from me soon. |
|
Hello guys, i'm reviewing dependencies not resolved on my port and i have news! Since version 3.4.0, Common.Logging adds .NET Standard support. It's a great news! |
|
I ended up switching jobs from a .NET job to one where I will be working in Java, and had to give back my .NET development machine since it was my work computer. I will continue this work either in a VM or using VS Code/Rider on my MBP. I am still here, and have't left, just in a bit of a transition. I apologize for the delays. |
|
@luizcarlosfaria, do you think Spring.NET should have dependencies on Common.Logging? I would like your opinion. I thought it would be better if Spring.NET didn't directly depend on a specific logging implementation, but instead used an abstraction where logging could be plugged in. The default logging would be to the debugger log or to std out. That's just my belief, though. |
|
I hope you guys had a great holiday season! |
|
Jeff,
I agree that dependency on specific libraries is problematic, so I like
your suggested solution of building an abstraction.
We had a nice quiet holiday season and my current contract is about to wrap
up so I am ramping up my studying and practice coding as I job search.
I have VS 2017 Community edition on both my PC and my Mac, so I'll try to
start really contributing soon.
Chris
Chris Tully
cptully@gmail.com
240-475-9753 (c)
[image: View my profile on LinkedIn]
<http://www.linkedin.com/in/christully/> *Check me out on*
<https://github.com/cptully>
…On Fri, Jan 5, 2018 at 11:43 AM, Jeffrey Schultz ***@***.***> wrote:
I hope you guys had a great holiday season!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AStL35S29vm9qD1SjeQr5Pn2xo74hFM3ks5tHlFBgaJpZM4QJfhy>
.
|
|
@jeffreyschultz Common.logging IS a logging abstraction layer so you can use Log4net, NLog, etc. It provides exactly what you are saying - no dependency on a specific logging library. |
|
@swalters, I understand. My question is whether it should be decoupled from such a library, or any other library for that matter. This removes a direct dependency of the core code from a specific version of a third party library, and adds a level of indirection between them. This does mean that adapter libraries have to be written for each specific logging library to be brought in. My belief is that the core parts of Spring.NET should be self-contained to the maximum extent within reason. Where we draw the line it is fuzzy in my mind. This is more of a philosophical question, but does have huge real world ramifications as a result. |
|
The original Spring project already depends on Common.logging:
https://docs.spring.io/spring-ws/site/spring-xml/dependencies.html
So we might as well keep that dependency.
Chris
Chris Tully
cptully@gmail.com
240-475-9753 (c)
[image: View my profile on LinkedIn]
<http://www.linkedin.com/in/christully/> *Check me out on*
<https://github.com/cptully>
…On Fri, Jan 5, 2018 at 1:25 PM, Jeffrey Schultz ***@***.***> wrote:
@swalters <https://github.com/swalters>, I understand. My question is
whether it should be decoupled from such a library, or any other library
for that matter. This removes a direct dependency of the core code from a
specific version of a third party library, and adds a level of indirection
between them. This does mean that adapter libraries have to be written for
each specific logging library to be brought in.
My belief is that the core parts of Spring.NET should be self-contained to
the maximum extent within reason. Where we draw the line it is fuzzy in my
mind. This is more of a philosophical question, but does have huge real
world ramifications as a result.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AStL34NzXEyiE6sGF2JzeOqwjxjXiS2nks5tHmj9gaJpZM4QJfhy>
.
|
|
Hi guys, happy new year for us! @jeffreyschultz, Specifically about Common.logging, this is a kind of abstractions of logging. About be or not be dependent ot this? It's a choice, like everything else. It's a tradoff to consider when choose implements or reference other libraries. The workaround to avoid external dependences maybe does not make sense. Projects like Polly, Common.logging, Newtonsoft.Json and others, can be considered essentials. Just in case of Common.logging, this is a good project, can help to abstract and connect logging about spring and others loggers and this is a cool feature. It's must be considered. Thanks! |
|
About the future of Spring.NET, I'm getting more sure that Spring.NET must be a downsize. My opinion is:
It's sounds so pragmatically for me, but on same time i can see two important things: Community sense, and viability. |
|
@luizcarlosfaria, I understand your perspective, and it makes a lot of sense. I have moved back to the Java Spring libraries for my new job, so have been focused on working with them. I want to continue to work on the Spring.NET port, but need some others to pick up some of the work. All of my changes are available in the spring-net-futures/spring-net repo under the netstandard-2.0 branch. https://github.com/spring-net-futures/spring-net/tree/feature/netstandard-2.0 |
|
@luizcarlosfaria I think it might be prudent to take your suggestion and upgrade Common Logging for now, but personally, I would like to see a facility built into Spring.NET for this sort of thing. |
|
Today i'm writing about these projects and i've found the proposal and decisions of future of Common.Logging. It's like i've proposed for Spring.NET. best regards! |
|
We used Spring.NET and nHibernate heavily in an Application built around 2010. As we have noticed no updates to Spring.NET and at the same time nHiberante got new releases, Spring.NET was posing a bottleneck for us to move to latest version of nHibernate. Somehow we managed to decouple Spring.NET and nHiberante and use them independently. Meantime we are making major enhancements to Application and thinking of replacing Spring.NET with Unity. This requires considerable amount of work as we have used Spring.NET for IOC and all the cross cutting concerns( Logging, Exception, Transaction, caching, Validation etc..). Lately noticed some interest in bringing back life to Spring.NET from community. Given that there is some community interest in Spring.NET, is it worth taking effort to replace Spring.NET? Hope community can provide some input. |
|
HI Guys .. I would love to contribute.. I am in the same boat ... I used this back in 2008-2010... and I feel strongly Spring-NET was awesome... just let me know if this will have a life here... or should we move this outside ? |
|
I've completed the somewhat long journey for .NET Core compilation and master now has the capabilities, see #133 (comment). I "stole" a commit from @jeffreyschultz to get some functionality in that he already had implemented, I hope that is OK. So anyone wanting to build a beta'ish release it can be done from current master. |
|
My recommendation is that work continue here (vs. forking the repo and
attempting to stand up a second 'authoritative' instance elsewhere) unless
there is a specific *benefit *to doing so. To my knowledge there shouldn't
be any blockers to everyone wishing to participate being able to do so in
the context of this current repo/project location.
Steve Bohlen
sbohlen@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen
…On Sat, Sep 29, 2018 at 4:09 PM meshpaul ***@***.***> wrote:
HI Guys .. I would love to contribute.. I am in the same boat ... I used
this back in 2008-2010... and I feel strongly Spring-NET was awesome...
just let me know if this will have a life here... or should we move this
outside ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALX4MFo6cIAbYiAS0p7w99NWc236aewks5uf9NdgaJpZM4QJfhy>
.
|
|
I now have one leg in the Java world, and the other in the .NET world with a new web app that we have been gifted by our parent company. It isn't using Spring, but this still reinvigorates my interest in this project. I am working in a Virtual Box instance with Windows 10/Visual Studio 2017, so I am good to go. @lahma You won't get any complaints from me. 👍 |
|
Good idea! |
|
Nice seeing the project comes back to life Would be happy to get the new release a test drive soon. |
|
Who is interested to talk about Spring.NET and run some workshops here: http://dotnetfest.com/indexe.html ? @OliaG can answer any question, related to the event - the link for submitting proposals is available here: Ivan |
|
See #187 (comment) . Please push PRs and improvements, it should be now easier to get things out of the door. |
Like the title says, I would like to join the project and help get development started again. There is still a need for Spring.NET in the .NET ecosystem, and it's a shame to see this wonderful code base collect dust.
I have already forked the repo in GitHub, and am wondering what is the state of things that need to be worked? I have used both Spring.NET and Spring, so I have a bit of familiarity with them, which is good, but I have only recently started to poke around the source code.
Also, who is available to provide guidance on implementation decisions and deal with pull requests? Anyone?
The text was updated successfully, but these errors were encountered: