July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: Problems with maven builds again

by adrian＠jboss.org

Actually, changing it to packaging=pom means it doesn't compile anything so it wasn't even fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060515#4060515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060515

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Problems with maven builds again

by adrian＠jboss.org

I created a new project that uses Maven and built it, then imported it into svn and once I checked it out again, it stopped building (didn't find the dependent jars for compilation). jbossas/projects/integration To try to fix the problem, I did the usual trick of blowing away my local maven repository, but that still didn't fix it. I then compared it with the microcontainer pom and found a difference. The mc was using | <packaging>pom</packaging> | instead of jar. I changed it and then it compiled? No idea how it compiled before if this is the reason. To make sure I had it working, I did a mvn clean and mvn assembly:assembly and now it throws an NPE | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Transaction 5.0.0 SPI | [INFO] ---------------------------------------------------------------------------- | [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation. | [INFO] [site:attach-descriptor] | [INFO] [assembly:assembly] | [INFO] Reading assembly descriptor: /home/ejort/integration/build/assembly/bin.xml | [INFO] Reading assembly descriptor: /home/ejort/integration/build/assembly/sources.xml | [INFO] ------------------------------------------------------------------------ | [ERROR] FATAL ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] null | [INFO] ------------------------------------------------------------------------ | [INFO] Trace | java.lang.NullPointerException | at org.apache.maven.plugin.assembly.archive.ManifestCreationFinalizer.getVirtualFiles(ManifestCreationFinalizer.java:99) | at org.codehaus.plexus.archiver.AbstractArchiver.hasVirtualFiles(AbstractArchiver.java:546) | at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:258) | at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) | at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:513) | at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:103) | at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) | at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) | at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) | at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) | at org.codehaus.classworlds.Launcher.main(Launcher.java:375) | Not only that my MC build is failing on a different NPE | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Deployers Core SPI | [INFO] task-segment: [install] | [INFO] ---------------------------------------------------------------------------- | [INFO] [resources:resources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:compile] | [INFO] Nothing to compile - all classes are up to date | [INFO] [jboss-retro:retro-compile {execution: default}] | [INFO] [retro] Compiling classes for jdk14 | [INFO] [resources:testResources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:testCompile] | [INFO] Nothing to compile - all classes are up to date | [INFO] [surefire:test] | [INFO] ------------------------------------------------------------------------ | [ERROR] FATAL ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] null | [INFO] ------------------------------------------------------------------------ | [INFO] Trace | java.lang.NullPointerException | at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) | at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) | at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) | at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) | at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) | at org.codehaus.classworlds.Launcher.main(Launcher.java:375) | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 44 seconds | [INFO] Finished at: Wed Jul 04 17:04:49 CEST 2007 | [INFO] Final Memory: 24M/73M | [INFO] ------------------------------------------------------------------------ | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060512#4060512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060512

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by alesj

I've commited the changes. You can now use any of these two: - (1) from Adrian's list - setting up exact class - my preinstantiate attribute on property - setting it to false Let me know how it goes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060506#4060506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060506

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by juha＠jboss.org

I'm solidly in the camp of accepting ugliness in implementation for ease of use :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060487#4060487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060487

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by adrian＠jboss.org

"juha(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : There's no way to check whether a collections is modifiable or otherwise. | | | | True. You could address the scenario by catching the UnsupportedOperationException on Collection.add() and falling back to a default mechanism. | | It's not a complete solution but depending on how common you think the use case is, would address it without extra burden of configuration on user's part. It doesn't quite work the way you describe. The collection is first instantiated and then the values added. We could hack it like you describe, but it wouldn't be very clean. Maybe it is worth the ugliness for the ease of use? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060483#4060483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060483

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by juha＠jboss.org

"adrian(a)jboss.org" wrote : There's no way to check whether a collections is modifiable or otherwise. | True. You could address the scenario by catching the UnsupportedOperationException on Collection.add() and falling back to a default mechanism. It's not a complete solution but depending on how common you think the use case is, would address it without extra burden of configuration on user's part. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060476#4060476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060476

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by adrian＠jboss.org

Yes, but the whole point of pre-instantiated is to reduce the amount users have to write in xml - not least because it can also become inconsistent if they have to do it two places. Imagine if Juha's class was: | public class PluginManager | { | private List bootstrapPlugins = new CopyOnWriteArrayList(10); | | public void setBootstrapPlugins(List listOfPluginNames) | { | this.bootstrapPlugins = listOfPluginNames; | } | | public List getBootstrapPlugins() | { | return bootstrapPlugins; | } | } | The user doesn't want to have to say "preinstantiated=true" or class="java.util.concurrent.CopyOnWriteArrayList" to make this work how they would expect! It should just work out of the box. It's only in classes like Juha's where you have to turn off preinstantiated because the getter is returning an immutable. Therefore you need to be explicit about what implementation you really want, we can't work it out. We should optimize for the common cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060455#4060455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060455

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by alesj

Yes, but this means people have to explicitly write class="java.util.ArrayList" if they don't want to use preinstantiated instance. All they really want is to write (list)...elements(/list). I leave the preinstantiated attribute - false by default. I think it is simple enough. What we really wanted is to have Juha's case resolved. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060444#4060444 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060444

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Bug in JBoss Portal 2.6 GA Version

by julien＠jboss.com

the change for 1527 is : | Modified: branches/JBoss_Portal_Branch_2_6/core-admin/src/resources/portal-admin-war/WEB-INF/jsf/dashboard/dashboard.xhtml | =================================================================== | --- branches/JBoss_Portal_Branch_2_6/core-admin/src/resources/portal-admin-war/WEB-INF/jsf/dashboard/dashboard.xhtml 2007-07-04 12:35:36 UTC (rev 7662) | +++ branches/JBoss_Portal_Branch_2_6/core-admin/src/resources/portal-admin-war/WEB-INF/jsf/dashboard/dashboard.xhtml 2007-07-04 12:49:53 UTC (rev 7663) | @@ -53,7 +53,7 @@ | id="pageNameSelector" | value="#{dashboard.selectedPageName}" | styleClass="portlet-form-field" | - onclick="document.getElementById('page_selector_form').submit()"> | + onchange="document.getElementById('page_selector_form').submit()"> | <f:selectItems value="#{dashboard.pageItems}"/> | </h:selectOneMenu> | </h:form> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060443#4060443 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060443

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AbstractCollectionMetaData fails with optional add() ope

by adrian＠jboss.org

Actually (2) is probably not correct in the above, it should come between (3) and (4) It doesn't actually exist for properties (except as a hack/short hand for string value properties - not relevant here) and actually defines which constructor/method to use for parameters so it would always override the preinstantiated which isn't what is wanted and sometimes it will just represent an interface anyway (because that is the parameter type). So, the correct order should be: 1) AbstractTypeMetaData.getClassInfo(ClassInfo); 2) preinstantiated 3) TypeInfo in getValue() parameters 4) Default collection type But can still stop the getter being used by adding a class= to the list element. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060442#4060442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060442

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007