Springsource koopt Apache-specialist Covalent

Springsource, het bedrijf achter het gelijknamige Java-ontwikkelplatform, heeft aangekondigd dat het Covalent Technologies gaat overnemen. Covalent biedt ondersteuning aan gebruikers van Apache en Apache Tomcat.

Details over het overnamebedrag zijn niet bekendgemaakt. Covalent werd in 1998 opgericht en combineert de Java-applicatieserver Apache Tomcat met verschillende opensourcemodules in zijn Covalent Enterprise Ready Server-oplossing. Het bedrijf verdient zijn geld met de installatie en ondersteuning van de opensource applicatieserver bij grote bedrijven.

Springsource, vooral bekend van zijn Spring Java-framework, zegt Covalent te hebben overgenomen om een betere positie in het veld van opensource Java-ontwikkeling te verkrijgen. Ook zou het bedrijf kunnen profiteren van de uitgebreide ondersteuning die Covalent aan zijn klanten biedt. Springsource-directeur Rod Johnson concludeerde vol trots dat zijn bedrijf nu voor de 'A' van de bekende webontwikkelingsomgeving LAMP een leidende positie in handen heeft. Eerder al ging Sun voor een miljard dollar met de 'M' van de opensourcedatabase Mysql aan de haal.

Reacties (18)

[Herko_ter_Horst]

Lijkt me een goede aanvulling op het bestaande dienstenpakket van Springsource (voorheen Interface21). Zowel Spring als Tomcat zijn een belangrijk onderdeel van veel (web-based) Java oplossingen. Als je ondersteuning voor die combinatie bij één partij in kan kopen, lijkt me dat prettig.

Maar om nou het kopen van "een" dienstverlener die diensten levert voor Apache (httpd en Tomcat) gelijk te stellen aan het "in handen hebben" van de A uit LAMP...
Des te vreemder omdat LAMP niks met Java te maken heeft.

[Reactie gewijzigd door Herko_ter_Horst op 25 juli 2024 21:07]

[YopY]

Nein, maar Apache en Apache Tomcat wel.

Wat me wel opvalt is dat een bedrijf die ondersteuning e.d. biedt voor een application framework genoeg geld heeft voor het overnemen van een bedrijf dat ondersteuning biedt voor de meest gebruikte webserver. Maar vooruit maar weer.

[Herko_ter_Horst]

'Nein, maar Apache en Apache Tomcat wel.

Onder de 'A' uit LAMP versta ik Apache httpd. Heeft niks met Java/Spring of wat dan ook te maken.

Tomcat, ok. Toevallig wordt dat ook ontwikkeld onder de vlag van de Apache Software Foundation, maar (veel) meer ook niet. De vergelijking met MySQL gaat in elk geval volledig mank.

Wat me wel opvalt is dat een bedrijf die ondersteuning e.d. biedt voor een application framework genoeg geld heeft voor het overnemen van een bedrijf dat ondersteuning biedt voor de meest gebruikte webserver.

Waarom zou dat vreemd zijn? Ik weet niet hoe groot Covalent is, maar het is zeker niet de enige (of waarschijnlijk zelfs maar de grootste partij) die diensten levert voor Apache (httpd en/of Tomcat). Dus zo vreemd vind ik het niet.

[Reactie gewijzigd door Herko_ter_Horst op 25 juli 2024 21:07]

[NLxAROSA]

Ik denk dat je verbaasd zal staan te kijken van de hoeveelheid geld die de mannen van SpringSource (voorheen Interface21) binnenhalen met consultancy, trainingen en lezingen.

[YopY]

Er was hier laatst ook een cursus daarvan, drie dagen, een stuk of twintig mensen - ik geloof zo dat een training al veel oplevert.

[Verwijderd]

Beste allen,

SpringSource heeft zich als doel gesteld de leading productenset in de enterprise Java ontwikkelingsmarkt te zijn / worden. Met Covalent halen we supportcapaciteit voor zowel Tomcat als Apache in huis, alsmede ontwikkelaars die aan deze producten meewerken. Tomcat en Apache worden in de Java-wereld veel gebruikt.

Voor wat betreft het partnership met Cap Gemini: voor zowel ons als Cap Gemini is het interessant om van elkaars diensten en producten te profiteren. Cap Gemini komt bij veel klanten over de vloer. Door te partneren met ons kan Cap Gemini een beter dienstenpakket neerzetten (bijvoorbeeld 'from the source' ondersteunen op applicaties die Spring en nu ook Tomcat gebruiken). Andersom helpt Cap Gemini ons bij het leveren van input rondom onze productenset. Input vanuit de markt is voor ons van groot belang om producten te blijven bouwen die de markt daadwerkelijk aanspreekt.

groetjes,
Alef Arendsen
Principal Consultant & co-founder SpringSource

[NLxAROSA]

Ben wel benieuwd waarom je geen voorstander bent van Spring. Spring zorgt ervoor dat je je bezig kunt houden met zaken waar het echt om gaat i.p.v. het 'leidingwerk'. Dependency Injection (hoewel niet uniek voor Spring) maakt het daarnaast mogelijk je componenten los te testen zonder je hele applicatie op te tuigen, wat het weer mogelijk maakt een goed continuous integration proces in te richten. Werk er inmiddels al enige jaren mee, en ik vind het alleen maar beter worden. Nog een groot voordeel van Spring is dat het heel veel mogelijk maakt, maar je niets opdringt. Je kunt dus heel veel zaken configureren (bv. transactiemanagement, security) m.b.v. Spring en AOP, maar als je het allemaal zelf wil doen of een 3rd party oplossing wil gebruiken is dat ook prima. Enige nadeel dat ik zou kunnen bedenken is de enorme API. Maar daar zijn genoeg boeken over en trainingen voor.

[Reactie gewijzigd door NLxAROSA op 25 juli 2024 21:07]

[latka]

Continuous integration is leuk, maar volgens mij is het de bedoeling dat je dan wel op het target platform test, dus niks omhangen en mocks maar gewoon een 'oracle light' gebruiken e.d. Junit testen is een ander verhaal, maar ook daar werk ik liever met DBUnit en de target DB op de ontwikkelmachine dan testen met iets waar je in productie toch geen gebruik van maakt.

[MatthiasDS]

Hoezo, testen met iets waar je in productie geen gebruik van maakt?

JUnit/Spring-Mock etc laten toe om op een zeer eenvoudige manier zowat alles te testen wat je wil. DBUnit kan je gebruiken, maar niet elke applicatie is vooral DB-gericht hoor.

[NLxAROSA]

Continuous integration/build is niet hetzelfde als een systeemtest. Het continuous proces is er juist om te detecteren dat iemand brakke code in je repository aan het inchecken is, in plaats van dat je er pas achter komt als jij de meest recente versie van de applicatie uitchecked en jij kan gaan zoeken naar wat er in vredesnaam mis is. Of nog erger, tijdens een systeemtest of vlak voor een delivery.

[Reactie gewijzigd door NLxAROSA op 25 juli 2024 21:07]

[YopY]

Er zit verschil tussen unit tests, integration tests en functionele tests, en alles wat daar nog tussenin en omheen zit. Voor unit tests is het ideaal, bijvoorbeeld, in combinatie met JUnit en JMock. Maar dan moet je je ook aan bepaalde ontwikkelmethodes houden, o.a. ontwikkelen met interfaces ipv implementaties.

[MatthiasDS]

Maar dan moet je je ook aan bepaalde ontwikkelmethodes houden, o.a. ontwikkelen met interfaces ipv implementaties.

Doet niet elke deftige programmeur dat?

[SPee]

Het is wel leuk als je omgeving ook op een andere werkt als het specifieke platform.
Zo krijg je later bij eventuele wijzigingen geen/minder problemen.

[offtopic]
Het is echt geweldig!
Het laatste bericht is van Springsource's Alef Arendsen
Uit respect plaats niemand meer een topic

[momania]

En kun je ook aangeven waarom je dan geen voorstander van Spring bent?

Vanuit de ogen van SpringSource is dit wel een logische overname.

De samenwerking met CapGemini snap ik dan weer niet...

[latka]

Volgens mij hebben weinig mensen echt serieus met EJB2.x gewerkt, anders was spring niet zo populair. Met XDoclet was EJB2.x niet eens zo'n probleem en had je in ieder geval geen EARs van 20Mb omdat je het hele internet meepackaged.

[MatthiasDS]

Ik heb al in verscheidene projecten met EJB2.x gezeten en ben steeds tevreden als mijn volgend een Spring-based project is. Ik zit heden ten dage in een gemixte Spring/EJB2.x omgeving en weet ook duidelijk waar mijn voorkeur ligt.

Spring is populair omdat het zeer overzichtelijk is (imo), zeer gemakkelijk testbaar en naar ik persoonlijk vind ook veel eenvoudiger om te gaan debuggen. De vele interfaces in EJB2.x en het vele overerven maakt het er allemaal niet overzichtelijker op.

Trouwens, zelfs Sun heeft ingezien dat het hele EJB2.x-gebeuren rot was. Heb je EJB3 al eens bekeken? De link met een Spring+Hibernate setup is zeer duidelijk te merken.