Checksum failures in M2 repository
by Trustin Lee
I found the .pom of some artifacts in repository.jboss.org/maven2 have
different MD5/SHA1 checksum from what their .pom.md5 and .pom.sha1
claims. This is a sort of a problem because it makes Maven to hit the
repository server twice (i.e. retries), slowing down the initial
build. I have fixed some of them, but I'm not sure I have fixed all
of them. I'm checking out the whole repository, but it's taking too
long. Probably someone with proper access right to the repository SVN
could fix this easily? I used the following shell script:
$ cat /usr/local/bin/update-pom-checksum
#!/bin/sh -e
find "$@" -name "*.pom" -print | while read F; do
sha1sum "$F" | perl -pi -e 's/ +.*[\r\n]//' > $F.sha1
md5sum "$F" | perl -pi -e 's/ +.*[\r\n]//' > $F.md5
done
If the checksum was correct, it wouldn't increase the commit traffic,
so I think it's fine to generate the checksum files for all .pom
files.
On the other hand, I also have found some .pom files don't have .md5
and .sha1 files at all. In this case, the checksum files need to be
added to the repository once they are generated (i.e. svn add.)
— Trustin Lee, http://gleamynode.net/
16 years, 11 months
JBoss AS 5.0.1.GA
by Dimitris Andreadis
Following popular vote/demand we'll deviate a bit from our AS 5.1 target to produce a
bug-fixing JBoss AS 5.0.1.GA release.
The target date is Jan/30th with a code freeze of Branch_5_0 on Jan/23rd.
Please help making sure that any critical bugs reported by the community are recorded
properly in JIRA. Fixes to the stable Branch_5_0 should also be applied to Branch_5_x and trunk.
At this point it seems our biggest issues with AS5 are related to VFS and/or deployment. Any
other issue you want to bring up for discussion, please do.
I'll come up with more info for the release, so stay tuned.
Thanks
/Dimitris
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
JBoss AS, Project Lead
JBoss, a Division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 12 months
[Fwd: [jboss-dev] Maven and non-existent versions of jboss-cache artifacts]
by Galder Zamarreno
Forwarding to jbosscache-dev(a)lists.jboss.org.
-------- Original Message --------
Subject: [jboss-dev] Maven and non-existent versions of jboss-cache
artifacts
Date: Mon, 12 Jan 2009 05:54:36 -0500 (EST)
From: Juraci Costa <jcosta(a)redhat.com>
Reply-To: JBoss.org development list <jboss-development(a)lists.jboss.org>
To: JBoss.org development list <jboss-development(a)lists.jboss.org>
All,
Is there anything I can read about how we publish artifacts to the main
maven repository and maybe suggest some change to that? I'm asking that
because it is not the first time I see a mismatch between version
numbers in the public maven repository. So, if we follow some guide when
publishing it to the main repository, we need to make certain to not use
SNAPSHOT (which are temporal, AFAIK), and use GA's instead.
Example:
Hibernate tag 3.3.1.GA points to jbosscache-core 2.1.1.GA
https://svn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.1.GA/cache-...
JBoss Cache core 2.1.1.GA says that its parent is
jbosscache-common-parent 1.3-SNAPSHOT
http://repository.jboss.org/maven2/org/jboss/cache/jbosscache-core/2.1.1....
But it doesn't exists. Only 1.3 or 1.4 are available.
http://repository.jboss.org/maven2/org/jboss/cache/jbosscache-common-parent/
To fix a local build, I can change my local jbosscache-core-2.1.1.GA.pom
to point to jbosscache-common-parent 1.3 or 1.4, but we would also need
to change it on our Hudson machines. Although possible, this sounds
wrong, as the builds should be reproducible without manual changes to
the environment :-)
- Juca.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years, 12 months
Administration_And_Configuration_Guide build error
by Scott Stark
After updating to the latest Administration_And_Configuration_Guide
contents, the package is failing with this CCE for me. Suggestions?
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] org.apache.fop.layoutmgr.inline.WrapperLayoutManager
[INFO]
------------------------------------------------------------------------
[INFO] Trace
java.lang.ClassCastException:
org.apache.fop.layoutmgr.inline.WrapperLayoutManager
at
org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:76)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:272)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:554)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:264)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301)
at
org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:157)
at
org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:385)
at
org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:148)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
at
com.icl.saxon.output.ContentHandlerProxy.endElement(ContentHandlerProxy.java:137)
at com.icl.saxon.output.ProxyEmitter.endElement(ProxyEmitter.java:91)
at
com.icl.saxon.output.NamespaceEmitter.endElement(NamespaceEmitter.java:150)
at
com.icl.saxon.output.GeneralOutputter.writeEndTag(GeneralOutputter.java:681)
at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:293)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:255)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at
com.icl.saxon.style.LiteralResultElement.process(LiteralResultElement.java:289)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at com.icl.saxon.Controller.defaultAction(Controller.java:271)
at com.icl.saxon.Controller.applyTemplates(Controller.java:236)
at
com.icl.saxon.style.XSLApplyTemplates.process(XSLApplyTemplates.java:135)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLIf.process(XSLIf.java:78)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLOtherwise.process(XSLOtherwise.java:48)
at com.icl.saxon.style.XSLChoose.process(XSLChoose.java:96)
at
com.icl.saxon.style.StyleElement.processChildren(StyleElement.java:634)
at com.icl.saxon.style.XSLTemplate.expand(XSLTemplate.java:225)
at com.icl.saxon.style.XSLTemplate.start(XSLTemplate.java:198)
at com.icl.saxon.Controller.applyTemplates(Controller.java:246)
at com.icl.saxon.Controller.run(Controller.java:178)
at com.icl.saxon.Controller.transformDocument(Controller.java:1086)
at com.icl.saxon.Controller.transform(Controller.java:953)
at
org.jboss.jdocbook.render.impl.BasicRenderer.performRendering(BasicRenderer.java:123)
at
org.jboss.jdocbook.render.impl.BasicRenderer.render(BasicRenderer.java:115)
at
org.jboss.maven.plugins.jdocbook.GenerationMojo.process(GenerationMojo.java:117)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.doExecute(AbstractDocBookMojo.java:260)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.execute(AbstractDocBookMojo.java:292)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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: 51 seconds
[INFO] Finished at: Thu Jan 08 11:24:48 PST 2009
[INFO] Final Memory: 12M/71M
[INFO]
------------------------------------------------------------------------
17 years
Include Web Beans RI in next JBoss 5 release
by Pete Muir
I would like to discuss including the Web Beans RI in the next release
of JBoss 5.
As Web Beans is quite young, I think we should include it as a
"Technology Preview". The included version should be at least
1.0.0.ALPHA2, out in the next couple of weeks.
We have a deployer for Web Beans, which looks like:
$ ls -lR webbeans.deployer
total 1008
drwxr-xr-x 4 pmuir admin 136 8 Jan 12:49 META-INF
-rw-r--r-- 1 pmuir admin 484056 8 Jan 12:49 google-collections.jar
drwxr-xr-x 6 pmuir admin 204 8 Jan 12:49 lib-int
-rw-r--r-- 1 pmuir admin 26744 8 Jan 12:49 webbeans-ri-int-
microcontainer.jar
webbeans.deployer/META-INF:
total 16
-rw-r--r-- 1 pmuir admin 286 8 Jan 12:49 jboss-structure.xml
-rw-r--r-- 1 pmuir admin 1686 8 Jan 12:49 webbeans-deployers-jboss-
beans.xml
webbeans.deployer/lib-int:
total 560
-rw-r--r-- 1 pmuir admin 37664 8 Jan 12:49 webbeans-api.jar
-rw-r--r-- 1 pmuir admin 29714 8 Jan 12:49 webbeans-ri-int-
jbossas.jar
-rw-r--r-- 1 pmuir admin 6713 8 Jan 12:49 webbeans-ri-spi.jar
-rw-r--r-- 1 pmuir admin 201152 8 Jan 12:49 webbeans-ri.jar
All jars in lib-int are inserted into the application's classpath by a
deployer.
The only task I can see to include Web Beans is to add the deployer to
the JBoss AS build - I can do this (with Ales' help ;-).
Anything I'm missing?
Pete
17 years
JBoss AS branching and next releases
by Dimitris Andreadis
Hi there and Happy New Year!
following up on the discussions about AS branching:
a) the branch that produced AS 5.0.0.GA should be considered "dead". We won't be doing a dot
release from this branch (5.0.1.CR1)
https://svn.jboss.org/repos/jbossas/branches/Branch_5_0/
b) trunk was instead branched into:
https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/
The next AS release to fix 5.0.0 glitches and introduce any missing EAP features will be
5.1. As it is now the branch produces 5.1.0.Beta1 but I'm not clear yet if we have time for
a Beta1 version; maybe we have to go directly to CR1.
c) trunk will produce the next AS6 release (6.0.0.Alpha1)
https://svn.jboss.org/repos/jbossas/trunk/
This is still WIP as to how exactly AS6 will look like, or if it will further broken out.
JIRA needs adjustment, so that all the 5.0.0.CR1 issues move to 5.1.0.Beta1. It also needs a
good cleaning up as we'll have more than 200 tasks scheduled for 5.1.
Hudson will be adjusted accordingly, too.
When we have a clearer idea about the effort needed for 5.1 we'll come up with target dates.
Cheers
/Dimitris
PS
for David: branch/Branch_xyz is just legacy from the CVS days...
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
JBoss AS, Project Lead
JBoss, a Division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years
jboss xsd versions
by Alexey Loubyansky
Now that 5.0.0.GA is released, I think, all changes/fixes should go into
different schema versions (although 5.0.0.GA is based on metadata CR and
GA hasn't been released yet) and all the xsd files with '5_0' in their
names shouldn't be modified.
Which versions should be used for the new schemas? 5_1? 5_0_1?
I want to make sure different JBoss schemas (ejb, web, client, app, etc)
follow same principles and share common structures. So, the next
versions won't be backwards compatible (differences in element order,
namespaces for some common types, etc).
Alexey
17 years
ServerInfo.getHostName()/getHostAddress() can show confusing information
by Galder Zamarreno
Hi,
I'm wondering whether the current implementation of
ServerInfo.getHostName() and ServerInfo.getHostAddress() are of any real
use, specially when the value passed via -b is different to
InetAddress.getLocalHost() which leads to confusion: You bind to X but
ServerInfo shows host name or host address being Y.
Besides, there's no easy way of checking what's the IP to which the
server is bound other than browsing through the system properties.
So, I'd suggest changing getHostName/getHostAddress to be based on
jboss.bind.address system property and this is not set fall back on
InetAddress.getLocalHost().
Thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years
