Re: Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?

2019-06-08 Thread Jeff MAURY
because it's much better and oss

Le sam. 8 juin 2019 à 10:29, Tibor Digana  a écrit :

> Why you use Eclipse. Use InteliJ IDEA. It is professional tool. Every
> company has money to buy enterprise IDEA, the company wouln'd say no
> because it is price you pay once and you can upgrade to major version
> within whole year. You can use it forever without paying more after the
> support period of one year you paid before. For instance I had IDEA 14
> since 2014 - 2019 without any issue in that tool.
>
> On Fri, Jun 7, 2019 at 3:32 PM Cristiano  wrote:
>
> > Hello,
> >
> > Yesterday I did an upgrade on some dependencies and plugins of my
> > company's master POM.
> >
> > I used the versions-plugin and changed many of the suggested ones. After
> > conclude and build on CI without error, I ended up with a strange error
> > in Eclipse IDE (ubuntu, 201903, jdk11) on every project that has it as
> > its parent POM.
> >
> > The error has no description and its title is "Unknown".
> >
> >
> > It took some time to track the culprit down and after I have downgraded
> > the maven-jar-plugin to 3.1.1 the error was gone.
> >
> > I'm curious about this...
> >
> > best regards,
> >
> >
> > Cristiano
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


Re: I am wandering how you do guys debug maven?

2018-10-08 Thread Jeff MAURY
M2e takes care of everything

Jeff

Le lun. 8 oct. 2018 à 23:09, Simon Sheng  a écrit :

> Hi,
>
> I am bringing this baby question since Maven load all it's classes by
> ClassWorlds. Which means it doesn't have "main method". instead we debug
> everything by log, do we have other way like debug with any IDE: Eclipse,
> Intellij etc. put breakpoints and debug step by step ?
>
> Thanks
>
> Simon(ChengHong) Sheng
>


Re: any github/git magic to migrate pull requests?

2018-03-20 Thread Jeff MAURY
A pr has its own branch (refs/pull/prid/head)
So it's easy to retrieve them but don't know how to recreate them on the
target repository

Hope this helps
Jeff

Le mar. 20 mars 2018 à 22:06, Olivier Lamy  a écrit :

> Hi
> We have a lot of pr here https://github.com/apache/maven-plugins/pulls
>
> any ideas how to migrate those pr to their new git plugin repo?
>
> Cheers
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


Re: Harnes 3.3.0 - Test fails to resolve artifact

2015-12-02 Thread Jeff MAURY
rride
> protected void setUp() throws Exception {
> // required
> super.setUp();
>
> }
>
> /** {@inheritDoc} */
> @Override
> protected void tearDown() throws Exception {
> // required
> super.tearDown();
>
> }
>
> /**
>  * @throws Exception
>  * if any
>  */
> public void testSomething() throws Exception {
> final File pom = getTestFile(
> "src/test/resources/unit/setup/pom.xml");
> assertNotNull(pom);
> assertTrue(pom.exists());
>
> final SetupMojo setupMojo = (SetupMojo) lookupMojo("setup"
> , pom);
> assertNotNull(setupMojo);
> setupMojo.execute();
>
> }
> }
>
> -
> public class MyProjectStub extends MavenProjectStub {
> /**
>  * Default constructor
>  */
> public MyProjectStub() {
> final MavenXpp3Reader pomReader = new MavenXpp3Reader();
> Model model;
> try {
> model = pomReader.read(ReaderFactory.newXmlReader(
> new File(
> getBasedir(),
> "/unit/setup/pom.xml")));
> setModel(model);
> } catch (final Exception e) {
> throw new RuntimeException(e);
> }
>
> setGroupId(model.getGroupId());
> setArtifactId(model.getArtifactId());
> setVersion(model.getVersion());
> setName(model.getName());
> setUrl(model.getUrl());
> setPackaging(model.getPackaging());
>
> final Build build = new Build();
> build.setFinalName(model.getArtifactId());
> build.setDirectory(getBasedir() + "/target");
> build.setSourceDirectory(getBasedir() + "/src/main/java");
> build.setOutputDirectory(getBasedir() + "/target/classes"
> );
> build.setTestSourceDirectory(getBasedir() +
> "/src/test/java");
> build.setTestOutputDirectory(getBasedir() +
> "/target/test-classes");
> setBuild(build);
>
> final List compileSourceRoots = new
> ArrayList();
> compileSourceRoots.add(getBasedir() + "/src/main/java");
> setCompileSourceRoots(compileSourceRoots);
>
> final List testCompileSourceRoots = new
> ArrayList();
> testCompileSourceRoots.add(getBasedir() + "/src/test/java"
> );
> setTestCompileSourceRoots(testCompileSourceRoots);
> }
>
>
> /** {@inheritDoc} */
> @Override
> public List getRemoteArtifactRepositories() {
> final ArtifactRepository repository = new
> DefaultArtifactRepository("central", "http://repo.maven.apache.org/maven2";
> ,new DefaultRepositoryLayout());
> return Collections.singletonList(repository);
> }
>
> /** {@inheritDoc} */
> @Override
> public File getBasedir() {
> return new File(super.getBasedir() +
> "/src/test/resources/");
> }
> }
> --
> src/test/resources/unit/setup/pom.xml
>
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.occ.maven
> test-setup
> 1.0.0-SNAPSHOT
> pom
> Test SetupMojo
>
> 
> 
> 
> com.occ.maven
> oas
> 1.0.0-SNAPSHOT
> 
>  "com.occ.oas.maven.mojo.stubs.MyProjectStub"/>
> 
> ${localRepository}
> 
> 
> 
> 
>
> 
>
>
> Kind Regards,
>
> Nathalie Keymeulen | Agfa HealthCare
> Software Engineer | HE/Orbis Connectivity Core Team Ghent | IT BD,
> Enterprise BU
> T  +32 3444 7644 | F  +32 3 444 8401 | M  +32 494 56 02 80
>
> Moutstraat 100, B-9000 Ghent, Belgium
> http://www.agfahealthcare.com
> http://blog.agfahealthcare.com
> Click on link to read important disclaimer:
> http://www.agfahealthcare.com/maildisclaimer




-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

2015-04-14 Thread Jeff MAURY
have tru crossplatform
> > > > >
> > > > > compilation
> > > > >
> > > > > > > > >> > option,
> > > > > > > > >> > to avoid using 2 JDKs (ie JDK 5 for compiling java 5
> code
> > and
> > > > >
> > > > > being
> > > > >
> > > > > > > > >> > sure
> > > > > > > > >> > there is no Java 7 API reference, and JDK 7 for the
> java 7
> > > >
> > > > part)
> > > >
> > > > > > > > >> > I see there will be impact on tooling, and if javac
> does a
> > > >
> > > > part
> > > >
> > > > > of
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > >> > job,
> > > > > > > > >> > this will be a lot easier to implement at Maven level
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > But at the moment, my objective was not from Maven point
> > of
> > > >
> > > > view
> > > >
> > > > > > > > >> > but
> > > > > > > > >> > library developper point of view: show a real world case
> > of
> > > >
> > > > how
> > > >
> > > > > an
> > > > >
> > > > > > > > >> > existing library could be refactored to use the feature,
> > > > >
> > > > > expecting
> > > > >
> > > > > > > that
> > > > > > >
> > > > > > > > >> > the new source code would be easier to maintain
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > WDYT?
> > > > > > > > >> >
> > > > > > > > >> > Regards,
> > > > > > > > >> >
> > > > > > > > >> > Hervé
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > [1]
> > > > >
> > > > >
> > https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/j
> > > > >
> > > > > > > > >> > av
> > > > > > > > >> > a-7/org/codehaus/plexus/util>
> > > > > > > > >> >
> > > > > > > > >> > Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit :
> > > > > > > > >> >> Hi,
> > > > >
> > > > > > > > >> >> we've been asked to give our opinion on the JEP 238:
> > > > > Multi-Version
> > > > >
> > > > > > > JAR
> > > > > > >
> > > > > > > > >> >> Files
> > > > > > > > >> >>
> > > > > > > > >> >> Here's a quote from Rory O'Donnels e-mail:
> > > > > > > > >> >> ---
> > > > > > > > >> >>
> > > > > > > > >> >>   It's goal is to extend the JAR file format to allow
> > > >
> > > > multiple,
> > > >
> > > > > > > > >> >>   JDK
> > > > > > > > >> >>
> > > > > > > > >> >> release-specific versions of class
> > > > > > > > >> >>
> > > > > > > > >> >>   files to coexist in a single file. An additional goal
> > is
> > > > > > > > >> >>   to
> > > > > > >
> > > > > > > backport
> > > > > > >
> > > > > > > > >> >>   the
> > > > > > > > >> >>
> > > > > > > > >> >> run-time changes to
> > > > > > > > >> >>
> > > > > > > > >> >>   JDK 8u60, thereby enabling JDK 8 to consume
> > multi-version
> > > > >
> > > > > JARs.
> > > > >
> > > > > > > For
> > > > > > >
> > > > > > > > >> >>   a
> > > > > > > > >> >>
> > > > > > > > >> >> detailed discussion,
> > > > > > > > >> >>
> > > > > > > > >> >>   please see the corresponding thread on the
> > core-libs-dev
> > > > >
> > > > > mailing
> > > > >
> > > > > > > > >> >>   list.
> > > > > > > > >> >>   [1]
> > > > > > > > >> >>
> > > > > > > > >> >>   Please keep in mind that a JEP in the Candidate state
> > is
> > > > >
> > > > > merely
> > > > >
> > > > > > > an
> > > > > > >
> > > > > > > > >> >>   idea
> > > > > > > > >> >>
> > > > > > > > >> >> worthy of consideration
> > > > > > > > >> >>
> > > > > > > > >> >>   by JDK Release Projects and related efforts; there is
> > no
> > > > > > >
> > > > > > > commitment
> > > > > > >
> > > > > > > > >> >>   that
> > > > > > > > >> >>
> > > > > > > > >> >> it will be delivered in
> > > > > > > > >> >>
> > > > > > > > >> >>   any particular release.
> > > > > > > > >> >>
> > > > > > > > >> >>   Comments, questions, and suggestions are welcome on
> the
> > > > > > >
> > > > > > > corelibs-dev
> > > > > > >
> > > > > > > > >> >> mailing list. (If you
> > > > > > > > >> >>
> > > > > > > > >> >>   haven’t already subscribed to that list then please
> do
> > so
> > > > >
> > > > > first,
> > > > >
> > > > > > > > >> >> otherwise your message will be
> > > > > > > > >> >>
> > > > > > > > >> >>   discarded as spam.)
> > > > > > > > >> >>
> > > > > > > > >> >>   [0] http://openjdk.java.net/jeps/238
> > > > > > > > >> >>   [1]
> > > >
> > > >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031
> > > >
> > > > > > > > >> >> 461
> > > > > > > > >> >> .ht ml
> > > > > > > > >> >>
> > > > > > > > >> >> ---
> > > > > > > > >> >>
> > > > > > > > >> >> IIUC the original request was to have different version
> > of
> > > >
> > > > the
> > > >
> > > > > > > > >> >> same
> > > > > > > > >> >> class
> > > > > > > > >> >> within the same artifact. On the mailinglist I noticed
> a
> > > > > > > > >> >> more
> > > > > > > > >> >> interesting
> > > > > > > > >> >> idea: you need a mechanism to map Classes, Methods or
> > Fields
> > > > >
> > > > > from
> > > > >
> > > > > > > one
> > > > > > >
> > > > > > > > >> >> version to the other.
> > > > > > > > >> >>
> > > > > > > > >> >>  From a Maven perspective I don't see that much issues
> > with
> > > >
> > > > the
> > > >
> > > > > > > > >> >>  original
> > > > > > > > >> >>
> > > > > > > > >> >> idea. You should already be able to do it right now
> with
> > a
> > > >
> > > > lot
> > > >
> > > > > of
> > > > >
> > > > > > > > >> >> execution-blocks.
> > > > > > > > >> >> However, I don't see how users would maintain different
> > > > >
> > > > > version of
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > >> >> same class (within an IDE).
> > > > > > > > >> >> To me this all looks quite complex for rare cases.
> > > > > > > > >> >> If you really want multiple JDK versions of the same
> > > >
> > > > artifact,
> > > >
> > > > > I
> > > > >
> > > > > > > would
> > > > > > >
> > > > > > > > >> >> probably split them into classified artifacts.
> > > > > > > > >> >>
> > > > > > > > >> >> Any other comments?
> > > > > > > > >> >>
> > > > > > > > >> >> thanks,
> > > > > > > > >> >> Robert
> > > > > > >
> > > > > > >
> > 
> > > > > > > -
> > > > > > >
> > > > > > > > >> >> To unsubscribe, e-mail:
> dev-unsubscr...@maven.apache.org
> > > > > > > > >> >> For additional commands, e-mail:
> > dev-h...@maven.apache.org
> > > > > > >
> > > > > > >
> > 
> > > > > > > -
> > > > > > >
> > > > > > > > >> > To unsubscribe, e-mail:
> dev-unsubscr...@maven.apache.org
> > > > > > > > >> > For additional commands, e-mail:
> > dev-h...@maven.apache.org
> > > > >
> > > > >
> -
> > > > >
> > > > > > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > > >> For additional commands, e-mail:
> dev-h...@maven.apache.org
> > > > >
> > > > >
> -
> > > > >
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > -
> > > >
> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > > >
> > > > > > >
> > 
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Unreadable commits notifications was Re: [49/50] [abbrv] maven git commit: Package and configure log4J 2.2 by default. Replace the content of conf/logging/log4j2.xml by the one from conf/logging/l

2015-04-02 Thread Jeff MAURY
According to the commits archive, there is 1 email per commit and I can see
the 50/50 notification email (
http://mail-archives.apache.org/mod_mbox/maven-commits/201504.mbox/%3Cbfb2482f10c94b7180353e96763ee865%40git.apache.org%3E
)

Jeff

On Thu, Apr 2, 2015 at 10:17 AM, Arnaud Héritier 
wrote:

> yes but it seems we are receiving one email per commit
> Thus with my change in the branch we are receiving 48 notifications due to
> the rebase + 2 for real commits on this branch
> Note that myself I don't find in my inbox the 50/50 notification email
>
> On Wed, Apr 1, 2015 at 9:38 AM, Jeff MAURY 
> wrote:
>
> > On Wed, Apr 1, 2015 at 2:46 AM, Arnaud Héritier 
> > wrote:
> >
> > > Hi all,
> > >
> > >   Is it normal to have so much (unreadable) notifications when we
> > rewrite a
> > > branch ?
> > >   I updated, cleaned and rewrote the history of the slf4j-log4j2 branch
> > >
> > > https://github.com/apache/maven/commits/slf4j-log4j2
> > >
> > >   I found this better to rewrite such WIP branch than creating a new
> one
> > > (and deleting this one)
> > >   Note that that are several old branches on the same subject that can
> be
> > > trashed I think :
> > >
> https://github.com/apache/maven/commits/feature/colorized-console/log4j2
> > > https://github.com/apache/maven/commits/logging/slf4j-log4j2
> > >
> > >   I think it is important to be notified when a branch is rewritten but
> > > having 50 emails when I replaced an old branch with < 10 commits by a
> > > sanitised one of 2 commits, I don't understand.
> > >
> > Rewriting history does not reduce the amount of modified/deleted/added
> > code. And as the notification emails also send diffs, 
> >
> > Jeff
> >
> > >
> > > Cheers
> > >
> > > Arnaud
> > >
> > > On Wed, Apr 1, 2015 at 2:24 AM,  wrote:
> > >
> > > > Package and configure log4J 2.2 by default.
> > > > Replace the content of conf/logging/log4j2.xml by the one from
> > > > conf/logging/log4j2-color.xml to enjoy the colorised console
> > > >
> > > >
> > > > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> > > > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/dbad2e53
> > > > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/dbad2e53
> > > > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/dbad2e53
> > > >
> > > > Branch: refs/heads/slf4j-log4j2
> > > > Commit: dbad2e536a7024a277eef1c56eaa2286f9f2a7f9
> > > > Parents: f78742f
> > > > Author: Arnaud Héritier 
> > > > Authored: Wed Apr 1 02:16:56 2015 +0200
> > > > Committer: Arnaud Héritier 
> > > > Committed: Wed Apr 1 02:16:56 2015 +0200
> > > >
> > > >
> --
> > > >  apache-maven/pom.xml| 15 +++-
> > > >  apache-maven/src/conf/logging/log4j2-color.xml  | 36
> > > 
> > > >  apache-maven/src/conf/logging/log4j2.xml| 36
> > > 
> > > >  maven-embedder/pom.xml  |  8 +
> > > >  .../maven/slf4j-configuration.properties|  2 +-
> > > >  pom.xml | 31
> +++--
> > > >  6 files changed, 123 insertions(+), 5 deletions(-)
> > > >
> --
> > > >
> > > >
> > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/dbad2e53/apache-maven/pom.xml
> > > >
> --
> > > > diff --git a/apache-maven/pom.xml b/apache-maven/pom.xml
> > > > index e8277b5..c3e9e49 100644
> > > > --- a/apache-maven/pom.xml
> > > > +++ b/apache-maven/pom.xml
> > > > @@ -95,7 +95,20 @@
> > > >  
> > > >  
> > > >org.slf4j
> > > > -  slf4j-simple
> > > > +  slf4j-ext
> > > > +
> > > > +
> > > > +  org.apache.logging.log4j
> > > > +  log4j-slf4j-impl
> > > > +
> > > > +
> > > > +  org.apache.logging.log4j
> > > > +  log4j-core
> > > > +
> 

Re: Unreadable commits notifications was Re: [49/50] [abbrv] maven git commit: Package and configure log4J 2.2 by default. Replace the content of conf/logging/log4j2.xml by the one from conf/logging/l

2015-04-01 Thread Jeff MAURY
gt; +
> > +  
> > +
> > +  
> > +  
> > +
> > +  
> > +
> > +  
> > +
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/dbad2e53/maven-embedder/pom.xml
> > --
> > diff --git a/maven-embedder/pom.xml b/maven-embedder/pom.xml
> > index 53f0724..ef8b935 100644
> > --- a/maven-embedder/pom.xml
> > +++ b/maven-embedder/pom.xml
> > @@ -82,6 +82,10 @@
> >  
> >  
> >org.slf4j
> > +  slf4j-ext
> > +
> > +
> > +  org.slf4j
> >slf4j-simple
> >true
> >  
> > @@ -90,6 +94,10 @@
> >logback-classic
> >true
> >  
> > +
> > +  org.apache.logging.log4j
> > +  log4j-slf4j-impl
> > +
> >  
> >  
> >commons-cli
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/dbad2e53/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> > --
> > diff --git
> >
> a/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> >
> b/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> > index 8741836..cd01f9e 100644
> > ---
> >
> a/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> > +++
> >
> b/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> > @@ -18,5 +18,5 @@
> >  # key = Slf4j effective logger factory implementation
> >  # value = corresponding o.a.m.cli.logging.Slf4jConfiguration class
> >  org.slf4j.impl.SimpleLoggerFactory
> > org.apache.maven.cli.logging.impl.Slf4jSimpleConfiguration
> > -org.slf4j.helpers.Log4jLoggerFactory
> > org.apache.maven.cli.logging.impl.Log4j2Configuration
> > +org.apache.logging.slf4j.Log4jLoggerFactory
> > org.apache.maven.cli.logging.impl.Log4j2Configuration
> >  ch.qos.logback.classic.LoggerContext
> > org.apache.maven.cli.logging.impl.LogbackConfiguration
> >
> > http://git-wip-us.apache.org/repos/asf/maven/blob/dbad2e53/pom.xml
> > --
> > diff --git a/pom.xml b/pom.xml
> > index b0ab4e8..87442f3 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -61,6 +61,9 @@
> >  1.3
> >  1.0.2.v20150114
> >  1.7.5
> > +2.2
> > +1.0.7
> > +1.11
> >
> >
> true
> >  
> >  apache-maven
> > @@ -252,6 +255,7 @@
> >  plexus-interpolation
> >  ${plexusInterpolationVersion}
> >
> > +  
> >
> >  org.slf4j
> >  slf4j-api
> > @@ -261,13 +265,34 @@
> >  org.slf4j
> >  slf4j-simple
> >  ${slf4jVersion}
> > -true
> >
> >
> >  ch.qos.logback
> >  logback-classic
> > -1.0.7
> > -true
> > +${logbackVersion}
> > +  
> > +  
> > +org.slf4j
> > +slf4j-ext
> > +${slf4jVersion}
> > +compile
> > +  
> > +  
> > +org.apache.logging.log4j
> > +log4j-slf4j-impl
> > +${log4j2Version}
> > +compile
> > +  
> > +  
> > +org.apache.logging.log4j
> > +log4j-core
> > +${log4j2Version}
> > +  
> > +  
> > +org.fusesource.jansi
> > +jansi
> > +${jansiVersion}
> > +runtime
> >
> >
> >
> >
> >
>
>
> --
>
> Arnaud
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Idea RFI: Artifact-based repositories

2015-03-21 Thread Jeff MAURY
You should look at news brought by latest 3.3 from Maven that target
extensibility but to my knowledge, extending the format of the POM is not
yet supported (see
http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/)

Regards
Jeff

On Sat, Mar 21, 2015 at 2:14 PM, Arcadiy Ivanov  wrote:

> So Maven pom is set in stone and no changes can be introduced to it?
> I'm writing this specifically to guage the community interest before
> starting the work. I.e. my intention is to have a general consensus that 1)
> it's a good thing to add 2) it's the right way to go about it.
>
> Generally speaking, adding optional tags does not break forward
> functionality, i.e. it's relatively safe.
>
> What would be the fundamental reason for never ever ever considering any
> additions to the POM ever again?
>
>
> On 2015-03-21 04:11, Jeff MAURY wrote:
>
>> then your stuff will not be Maven compatible. You will face non adoption
>> from the community
>>
>> Jeff
>>
>> On Sat, Mar 21, 2015 at 9:01 AM, Arcadiy Ivanov 
>> wrote:
>>
>>  Presumably, by editing maven-model/src/main/mdo/maven.mdo ? :)
>>>
>>>
>>> On 2015-03-21 03:31, Jeff MAURY wrote:
>>>
>>>  how will you extend the repository element in maven ?
>>>>
>>>> Jeff
>>>>
>>>> On Fri, Mar 20, 2015 at 11:52 PM, Arcadiy Ivanov 
>>>> wrote:
>>>>
>>>>   Hi folks,
>>>>
>>>>> I'd like to feel your temperature wrt the following improvement I would
>>>>> like to make to Maven before I start working on it.
>>>>>
>>>>> *== Artifact-based Reposi**tories* ==
>>>>>
>>>>> In Tycho we have these constructs:
>>>>>
>>>>> https://wiki.eclipse.org/Tycho/Reference_Card#
>>>>> Repository_providing_the_
>>>>> context_of_the_build
>>>>>
>>>>>
>>>>> eclipse-indigo
>>>>> p2
>>>>> http://download.eclipse.org/releases/indigo
>>>>>
>>>>>
>>>>> P2 repositories can be encapsulated in an archive. An archive,
>>>>> naturally,
>>>>> can be available as an artifact in some repo somewhere (including the
>>>>> local
>>>>> one).
>>>>>
>>>>>
>>>>> What would you think about adding something like:
>>>>>
>>>>>
>>>>>
>>>>> eclipse-indigo
>>>>> p2
>>>>> foo
>>>>> bar
>>>>> 1.2.3-SNAPSHOT
>>>>> tgz
>>>>> true
>>>>>
>>>>>
>>>>>
>>>>> The broad strokes are as follows:
>>>>>
>>>>>* Repo artifact becomes a dependency of an artifact being built on
>>>>> the
>>>>>  same terms as its parent would be, i.e. if you can't find parent
>>>>> you
>>>>>  can't build same with repo artifact (by default)
>>>>>* If repo  (or  to reverse the semantics) is
>>>>> false
>>>>>  (true), failure to resolve the repository does not lead to a
>>>>>  critical failure and reactor proceeeds as if the repository
>>>>>  declaration did not occur.
>>>>>* Repo artifact is attempted to be resolved using all of the
>>>>>  repositories inherited from parents, ad infinitum, or in the
>>>>>  repository declarations prior to the one being considered.
>>>>> Artifact
>>>>>  is, otherwise, resolved by standard means.
>>>>>
>>>>> Let me know what you think,
>>>>>
>>>>> --
>>>>> Arcadiy Ivanov
>>>>> arca...@gmail.com | @arcivanov | https://ivanov.biz
>>>>> https://github.com/arcivanov
>>>>>
>>>>>
>>>>>
>>>>>  --
>>> Arcadiy Ivanov
>>> arca...@gmail.com | @arcivanov | https://ivanov.biz
>>> https://github.com/arcivanov
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>
>
> --
> Arcadiy Ivanov
> arca...@gmail.com | @arcivanov | https://ivanov.biz
> https://github.com/arcivanov
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Idea RFI: Artifact-based repositories

2015-03-21 Thread Jeff MAURY
then your stuff will not be Maven compatible. You will face non adoption
from the community

Jeff

On Sat, Mar 21, 2015 at 9:01 AM, Arcadiy Ivanov  wrote:

> Presumably, by editing maven-model/src/main/mdo/maven.mdo ? :)
>
>
> On 2015-03-21 03:31, Jeff MAURY wrote:
>
>> how will you extend the repository element in maven ?
>>
>> Jeff
>>
>> On Fri, Mar 20, 2015 at 11:52 PM, Arcadiy Ivanov 
>> wrote:
>>
>>  Hi folks,
>>>
>>> I'd like to feel your temperature wrt the following improvement I would
>>> like to make to Maven before I start working on it.
>>>
>>> *== Artifact-based Reposi**tories* ==
>>>
>>> In Tycho we have these constructs:
>>>
>>> https://wiki.eclipse.org/Tycho/Reference_Card#Repository_providing_the_
>>> context_of_the_build
>>>
>>>   
>>>eclipse-indigo
>>>p2
>>>http://download.eclipse.org/releases/indigo
>>>   
>>>
>>> P2 repositories can be encapsulated in an archive. An archive, naturally,
>>> can be available as an artifact in some repo somewhere (including the
>>> local
>>> one).
>>>
>>>
>>> What would you think about adding something like:
>>>
>>>
>>>   
>>>eclipse-indigo
>>>p2
>>>foo
>>>bar
>>>1.2.3-SNAPSHOT
>>>tgz
>>>true
>>>   
>>>
>>>
>>> The broad strokes are as follows:
>>>
>>>   * Repo artifact becomes a dependency of an artifact being built on the
>>> same terms as its parent would be, i.e. if you can't find parent you
>>> can't build same with repo artifact (by default)
>>>   * If repo  (or  to reverse the semantics) is false
>>> (true), failure to resolve the repository does not lead to a
>>> critical failure and reactor proceeeds as if the repository
>>> declaration did not occur.
>>>   * Repo artifact is attempted to be resolved using all of the
>>> repositories inherited from parents, ad infinitum, or in the
>>> repository declarations prior to the one being considered. Artifact
>>> is, otherwise, resolved by standard means.
>>>
>>> Let me know what you think,
>>>
>>> --
>>> Arcadiy Ivanov
>>> arca...@gmail.com | @arcivanov | https://ivanov.biz
>>> https://github.com/arcivanov
>>>
>>>
>>>
>>
>
> --
> Arcadiy Ivanov
> arca...@gmail.com | @arcivanov | https://ivanov.biz
> https://github.com/arcivanov
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Idea RFI: Artifact-based repositories

2015-03-21 Thread Jeff MAURY
how will you extend the repository element in maven ?

Jeff

On Fri, Mar 20, 2015 at 11:52 PM, Arcadiy Ivanov  wrote:

> Hi folks,
>
> I'd like to feel your temperature wrt the following improvement I would
> like to make to Maven before I start working on it.
>
> *== Artifact-based Reposi**tories* ==
>
> In Tycho we have these constructs:
>
> https://wiki.eclipse.org/Tycho/Reference_Card#Repository_providing_the_
> context_of_the_build
>
>  
>   eclipse-indigo
>   p2
>   http://download.eclipse.org/releases/indigo
>  
>
> P2 repositories can be encapsulated in an archive. An archive, naturally,
> can be available as an artifact in some repo somewhere (including the local
> one).
>
>
> What would you think about adding something like:
>
>
>  
>   eclipse-indigo
>   p2
>   foo
>   bar
>   1.2.3-SNAPSHOT
>   tgz
>   true
>  
>
>
> The broad strokes are as follows:
>
>  * Repo artifact becomes a dependency of an artifact being built on the
>same terms as its parent would be, i.e. if you can't find parent you
>can't build same with repo artifact (by default)
>  * If repo  (or  to reverse the semantics) is false
>(true), failure to resolve the repository does not lead to a
>critical failure and reactor proceeeds as if the repository
>declaration did not occur.
>  * Repo artifact is attempted to be resolved using all of the
>repositories inherited from parents, ad infinitum, or in the
>repository declarations prior to the one being considered. Artifact
>is, otherwise, resolved by standard means.
>
> Let me know what you think,
>
> --
> Arcadiy Ivanov
> arca...@gmail.com | @arcivanov | https://ivanov.biz
> https://github.com/arcivanov
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: "Not a local repository. It is a local repository cache." (was: Fwd: Why Is Maven Ignoring My Local Repo?)

2014-04-26 Thread Jeff MAURY
 Central
>>>>>>
>>>>>> [ERROR] Failed to execute goal
>>>>>>
>>>>>>  org.apache.maven.plugins:maven-site-plugin:3.3:site
>>>>>
>>>>>  (default-site) on project csharp-windows-elevate: Execution
>>>>>> default-site
>>>>>>
>>>>>>  of
>>>>>
>>>>>  goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed:
>>>>>> Plugin
>>>>>> org.apache.maven.plugins:maven-site-plugin:3.3 or one of its
>>>>>> dependencies
>>>>>> could not be resolved: Could not find artifact
>>>>>>
>>>>>>  net.trajano.wagon:wagon-git:jar:1.0.1-SNAPSHOT
>>>>>
>>>>>  in local-nexus (http://localhost:8081/nexus/content/groups/public) ->
>>>>>> [Help 1]
>>>>>>
>>>>>> I can see the artifact in my local repo, but maven somehow feels,
>>>>>> because
>>>>>> it cannot find it in my nexus repository, then it does not exist.
>>>>>>
>>>>>> The side problem is, even though nexus can see the artifact in its
>>>>>> index,
>>>>>> it refuses to download it.
>>>>>>
>>>>>> Why do maven and nexus work so hard at ignoring artifacts?
>>>>>>
>>>>>> Cheers, Eric
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  -
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-23 Thread Jeff MAURY
+1

Jeff


On Tue, Jul 23, 2013 at 9:40 PM, Michael-O <1983-01...@gmx.net> wrote:

> Am 2013-07-23 15:59, schrieb Stephen Connolly:
>
>  This vote is to cover the minimum required version of Java for Maven Core.
>>
>>
> Given than most companies/folks react only when something has been
> discontinued, I would move to Java 6 as a baseline not before Christman
> 2013. First release in 2014 can ben Java 6+.
>
> E.g., we now have a policy to make all apps run in Java 7 but this will
> take months and even some are not compatible (doesn't concern mine...but).
>
> So -0,
>
> Michael
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: [VOTE] Apache 3.1.0-alpha-1

2013-05-28 Thread Jeff MAURY
Tested on my Tycho (0.17.0 and latest staged 0.18.0) build and it fails but
I think this is a Tycho issue.

Regards
Jeff



On Tue, May 28, 2013 at 10:03 AM, Baptiste MATHUS wrote:

> OK, you're right. Jason's cancellation mail was
> http://mail-archives.apache.org/mod_mbox/maven-dev/201305.mbox/browser and
> is actually for -038.
>
> Gmail has merged threads for me so I mixed up things.
>
> Thanks
>
>
> 2013/5/28 Stephen Connolly 
>
> > I think staging 044 is the respin
> >
> >
> > On 28 May 2013 08:10, Baptiste MATHUS  wrote:
> >
> > > I *think* that vote was also cancelled, isn't it?
> > >
> > >
> > > 2013/5/27 Hervé BOUTEMY 
> > >
> > > > +1
> > > >
> > > > works fine for me
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 25 mai 2013 08:51:00 Jason van Zyl a écrit :
> > > > > Here are the release bits for 3.1.0-alpha-1:
> > > > >
> > > > > Release notes:
> > > > >
> > > >
> > >
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18
> > > > > 967
> > > > >
> > > > > Staging repository:
> > > > > https://repository.apache.org/content/repositories/maven-044/
> > > > >
> > > > > Staged distribution:
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-044/org/apache/mave
> > > > > n/apache-maven/3.1.0-alpha-1/
> > > > >
> > > > > Staged Site:
> > > > > http://maven.apache.org/ref/3.1.0-alpha-1
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jason
> > > > >
> > > > > --
> > > > > Jason van Zyl
> > > > > Founder & CTO, Sonatype
> > > > > Founder,  Apache Maven
> > > > > http://twitter.com/jvanzyl
> > > > > -
> > > > >
> > > > > We know what we are, but know not what we may be.
> > > > >
> > > > > -- Shakespeare
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> -----
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Baptiste  MATHUS - http://batmat.net
> > > Sauvez un arbre,
> > > Mangez un castor !
> > >
> >
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Surefire - Run tests on remote hosts through SSH

2013-02-18 Thread Jeff MAURY
Looks interesting but sharing the current work dir is not enough:
- what about dependencies (in local repo or in reactor)
- what about multi modules project

Jeff
Le 18 févr. 2013 10:52, "Julien Nicoulaud"  a
écrit :

> Hi all,
>
> I'm writing a Maven plugin for Vagrant (
> http://nicoulaj.github.com/vagrant-maven-plugin), which is a tool for
> managing virtual machines. Right now I have goals to start/stop a virtual
> machine on pre/post-integration-test phases.
>
> The next step would be to run integration tests directly on the virtual
> machine. Vagrant shares the current working directory with the VM, so it
> really is just a matter of "piping" the forked test runner process through
> SSH.
>
> After taking a quick look at Surefire API, it seems to me this could be
> done by implementing a new provider that would just "wrap" the real one to
> have it executed over SSH.
>
> Can any Surefire expert provide advice on this ? Is there a cleaner/simpler
> way ?
>
> Sorry if I am asking this on the wrong place, but it seems Surefire
> mailing-lists do not work anymore.
>
> Cheers,
> Julien
>


Re: EOL of 1.5 as minimum

2013-02-07 Thread Jeff MAURY
 in generics that means that some of the generics
> I want to introduce into Maven's APIs will not compile on JDK 1.5 => that
> is a valid reason to require 1.6 as a build maven requirement, but
> animal-sniffer can let us keep 1.5 as a run-time requirement.
>
> Valid reasons to move to 1.6 are things like:
>
> * This 3rd party dependency we use has a bug that needs fixing, they have
> fixed it in version V.W but that artifact is using 1.6 bytecode so we
> either keep the bug or upgrade the dependency and consequently upgrade the
> minimum required JVM to run Maven.
>
> * There is a big feature that I want to implement and it will be 10 times
> easier to write and maintain with the language features in 1.6
>
> My point is I am 100% fine with us upping the requirement to 1.6 or 1.7. I
> just want a *good* reason... doesn't have to be a *big* reason... just a
> good one.
>
> -STephen
>
>
> > >>
> > >> I also do wonder how many installations are in said data centres and
> are
> > >> unable to report their presence. So I do believe that the 1.5% figure
> > > would
> > >> be low, but certainly within an order of magnitude.
> > >
> > > I'm thinking that'd certainly be averaged with versions bigger than
> JDK5
> > > also not reporting.
> > >
> > >>
> > >> So, please do not cut us off from future updates.
> > >>
> > >> Thanks,
> > >>
> > >> -Chris
> > >>
> > >>
> > >>
> > >> On Thu, Feb 7, 2013 at 12:05 PM, Manfred Moser 
> > > wrote:
> > >>
> > >>> Totally agree... if people really need to build for older Java
> runtimes
> > >>> they still can..  but if Oracle thinks they dont want to support JDK
> <
> > > 1.7
> > >>> without getting paid why would the Maven project do it ;-)
> > >>>
> > >>> For now 1.6 seems just fine and I would even say a jump to 1.7 in the
> > > next
> > >>> year or three (;-)) would be reasonable..
> > >>>
> > >>> manfred
> > >>>
> > >>>> +1, bump to JDK6 minimum for Maven.
> > >>>>
> > >>>>
> > >>>> 2013/2/6 Stephen Connolly 
> > >>>>
> > >>>>> I think we should at least have a minor version bump on core to
> > >>>>> co-incide... Though I think calling it maven 4.0 might be better
> > > (that
> > >>>>> way
> > >>>>> we catch up with the model version ;-)
> > >>>>>
> > >>>>> On Wednesday, 6 February 2013, Olivier Lamy wrote:
> > >>>>>
> > >>>>>> Hi,
> > >>>>>> As we are now in 2013, it's probably time to think about that
> > > (again).
> > >>>>>>
> > >>>>>> Reading [1], even 1.6 won't be anymore updated after feb 2013.
> > >>>>>>
> > >>>>>> Can we say we are safe to go to 1.6 as minimum required ?
> > >>>>>>
> > >>>>>> NOTE: That will probably need a vote. So depending on how the
> > > thread
> > >>>>>> move, I will start a vote (or not).
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> --
> > >>>>>> Olivier Lamy
> > >>>>>> Talend: http://coders.talend.com
> > >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >>>>>>
> > >>>>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> > >>>>>>
> > >>>>>>
> > > -
> > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>>>> 
> > >>>>>> For additional commands, e-mail:
> > >>>>> dev-h...@maven.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Baptiste  MATHUS - http://batmat.net
> > >>>>> Sauvez un arbre,
> > >>>>> Mangez un castor ! nbsp;!
> > >>>>
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>>
> > >>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Pain with MNG-5181 (_maven.repositories)

2013-02-01 Thread Jeff MAURY
y
> > >> Talend: http://coders.talend.com
> > >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > -
> > > Arnaud Héritier
> > > http://aheritier.net
> > > Mail/GTalk: aheritier AT gmail DOT com
> > > Twitter/Skype : aheritier
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> >
> > Our achievements speak for themselves. What we have to keep track
> > of are our failures, discouragements and doubts. We tend to forget
> > the past difficulties, the many false starts, and the painful
> > groping. We see our past achievements as the end result of a
> > clean forward thrust, and our present difficulties as
> > signs of decline and decay.
> >
> >  -- Eric Hoffer, Reflections on the Human Condition
> >
> >
> >
> >
> >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Cas build failure

2012-11-23 Thread Jeff MAURY
I think you did something wrong while pastiong from the web page.
According to the error, it seems your pom didn't start with  wrote:

> Hello Team,
>
> I'm following the instructions on
>
> https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
>
> I'm using the pom.xml file that is described on the upper page.
>
> the problem is that I'm stuck at the step "Build it" where we build the
> Cas.
> I have the Error below:
> [[ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: unknown
> POM Location: C:\opt\work\pom.xml
>
> Reason: Parse error reading POM. Reason: processing instruction can not
> have PIT
> arget with reserveld xml name (position: START_DOCUMENT seen \r\n @2:7)
>   for project unknown at C:\opt\work\pom.xml]
>
> Can you please advise on what is missing in my pom.xml file??
>



-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Toolchains integration point

2012-09-24 Thread Jeff MAURY
Hello,

I am working on integration toolchains configuration files into Jenkins.
In order to be compatible with distributed Jenkins, I need to be able to
dynamically compute the path of the JDKs configured in the toolchains
configuration file.
Do you know if there is an integration point in Maven for the toolchains
feature.

Thanks
Jeff


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: How to customize the folder structure

2012-06-01 Thread Jeff MAURY
I would recommand to follow Maven conventions and not trying to break
Maven, assumed that if you do that while beginning with Maven, you will FAIL

Jeff
Le 1 juin 2012 08:22, "preetppg"  a écrit :

>
> Team,
>
> I am doing a POC using Maven.
>
> Can anybody share the steps to customize the folder structure while
> creating
> a java project ?
>
>
>  Command Prompt $$
>
> D:\Explore Maven\dummy_app2>mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
> Java version: 1.6.0
> Java home: D:\rad\7.5\SDP75\jdk\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86"
> Family: "windows"
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/How-to-customize-the-folder-structure-tp5710515.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Developing a new repository layout / proxy?

2012-01-25 Thread Jeff MAURY
You must implement the ArtificatRepositoryLayout (
http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/repository/layout/ArtifactRepositoryLayout.java?view=markup)
and register it as a Plexus component.
You can find an example for the default Maven repository layout here:
http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/artifact/repository/layout/DefaultRepositoryLayout.java?view=markup

Regards
Jeff

On Fri, Jan 20, 2012 at 2:45 PM, Bertram, Alexander
wrote:

> Hi there,
>
> I'm working on Renjin, an interpreter for the R language written in Java
> for the JVM. Since a major goal of the project is to make it easier to
> intermix R language packages and java packages, I'd like to develop a set
> of plugins for maven to that make it easy to include R-language packages in
> java/maven projects, and vice-versa.
>
> I've tried to look through the docs, but I'm still not sure on how to build
> a plugin for a new repo layout: the idea would be that java developers
> could include a dependency for an R package like:
>
> 
> org.r-project.cran
> packageName
> 1.0
> 
>
> And have some sort of hook that would then track down the R sources from
> the CRAN repository, make some transformations, and then store as a jar in
> the local maven repo. Is this possible? Can someone point me to the
> javadocs for the relevant extension point?
>
> Many thanks,
>
> Alex
>



-- 
Jeff MAURY

"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: [CALL FOR TEST] Apache Maven 3.0.4-RC5 staged

2012-01-10 Thread Jeff MAURY
Works fine with 2 of my Tycho builds, maven-gwt-plugin and
hudson-the-definitive-guide

Jeff

On Tue, Jan 10, 2012 at 2:13 PM, Mirko Friedenhagen  wrote:

> Works fine here.
>
> Regards Mirko
>
> On Tue, Jan 10, 2012 at 01:21, Stephen Connolly
>  wrote:
> > None here
> >
> > On 9 January 2012 23:44, Brett Porter  wrote:
> >> No issues here.
> >>
> >> On 06/01/2012, at 7:52 AM, Olivier Lamy wrote:
> >>
> >>> Hello,
> >>>
> >>> Apache Maven 3.0.4-RC5 has been staged for testing purpose.
> >>> This is a preview (and not an official supported version) of the
> >>> coming 3.0.4 official release.
> >>>
> >>> The repository is available here:
> >>> https://repository.apache.org/content/repositories/maven-017/
> >>>
> >>> For convenience, binaries have been copied here:
> >>> http://people.apache.org/~olamy/maven/3.0.4-RC5/
> >>>
> >>> Changelog is available here:
> >>>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17215&styleName=Text&projectId=10500&Create=Create
> >>>
> >>> Since previous RC following changes have been added:
> >>> * [MNG-5224] - REGRESSION: Injected Settings in a Mojo are missing the
> >>> profiles from settings.xml
> >>> * [MNG-5225] - The default version of the maven-site-plugin as defined
> >>> in the site-lifecycle must be 3.x
> >>>
> >>> The review period will end on 16 Jan (see
> >>> http://s.apache.org/REVIEW-END-MVN-3.0.4-RC5)
> >>>
> >>> Feel free to report any regressions in
> http://jira.codehaus.org/browse/MNG
> >>>
> >>> Have Fun!
> >>> --
> >>> Olivier Lamy
> >>> Talend: http://coders.talend.com
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>
> >> --
> >> Brett Porter
> >> br...@apache.org
> >> http://brettporter.wordpress.com/
> >> http://au.linkedin.com/in/brettporter
> >> http://twitter.com/brettporter
> >>
> >>
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: pom.xml parser

2011-12-11 Thread Jeff MAURY
Look around
http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/java/org/apache/maven/model/building/

Regards
Jeff MAURY

On Sun, Dec 11, 2011 at 8:45 PM, Simone Tripodi wrote:

> Hi all guys,
> can you please point me to the pom.xml parser location on SVN?
> Many thanks in advance, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: [VOTE] Apache Maven 3.0.4

2011-11-27 Thread Jeff MAURY
Works fine with gwt-maven-plugin, jenkins-the-definitive-guide-book and one
of my Hadoop based project.

Regards
Jeff MAURY

2011/11/27 Arnaud Héritier 

> +1 (binding)
> No regression found on a large set of projects.
>
> Thx
>
> Cheers
>
> Le 27 nov. 2011 à 14:38, Robert Scholte  a écrit :
>
> >
> >
> > Tried on several Maven and Mojo projects, all looking good.
> >
> >
> >
> > +1
> >
> >
> >
> > -Robert
> >
> >
> >> Date: Sat, 26 Nov 2011 00:22:11 -0200
> >> Subject: Re: [VOTE] Apache Maven 3.0.4
> >> From: velo...@gmail.com
> >> To: dev@maven.apache.org
> >>
> >> Flexmojos built just fine!
> >>
> >> On Fri, Nov 25, 2011 at 7:17 AM, Olivier Lamy  wrote:
> >>
> >>> Hello,
> >>>
> >>> I'd like to release Apache Maven 3.0.4.
> >>>
> >>> We fixed 31 issues.
> >>> See release notes:
> >>>
> >>>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=17215
> >>>
> >>> The staged repo is available here:
> >>> https://repository.apache.org/content/repositories/maven-244/ .
> >>>
> >>> The staged distributions are available here:
> >>> http://people.apache.org/builds/maven/3.0.4/
> >>>
> >>> As we are near the week end, the vote will be a 5 days vote (which is
> >>> around 120 hours)
> >>>
> >>> [+1]
> >>> [0]
> >>> [-1]
> >>>
> >>> Here my +1
> >>>
> >>> Thanks,
> >>> --
> >>> Olivier Lamy
> >>> Talend: http://coders.talend.com
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: POM5 proposal

2011-07-27 Thread Jeff MAURY
On Wed, Jul 27, 2011 at 7:45 PM, Tim O'Brien  wrote:

> Vincent that seems like a mistake.  Why add more specific elements like
> Wiki
> and API.  Why make the POM syntax this specific.   Why not make it free
> from, something like:
>
> 
>  
> 
>
> Which you could compact down in some groovy syntax to something like
> "wiki:"
>
> I see a lot of people using Maven for projects other than open source Java
> (or even projects that involve code).  I'd like to see the next version of
> the POM move toward being something more agnostic.
>
+1

>
> On Wed, Jul 27, 2011 at 12:16 AM, Vincent Siveton  >wrote:
>
> > Hi Benson
> >
> > Thanks for your proposal!
> >
> > IMHO the pom5 should include some tags like  or
> >  and the javadoc 
> > see MPIR-149 MJAVADOC-32
> >
> > Cheers,
> >
> > Vincent
> >
> > 2011/7/24 Benson Margulies :
> > > Since I can't edit the Wiki, I created:
> > >
> > >
> >
> https://docs.google.com/document/d/1k3E4vx_4cKJ4zzksVM4oROX3Dffsh0Q4VOGVjd3oUto/edit?hl=en_US
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: annotate complex types in lists

2011-06-30 Thread Jeff MAURY
Tony,

the simplest way of doing is to use Arrays. If you must use List, then look
at the Mojo documentation as there are some limitations:
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Complex_Objects

Regards
Jeff MAURY

On Thu, Jun 30, 2011 at 9:48 AM, DE GOEDE Tony <
tony.dego...@nl.thalesgroup.com> wrote:

> Hello,
>
> ** **
>
> I have a problem.
>
> ** **
>
> I am building a new maven plugin to interface with a local build tool.
>
> To control the plugin I supply some configuration data. For simple elements
> this works using annotations.
>
> Because we want to configure maven to get the correct target artifacts from
> nexus for the current platform, we need more complex type of configuration
> data. Example:
>
> ** **
>
> 
>
> 
>
> 
>
> linux64
>
> 
>
> targetX
>
> targetY
>
> 
>
> 
>
> ** **
>
> 
>
> linux
>
> 
>
> targetZ
>
> 
>
> 
>
> 
>
> etc
>
> ** **
>
> How do I annotate this list in my plugin.
>
> There is no example on the maven website for a list of complex data types.
> 
>
> ** **
>
> Does anybody knows how to implement this, have an alternative or maybe have
> an example of how to do it.
>
> I am very unfamiliar in programming plugins and in using java.
>
> ** **
>
> Thanks in advance.
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> [image: Description: Thales Nederland]
>
> *Tony de Goede*
>
> Software Engineer
>
> Sensors
>
> ** **
>
>
> Phone:
>
>
> +31 (0)74 248 4599
>
> Mobile:
>
> +31 (0)6 4405 7890
>
> E-mail:
>
> tony.dego...@nl.thalesgroup.com
>
> ** **
>
>
> *THALES NEDERLAND*
>
> Haaksbergerstraat 49
>
> 7554 PA Hengelo
>
>
> PO Box 42
>
> 7550 GD Hengelo
>
> The Netherlands
>
> www.thalesgroup.com/nl
>
> ** **
>
> ** **
>
> 
> Disclaimer:
>
> If you are not the intended recipient of this email, please notify the sender 
> and delete it.
> Any unauthorized copying, disclosure or distribution of this email or its 
> attachment(s) is forbidden.
> Thales Nederland BV will not accept liability for any damage caused by this 
> email or its attachment(s).
> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of 
> Commerce under number 06061578.
> 
>
>
>


-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: relativePath in m3 release notes

2010-09-16 Thread Jeff MAURY
I agree with Baptiste that the explanation is ambiguous. I understand the
same thing.

Regards
Jeff MAURY

On Thu, Sep 16, 2010 at 11:30 AM, Benjamin Bentmann <
benjamin.bentm...@udo.edu> wrote:

> Baptiste MATHUS wrote:
>
>  Does it mean that  must now be put *even if* the parent pom
>> is
>> in the default path?
>>
>
> No, it means the effective value for  should be correct,
> whether that value is given by the user or using the implicit default.
>
>
> Benjamin
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury


Re: Mojo Complex Object From Pom

2010-08-18 Thread Jeff MAURY
Your class MUST have an empty constructor !!!

Regards
Jeff MAURY

On Wed, Aug 18, 2010 at 3:21 PM, onlinegeek  wrote:

>
> I am trying to pass an object through my pom to my maven mojo.
> I have a class...
>
> public class Shortcut {
>
>/**
> * @parameter expression="${project}"
> */
>private String name;
>private String description;
>private String commandLine;
>
>public Shortcut(String Name)
>{
>setName(Name);
>//setDescription(Description);
>//setCommandLine(CommandLine);
>}
>
>public void setName(String name) {
>this.name = name;
>}
>
>public String getName() {
>return name;
>}
>
>public void setDescription(String description) {
>this.description = description;
>}
>
>public String getDescription() {
>return description;
>}
>
>public void setCommandLine(String commandLine) {
>this.commandLine = commandLine;
>}
>
>public String getCommandLine() {
>return commandLine;
>}
>
> }
>
> and i declare the variable
> /**
> * Shortcuts to add to XML
> * @parameter
> */
>private Shortcut shortcut;
>
> and in my pom i declare this in the  tag
> 
>TESTING
>TESTING
>TESTING
> 
> I keep getting this error
> [ERROR] Failed to execute goal SOME.PACKAGE (default-cli) on project test:
> Unable to parse configuration of mojo SOME.PACKAGE for parameter shortcut:
> Class 'SOME.PACKAGE.Shortcut' cannot be instantiated -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal SOME.PACKAGE (default-cli) on project test: Unable to parse
> configuration of mojo SOME.PACKAGE for parameter shortcut: Class
> 'SOME.PACKAGE.Shortcut' cannot be instantiated
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:589)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:324)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247)
>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
>at org.apache.maven.cli.MavenCli.execute(MavenCli.java:427)
>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:121)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to
> parse configuration of mojo SOME.PACKAGE for parameter shortcut: Class
> 'SOME.PACKAGE.Shortcut' cannot be instantiated
>at
>
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:643)
>at
>
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:595)
>at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:94)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:577)
>... 14 more
> Caused by:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Class 'SOME.PACKAGE.Shortcut' cannot be instantiated
>at
>
> org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:133)
>at
>
> org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:90)
>at
>
> org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:260)
>at
>
> org.codehaus.plexu