You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@onami.apache.org by Eric Charles <er...@apache.org> on 2013/01/14 08:33:34 UTC
Building trunk
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
Re: Building trunk
Posted by Simone Tripodi <si...@apache.org>.
Salut mon ami,
> I am now up-and-running in eclipse with all modules heriting from parent
> trunk.
>
> Small detail: it would be greate if can commit the classical svn:ignore (I
> usually svn:ignore .* and target) on each of the modules (I'm quite fanatic
> of a clean workspace).
will do, I just realised that not in all module that dirs have been
ignored - I am by your side about keeping clean the SCM repo as much
as we can :)
thanks again for your priceless participation!
A+
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
On 14/01/2013 11:00, Simone Tripodi wrote:
> Salut Eric,
>
>>> Wait before looking ONAMI-52, my workspace is now red (API change).
>>> Good opportunity for me to go into the src.
>
> I just fixed autobind-configuration, later I will reply to all other
> emails - thanks for contributing!
Thx Simo.
I am now up-and-running in eclipse with all modules heriting from parent
trunk.
Small detail: it would be greate if can commit the classical svn:ignore
(I usually svn:ignore .* and target) on each of the modules (I'm quite
fanatic of a clean workspace).
Thx, Eric
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
On 14/01/2013 11:00, Simone Tripodi wrote:
> Salut Eric,
>
>>> Wait before looking ONAMI-52, my workspace is now red (API change).
>>> Good opportunity for me to go into the src.
>
> I just fixed autobind-configuration, later I will reply to all other
> emails - thanks for contributing!
Thx Simo.
I am now up-and-running in eclipse with all modules heriting from parent
trunk.
Small detail: it would be greate if can commit the classical svn:ignore
(I usually svn:ignore .* and target) on each of the modules (I'm quite
fanatic for a clean workspace).
Thx, Eric
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
Re: Building trunk
Posted by Simone Tripodi <si...@apache.org>.
Salut Eric,
>> Wait before looking ONAMI-52, my workspace is now red (API change).
>> Good opportunity for me to go into the src.
I just fixed autobind-configuration, later I will reply to all other
emails - thanks for contributing!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
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 <er...@apache.org> 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
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
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.
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 <er...@apache.org> 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
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
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 <er...@apache.org> 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
Re: Building trunk
Posted by Eric Charles <er...@apache.org>.
On 14/01/2013 10:26, Jordi Gerona wrote:
> I'm just having the same issue trying to build the trunk.
>
> Is there any Jenkins build taking care of this? I mean, building the
> project for the first time
>
That would mean removing the local mvn repo.
That's not done usually, except if we have a previous step wich rm -fr
~/.m2/org/apache/onami
> Cheers
>
>
> On Mon, Jan 14, 2013 at 9:14 AM, Simone Tripodi <si...@apache.org>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 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 :(
>>
>>>
>>> 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.
>>
>> 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 <er...@apache.org> 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
>>
>
Re: Building trunk
Posted by Simone Tripodi <si...@apache.org>.
Hola amigo!
> Is there any Jenkins build taking care of this? I mean, building the
> project for the first time
Yes, each component has a Jenkins job that publishes snapshots on the
ASF repository - you can find details on each pom, where metadata have
been set.
You can find the overview on the Onami tab[1]
HTH, hasta pronto!
-Simo
[1] https://builds.apache.org/view/Onami/
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: Building trunk
Posted by Jordi Gerona <jo...@apache.org>.
I'm just having the same issue trying to build the trunk.
Is there any Jenkins build taking care of this? I mean, building the
project for the first time
Cheers
On Mon, Jan 14, 2013 at 9:14 AM, Simone Tripodi <si...@apache.org>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 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 :(
>
> >
> > 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.
>
> 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 <er...@apache.org> 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
>
Re: Building trunk
Posted by Simone Tripodi <si...@apache.org>.
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 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 :(
>
> 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.
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 <er...@apache.org> 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