Broken builds

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

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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-developmentlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>     

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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-developmentlists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>     
> 
> _______________________________________________
> jboss-development mailing list
> jboss-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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-developmentlists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>     
> 
> _______________________________________________
> jboss-development mailing list
> jboss-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

On Fri, Apr 18, 2008 at 5:25 PM, Galder Zamarreno
<galder.zamarrenoredhat.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-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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.zamarrenoredhat.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-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

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://exitcondit
ion.alrubinger.com
_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

On Fri, Apr 18, 2008 at 6:06 PM, Andrew Lee Rubinger
<andrew.rubingerredhat.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

_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment