[swd847]

With regard to submitting patches I keep one 'clean' copy of the svn checkout and just make a new copy for every patch, hardly ideal, but it works. When a new branch is tagged you can just do a svn switch.

[kukeltje.ronald.jbpm.org]

Wow, how many counter arguments... That is what I see very often. All kinds of (imo) not always valid arguments to not have/want to contribute back
- In SVN Seam is fairly modularized so the '7 step counter argument' is not really an issue imo.
- Submitting patches 2 or 3 times via Jira is normal for a project so they can see you are capable. Afterwards, ask/get commit access and this becomes much easier.
- The internals of the really core parts maybe rocket science, many other parts are not
- Employers already pay lots of money for 'the basics' but they almost always do not see the hidden cost of keeping workarounds alive over a long time with different devs etc... way, way more costly
- A branche for user contributed stuff can always be made (navigation, temp nested conv.). That way people who dare can try out that code. It is stored centrally, others can play with it and it can in a later stage be integrated in trunk.

Even with just SVN and no OpenClosed principle there are a lot of things people can do themselves. Seam eats it's own dogfood and some parts are great examples of how thing in many cases can be done. E.g. I used the GWT and Wicket integration code as an example to make an XForms 'module'.

[luxspes]

Stuart Douglas wrote on Aug 27, 2009 10:28:


With regard to submitting patches I keep one 'clean' copy of the svn checkout and just make a new copy for every patch, hardly ideal, but it works. When a new branch is tagged you can just do a svn switch.

And another copy with all your patches mixedup? and how  do you handle pach dependencies...manually? and, how many people where you work also patch seam? how do you coordinate with them?

[swd847]

One copy per patch, so they are not all mixed up. I'm the only one that patches seam, so co-ordination is not really an issue. People have been contributing to open source long before distributed VCS came along.

The thing that frustrates me most about the seam development process is that there is very little traffic on seam-dev, I think the jboss people have most of their design discussions off list.

[luxspes]

Ronald van Kuijk wrote on Aug 27, 2009 11:29:


Wow, how many counter arguments... That is what I see very often. All kinds of (imo) not always valid arguments to not have/want to contribute back

• In SVN Seam is fairly modularized so the '7 step counter argument' is not really an issue imo.

You think? Okay, explain me please how to create a new scope type without modifying Seam 2 code? Or explain me how to replace the navigation code with my own implementation without recompiling... Maybe altering Nested conversations not to be long by default? or a way to getComponentFromParentConversation? not possible? I thought so...:-P

• Submitting patches 2 or 3 times via Jira is normal for a project so they can see you are capable. Afterwards, ask/get commit access and this becomes much easier.

Why not make it easier all the time (if SVK were better, or if hgsubversion were stable, I would already be easier)

• The internals of the really core parts maybe rocket science, many other parts are not


• Employers already pay lots of money for 'the basics' but they almost always do not see the hidden cost of keeping workarounds alive over a long time with different devs etc... way, way more costly

Patching for small not interdependent workarounds can be fine (as long as your concept of workaround matches Seam general direction), but new features (specially if they have dependencies with each other) are just too hard to handle as patches.

• A branche for user contributed stuff can always be made (navigation, temp nested conv.). That way people who dare can try out that code. It is stored centrally, others can play with it and it can in a later stage be integrated in trunk.

Or, as it happened with Tim, he keeps his own private code for himself

Even with just SVN and no OpenClosed principle there are a lot of things people can do themselves. Seam eats it's own dogfood and some parts are great examples of how thing in many cases can be done. E.g. I used the GWT and Wicket integration code as an example to make an XForms 'module'.

Oh, please do not get me wrong, I do like Seam, I am just more aware of its flaws than when I haven used it for over a year, every product has its flaws, and I do like the fact that Seam eats its own dog food (nothing better to remove bugs and add syntactic sugar), but I do think that Seam 2 architecture is too monolitic, and I would like that to change

[luxspes]

Stuart Douglas wrote on Aug 27, 2009 12:28:


One copy per patch, so they are not all mixed up. I'm the only one that patches seam, so co-ordination is not really an issue. People have been contributing to open source long before distributed VCS came along.

Yes,well, people were coding in punching cards long before compilers came along, that does not mean that was comfortable situation... (sorry if that sounds rude, but I really dislike the we have been doing it in a primitive cumbersome way for years, why improve? kind of argument)

[swd847]

Oh, please do not get me wrong, I do like Seam, I am just more aware of its flaws than when I haven used it for over a year, every product has its flaws, and I do like the fact that Seam eats its own dog food (nothing better to remove bugs and add syntactic sugar), but I do think that Seam 2 architecture is too monolitic, and I would like that to change

It always annoyed me somewhat that seam has this great component system that should allow you to override core behaviour really easily, but then because those core components where not abstracted behind interfaces and are full of private methods you can't. This is definatly something that I would like to see fixed in seam 3.

[luxspes]

Stuart Douglas wrote on Aug 27, 2009 12:48:

Oh, please do not get me wrong, I do like Seam, I am just more aware of its flaws than when I haven used it for over a year, every product has its flaws, and I do like the fact that Seam eats its own dog food (nothing better to remove bugs and add syntactic sugar), but I do think that Seam 2 architecture is too monolitic, and I would like that to change

It always annoyed me somewhat that seam has this great component system that should allow you to override core behaviour really easily, but then because those core components where not abstracted behind interfaces and are full of private methods you can't. This is definatly something that I would like to see fixed in seam 3.

I couldn't have written it better!

[kragoth]

Francisco Peredo wrote on Aug 27, 2009 12:38:

• A branche for user contributed stuff can always be made (navigation, temp nested conv.). That way people who dare can try out that code. It is stored centrally, others can play with it and it can in a later stage be integrated in trunk.

Or, as it happened with Tim, he keeps his own private code for himself

Hey Francisco, I didn't mean to keep my code private, I've just been really busy recently and havn't been on the forums much. If you would like I can go post my code (it is heavily customised for our application now so it might be difficult to work out exactly what's going on). I had planned to revisit my navigation code and make a version that anyone could pick up and use. But, I'm sure you know how it is.... all these great plans and the stupid clock keeps letting time go by too fast.

[asookazian]

Stuart Douglas wrote on Aug 27, 2009 12:48:


but then because those core components where not abstracted behind interfaces and are full of private methods you can't. This is definatly something that I would like to see fixed in seam 3.

like strategy pattern in Spring?  plug-in a new implementation class and the client doesn't even break or know what changed.

I've noticed that EE 5 and Seam don't seem to preach the strategy pattern a whole lot...

[luxspes]

Tim Evers wrote on Aug 28, 2009 01:07:


Hey Francisco, I didn't mean to keep my code private,

Thatis exactly my point, it is private because it is easier for you that way, if Seam were inside a distributed VCS, then it would probably have been easier for you to share it

I've just been really busy recently and havn't been on the forums much. If you would like I can go post my code (it is heavily customised for our application now so it might be difficult to work out exactly what's going on). I had planned to revisit my navigation code and make a version that anyone could pick up and use. But, I'm sure you know how it is.... all these great plans and the stupid clock keeps letting time go by too fast.

I'd love to be able to read it, but without a distributed VCS (like mercurial) exchanging ideas and modifications will require a lot of manual work, we could of course start a google code project and upload your code base there, and start playing around (that would be great BTW) but keeping it in sync with new Seam releases will not be an easy job.

[jkronegg]

Having read all your comments, I just would like to add my 2 cents to help Seam:

• go on JIRA (the Seam bug tracking system) and register (it's free and easy)


• look for the issues that impact your projects


• Vote for them!

This is some easy work that everyone can do. This gives some hints for the Seam developers and other freelance about where to patch and give some visibility to Seam.

P.S.: I can confirm that the learning curve is very high because of the several layers integrated (Hibernate, JSF, Richfaces, ... : about 10-12 technologies and API).

[jkronegg]

About Seam learning curve, I wrote some configuration tips to get meaningful information in the logs: Seam for dummies: Configuring the dev environment for meanningful information

P.S: in my previous post, I used the wrong tag (I wanted to bold everyone), but you probably understood anyway ;-)