April 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: jboss metadata pom

by heiko.braun＠jboss.com

Currently we have a mix of artifacts that have been converted from our previous repository format (was this automated, Paul?), whic contain wrong names and stuff that's been properly added (i.e. manual release). I think we need to migrate anything to the proper naming convention at once. Especially with CR1 being close everyday new artifacts pop-up and reference legacy names. This way we never get to a clean repo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141246#4141246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141246

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Maven release artifacts

by heiko.braun＠jboss.com

This leads to the question if we want to migrate the build to maven or simply add maven release capabilities to it, which is probably easier but may cause issue in the long run, when more and more project migrate. Maybe there is a partly solution? Like brining in Ivy for dependency management? Basically I see the only benefit in leveraging maven repositories. We need to be able to publish to and retrieve from a maven repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141241#4141241 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141241

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Maven release artifacts

by heiko.braun＠jboss.com

In order to simplify integration with AS 5, it would be helpful to create maven artifacts of our binaries that follow a naming convention. Currently the only artifacts that's manually being released to the repo is jbossws-spi (org.jboss.ws:jbossws-spi:jar) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141240#4141240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141240

18 years

1
0
0 / 0

[Design of JBoss Build System] - To be Mavenized or not to be Mavenized

by richard.opalka＠jboss.com

I'm really surprised such clever people like you JBoss AS developers are are still playing with Maven and still plan to use it in the future :( Yes, Maven is maybe good but for small or medium (less than 10 modules) projects (just my point of view). However if the project is bigger one (JBoss AS belongs to this set of projects) Maven becomes very useless. We will fight with problems like: * Ooops, where did we introduced this dependency? In which POM in the whole POM hierarchy was it? * Why this conflict wasn't detected by Maven? What did we wrong? * Is it our problem or Maven problem? * Why the AS doesn't build again? Who broke the build again? ... I won't enumerate all the troubles we will face in the future. I've used Maven for long time and once you don't have the full control over dependencies you can't just put it to some black box (Maven in our case) and rely on the fact it will do its job as expected :( There are many bugs in Maven dependencies handling mainly when you will start playing with dependency wildcards. Big projects like JBoss AS have to have the full control over the dependencies mechanism. If we were not satisfied with old dependencies resolution mechanism we should develop better one. What I'm trying to say? * Maven is good in theory but bad in practice (I mean for big software projects) * Maven has poor documentation. Mainly for the most critical parts of it like dependencies mechanism handling etc. * Maven is a black box. Black hall is a better term I would say. Yes there are some attempts from Adrian to make its dependencies handling mechanism a white box but shouldn't it be part of Maven exhausting documentation? * Maven isn't a build tool. Why we're using it for AS building purposes as well? I thought we're trying to get the most from its dependencies handling only? * If we will use Maven in the future we will need to put a big effort to educate new joiners to be Maven comfortable and don't break the things on their first touch to Maven POMs. * We will create the following forums in the future: - Maven Builds Issues Forum (40 % of all posts) - Maven Dependencies Issues Forum (30 % of all posts) - Maven Rewrite Forum (20 % of all posts) - Maven ... (5 % of all posts) - Rest Topics Forum (JBoss AS development, JBoss AS subprojects) (5 % of all posts) Do we really want to become Mavenized at all cost dear friends? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141238#4141238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141238

18 years

1
0
0 / 0

[Design of JBoss IIOP on JBoss] - Is JacORB.JAR in the bootclasspath?

by lzap

Hello, it seems I do not understand classloading of JBoss. Does have classes from jacorb.jar higher priority than from JREs rt.jar? Because we encouter problems when classes from JREs org.omg are used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141229#4141229 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141229

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - Snapshots during development

by heiko.braun＠jboss.com

If I understand the version format correctly, maven regards artifacts that contain a qualifier as snapshots anyway. (See my addition to the version format thread). This means to me, that if we switch from snapshot releases (X-SNAPSHOT) to beta milestones (X-Beta-1, X-Beta-2) instead, we should have proper dependency resolution when using version ranges. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141206#4141206 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141206

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by heiko.braun＠jboss.com

I mean there is so much implicit behavior build into it, that can easily become a nightmare if we want to circumvent what's given. But I think that's a general maven policy. It's the way it is. If you want to do things differently, you get into trouble. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141203#4141203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141203

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by heiko.braun＠jboss.com

The more I get into it, the more I start thinking we should switch to the maven version format. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141201#4141201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141201

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by heiko.braun＠jboss.com

Another useful pick from "BetterBuildsWithMaven": anonymous wrote : | With regard to ordering, the elements are considered in sequence to determine which is newer - first | by major version, second - if the major versions were equal - by minor version, third by bug fix version, | fourth by qualifier (using string comparison), and finally, by build number. A version that contains a | qualifier is older than a version without a qualifier; for example, 1.2-beta is older than version 1.2. A | version that also contains a build number is considered newer than a version without a build number; | for example, 1.2-beta-1 is newer than 1.2-beta. In some cases, the versions will not match this syntax. | In those cases, the two versions are compared entirely as strings. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141200#4141200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141200

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Root cause with iDependOn equal null

by alesj

"scott.stark(a)jboss.org" wrote : I believe it should just be <UNKNOWN + item.getName() +> so all dependencies on the unknown provider of name are seen as the same. | OK, I'll use that. And then I'll group the values for the same key. e.g. mykey --> somedep mykey --> otherdep ==> mykey -- > [somedep, otherdep] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141199#4141199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141199

18 years

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 April 2008