nized by this
project).
> [ProtonJ2] Add errorprone or some other linter/checker to the maven build
> -
>
> Key: PROTON-2417
> URL: https://issues.apache.org/jir
jiridanek closed pull request #2: PROTON-2417 Add errorprone to the maven build
URL: https://github.com/apache/qpid-protonj2/pull/2
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
jiridanek commented on pull request #2:
URL: https://github.com/apache/qpid-protonj2/pull/2#issuecomment-906726522
> These tools can be useful when run from an IDE or something but I don't
tend to find them useful in the maven build and especially errorprone which
tends to br
tool reports lots of things that are more a matter of style than
correctness
*Error Prone*: TODO (I suppressed the JavaDoc Google StyleGuide check that was
responsible for most of the reports before)
> [ProtonJ2] Add errorprone or some other linter/checker to the mave
jiridanek commented on a change in pull request #2:
URL: https://github.com/apache/qpid-protonj2/pull/2#discussion_r696937268
##
File path:
protonj2-client/src/test/java/org/apache/qpid/protonj2/client/util/ExternalMessage.java
##
@@ -237,6 +237,7 @@ public String contentEncod
rone*: TODO (I suppressed the JavaDoc Google StyleGuide check that was
responsible for most of the reports before)
> [ProtonJ2] Add errorprone or some other linter/checker to the maven build
> -
>
>
rror Prone*: TODO (I suppressed the JavaDoc Google StyleGuide check that was
responsible for most of the reports before)
> [ProtonJ2] Add errorprone or some other linter/checker to the maven build
> -
>
>
fore)
> [ProtonJ2] Add errorprone or some other linter/checker to the maven build
> -
>
> Key: PROTON-2417
> URL: https://issues.apache.org/jira/browse/PROTON-2417
>
://scan.coverity.com/).
One (or more) of these tools/services could/should be used, because they can
find real bugs with only a reasonable effort.
> [ProtonJ2] Add errorprone or some other linter/checker to the maven bu
ome other linter/checker to the maven build
> -
>
> Key: PROTON-2417
> URL: https://issues.apache.org/jira/browse/PROTON-2417
> Project: Qpid Proton
>
tabish121 commented on pull request #2:
URL: https://github.com/apache/qpid-protonj2/pull/2#issuecomment-904994379
These tools can be useful when run from an IDE or something but I don't tend
to find them useful in the maven build and especially errorprone which tends to
break more
jiridanek commented on pull request #2:
URL: https://github.com/apache/qpid-protonj2/pull/2#issuecomment-904718155
Few examples of what it reports, from
https://github.com/apache/qpid-protonj2/runs/3412406596
```
Warning:
/home/runner/work/qpid-protonj2/qpid-protonj2/protonj2-te
Jiri Daněk created PROTON-2417:
--
Summary: [ProtonJ2] Add errorprone or some other linter/checker to
the maven build
Key: PROTON-2417
URL: https://issues.apache.org/jira/browse/PROTON-2417
Project: Qpid
[
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDIT-39:
-
Fix Version/s: 0.1.0
> Make qpid-jms-client version a parameter of Maven bu
[
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed QPIDIT-39.
Resolution: Fixed
> Make qpid-jms-client version a parameter of Maven bu
[
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPIDIT-39:
---
Affects Version/s: 0.1.0
> Make qpid-jms-client version a parameter of Maven bu
and fix version?
> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Inter
.com/apache/qpid-interop-test/blob/master/pom.xml#L56
> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
>
[
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet reassigned QPIDIT-39:
--
Assignee: Kim van der Riet
> Make qpid-jms-client version a parameter of Maven bu
java/pom.xml#L46
> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Inter
-jms-client.version=0.20.0 package
{noformat}
> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
>
ould implement it myself and send a
patch. But this may be already in the works as part of the Jenkins issue.
> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https:
Jiri Danek created QPIDIT-39:
Summary: Make qpid-jms-client version a parameter of Maven build
Key: QPIDIT-39
URL: https://issues.apache.org/jira/browse/QPIDIT-39
Project: Apache QPID IT
Issue
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-5989:
--
Fix Version/s: (was: 0.31)
0.30
> Maven build generates duplicate system t
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew MacBean resolved QPID-5989.
--
Resolution: Fixed
> Maven build generates duplicate system test class fi
hink this must be included in
0.30, otherwise other merges involving systems tests will be difficult.
> Maven build generates duplicate system test class files
> ---
>
> Key: QPID-5989
> URL: https:
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-5989:
-
Assignee: Andrew MacBean
> Maven build generates duplicate system test class fi
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-5989:
-
Status: Reviewable (was: In Progress)
> Maven build generates duplicate system test class fi
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-5989:
-
Assignee: Keith Wall (was: Andrew MacBean)
> Maven build generates duplicate system test class fi
[
https://issues.apache.org/jira/browse/QPID-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-5989:
-
Assignee: Andrew MacBean (was: Keith Wall)
> Maven build generates duplicate system test class fi
mmit 1617697 from [~godfrer] in branch 'qpid/trunk'
[ https://svn.apache.org/r1617697 ]
QPID-5989 : remove empty directories left behind by git users :-)
> Maven build generates duplicate system test class files
> ---
>
>
mmit 1617503 from [~k-wall] in branch 'qpid/trunk'
[ https://svn.apache.org/r1617503 ]
QPID-5989: [Java Tests] Relocate system test classes to beneath src/test/java
> Maven build generates duplicate system test class files
> ---
>
twice. This is causing problems for tools such
as Sonar. (was: Running the test-comple shows that some classes with systst
directories are being compiled twice. This is causing problems for tools such
as Sonar.)
> Maven build generates duplicate system test class fi
Keith Wall created QPID-5989:
Summary: Maven build generates duplicate system test class files
Key: QPID-5989
URL: https://issues.apache.org/jira/browse/QPID-5989
Project: Qpid
Issue Type: Bug
mmit 1594177 from [~gemmellr] in branch 'qpid/trunk'
[ https://svn.apache.org/r1594177 ]
QPID-5764: update note to reflect the trunk maven build no longer requiring
flag to enable
> [Java] add a note detailing the move to the Maven build fo
[
https://issues.apache.org/jira/browse/QPID-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPID-5764.
--
Resolution: Fixed
> [Java] add a note detailing the move to the Maven build for future relea
mmit 1594179 from [~gemmellr] in branch 'qpid/branches/0.28'
[ https://svn.apache.org/r1594179 ]
QPID-5764: add note detaling the move to the maven build for future releases
merged from trunk r1594176
> [Java] add a note detailing the move to the Maven build fo
mmit 1594176 from [~gemmellr] in branch 'qpid/trunk'
[ https://svn.apache.org/r1594176 ]
QPID-5764: add note detaling the move to the maven build for future releases,
to be merged to 0.28 branch
> [Java] add a note detailing the move to the Maven build fo
Robbie Gemmell created QPID-5764:
Summary: [Java] add a note detailing the move to the Maven build
for future releases
Key: QPID-5764
URL: https://issues.apache.org/jira/browse/QPID-5764
Project
mmit 1586274 from rob...@apache.org in branch 'pom/trunk'
[ https://svn.apache.org/r1586274 ]
QPID-5676, QPID-5048: go back to using the original BCEL dependency and instead
update the dependency checking to cope with its lack of metadata
> [Java Broker] update the BCEL dependency to matc
mmit 1586273 from rob...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1586273 ]
QPID-5676, QPID-5677, QPID-5048: go back to using the original BCEL dependency,
update dependency related info accordingly
> [Java Broker] update the BCEL dependency to matc
mmit 1586272 from rob...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1586272 ]
QPID-5676: revert r1586026, taking a different approach to equalise the builds
> [Java Broker] update the BCEL dependency to matc
the maven build
> -
>
> Key: QPID-5676
> URL: https://issues.apache.org/jira/browse/QPID-5676
> Project: Qpid
> Issue Type: Task
> Components: Java Brok
?
> [Java Broker] update the BCEL dependency to match the maven build
> -
>
> Key: QPID-5676
> URL: https://issues.apache.org/jira/browse/QPID-5676
> Project: Qpid
>
mmit 1586026 from rob...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1586026 ]
QPID-5676: update BCEL dependency in the Ant build to match previous change for
the maven build
> [Java Broker] update the BCEL dependency to matc
Robbie Gemmell created QPID-5676:
Summary: [Java Broker] update the BCEL dependency to match the
maven build
Key: QPID-5676
URL: https://issues.apache.org/jira/browse/QPID-5676
Project: Qpid
mewhat from the first two. Because core proton
developers can't narrow their view to just Java, and real testing will
involve interacting with stuff not implemented in Java, it's fairly
likely that a maven build suitable for group (1) will be a bit more
complicated than you might think
I also took Alex's suggestion to mean leaving the Ant build in place and
then adding a Maven build too.
Whilst I have stated my dislike for this idea in the past in relation to
the main Qpid tree, if this is what it took to have a maven build for
proton I think it would be the way to go
tually switch the main qpid java build over to maven. I think maven has
too many advantages not to use if starting something fresh now, but I can
see that even the numerous benefits are a hard sell again the time required
to make the change and the fact so many of the Qpid developers seem to hate
it w
As others have indicated, many of the points being raised are basically
solvable 'problems'. I really doubt we would be the first project in the
world to use maven that might be included in a distro (or say twenty, for
projects with more widespread reach).
I understand that it might not be the eas
On 07/25/2012 04:49 PM, Robbie Gemmell wrote:
Even philosophically it seemed wrong to me - I want to compile my changes
and it goes off looking for any updates to jar files the project or the
tool itself might use. That sort of system update seems to me like it
should be an entirely separate step
On 24 July 2012 18:41, Gordon Sim wrote:
> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>
>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>>
>
> Any particular reason?
>
>
Because I think more people (excluding some of us, obviously) would prefer
that we use maven instead.
> I m
e and others hate. (It may be I'm stretching the
analogy too far!)
Also, burdening Joseph by having him
create/maintain a separate Ant build also takes away his efforts towards
creating an awesome Maven build.
I don't think that was what was being proposed. There is already an ant
On Wed, 2012-07-25 at 12:50 -0400, Joseph Ottinger wrote:
> Well, as far as I could tell, there *are* no tests yet - which worries
> me. But that's part of what motivated my desire to move to Maven; we
> can configure Arquillian to crank up a Qpid instance so that we can
> run tests as part of the
rs, never
having worked with it, tend to awfulize Maven, and then stick with Ant,
continuing their misconception of Maven. Maven is really an ice cream
cone,
not a brussels sprout, but sometimes people need to be given a push to
find
that out. :) Also, burdening Joseph by having him create/mainta
ith providing an Ant build is that non-Maven users, never
>>> having worked with it, tend to awfulize Maven, and then stick with Ant,
>>> continuing their misconception of Maven. Maven is really an ice cream
>>> cone,
>>> not a brussels sprout, but sometimes people need to
:) Also, burdening Joseph by having him create/maintain a
separate Ant build also takes away his efforts towards creating an awesome
Maven build.
Glen
Hi,
It looks for me that the structure of proton-j sub-project will be
quite simple and will not require the creation of complicated building
ultiple distros from the same "mvn clean install" (or
separately, by defining assemblies within specific profiles and
specifically activating them), the Maven Assembly plugin is normally
used: http://maven.apache.org/plugins/maven-assembly-plugin/. I know
Apache Roller does that in i
nception of Maven. Maven is really an ice cream cone,
> not a brussels sprout, but sometimes people need to be given a push to find
> that out. :) Also, burdening Joseph by having him create/maintain a
> separate Ant build also takes away his efforts towards creating an awesome
> Mav
sometimes people need to be given a
push to find that out. :) Also, burdening Joseph by having him
create/maintain a separate Ant build also takes away his efforts towards
creating an awesome Maven build.
Glen
>Hi,
>It looks for me that the structure of proton-j sub-project will be
Hi,
It looks for me that the structure of proton-j sub-project will be
quite simple and will not require the creation of complicated building
scripts similar to what we have in qpid java tree right now. I believe
that we can have 2 building systems for proton-j at least on first
stages of the proj
On Jul 24, 2012, at 5:19 PM, Rajith Attapattu wrote:
> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger
> wrote:
>> There *are* ways to turn that off - but the easiest is to run once
>
> While this might solve the developer headaches, it still doesn't solve
> the issue with customers/users and
So my 2 cents..
If your goal is to produce libraries which get published to maven central,
then it's much easier to use maven than to use Ivy. Several project at the
ASF have mastered that art of releasing using maven, so if Qpid feels timid
about how to best set it up / use it, then reach out.
On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger wrote:
> Fair enough. IMO, Maven is *the* build system for Java - people behind
> a security layer haven't proven to be impossible to serve with Maven,
> and the benefits in lifecycle are well worth it. But it's also not
> worth the pain if people a
Fair enough. IMO, Maven is *the* build system for Java - people behind
a security layer haven't proven to be impossible to serve with Maven,
and the benefits in lifecycle are well worth it. But it's also not
worth the pain if people are anti-Maven, when you *can* get what Maven
gets you through the
On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger wrote:
> There *are* ways to turn that off - but the easiest is to run once
While this might solve the developer headaches, it still doesn't solve
the issue with customers/users and release eng folks (at my employer).
For some users/customers downl
There *are* ways to turn that off - but the easiest is to run once
(after which most of the downloads will be finished), and then manage
dependency versions accurately; it won't redownload stuff it already
has, so if you specify a given dependency, version 6.0.12, it's not
going to redownload that
On 07/24/2012 01:41 PM, Gordon Sim wrote:
> On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
>> I wouldn't particularly be in favour of Ant+Ivy for proton.
>
> Any particular reason?
>
> I must be old or stupid (or both!) because I can't understand why people
> like maven. Admittedly I haven't used
h the host environment. This actually makes
>> it very difficult to integrate maven built software into controlled
>> build environments, e.g. distros or release builds.
>>
>> Given that it's pretty straightforward to get ant to play well with
>> others (including
nvironments, e.g. distros or release builds.
>
> Given that it's pretty straightforward to get ant to play well with
> others (including maven) and a core goal of proton is to be super easy
> to integrate, I'd be concerned that moving to a maven build might prove
> to be a ba
l of proton is to be super easy
to integrate, I'd be concerned that moving to a maven build might prove
to be a barrier to broader integration. I'd certainly like to understand
what it's impact will be e.g. on maintaining proton in distros or
getting it to build in embedded environment
On 07/23/2012 09:38 PM, Robbie Gemmell wrote:
I wouldn't particularly be in favour of Ant+Ivy for proton.
Any particular reason?
I must be old or stupid (or both!) because I can't understand why people
like maven. Admittedly I haven't used it for a long time and the
usability may have improv
Well, what I'll do then is convert proton's build to maven and submit that
as a patch attached to an issue, then I'll look into what it would take to
get qpid-java's build to maven, too. If those diffs pass inspection, good.
If not, we can fix them or ignore them as desired.
On Monday, July 23, 2
I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for
the main Qpid java stuff because it allowed a long overdue clean up of our
repo and didn't involve changing the entire build system (if it had, I
woudn't have done it), but if I was starting afresh I'd be using Maven for
tha
On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote:
> I think its safe to say Maven is a lot more mature now than it was back
> then, and is much more widely used. The issues that existed then certainly
> don't seem to bother the massive numbers of large projects using it today.
>
> Given how pop
I think its safe to say Maven is a lot more mature now than it was back
then, and is much more widely used. The issues that existed then certainly
don't seem to bother the massive numbers of large projects using it today.
Given how popular it is with other developers as a build system and as a
rou
Well, I have no problem maintaining the maven build, if that's the path chosen.
The "download the universe" thing can be a concern - but that's an
artifact of the build being what it is. Maven itself is pretty small;
it has a set of plugins for most of its actual operations,
I personally prefer the simple ant based system.
The last time Qpid used maven it was horrible :) .. it downloaded the
entire universe into my computer.
We also had trouble doing repeatable builds.
Now I don't know if it was due to the way Maven was used or if it was
an issue with Maven itself.
I'v
Hi,
I completely support Joseph's proposal to use maven as building system
for j-poton module.
Kind Regards,
Alex
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.or
Well, a lot of Java coders pretend Java doesn't exist, so that was okay too.
To be clear: personally, I'm happy with cmake being used for C, etc.;
I think idiom is important.
Using the maven directory structures is a no-brainer at the very
least. Using Maven has other benefits beyond the director
On Mon, 2012-07-23 at 12:04 -0400, Rafael Schloming wrote:
> The proton/proton-j directory is the top level entry point for Java and
> it's laid out pretty much as any Java developer would expect. (At least
> that is the idea modulo ant vs maven.) If you only care about the Java
> code you can chec
We don't actually try to build all the source code with a single build
system. In the interests of being as friendly as possible to various
different user communities, we have multiple points in the tree that can
be viewed as "top level entry points":
The proton/proton-c directory is the top level
+1 Please have the java code use maven, or at least use the maven directory
layouts. That way upstream folks can easily slap on a maven build on top
if they want to.
On Mon, Jul 23, 2012 at 11:52 AM, Joseph Ottinger wrote:
> Well, my thought wasn't necessarily to replace cmake for the
Well, my thought wasn't necessarily to replace cmake for the non-Java
parts - Maven is *capable* of doing non-Java-based builds, but isn't
necessarily idiomatic. I'd think using Maven for C++ builds would be a
little pathological, honestly - doable but not necessarily profitable.
For Java, it'd be
(In my best Rosanna Roasanna-danna imitation) Oh - never mind.
Thanks,
-Steve
On 7/23/12 11:45 AM, "Rafael Schloming" wrote:
>On Mon, 2012-07-23 at 15:20 +, Steve Huston wrote:
>> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
>> autoconf, but that's got a limited life
On Mon, 2012-07-23 at 15:20 +, Steve Huston wrote:
> Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
> autoconf, but that's got a limited lifespan). It would be nice to limit
> the number of build systems we need to maintain. I know proton is not
> Qpid, but the knowledge a
Exactly. Thank you, Andrew.
On 7/23/12 11:40 AM, "Andrew Stitcher" wrote:
>On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote:
>> What do you mean? I don't know what the proton devs would need to do
>> to support cmake -- the deliverables would be the same regardless of
>> the build system
On Mon, 2012-07-23 at 11:26 -0400, Joseph Ottinger wrote:
> What do you mean? I don't know what the proton devs would need to do
> to support cmake -- the deliverables would be the same regardless of
> the build system, or can be made to be identical.
I think you are talking at cross purposes here
What do you mean? I don't know what the proton devs would need to do
to support cmake -- the deliverables would be the same regardless of
the build system, or can be made to be identical.
On Mon, Jul 23, 2012 at 11:20 AM, Steve Huston wrote:
> Forgive my naiveté wrt Maven, but Qpid C++ currently
Forgive my naiveté wrt Maven, but Qpid C++ currently uses cmake (and
autoconf, but that's got a limited lifespan). It would be nice to limit
the number of build systems we need to maintain. I know proton is not
Qpid, but the knowledge and setups needed is one more thing C++ devs would
need to take
I was wondering if it'd be valuable to convert the build for proton to
maven. It's not a "rocket surgery" conversion - it involves moving
files and just a touch of configuration - but at the same time,
there're a lot of benefits.
For better or for worse, there're two dominant build systems in Java
91 matches
Mail list logo
