6:58 p.m.
Hi all,
I have created a branch for working on gatein optimization.
The branch is interesting for several reasons:
- we can always compare performances from the trunk and the branch and
estimate the gain
- the trunk will be isolated from that branch as it will likely use
snapshots at some points and perhaps introduce bugs
- when work is done and before merge to the trunk, we can run the
sniff tests
- it is based on the beta 2 so we can expect to have some stability
- it defines a clear life cycle in the work being done
I will probably not be the only person working on that effort
(hopefully) but I will be the person managing the life cycle of the
branch which means:
- perform the continuous merging of trunk to the branch
- perform the final merge of the branch back to the trunk at some points
The branch was created from the trunk revision number 380 (important
to keep the last revision number from which the branch is up to date)
which seems to be the beta 2 release tag.
I will work for the next couple of days on removing the major
bottlenecks, so you can expect an update before next monday.
We should try to use this thread to discuss about this topic.
cheers
Julien
11:24 p.m.
For any branch creation I strongly recommend to change the version number :
Here we can use :
3.0.0-CR1_perf-SNAPSHOT
It is doable in one step from the root dir using this command : "mvn
versions:set -DnewVersion=3.0.0-CR1-perf-SNAPSHOT"
Why ?
To avoid mix in binaries produced by maven in your local repository. It
is hard to find out when a problem is occuring because of that.
This apply for any branch imho (wsrp-integration is also concerned).
Dimitri BAELI - eXo Platform SAS
On Wed, Oct 21, 2009 at 6:58 PM, Julien Viet <julien(a)julienviet.com> wrote:
Hi all,
I have created a branch for working on gatein optimization.
The branch is interesting for several reasons:
- we can always compare performances from the trunk and the branch and
estimate the gain
- the trunk will be isolated from that branch as it will likely use
snapshots at some points and perhaps introduce bugs
- when work is done and before merge to the trunk, we can run the
sniff tests
- it is based on the beta 2 so we can expect to have some stability
- it defines a clear life cycle in the work being done
I will probably not be the only person working on that effort
(hopefully) but I will be the person managing the life cycle of the
branch which means:
- perform the continuous merging of trunk to the branch
- perform the final merge of the branch back to the trunk at some points
The branch was created from the trunk revision number 380 (important
to keep the last revision number from which the branch is up to date)
which seems to be the beta 2 release tag.
I will work for the next couple of days on removing the major
bottlenecks, so you can expect an update before next monday.
We should try to use this thread to discuss about this topic.
cheers
Julien
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
3:11 p.m.
+1
Cheers,
Arnaud
# Arnaud Héritier
# Software Factory Manager
# eXo Platform
# http://www.exoplatform.com
# http://blog.aheritier.net
On Wed, Oct 21, 2009 at 11:24 PM, Dimitri BAELI <dbaeli(a)gmail.com> wrote:
For any branch creation I strongly recommend to change the version
number :
Here we can use :
3.0.0-CR1_perf-SNAPSHOT
It is doable in one step from the root dir using this command : "mvn
versions:set -DnewVersion=3.0.0-CR1-perf-SNAPSHOT"
Why ?
To avoid mix in binaries produced by maven in your local repository. It
is hard to find out when a problem is occuring because of that.
This apply for any branch imho (wsrp-integration is also concerned).
Dimitri BAELI - eXo Platform SAS
On Wed, Oct 21, 2009 at 6:58 PM, Julien Viet <julien(a)julienviet.com>wrote:
> Hi all,
>
> I have created a branch for working on gatein optimization.
>
> The branch is interesting for several reasons:
>
> - we can always compare performances from the trunk and the branch and
> estimate the gain
> - the trunk will be isolated from that branch as it will likely use
> snapshots at some points and perhaps introduce bugs
> - when work is done and before merge to the trunk, we can run the
> sniff tests
> - it is based on the beta 2 so we can expect to have some stability
> - it defines a clear life cycle in the work being done
>
> I will probably not be the only person working on that effort
> (hopefully) but I will be the person managing the life cycle of the
> branch which means:
>
> - perform the continuous merging of trunk to the branch
> - perform the final merge of the branch back to the trunk at some points
>
> The branch was created from the trunk revision number 380 (important
> to keep the last revision number from which the branch is up to date)
> which seems to be the beta 2 release tag.
>
> I will work for the next couple of days on removing the major
> bottlenecks, so you can expect an update before next monday.
>
> We should try to use this thread to discuss about this topic.
>
> cheers
>
> Julien
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
4:01 p.m.
On Oct 21, 2009, at 11:24 PM, Dimitri BAELI wrote:
For any branch creation I strongly recommend to change the version
number :
Here we can use :
3.0.0-CR1_perf-SNAPSHOT
It is doable in one step from the root dir using this command :
"mvn versions:set -DnewVersion=3.0.0-CR1-perf-SNAPSHOT"
Hmm this kind of version is not valid. At least, Maven doesn't like it
when I try to build:
java.lang.IllegalArgumentException: The scm url does not contain a
valid delimiter.
[INFO] at org.apache.maven.scm.provider.ScmUrlUtils.getDelimiter
(ScmUrlUtils.java:60)
[INFO] at
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository
(AbstractScmManager.java:179)
[INFO] at
org.apache.maven.wagon.providers.scm.ScmWagon.getScmRepository
(ScmWagon.java:215)
[INFO] at org.apache.maven.wagon.providers.scm.ScmWagon.get
(ScmWagon.java:561)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile
(DefaultWagonManager.java:546)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata
(DefaultWagonManager.java:443)
Maven versions:set should perform validity check on the new version.
It's quite stupid to accept setting the version to a value you know is
not valid... So now I'm left trying to figure out what constitutes a
valid maven version… <sigh>
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
4:07 p.m.
On Oct 22, 2009, at 4:01 PM, Christophe Laprun wrote:
Maven versions:set should perform validity check on the new version.
It's quite stupid to accept setting the version to a value you know is
not valid... So now I'm left trying to figure out what constitutes a
valid maven version… <sigh>
For reference: http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
Seems like it's actually a problem with exobuild, ultimately:
Result of /bin/sh -c cd /Users/claprun/Dev/gatein/portal/branches/wsrp-
integration/packaging/pkg && java -Dexo.package.home=/Users/claprun/
Dev/gatein/portal/branches/wsrp-integration/packaging/pkg/target/
exopackage -Dexo.current.dir=/Users/claprun/Dev/gatein/portal/branches/
wsrp-integration/packaging/pkg -Dexo.base.dir=null -Dexo.conf.dir=/
Users/claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/
pkg/target/exopackage-conf -Dexo.working.dir=/Users/claprun/Dev/gatein/
portal/branches/wsrp-integration/packaging/pkg/target -Dexo.dep.dir=/
Users/claprun/Dev/exo-dependencies -Dexo.m2.repos=file:/Users/
claprun/.m2/repository,http://maven2.exoplatform.org/rest/maven2,http://r...
-Dclean.server=jboss-5.1.0.GA -Dexo.m2.home=/Users/claprun/Dev/
apache-maven-2.2.1 -Xshare:auto -Xms128m -Xmx512m -classpath /Users/
claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/pkg/
target/exopackage/lib/js.jar org.mozilla.javascript.tools.shell.Main /
Users/claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/
pkg/target/exopackage/javascript/eXo/eXo.js exobuild --product=portal
--deploy=jbossear execution is: '3'.
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
4:29 p.m.
"If your version number does not match this format, then the entire version
number is treated as being the *Qualifier*" Thus if your version isn't in
format 1.2.3-XXX all the version is considered to be a String
The issue you mentioned doesn't seem to be related to the version but to the
scm url :
"The scm url does not contain a valid delimiter."
Cheers,
Arnaud
# Arnaud Héritier
# Software Factory Manager
# eXo Platform
# http://www.exoplatform.com
# http://blog.aheritier.net
On Thu, Oct 22, 2009 at 4:07 PM, Christophe Laprun <claprun(a)redhat.com>wrote:
On Oct 22, 2009, at 4:01 PM, Christophe Laprun wrote:
> Maven versions:set should perform validity check on the new version.
> It's quite stupid to accept setting the version to a value you know is
> not valid... So now I'm left trying to figure out what constitutes a
> valid maven version… <sigh>
For reference:
http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
Seems like it's actually a problem with exobuild, ultimately:
Result of /bin/sh -c cd /Users/claprun/Dev/gatein/portal/branches/wsrp-
integration/packaging/pkg && java -Dexo.package.home=/Users/claprun/
Dev/gatein/portal/branches/wsrp-integration/packaging/pkg/target/
exopackage -Dexo.current.dir=/Users/claprun/Dev/gatein/portal/branches/
wsrp-integration/packaging/pkg -Dexo.base.dir=null -Dexo.conf.dir=/
Users/claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/
pkg/target/exopackage-conf -Dexo.working.dir=/Users/claprun/Dev/gatein/
portal/branches/wsrp-integration/packaging/pkg/target -Dexo.dep.dir=/
Users/claprun/Dev/exo-dependencies -Dexo.m2.repos=file:/Users/
claprun/.m2/repository,
http://maven2.exoplatform.org/rest/maven2,http://repository.jboss.org/maven2
-Dclean.server=jboss-5.1.0.GA -Dexo.m2.home=/Users/claprun/Dev/
apache-maven-2.2.1 -Xshare:auto -Xms128m -Xmx512m -classpath /Users/
claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/pkg/
target/exopackage/lib/js.jar org.mozilla.javascript.tools.shell.Main /
Users/claprun/Dev/gatein/portal/branches/wsrp-integration/packaging/
pkg/target/exopackage/javascript/eXo/eXo.js exobuild --product=portal
--deploy=jbossear execution is: '3'.
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com /
http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5362
days inactive
5363
days old
5 comments
4 participants
participants (4)
-
Arnaud HERITIER -
Christophe Laprun -
Dimitri BAELI -
Julien Viet