On 14/01/2013 10:31, Eric Charles wrote:
Wait before looking ONAMI-52, my workspace is now red (API change).
Good opportunity for me to go into the src.
That's why I don't like asking m2eclipse to ignore some errors, I'm not
100% sure of its state.
Any idea to allow onami to be loaded from the first time in eclipse.
For the m2eclipse, there is now ONAMI-53 with a patch.
I will further look how to migrate autobind-configuration to
configuration trunk.
Thx, Eric
On 14/01/2013 10:27, Eric Charles wrote:
On 14/01/2013 08:14, Simone Tripodi wrote:
Salut Eric!
Any reason why some modules depend still depend on version 1 of
parent. Why
not having all trunk modules following the latest parent? If there
are any
reasons to stay on version 1, at least that version 1 should be
available in
the snapshot repo.
all modules should depend to parent 1-incubating, no snapshots - no
specific reason why some of them are outdated, I will check them ASAP.
I've found the offending (1-SNAPSHOT resolution tentaive was transitive
via org.apache.onami.configuration:6.3-incubating-SNAPSHOT, should be
6.3.0-incubating-SNAPSHOT).
ONAMI-52 has the patch.
Btw, don't I have to grant apache for license when uploading the file (I
was not requested for this)
I bumped a failing module to use the 3-incubating-SNAPSHOT,
commented in
that parent pom the maven-jar-plugin configuration (where it says to
build
the MANISFEST.MF, and module became green. I had that kind of issue
on other
projects with m2eclipse, so I guess this is more a bug on the m2eclipse
side. However, I think onami should play fine with m2eclipse.
yes it is a known m2e issue :(
Ok, I told m2eclipse to 'ignore' those errors and projects are now
nicely loaded in workspace.
As direct action to allow further hack in eclipse, what about bumping
all
modules to 3-incubating-SNAPSHOT parent?
parent 2-incubating is still under vote on IPMC, once vote passes the
next step is updating the parent to that version.
ok, sorry to come back again with that, but releasing all modules in two
steps will make onami development slower than it could if all modules
were released at once, at least during the incubation phase.
We could use the Patch part of Major.Minor.Patch to avoid using all
version space during the incubation phase.
WDYT?
Thanks for reporting!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jan 14, 2013 at 8:33 AM, Eric Charles <[email protected]> wrote:
Hi,
1. cli
Building trunk from cli with 'mvn clean install' gives here:
Failed to execute goal on project
org.apache.onami.autobind.configuration:... Could not find artifact
org.apache.onami:org.apache.onami.parent:pom:1-incubating-SNAPSHOT in
apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
Any reason why some modules depend still depend on version 1 of
parent. Why
not having all trunk modules following the latest parent? If there
are any
reasons to stay on version 1, at least that version 1 should be
available in
the snapshot repo.
2. eclipse
I imported trunk in m2eclipse (latest version from eclipse.org) and
got some
red cross on the pom.xml:
org.codehaus.plexus.archiver.jar.Manifest.merge(org.codehaus.plexus.archiver.jar.Manifest)
I bumped a failing module to use the 3-incubating-SNAPSHOT,
commented in
that parent pom the maven-jar-plugin configuration (where it says to
build
the MANISFEST.MF, and module became green. I had that kind of issue
on other
projects with m2eclipse, so I guess this is more a bug on the m2eclipse
side. However, I think onami should play fine with m2eclipse.
As direct action to allow further hack in eclipse, what about bumping
all
modules to 3-incubating-SNAPSHOT parent?
Thx, Eric
