<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 03/28/2012 09:43 AM, Boleslaw Dawidowicz wrote:
<blockquote
cite="mid:06DDAE06-2387-4BFD-B4B4-AC5ECA4F5C7B@gmail.com"
type="cite">We are not really dev friendly anyway because you
first need to read README to setup settings.xml… Something I
personally don't really get either but anyway :)</blockquote>
And even more so with this change.<br>
<blockquote
cite="mid:06DDAE06-2387-4BFD-B4B4-AC5ECA4F5C7B@gmail.com"
type="cite">
<div><br>
</div>
<div>Our main problem with -Prelease profile so far is that it was
constantly behind. Thing is that we were using this approach so
far and each time I forgot to grep version after "mvn
release:prepare" I pushed somehow messed up tag. In most cases
when people do changes in the build they simply forget to update
release profile. If we keep like this then doing release is
repeating painful process as first you spend whole day putting
the build back into a decent state… </div>
<div><br>
</div>
<div>Ken I agree with you that in theory -Prelease should be a
better approach. In practice it just didn't work in our case. </div>
<div><br>
</div>
<div>Bolek </div>
<div><br>
<div>
<div>On Mar 26, 2012, at 6:59 PM, Ken Finnigan wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">When I stated it, I was thinking along
the lines of them wanting to develop on GateIn, but also use
that which they developed, which would require local changes
to be in their Maven repo.
<div><br>
</div>
<div>if someone has downloaded the GateIn bundle, played
with it, and decided that they want to take a look at the
code. That first time they want to download and build
source, they don't necessarily want or care about it being
packaged into a server. They just want to make sure it
builds and pulls in dependencies so that looking at the
code in an IDE makes sense and doesn't have red marks
everywhere with thousands of errors.</div>
<div><br>
</div>
<div>If it's desired to build a server env along with
source, I would suggest building a single server by
default, such as AS7, and then allowing the developer to
choose to build a different server if they want.</div>
<div><br>
</div>
<div>Ken<br>
<br>
<div class="gmail_quote">On Mon, Mar 26, 2012 at 12:50 PM,
Julien Viet <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:julien@julienviet.com">julien@julienviet.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>you said "but at least the codebase built and
is available in their Maven repo"</div>
<div><br>
</div>
if I need a jar in my repo, it's because I'm using
it. If I need log4j for instance, I don't build it,
I add a dependency, it's simpler.
<div>
<br>
</div>
<div>what is the point of building only jars and not
server ?
<div>
<div class="h5"><br>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On Mar 26, 2012, at 6:41 PM, Ken
Finnigan wrote:</div>
<br>
<blockquote type="cite">
Hmm. I may be mistaken, but when would
making a mistake not potentially, or
likely, break things? To me this is
solving a problem that can be solved
with documentation.
<div><br>
</div>
<div>Are you saying that you don't build
the GateIn packaging modules at all?
You only download the released
artifacts from a Maven repo?</div>
<div><br>
</div>
<div>Ken<br>
<br>
<div class="gmail_quote">On Mon, Mar
26, 2012 at 12:24 PM, Julien Viet <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:julien@julienviet.com"
target="_blank">julien@julienviet.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">as
I said the issue is that doing a
mistake breaks things, not that
it is hard or complex to add an
argument on the command line.
<div><br>
</div>
<div>That being said my opinion
is that if I need a jar in my
repo then I add a dependency
in my pom to get those jars
and maven will fetch them from
me. It will be faster than
having to wait 20 minutes to
build the same jars.</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>On Mar 26,
2012, at 6:02
PM, Ken
Finnigan
wrote:</div>
<br>
<blockquote
type="cite">ok,
but isn't that
what
documentation
is for, to
document the
release
process with
whatever
parameters are
needed?
<div>
<br>
</div>
<div>I'd
hardly
consider
-Prelease to
be extremely
onerous on a
releaser.</div>
<div><br>
</div>
<div>I guess
from a
different
perspective,
it's not a
very pleasant
experience for
a community
member to
attempt to
build GateIn
and end up
waiting
forever for it
to complete
because, like
everyone else,
they didn't
read the
readme before
trying to
build a
project.</div>
<div><br>
</div>
<div>In my
opinion, if
someone needs
to read a
readme before
they even
attempt to
build a Maven
project,
something is
very wrong.
Yes it means
they don't
have a
packaged
GateIn with a
server
environment
built, but at
least the
codebase built
and is
available in
their Maven
repo.</div>
<div><br>
</div>
<div>Ken<br>
<br>
<div
class="gmail_quote">On
Mon, Mar 26,
2012 at 11:53
AM, Julien
Viet <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:julien@julienviet.com"
target="_blank">julien@julienviet.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">
<div>the issue
we had in the
past was about
forgetting
profile or not
knowing
exactly which
profiles
should be
activated when
doing release.</div>
<div>
<div>
<div><br>
<div>
<div>On Mar
26, 2012, at
5:47 PM, Ken
Finnigan
wrote:</div>
<br>
<blockquote
type="cite">Julien,
<div><br>
</div>
<div>I think
what you're
describing is
different to
what I meant.</div>
<div><br>
</div>
<div>I don't
mean doing
some profile
as part of the
release
plugin, I mean
creating a new
release
profile that
has nothing
but the
modules to
build, no
plugins or
anything else
defined within
it. Then as
part of the
release you
only need to
add -Prelease
to build every
module</div>
<div><br>
</div>
<div>Might be
missing
something, but
to me it's
different.</div>
<div><br>
</div>
<div>Ken<br>
<br>
<div
class="gmail_quote">On
Mon, Mar 26,
2012 at 11:25
AM, Julien
Viet <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:julien@julienviet.com"
target="_blank">julien@julienviet.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">
<div>Hi Ken,</div>
<div><br>
</div>
<div>The
additional
profile added
in the release
plugin will
not be run in
the project
until the
release plugin
fork itself
(i.e the
release plugin
runs another
maven during
the release). </div>
<div><br>
<div>
<div>To
perform a
correct and
reproducible
release all
profiles
should be
executed from
the beginning
with all the
profiles that
will update
the pom.</div>
<div><br>
</div>
<div>We had
issues in the
past with some
releases (with
gatein and
portlet
container, I
don't know for
others) where
the release
was not done
correctly (the
main issue is
that poms were
not versioned
during the
release which
makes a broken
release and
also breaks
the
trunk/master
because there
are pom using
the previous
release
SNAPSHOT
version). Those
releases had
to be redone
or worse the
SVN tag was
"amended"
(which is not
possible
anymore with
git) to "fix"
the release.</div>
<div><br>
</div>
<div>The main
motivation is
to ensure that
the release
will be easy
to do, will be
correct and
that the build
after the
release is
correct.</div>
<div>
<div>
<div><br>
</div>
<div>On Mar
26, 2012, at
5:08 PM, Ken
Finnigan
wrote:</div>
<br>
<blockquote
type="cite">Why
not simply
have a
"release"
profile that
activates each
module of the
build?
<div><br>
</div>
<div>That is
usually what
Maven projects
do when there
are modules
they don't
want built
during dev,
such as docs,
etc.</div>
<div><br>
</div>
<div>Ken<br>
<br>
<div
class="gmail_quote">On
Mon, Mar 26,
2012 at 11:03
AM, Julien
Viet <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:julien@julienviet.com"
target="_blank">julien@julienviet.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
Hi,<br>
<br>
we are
currently
working on the
build after
the GIT
migration, one
of the current
issue is
profile
selection.<br>
<br>
The most
important
issue we are
solving is
that
performing a
release is
error prone
and often
fails to
perform the
release
properly:
often POM are
not versionned
by the release
plugin, du to
the fact that
it uses
incorrect
profile
activation. Of
course it is
always
possible to
have it
working by
selecting the
good profiles
in the release
plugin and on
the command
line, however
it is error
prone and it
is hard to
figure out by
looking at the
build what
should be
used.<br>
<br>
We are going
to change how
the build work
with profiles,
not because we
don't use
profiles the
right way, but
because Maven
profile
activation is
not good
enough.
(activeByDefault
is broken, you
cannot have
flexible
activation,
etc...)<br>
<br>
We still need
to use
profiles and
actually we
don't change
the current
profiles, what
we do change
is how their
activation is
done with a
simple and
important
change:
"Everything is
built by
default"<br>
<br>
It means that
the command
"mvn install"
builds
everything
(all server
packaging,
docs,
examples,
etc...). This
guarantees
that release
plugin will
release
properly the
project.
Obviously we
need to
address
developer
productivity
and we do
provide a way
to perform a
build that
saves the most
time we can
when it is
activated in a
simple manner.<br>
<br>
To achieve it
we use profile
activation
based on
properties:
the gatein.dev
property is
introduced to
do it.<br>
<br>
When this
property is
not present,
the build
behaves as
said before :
it builds
everthing.<br>
<br>
When it is
selected with
any value, it
means that the
build is done
for
development
purpose and it
skips some
parts of the
build
(examples,
docs, most of
packaging).<br>
<br>
When it is
selected with
a server
value, it
build that
server only :
for instance
"mvn install
-Dgatein.dev=jetty"
. The possible
values are<br>
<br>
- tomcat<br>
- jbossas5<br>
- jbossas6<br>
- jbossas<br>
- tomcat6<br>
- tomcat7<br>
- jetty<br>
<br>
Another issue
to fix is the
selected
database for
running the
unit tests,
but I believe
it affects you
less because
most of you
are using
hsqldb tests.
To perform
tests with
MySQL, the
profile
-Pmysql5 can
be used.<br>
<br>
Several things
to note:<br>
<br>
- The README
file of GateIn
has been
updated with
the
information<br>
- AS7 build is
not yet
finished and
is cut of the
build (which
means that
doing a
release would
not version
the AS7 poms)<br>
<br>
Let me know if
you have any
issue with the
build.<br>
<br>
Julien<br>
<br>
<br>
_______________________________________________<br>
gatein-dev
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:gatein-dev@lists.jboss.org" target="_blank">gatein-dev@lists.jboss.org</a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/gatein-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
gatein-dev
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:gatein-dev@lists.jboss.org" target="_blank">gatein-dev@lists.jboss.org</a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/gatein-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
gatein-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:gatein-dev@lists.jboss.org">gatein-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/gatein-dev">https://lists.jboss.org/mailman/listinfo/gatein-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gatein-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gatein-dev@lists.jboss.org">gatein-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/gatein-dev">https://lists.jboss.org/mailman/listinfo/gatein-dev</a>
</pre>
</blockquote>
</body>
</html>