[Design of JBoss Build System] - General Build System Update
by pgier
I haven't provided a general update for the build project in a while, so I thought I would give a summary of what is going on.
Current projects
---------------------
System for retro builds - I'm working on an improved system for retro jdk14 builds so that these builds can work more easily (tests, deployment, etc.) with the standard builds. See this thread for more information.
JBoss.org site integration - It would be very helpful to be able to deploy a maven generated site directly to jboss.org. This will reduce the need for creating wiki documentation, and will help standardized the organization of project sites. I have made some progress on this and have created sites for jboss-retro, maven-jboss-retro-plugin, and maven-jdocbook-plugin. These can be seen on the jboss.org site.
Docbook - Working on configuring microcontainer and other projects to use the maven-jdocbook-plugin.
Future stuff
---------------
Repository synchronization - soon we should have automated synchronization between the jboss repository and the central maven repository.
Standardized release process - The goal is to have standardized reproducible builds and releases. Some issues have been found related to integration of koji with maven, so there is some work to do on the maven side for this.
Mavenization of app server - the plan is to finish this within the next couple of months.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072760#4072760
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072760
18 years, 8 months
[Design of JBoss Build System] - Re: JDK 1.4 Compatibility for Microcontainer and other Proje
by pgier
After messing with this stuff for a while. I decided to use a single repository and just have different artifactIds for jdk14 artifacts (similar to what Ryan suggested). I was hoping that having two separate repositories would make things simpler because I would be able to translate dependency jars from a jdk15 repository and put them into the jdk14 repository. And that way a project could be easily built.
But I ran into problems trying to keep the jdk5 and jdk14 artifacts sorted out, especially in the local repository. Because if the jdk14 artifacts have the same name, they overwrite the jdk5 artifacts, and the local repo gets messed up. Also the maven ant tasks used to run the retro tests were having problems using the jdk14 repository.
So the current plan is to use profiles to have two different artifactIds. A maven profile doesn't allow me to modify the artifactId directly, but I can use a property in the profile to change the artifactId. The good thing is that this will allow projects to use transitive dependencies, but still be in a single repository. The bad part is that I will have to go back to some of the released versions of dependency projects and create retro versions of these projects, so that part will take some effort.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072745#4072745
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072745
18 years, 8 months
[Design of JBoss Portal] - Re: portletbridge/web-clipping
by cdelashmutt
After trying out the latest portletbridge (circa Jan 2007), I'm beginning to question the value of a full page in a portlet window. It seems to me that it might be more useful to simply clip a small part of a page. For instance, there is perhaps this table that you want to display, but you really don't need anything else.
Web Clipping in general has many challenges. Does it make sense to include CSS styling from the source? What about JavaScript? Personally, I'd rather the source strictly be used for data, and the portal styles should be applied to the content.
Specific to portletbridge, I tried to point it to Slashdot, which is what they seem to use for testing. In Portal 2.6, this causes the Renaissance theme to get corrupted. I don't know if this is a Portal problem or what, but it seems like the slashdot styles are leaking into Portal. The image and link HREF stuff does seem to be re-written properly, it's just that styling that is messed up.
Strangely, portletbridge actually only seems to work properly with plan HTML. If I try to go to a site that claims to be XHTML, I start getting problems. For instance, I've tried to clip some stuff from a site running RT, and none of the link re-writing works.
Is there any interest in this type of a feature? I thought I was interested, but I don't know if it even makes sense now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072711#4072711
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072711
18 years, 8 months
[Design the new POJO MicroContainer] - Re: PropertyInfo type creation
by scott.stark＠jboss.org
"alesj" wrote : "scott.stark(a)jboss.org" wrote : We should be restrictive on the type so if the setter is more specific use that.
| Any general rules on what is more restrictive?
| Or how to write AbstractBeanInfoFactory.getPropertyType()? ;-)
It has to be some compiler problem solution. It seems you have to have a type tree for the non-parameterized type and find the most derived type, and then the most derived parameterized type. For these two examples of property accessors, List would be determined for both.
| public List getBeans()
| {
| return beans;
| }
|
| public void setBeans(Iterable<SimpleBean> beans)
| {
| this.beans = beans;
| }
|
| public Iterable<SimpleBean> getBeans()
| {
| return beans;
| }
|
| public void setBeans(List beans)
| {
| this.beans = beans;
| }
|
| public Iterable<SimpleBean> getBeans()
| {
| return beans;
| }
|
| public void setBeans(List beans)
| {
| this.beans = beans;
| }
|
It gets more complicated if a concrete type vs an interface is used though, as in this crazy example:
| public Iterable<SimpleBean> getBeans()
| {
| return beans;
| }
|
| public void setBeans(javax.management.AttributeList beans)
| {
| this.beans = beans;
| }
|
where AttributeList is a non-parameterized List with overloaded methods for adding/setting elements of type javax.management.Attribute, a non-interface type. If SimpleBean is a class its impossible to reconcile all expected uses. Its possible if SimpleBean is an interface, but that is a crazy type graph to figure out.
I guess the main question is how much trouble do we want to go to at this point? What does the java.beans.Introspector return for the BeanInfo.PropertyDescriptor for such examples? Does it match up these as the same property with a common type, or does it see these as the same property with different accessors, or a conflict?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072685#4072685
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072685
18 years, 8 months