[INFO]
------------------------------------------------------------------------
[INFO] Building GateIn Portal Component Portal Data
[INFO] task-segment: [dependency:tree]
[INFO]
------------------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's
POM).
Project ID: org.gatein:gatein-dep
Reason: POM 'org.gatein:gatein-dep' not found in
repository: Unable to download the artifact from any
repository
org.gatein:gatein-dep:pom:1.0.3-Beta01
from the specified remote repositories:
for project org.gatein:gatein-dep
I don't understand where this issue is coming from, if
someone else can double check and help, it would be cool.
On Mar 26, 2012, at 6:50 PM, Julien Viet wrote:
you said "but at least the codebase built and is
available in their Maven repo"
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.
what is the point of building only jars and not
server ?
On Mar 26, 2012, at 6:41 PM, Ken Finnigan
wrote:
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.
Are you saying that you don't build the
GateIn packaging modules at all? You only
download the released artifacts from a Maven
repo?
Ken
On Mon, Mar 26,
2012 at 12:24 PM, Julien Viet
<julien@julienviet.com>
wrote:
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.
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.
On Mar 26, 2012,
at 6:02 PM, Ken
Finnigan wrote:
ok, but
isn't that what
documentation is
for, to document the
release process with
whatever parameters
are needed?
I'd hardly
consider -Prelease
to be extremely
onerous on a
releaser.
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.
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.
Ken
On
Mon, Mar 26,
2012 at 11:53
AM, Julien Viet
<julien@julienviet.com>
wrote:
the issue
we had in the
past was about
forgetting
profile or not
knowing
exactly which
profiles
should be
activated when
doing release.
On Mar
26, 2012, at
5:47 PM, Ken
Finnigan
wrote:
Julien,
I think
what you're
describing is
different to
what I meant.
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
Might be
missing
something, but
to me it's
different.
Ken
On
Mon, Mar 26,
2012 at 11:25
AM, Julien
Viet
<julien@julienviet.com>
wrote:
Hi Ken,
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).
To
perform a
correct and
reproducible
release all
profiles
should be
executed from
the beginning
with all the
profiles that
will update
the pom.
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.
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.
On Mar
26, 2012, at
5:08 PM, Ken
Finnigan
wrote:
Why
not simply
have a
"release"
profile that
activates each
module of the
build?
That is
usually what
Maven projects
do when there
are modules
they don't
want built
during dev,
such as docs,
etc.
Ken
On
Mon, Mar 26,
2012 at 11:03
AM, Julien
Viet
<julien@julienviet.com>
wrote:
Hi,
we are
currently
working on the
build after
the GIT
migration, one
of the current
issue is
profile
selection.
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.
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...)
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"
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.
To achieve it
we use profile
activation
based on
properties:
the gatein.dev
property is
introduced to
do it.
When this
property is
not present,
the build
behaves as
said before :
it builds
everthing.
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).
When it is
selected with
a server
value, it
build that
server only :
for instance
"mvn install
-Dgatein.dev=jetty"
. The possible
values are
- tomcat
- jbossas5
- jbossas6
- jbossas
- tomcat6
- tomcat7
- jetty
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.
Several things
to note:
- The README
file of GateIn
has been
updated with
the
information
- AS7 build is
not yet
finished and
is cut of the
build (which
means that
doing a
release would
not version
the AS7 poms)
Let me know if
you have any
issue with the
build.
Julien
_______________________________________________
gatein-dev
mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
gatein-dev
mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev