9:28 a.m.
Well done guys.
We've had *five* broken builds this week,
two of them today (or so I'm told because I've not resynched
after fixing the vfs issue from this morning).
With the exception of Scott forgetting to commit
his new resolver deployer most of these have been
due to broken uses of version control.
i.e. broken snapshots or what was equivalent
Clebert's retagging of a jboss messaging release
With no proper version control we can't even rollback
the broken builds :-(
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:40 a.m.
This probably doesn't have the slightest chance of happening, but here I
go: I wrote a dependency management and release automation tool that's
available here for download:
https://sourceforge.net/project/showfiles.php?group_id=224810 I
volunteer to install it, make it work in your environment and work with
you to adapt it to JBoss' needs, starting with a small project first and
then expanding it, if proves to be successful.
It's a lightweight replacement for Maven and I am using it for my
projects. My clients are using it as well.
There's a user manual under doc, if you download the bundle.
Cheers,
Ovidiu
Adrian Brock wrote:
i.e. broken snapshots or what was equivalent
Clebert's retagging of a jboss messaging release
With no proper version control we can't even rollback
the broken builds :-(
9:48 a.m.
The main issue is misuse of version control and
people doing "half-a-commit".
No build tool is going to solve those problems. ;-)
P.S. It looks like the latest breakage was my fault.
i.e. no "svn add" before "svn commit"
Ironic. ;-)
On Fri, 2008-04-18 at 07:40 -0700, Ovidiu Feodorov wrote:
This probably doesn't have the slightest chance of happening, but
here I
go: I wrote a dependency management and release automation tool that's
available here for download:
https://sourceforge.net/project/showfiles.php?group_id=224810 I
volunteer to install it, make it work in your environment and work with
you to adapt it to JBoss' needs, starting with a small project first and
then expanding it, if proves to be successful.
It's a lightweight replacement for Maven and I am using it for my
projects. My clients are using it as well.
There's a user manual under doc, if you download the bundle.
Cheers,
Ovidiu
Adrian Brock wrote:
> i.e. broken snapshots or what was equivalent
> Clebert's retagging of a jboss messaging release
>
> With no proper version control we can't even rollback
> the broken builds :-(
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:55 a.m.
A way to solve it is to partition your work into pieces that produce
autonomous artifacts, which are (automatically) tested before you
publish them in the repository. Then your final product becomes an
assembly of artifacts, not source files.
You handle versioned complex artifacts the same way you handle your
source files, with the added bonus that you can tell an artifact is
functional and you can prove it.
Just a thought.
Adrian Brock wrote:
The main issue is misuse of version control and
people doing "half-a-commit".
No build tool is going to solve those problems. ;-)
P.S. It looks like the latest breakage was my fault.
i.e. no "svn add" before "svn commit"
Ironic. ;-)
On Fri, 2008-04-18 at 07:40 -0700, Ovidiu Feodorov wrote:
> This probably doesn't have the slightest chance of happening, but here I
> go: I wrote a dependency management and release automation tool that's
> available here for download:
> https://sourceforge.net/project/showfiles.php?group_id=224810 I
> volunteer to install it, make it work in your environment and work with
> you to adapt it to JBoss' needs, starting with a small project first and
> then expanding it, if proves to be successful.
>
> It's a lightweight replacement for Maven and I am using it for my
> projects. My clients are using it as well.
>
> There's a user manual under doc, if you download the bundle.
>
> Cheers,
> Ovidiu
>
>
> Adrian Brock wrote:
>
>> i.e. broken snapshots or what was equivalent
>> Clebert's retagging of a jboss messaging release
>>
>> With no proper version control we can't even rollback
>> the broken builds :-(
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
10:25 a.m.
Ovidiu Feodorov wrote:
A way to solve it is to partition your work into pieces that produce
autonomous artifacts, which are (automatically) tested before you
publish them in the repository. Then your final product becomes an
assembly of artifacts, not source files.
Isn't that what "mvn install" does?
I might be wrong but I think you're hijacking Adrian's thread...
You handle versioned complex artifacts the same way you handle your
source files, with the added bonus that you can tell an artifact is
functional and you can prove it.
Just a thought.
Adrian Brock wrote:
> The main issue is misuse of version control and people doing
> "half-a-commit".
> No build tool is going to solve those problems. ;-)
>
> P.S. It looks like the latest breakage was my fault.
>
> i.e. no "svn add" before "svn commit"
>
> Ironic. ;-)
>
> On Fri, 2008-04-18 at 07:40 -0700, Ovidiu Feodorov wrote:
>
>> This probably doesn't have the slightest chance of happening, but
>> here I go: I wrote a dependency management and release automation
>> tool that's available here for download:
>> https://sourceforge.net/project/showfiles.php?group_id=224810 I
>> volunteer to install it, make it work in your environment and work
>> with you to adapt it to JBoss' needs, starting with a small project
>> first and then expanding it, if proves to be successful.
>>
>> It's a lightweight replacement for Maven and I am using it for my
>> projects. My clients are using it as well.
>>
>> There's a user manual under doc, if you download the bundle.
>>
>> Cheers,
>> Ovidiu
>>
>>
>> Adrian Brock wrote:
>>
>>> i.e. broken snapshots or what was equivalent
>>> Clebert's retagging of a jboss messaging release
>>>
>>> With no proper version control we can't even rollback
>>> the broken builds :-(
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
_______________________________________________
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
10:46 a.m.
On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
<galder.zamarreno(a)redhat.com> wrote:
Isn't that what "mvn install" does?
I might be wrong but I think you're hijacking Adrian's thread...
Personally, I think Maven is an abomination. +1 to any proposal to get
rid of this piece of junk ASAP.
Rémy
10:51 a.m.
Can't we just stop using snapshots... give it a nightly build release
name, and that's it. If you want to call it snapshot-XYZ.. that's
fine... tomorrow you release snapshot-XYZ2... and we can aways come back
to any point we like on the version control.
I reckon I did a mistake on the retag, but that's something everybody is
doing, since the old build-magic... so this is an old problem even
before maven.
Rémy Maucherat wrote:
On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
<galder.zamarreno(a)redhat.com> wrote:
> Isn't that what "mvn install" does?
>
> I might be wrong but I think you're hijacking Adrian's thread...
Personally, I think Maven is an abomination. +1 to any proposal to get
rid of this piece of junk ASAP.
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:09 a.m.
Clebert is 100% correct. If you're going to post a snapshot, give it a
unique name. It could be the SVN revision, or the date & time, or just a
numeric identifier. Uploading an non-uniquely-named snapshot is just as
bad as retagging.
Doesn't the much-reviled maven even have a built-in named snapshot
generation thing?
- DML
On 04/18/2008 10:51 AM, Clebert Suconic wrote:
Can't we just stop using snapshots... give it a nightly build
release
name, and that's it. If you want to call it snapshot-XYZ.. that's
fine... tomorrow you release snapshot-XYZ2... and we can aways come back
to any point we like on the version control.
I reckon I did a mistake on the retag, but that's something everybody is
doing, since the old build-magic... so this is an old problem even
before maven.
Rémy Maucherat wrote:
> On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
> <galder.zamarreno(a)redhat.com> wrote:
>> Isn't that what "mvn install" does?
>>
>> I might be wrong but I think you're hijacking Adrian's thread...
>
> Personally, I think Maven is an abomination. +1 to any proposal to get
> rid of this piece of junk ASAP.
>
> Rémy
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:11 a.m.
Here's an idea.
How about adding an SVN pre-commit hook to repository.jboss.org that
rejects any attempt to create or commit to any directory that matches
**/snapshot/** (other than to delete them). :-)
- DML
On 04/18/2008 11:09 AM, David M. Lloyd wrote:
Clebert is 100% correct. If you're going to post a snapshot,
give it a
unique name. It could be the SVN revision, or the date & time, or just
a numeric identifier. Uploading an non-uniquely-named snapshot is just
as bad as retagging.
Doesn't the much-reviled maven even have a built-in named snapshot
generation thing?
- DML
On 04/18/2008 10:51 AM, Clebert Suconic wrote:
> Can't we just stop using snapshots... give it a nightly build release
> name, and that's it. If you want to call it snapshot-XYZ.. that's
> fine... tomorrow you release snapshot-XYZ2... and we can aways come
> back to any point we like on the version control.
>
> I reckon I did a mistake on the retag, but that's something everybody
> is doing, since the old build-magic... so this is an old problem even
> before maven.
>
>
> Rémy Maucherat wrote:
>> On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
>> <galder.zamarreno(a)redhat.com> wrote:
>>> Isn't that what "mvn install" does?
>>>
>>> I might be wrong but I think you're hijacking Adrian's thread...
>>
>> Personally, I think Maven is an abomination. +1 to any proposal to get
>> rid of this piece of junk ASAP.
>>
>> Rémy
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:15 a.m.
Assuming the risk of Galder accusing me again that I hijack the thread,
I'll just that that yes, that system works extremely well.
Instead of calling them "snapshots", I call them "r" releases (from
SVN
revision number), and I can end up with a hundred of them in the
artifact repository. If this bothers you, once the product reaches a GA,
and all its dependencies are tagged with point releases (ideally GAs
too), all "r" releases can be deleted from the repository, thus saving
you precious milli-cents per MB disk space.
David M. Lloyd wrote:
Clebert is 100% correct. If you're going to post a snapshot,
give it
a unique name. It could be the SVN revision, or the date & time, or
just a numeric identifier. Uploading an non-uniquely-named snapshot
is just as bad as retagging.
Doesn't the much-reviled maven even have a built-in named snapshot
generation thing?
- DML
On 04/18/2008 10:51 AM, Clebert Suconic wrote:
> Can't we just stop using snapshots... give it a nightly build
> release name, and that's it. If you want to call it snapshot-XYZ..
> that's fine... tomorrow you release snapshot-XYZ2... and we can aways
> come back to any point we like on the version control.
>
> I reckon I did a mistake on the retag, but that's something everybody
> is doing, since the old build-magic... so this is an old problem even
> before maven.
>
>
> Rémy Maucherat wrote:
>> On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
>> <galder.zamarreno(a)redhat.com> wrote:
>>> Isn't that what "mvn install" does?
>>>
>>> I might be wrong but I think you're hijacking Adrian's thread...
>>
>> Personally, I think Maven is an abomination. +1 to any proposal to get
>> rid of this piece of junk ASAP.
>>
>> Rémy
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:18 a.m.
It's just decided then?
The next person to commit a non-unique-name or non-tagged, or to retag
any other component will be called "idiot of the day" in a public post.
Andrew Lee Rubinger wrote:
David M. Lloyd wrote:
> Doesn't the much-reviled maven even have a built-in named snapshot
> generation thing?
Yes, Maven calls it a "release". ;)
S,
ALR
>
> On 04/18/2008 10:51 AM, Clebert Suconic wrote:
>> Can't we just stop using snapshots...
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:06 a.m.
New subject: Maven Complaints [Was: Broken builds]
Rémy Maucherat wrote:
Personally, I think Maven is an abomination. +1 to any proposal to
get
rid of this piece of junk ASAP.
Rémy
Ultra constructive, bravo!
Upon what are you basing this opinion? And what helpful solutions would
you recommend to solve the issues giving you trouble?
We've outgrown the monolithic AS layout, and need to be adopting a
componentized structure where each project pushes forth frequent
releases for integration.
Most of the problems we've encountered can be chalked up to Maven's
exposure of an improper build process that we've inflicted upon
ourselves during the breakout of AS components. Bringing cyclic
dependencies to the forefront gives us a fail-fast that prevents release.
With the new mandate set to remove all snapshots from the AS
component-matrix, we can expect to see reliably reproducible builds.
Snapshots were just as horrid with the older Thirdparty setup.
Maven is just a build tool, and it's not the offender here. Until
snapshots are gone and the new projects have a proper dependency chain,
we'll be in the muck pointing fingers at one another.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com
11:11 a.m.
New subject: Maven Complaints [Was: Broken builds]
Andrew Lee Rubinger wrote:
With the new mandate set to remove all snapshots from the AS
component-matrix, we can expect to see reliably reproducible builds.
Snapshots were just as horrid with the older Thirdparty setup.
I know there was an older discussion on snapshots, but I don't remember
the conclusion.
Regardless of the dependency management/build tool, if one handles
artifacts the same way it handles a source code file, in that you never
"re-tag", then it shouldn't be any problems, or at least I never had any.
Assuming that your sub-project is producing an artifact a.jar and it
publishes it as a.jar version r100 (the SVN revision number), that r100
will "forever" stay in the artifact repository, unchanged, so any
dependents will use that specific "snapshot" unless they explicitly
declare they want another one.
If I patch my artifact, I release and publish r105 (or whatever), while
r100 is still available in the repository and all "outdated" dependents
still have their dependency satisfied and they don't break.
How can this not work?
11:32 a.m.
New subject: Maven Complaints [Was: Broken builds]
On Fri, Apr 18, 2008 at 6:06 PM, Andrew Lee Rubinger
<andrew.rubinger(a)redhat.com> wrote:
Rémy Maucherat wrote:
> Personally, I think Maven is an abomination. +1 to any proposal to get
> rid of this piece of junk ASAP.
>
> Rémy
>
Ultra constructive, bravo!
My pleasure :)
Upon what are you basing this opinion? And what helpful solutions
would
you recommend to solve the issues giving you trouble?
I base my opinion on this after looking at what Maven is doing when
downloading dependencies, and how it apparently needs specific
configuration to consider downloading the right thing.
The solutions I recommend are consider non broken alternatives [I see
Ovidiu's showing up with something, for instance], or switching back
to thirdparty (it has flaws but is easier to manage).
We've outgrown the monolithic AS layout, and need to be adopting
a
componentized structure where each project pushes forth frequent releases
for integration.
If this could stop, it would be nice. It has been going on for months :(
Most of the problems we've encountered can be chalked up to
Maven's
exposure of an improper build process that we've inflicted upon ourselves
during the breakout of AS components. Bringing cyclic dependencies to the
forefront gives us a fail-fast that prevents release.
With the new mandate set to remove all snapshots from the AS
component-matrix, we can expect to see reliably reproducible builds.
Snapshots were just as horrid with the older Thirdparty setup.
No. Maven stores JARs in two places, I have found (its own, and
thirdparty). This causes management problems that did not exist
before. Also, errors in poms yield non existent error messages
(stacktrace with "invalid POM" without mention on what or where the
error was).
Maven is just a build tool, and it's not the offender here.
Until
snapshots are gone and the new projects have a proper dependency chain,
we'll be in the muck pointing fingers at one another.
I think the snashots are not at fault, it's simply the tool that is
completely inappropriate. Since you force fed me with this great tool,
I think I have to pass on my thanks for making my job harder, I
appreciate it :)
Rémy
11:47 a.m.
New subject: Maven Complaints [Was: Broken builds]
Rémy Maucherat wrote:
I base my opinion on this after looking at what Maven is doing when
downloading dependencies, and how it apparently needs specific
configuration to consider downloading the right thing.
Well, we've been specifying "suggestions" to the dependency resolution
mechanism. This gives Maven free reign to resolve based on a "nearest
wins" model in the tree. After we stabilize with specific versions, we
should be *constraining* into compatible version ranges using the
bracket syntax. Anything that doesn't fit will fail the build.
> We've outgrown the monolithic AS layout, and need to be
adopting a
> componentized structure where each project pushes forth frequent releases
> for integration.
If this could stop, it would be nice. It has been going on for months :(
So we keep everything together under repos/jbossas/trunk? This presents
that:
* No IDE can handle such a huge codebase
* Every project must be tagged and released together
...which means that EJB3, as a defining example, would not be able to
push time-boxed releases to the community without waiting on the rest of
AS stabilizing and going through QA.
For the past 3 days, AS has been so unstable that it's been nearly
impossible to develop. Back when the EJB3 Plugin was compatible with
Beta4, our project did not have to worry about being stalled because of
regression introduced into AS. It's a matter of numbers; too many hands
in one codebase, and one commit is sure to bring down the whole house
eventually.
No. Maven stores JARs in two places, I have found (its own, and
thirdparty). This causes management problems that did not exist
before. Also, errors in poms yield non existent error messages
(stacktrace with "invalid POM" without mention on what or where the
error was).
Another point eased by restricting to releases, not snapshots, pushed
upstream to consumers of your project. :)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com
12:15 p.m.
New subject: Current Snapshots WAS:Maven Complaints [Was: Broken builds]
Ok... these are the current snapshots we have... maybe we should start
getting rid of them (next update to any of these snapshots should
include any sort of UniqueIDs)
<version.jboss.jbossws-framework>3.0.2-SNAPSHOT</version.jboss.jbossws-framework>
<version.org.jboss.deployers>2.0.0-SNAPSHOT</version.org.jboss.deployers>
<dependency>
<groupId>org.jboss.aspects</groupId>
<artifactId>jboss-remoting-aspects</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.jboss.aspects</groupId>
<artifactId>jboss-security-aspects</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.jboss.aspects</groupId>
<artifactId>jboss-transaction-aspects</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-common</groupId>
<artifactId>jbossws-common</artifactId>
<version>1.0.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>jbossws-framework</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>resources</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-vfs</artifactId>
<version>2.0.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>jboss</groupId>
<artifactId>jboss-common-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.cluster</groupId>
<artifactId>jboss-ha-client</artifactId>
<version>1.1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.jboss.cluster</groupId>
<artifactId>jboss-ha-server-api</artifactId>
<version>1.1.0-SNAPSHOT</version>
</dependency>
EJB3 has a bunch (but there is a version number on each one.. maybe this
is okay)
12:24 p.m.
New subject: Current Snapshots WAS:Maven Complaints [Was: Broken builds]
Clebert Suconic wrote:
Ok... these are the current snapshots we have... maybe we should
start
getting rid of them (next update to any of these snapshots should
include any sort of UniqueIDs)
Thank you for this audit, Clebert.
I'm sure Dimitris and the rest of the AS team would appreciate any help
that could be given towards the definition of SPIs where some are
lacking, resolving cyclic dependencies, and making releases of the
current snapshots. He's the point guy for any questions on this front.
Brian is already working on Clustering, Anil on Security. The aspects
mentioned are now in repos/jbossas/projects/jboss-aspects and (I
believe) are nearly ready for release, pending some more love to 'em.
EJB3 has a bunch (but there is a version number on each one.. maybe
this
is okay)
Nope, EJB3 team is looking forward to a proper release next week, but
until our transitive dependencies all have releases, we can't deliver
that yet. :)
Been pushing hard the past couple weeks towards that end. ;)
S,
ALR
3:39 a.m.
New subject: Current Snapshots WAS:Maven Complaints [Was: Broken builds]
Guys, the team has been locked in a room in the last two weeks,
componentizing the build. Dimitris is in close touch with the very few
persons that still need to deliver the SPI/releases. Once this is done,
we should clearly be able to see much more stability. Dimitris will send
new "guidelines" to this ML once all releases/SPI will have been
contributed. Stay tuned.
Cheers,
sacha
On 04/18/2008 07:24 PM, Andrew Lee Rubinger wrote:
Clebert Suconic wrote:
> Ok... these are the current snapshots we have... maybe we should start
> getting rid of them (next update to any of these snapshots should
> include any sort of UniqueIDs)
Thank you for this audit, Clebert.
I'm sure Dimitris and the rest of the AS team would appreciate any help
that could be given towards the definition of SPIs where some are
lacking, resolving cyclic dependencies, and making releases of the
current snapshots. He's the point guy for any questions on this front.
Brian is already working on Clustering, Anil on Security. The aspects
mentioned are now in repos/jbossas/projects/jboss-aspects and (I
believe) are nearly ready for release, pending some more love to 'em.
> EJB3 has a bunch (but there is a version number on each one.. maybe
> this is okay)
Nope, EJB3 team is looking forward to a proper release next week, but
until our transitive dependencies all have releases, we can't deliver
that yet. :)
Been pushing hard the past couple weeks towards that end. ;)
S,
ALR
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:47 a.m.
New subject: AS5 targets/guidelines (was: maven gripes)
Sacha Labourey wrote:
Guys, the team has been locked in a room in the last two weeks,
componentizing the build. Dimitris is in close touch with the very few
persons that still need to deliver the SPI/releases. Once this is done,
we should clearly be able to see much more stability. Dimitris will send
new "guidelines" to this ML once all releases/SPI will have been
contributed. Stay tuned.
Cheers,
sacha
The current set of targets/guidelines include:
============
- Complete the componetization of EJB3 (so it can be released) by breaking out remaining
cyclical dependencies: In the current component dependency list we have:
- Security aspect & AS security module, Anil
- AS connector module/spi, Jasper
- Clustering aspects, Brian
- EJB3/WS spi, Heiko
- EJB3 core depending on jbossAS classes, Carlo
Those aspects were already broken out:
- asynch
- currentinvocation
- remoting
- transaction
===============
- No further changes to the AS build. The thirdparty directory is now backed by the maven
repo and that seems to work well (minus the gripes). In order not to disrupt the builds we
will leave the full mavenization of the AS build for later.
===============
- No more SNAPSHOTs (or re-tagging of releases). Please use tagged releases for whatever
goes in the AS build. The current snapshots that come directly or indirectly to AS that we
need to get rid of are:
(cd thirdparty; mvn -U dependency:tree | grep SNAPSHOT)
[INFO] org.jboss.jbossas:jboss-as-thirdparty:pom:5.0.0-SNAPSHOT
[INFO] +- org.jboss.javaee:jboss-servlet-api:jar:2.5.0-SNAPSHOT:compile
[INFO] +- org.jboss.aspects:jboss-security-aspects:jar:1.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-vfs:jar:2.0.0-SNAPSHOT:compile
[INFO] | \- org.jboss.deployers:jboss-deployers-core:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss:jboss-vfs:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.ejb3:jboss-ejb3-core:jar:jboss-ejb3-client:0.1.0-SNAPSHOT:co
mpile
[INFO] | +- org.jboss.ejb3:jboss-ejb3-interceptors:jar:0.13.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-jms-api:jar:1.1.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-client-spi:jar:2.0.0-SNAPSHOT:comp
ile
[INFO] +- org.jboss.javaee:jboss-jca-api:jar:1.5.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-ejb-api:jar:3.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.cluster:jboss-ha-client:jar:1.1.0-SNAPSHOT:compile
[INFO] | \- org.jboss.aspects:jboss-remoting-aspects:jar:1.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-javaee:jar:5.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-jacc-api:jar:1.1.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-impl:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-spi:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-vfs-spi:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.ejb3:jboss-ejb3-core:jar:0.1.0-SNAPSHOT:compile
[INFO] +- org.jboss.ejb3:jboss-ejb3-cache:jar:0.13.0-SNAPSHOT:compile
[INFO] +- jboss.jbossws-framework:jbossws-framework:jar:3.0.2-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-core-spi:jar:2.0.0-SNAPSHOT:compil
e
[INFO] +- org.jboss.deployers:jboss-deployers-client:jar:2.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.deployers:jboss-deployers-structure-spi:jar:2.0.0-SNAPSHOT:c
ompile
[INFO] +- jboss.jbossws-framework:resources:jar:3.0.2-SNAPSHOT:compile
[INFO] +- org.jboss.ejb3:jboss-ejb3-security:jar:0.13.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-persistence-api:jar:3.0.0-SNAPSHOT:compile
[INFO] +- jboss.jbossws-common:jbossws-common:jar:1.0.5-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-jaspi-api:jar:1.0.0-SNAPSHOT:compile
[INFO] +- org.jboss.cluster:jboss-ha-server-api:jar:1.1.0-SNAPSHOT:compile
[INFO] +- org.jboss.javaee:jboss-jad-api:jar:1.2.0-SNAPSHOT:compile
[INFO] \- org.jboss.aspects:jboss-transaction-aspects:jar:1.0.0-SNAPSHOT:compile
=====================
- Complete component updates. Expecting deliverables from:
hibernate
jboss/pojo-cache
security
vfs
remoting
integration
metadata
microcontainer
full list: http://jira.jboss.com/jira/browse/JBAS-5121
=====================
- JDK5 will be the basis of all our TCK testing. All code should be compiled with JDK5 and
be able to run with both JDK5/6. We need to adapt our testsuite to test for the later
scenario.
=====================
- The number of JBAS JIRA are going up instead of going down. Please take a look at what
has
been assign to you or created by you and change the priority to Critical/Blocker, if it
must
make it for AS5 CR1, or reschedule it.
JBossAS 5.0.0.CR1 tasks assigned to me
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&reque...
JBossAS 5.0.0.CR1 tasks reported by me
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hide&reque...
I'm going to reschedule all non Blocker/Critical issues very soon.
=====================
- Testsuite, thanks to Brian, Adrian, Shelly and others we are under ~200 failures! My
proposal would be to exclude tests that don't make much sense and nobody has cared to
look
at for the past year or so.
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
====================
Once things are stabilized we'll try to come up with a new estimate for the AS5 CR1
delivery
date.
Thanks
/Dimitris
11:51 a.m.
New subject: AS5 targets/guidelines (was: maven gripes)
When I look at the thirdparty/pom.xml and jbossas-component-matrix
it seems that all dependencies that once have been declared in
component-info.xml have disappeared from the maven build or have been
replaced by some (latest?) release.
* Is the migration from buildmagic to maven automated or done by hand?
* Who is responsible for that? The subcomponent developer?
* How do I change jbossas-component-matrix?
/Heiko
On Mon, 2008-04-21 at 12:47 +0300, Dimitris Andreadis wrote:
No further changes to the AS build. The thirdparty directory is now
backed by the maven
repo and that seems to work well (minus the gripes). In order not to
disrupt the builds we
will leave the full mavenization of the AS build for later.
12:03 p.m.
New subject: AS5 targets/guidelines
When you do a 'mvn package' from thirdparty (it's part of the build), the old
component-info.xml files are generated and the jar files copied in the expected locations
in
thirdparty directory, driven by the information in the thirdparty.pom.xml. This is a
plugin
Paul wrote.
What you want to change?
Heiko Braun wrote:
When I look at the thirdparty/pom.xml and jbossas-component-matrix
it seems that all dependencies that once have been declared in
component-info.xml have disappeared from the maven build or have been
replaced by some (latest?) release.
* Is the migration from buildmagic to maven automated or done by hand?
* Who is responsible for that? The subcomponent developer?
* How do I change jbossas-component-matrix?
/Heiko
On Mon, 2008-04-21 at 12:47 +0300, Dimitris Andreadis wrote:
> No further changes to the AS build. The thirdparty directory is now
> backed by the maven
> repo and that seems to work well (minus the gripes). In order not to
> disrupt the builds we
> will leave the full mavenization of the AS build for later.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:13 p.m.
New subject: AS5 targets/guidelines
The WS snapshots you asked to be removed shouldn't actually be there.
Currently the build contains jbossws-native-3.0.1 but pulls in
jbossws-framework 3.0.2-SNAPSHOT. The original dependency on framework
was different (3.0.1.GA) and for some reason has changed. I am currently
looking for the reason why and a proper way to change it.
/Heiko
On Mon, 2008-04-21 at 20:03 +0300, Dimitris Andreadis wrote:
What you want to change?
12:20 p.m.
New subject: AS5 targets/guidelines
It's referenced directly in component-matrix/pom.xml
<dependency>
<groupId>jboss.jbossws-common</groupId>
<artifactId>jbossws-common</artifactId>
<version>1.0.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>jbossws-framework</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>resources</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
Heiko Braun wrote:
The WS snapshots you asked to be removed shouldn't actually be
there.
Currently the build contains jbossws-native-3.0.1 but pulls in
jbossws-framework 3.0.2-SNAPSHOT. The original dependency on framework
was different (3.0.1.GA) and for some reason has changed. I am currently
looking for the reason why and a proper way to change it.
/Heiko
On Mon, 2008-04-21 at 20:03 +0300, Dimitris Andreadis wrote:
> What you want to change?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:29 p.m.
New subject: AS5 targets/guidelines
OK, I am can change it for CR1 to reflect the proper dependencies.
But how did it get there in the first place? I want to avoid that a
subsequent generation step overwrites it again.
/Heiko
On Mon, 2008-04-21 at 20:20 +0300, Dimitris Andreadis wrote:
It's referenced directly in component-matrix/pom.xml
<dependency>
<groupId>jboss.jbossws-common</groupId>
<artifactId>jbossws-common</artifactId>
<version>1.0.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>jbossws-framework</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>resources</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
Heiko Braun wrote:
> The WS snapshots you asked to be removed shouldn't actually be there.
> Currently the build contains jbossws-native-3.0.1 but pulls in
> jbossws-framework 3.0.2-SNAPSHOT. The original dependency on framework
> was different (3.0.1.GA) and for some reason has changed. I am currently
> looking for the reason why and a proper way to change it.
>
> /Heiko
>
>
> On Mon, 2008-04-21 at 20:03 +0300, Dimitris Andreadis wrote:
>> What you want to change?
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:34 p.m.
New subject: AS5 targets/guidelines
Moving to the forums:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145599#...
On Mon, 2008-04-21 at 20:20 +0300, Dimitris Andreadis wrote:
It's referenced directly in component-matrix/pom.xml
<dependency>
<groupId>jboss.jbossws-common</groupId>
<artifactId>jbossws-common</artifactId>
<version>1.0.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>jbossws-framework</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>jboss.jbossws-framework</groupId>
<artifactId>resources</artifactId>
<version>3.0.2-SNAPSHOT</version>
</dependency>
Heiko Braun wrote:
> The WS snapshots you asked to be removed shouldn't actually be there.
> Currently the build contains jbossws-native-3.0.1 but pulls in
> jbossws-framework 3.0.2-SNAPSHOT. The original dependency on framework
> was different (3.0.1.GA) and for some reason has changed. I am currently
> looking for the reason why and a proper way to change it.
>
> /Heiko
>
>
> On Mon, 2008-04-21 at 20:03 +0300, Dimitris Andreadis wrote:
>> What you want to change?
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:22 p.m.
Rémy Maucherat wrote:
On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
<galder.zamarreno(a)redhat.com> wrote:
> Isn't that what "mvn install" does?
>
> I might be wrong but I think you're hijacking Adrian's thread...
Personally, I think Maven is an abomination. +1 to any proposal to get
rid of this piece of junk ASAP.
It is definitely a major disappointment. I will never move another
project to it.
--
Jason T. Greene
JBoss, a division of Red Hat
10:48 a.m.
I apologize. If you're interested in the subject, please create a new
thread and I'll follow up on that.
Galder Zamarreno wrote:
Ovidiu Feodorov wrote:
>
> A way to solve it is to partition your work into pieces that produce
> autonomous artifacts, which are (automatically) tested before you
> publish them in the repository. Then your final product becomes an
> assembly of artifacts, not source files.
Isn't that what "mvn install" does?
I might be wrong but I think you're hijacking Adrian's thread...
>
> You handle versioned complex artifacts the same way you handle your
> source files, with the added bonus that you can tell an artifact is
> functional and you can prove it.
>
> Just a thought.
>
> Adrian Brock wrote:
>> The main issue is misuse of version control and people doing
>> "half-a-commit".
>> No build tool is going to solve those problems. ;-)
>>
>> P.S. It looks like the latest breakage was my fault.
>>
>> i.e. no "svn add" before "svn commit"
>>
>> Ironic. ;-)
>>
>> On Fri, 2008-04-18 at 07:40 -0700, Ovidiu Feodorov wrote:
>>
>>> This probably doesn't have the slightest chance of happening, but
>>> here I go: I wrote a dependency management and release automation
>>> tool that's available here for download:
>>> https://sourceforge.net/project/showfiles.php?group_id=224810 I
>>> volunteer to install it, make it work in your environment and work
>>> with you to adapt it to JBoss' needs, starting with a small project
>>> first and then expanding it, if proves to be successful.
>>>
>>> It's a lightweight replacement for Maven and I am using it for my
>>> projects. My clients are using it as well.
>>>
>>> There's a user manual under doc, if you download the bundle.
>>>
>>> Cheers,
>>> Ovidiu
>>>
>>>
>>> Adrian Brock wrote:
>>>
>>>> i.e. broken snapshots or what was equivalent
>>>> Clebert's retagging of a jboss messaging release
>>>>
>>>> With no proper version control we can't even rollback
>>>> the broken builds :-(
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
10:41 a.m.
I call it the ejb3 breakout. :-)
Carlo
Ovidiu Feodorov wrote:
A way to solve it is to partition your work into pieces that produce
autonomous artifacts, which are (automatically) tested before you
publish them in the repository. Then your final product becomes an
assembly of artifacts, not source files.
You handle versioned complex artifacts the same way you handle your
source files, with the added bonus that you can tell an artifact is
functional and you can prove it.
Just a thought.
Adrian Brock wrote:
> The main issue is misuse of version control and people doing
> "half-a-commit".
> No build tool is going to solve those problems. ;-)
>
> P.S. It looks like the latest breakage was my fault.
>
> i.e. no "svn add" before "svn commit"
>
> Ironic. ;-)
>
> On Fri, 2008-04-18 at 07:40 -0700, Ovidiu Feodorov wrote:
>
>> This probably doesn't have the slightest chance of happening, but
>> here I go: I wrote a dependency management and release automation
>> tool that's available here for download:
>> https://sourceforge.net/project/showfiles.php?group_id=224810 I
>> volunteer to install it, make it work in your environment and work
>> with you to adapt it to JBoss' needs, starting with a small project
>> first and then expanding it, if proves to be successful.
>>
>> It's a lightweight replacement for Maven and I am using it for my
>> projects. My clients are using it as well.
>>
>> There's a user manual under doc, if you download the bundle.
>>
>> Cheers,
>> Ovidiu
>>
>>
>> Adrian Brock wrote:
>>
>>> i.e. broken snapshots or what was equivalent
>>> Clebert's retagging of a jboss messaging release
>>>
>>> With no proper version control we can't even rollback
>>> the broken builds :-(
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5858
days inactive
5861
days old
jboss-development@lists.jboss.org
28 comments
12 participants
participants (12)
-
Adrian Brock -
Andrew Lee Rubinger -
Carlo de Wolf -
Clebert Suconic -
David M. Lloyd -
Dimitris Andreadis -
Galder Zamarreno -
Heiko Braun -
Jason T. Greene -
Ovidiu Feodorov -
Rémy Maucherat -
Sacha Labourey