Duplicate entry in jboss-aspect-library-jdk50.jar
by Rajesh Rajasekaran
Looks like we have
org/jboss/aspects/remoting/AOPRemotingInvocationHandler coming from
jbossas/trunk/aspects and from the maven repo in
org/jboss/aspects/jboss-remoting-aspects
Which is the right version to use? The build should be altered to remove
the duplicate one.
This prevents the server startup.
Details here. https://jira.jboss.org/jira/browse/JBAS-5967
I wonder why we didn't catch this in the continuous runs. The only thing
different here is i started the release build on a machine with a clean
local maven repo.
Thanks
Rajesh
15 years, 7 months
Re: AS trunk freeze
by Ales Justin
I would rather include it into CR2,
if Adrian can provide some feedback on Monday.
Otherwise we're paying additional performance penalty
for visiting all things from ear's root.
Perhaps this can be included together with JBCL-43?
Dimitris Andreadis wrote:
> That's moving to GA, right?
>
> Ales Justin wrote:
>> I've got this issue:
>> - https://jira.jboss.org/jira/browse/JBAS-5895
>> -
>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175789#4175789
>>
>> Where, if you look at the cause,
>> the solution could/should be easy - if you know how to apply it . :-)
>> And it would save us a lot of performance time,
>> e.g. annotation scanning wouldn't scan wrong stuff.
>>
>> Hence it would be good if it would be included into AS5.CR2.
>> I'll play around a bit, if I can figure out how to apply that ear
>> filter in non-invasive way.
>> Although I was more counting for Adrian's input. :-)
>>
>> Dimitris Andreadis wrote:
>>> Unless you are working on some JBCTS tidy-up issue or a
>>> blocker/critical JBAS one, please refrain from making changes to AS
>>> trunk.
>>>
>>> If nothing urgent pops up we'll be releasing AS5 CR2 early next week,
>>> Monday 15th if possible.
>>>
>>> I'm cleaning up the JBAS jira, but you can help as well:
>>>
>>> Issues assigned to you
>>> https://jira.jboss.org/jira/secure/IssueNavigator.jspa?mode=hide&requestI...
>>>
>>>
>>> Issues reported by you
>>> https://jira.jboss.org/jira/secure/IssueNavigator.jspa?mode=hide&requestI...
>>>
>>>
>>> If you have any concerns, please let me know.
>>>
>>> Thank you
>>> /Dimitris
>>>
>>
15 years, 8 months
Re: AS5 remaining upgrades
by Andrew Lee Rubinger
JBAS-5840 defines requisite releases for non-CR-level JBoss Aspects
Projects. These are:
[alrubinger@localhost thirdparty]$ mvn dependency:tree
-Dincludes=org.jboss.aspects
[INFO] [dependency:tree]
[INFO] org.jboss.jbossas:jboss-as-thirdparty:pom:5.0.0-SNAPSHOT
[INFO] +-
org.jboss.aspects:jboss-transaction-aspects:jar:1.0.0.Beta1:compile
[INFO] +- org.jboss.aspects:jboss-security-aspects:jar:1.0.0.Beta3:compile
[INFO] +- org.jboss.ejb3:jboss-ejb3-core:jar:1.0.0-SNAPSHOT:compile
[INFO] | \-
org.jboss.aspects:jboss-remoting-aspects:jar:1.0.1.CR3:compile (version
managed from 1.0.1.CR4)
[INFO] \- org.jboss.ejb3:jboss-ejb3-security:jar:client:1.0.0-Beta1:compile
[INFO] \-
org.jboss.aspects:jboss-current-invocation-aspects:jar:1.0.0.CR1:compile
...so in violation are:
org.jboss.aspects:jboss-transaction-aspects:jar:1.0.0.Beta1
org.jboss.aspects:jboss-security-aspects:jar:1.0.0.Beta3:compile
...I've released:
jboss-aspects-build/1.0.1.CR5
jboss-transaction-aspects/1.0.0.CR1
jboss-security-aspects/1.0.0.CR1
I will integrate these with AS once they propogate to repository.jboss.org.
S,
ALR
Dimitris Andreadis wrote:
> In my list there are 2 remaining component updates:
>
> https://jira.jboss.org/jira/browse/JBAS-5840 - jboss aspects (Andrew)
> https://jira.jboss.org/jira/browse/JBAS-5938 - hibernate (Shelly)
>
> Can you provide a status please?
>
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com
15 years, 8 months
Microntainer CR releases - proper job
by Adrian Brock
WRT: https://jira.jboss.org/jira/browse/JBAS-5607
Let's work this properly and methodically
rather than doing random releases without notification
to the project lead.
The correct order for doing the candidate releases
(and the eventual final releases)
if you look at the dependencies should be:
jboss-reflect
jboss-mdr
jboss-man
jboss-mc
jboss-vfs
jboss-cl
jboss-deployers
Also since we are moving to candidate releases
(which could in effect be final releases)
these projects should be branched in SVN.
When doing a release, you should always check
it has the most up-to-date dependencies
(or at least is using the versions used by
JBossAS) and that the mvn dependency:tree is not
using spurious dependencies due to changes
in dependent poms.
Otherwise the project's unit tests are not
going to find problems that will occur
when the release is included in JBossAS.
Running a pre-release snapshot (equivalent binaries)
in a local JBossAS build is also a good way to make
sure you won't have to redo your releases
when it later gets integrated it into JBossAS.
Admitably, I didn't create the JIRA issues
for JBossCL like the other projects, e.g.
https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&pid=123...
I also need to look at why Scott's release
didn't create the parent pom .
i.e. whether it is an artifact of Paul's
maven refactoring or whether Scott just didn't
upload it?
I'll create a JBossCL CR2 when I do the proper
release, please treat CR1 as a BETA.
JBossMC, VFS and deployers still have outstanding
(minor?) issues as I mentioned in a thread earlier this week.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 8 months
place for seam-int-jbossas lib
by Ales Justin
I need a place in AS config where I will put optional
jboss-seam-int-jbossas.jar.
This is the jar which gets included into classpath when we recognize
deployment as Seam app.
Adrian suggested something like ${jboss.home.url}/integration/seam/.
This means we need to create this integration dir for the first time.
How does that sound?
Or is there already some place where this integration libs could be put.
We might have other int libs.
e.g. integration with various external frameworks that don't speak VFS ;-)
15 years, 8 months
stax-api, which version?
by Adrian Brock
Previously we were relying on JBossXB
providing the version of the stax api
which came via a transitive dependency from
http://repository.jboss.com/maven2/javax/xml/bind/jaxb-api/2.1/jaxb-api-2...
and was version 1.0-2
But JBossXB has since changed to use
http://repository.jboss.com/maven2/sun-jaxb/jaxb-api/2.1.4/jaxb-api-2.1.4...
which specifies no dependency.
The AS in component matrix is currently specifying version 1.0
Incidentally, I don't see 1.0-2 (whatever that means? :-)
in our repository
http://repository.jboss.com/maven2/stax/stax-api/
I'm going to switch the deployers which contains a JAXB deployer
that uses stax to have an **optional** dependency on 1.0
unless there is any objection.
<version.stax.staxapi>1.0</version.stax.staxapi>
<dependency>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
<version>${version.stax.staxapi}</version>
<optional>true</optional>
</dependency>
Which means anybody using this deployer would need to
specify there own version explicitly, but we compile over 1.0
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 8 months
