[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
[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
[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