Ben,
The problem with the pom for the 1.5.4 snapshot is the following dependency:
<!-- Required for APT. -->
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
When compiling I get the following error:
[ERROR] Failed to execute goal on project lightagents-tier-ui-web: Missing:
----------
1) com.sun:tools:jar:1.5.0
Try downloading the file manually from the project website.
There are several issues here:
1) Mac OS X does NOT have a tools.jar. It's analog is something called
classes.jar. So there is no way for me to satisfy this dependency on
Mac OS X.
2) People using non-Sun VM's may have a similar issue.
3) Although yes this is a "system" dependency and even the Maven2 docs
suggest this is how to fix this they don't suggest that this will work
for Mac OS X. IMO using a "system" dependency is probably not something
someone really wants to include unless you can GUARANTEE it will be
available on all systems... and anything that should be built into the
JDK shouldn't be a dependency.
So how to solve this issue?
I have googled this issue and there appear to be some solutions (though
many don't work) but in the end it really boils to EITHER:
1) Changing the dependency scope above from "system" to "compile".
2) Removing the dependency altogether from your pom file which is the
the IDEAL solution. In fact, you should not need this dependency and it
arises in most cases werein the IDE is started with java pointing to a
JRE and NOT a JDK i.e. on many platforms by default the JRE is the
default JVM and although that is OK and the IDE's typically include
their own bundled JDK this issue can occur as the IDE has no way of
finding the jar. Of course on a Mac OS X system this is moot as the
tools.jar classes are already loaded within the Classes.jar so those
systems are already set except they are being forced to satisfy this
EXPLICIT presence of a file called tools.jar.
Apparently... once you remove the dependency any one of the following
should allow you to compile your project:
A) If you are using Eclipse you can explicitly start it with a specified
JDK or include it in the ini options:
-vm <JDK>
B) Setting JDK first in your PATH before starting your IDE
C) Setting up JAVA_HOME before starting your IDE (actually I am not so
sure of this last option as A) and B) have been reported to work but
haven't seen anything on C) as it all depends if Eclipse picks up the
setting and uses it - personally I think it should but don't know).
As a work around, what I did for now was attempt to compile which failed
and then manually tweaked the 1.5.4 downloaded pom's under
~/m2/repository/<pom-path> to have the scope changed from "system" to
"compile"
Of course once you release another snapshot I will have the same problem
and need to apply the same kludge.
Either way I think the pom.xml file should be fixed in the repo using
either 1) or ideally 2).
Much Appreciate,
--Nikolaos
Nikolaos Giannopoulos wrote:
Ben,
Comments in-line...
Ben Gunter wrote:
The short answer is because the trunk does not yet have all the
features we planned for 1.6. We might need to revisit what we
actually want in 1.6, but until then it doesn't make sense to release
a beta.
If all features aren't there but the build is stable and you want
people to potentially play with it then why not release a maven
1.6.0-SNAPSHOT? I don't think anyone is asking for a reduction in
features.
I have been working since last week on getting Stripes into the
Sonatype repository. I know virtually nothing about Maven so it's
been a challenge.
I'm sure you have heard this before - the learning curve for M2 is
steep - IMO primarily because so much is IMPLICIT and automatically
decided for you it is some times a challenge to get the pieces in the
right places. However, once setup M2 is truly a wonderful thing. If
I can be of any assistance / if you have any question that I can
potentially help with please feel free to contact me directly.
I have a 1.5.4 snapshot in there right now. I'm still trying to
figure out what all I need to do to deploy releases. In the meantime,
I'll push snapshots whenever something interesting gets added or
fixed. Here's the URL to the snapshot repository, I think.
http://oss.sonatype.org/content/repositories/snapshots/
So the way to verify this is to consider the above as your base URL
and then append to that the "Group Id", "Artifact Id" and "Version" of
the resource you are looking for. For Stripes 1.5.3 the dependency was:
<dependency>
<groupId>net.sourceforge.stripes</groupId>
<artifactId>stripes</artifactId>
<version>1.5.3</version>
</dependency>
For Stripes 1.5.4 that you built and considering you are using
snapshots the dependency is:
<dependency>
<groupId>net.sourceforge.stripes</groupId>
<artifactId>stripes</artifactId>
<version>1.5.4-SNAPSHOT</version>
</dependency>
And indeed that is correct as the snapshot pom and jar are found in:
http://oss.sonatype.org/content/repositories/snapshots/net/sourceforge/stripes/stripes/1.5.4-SNAPSHOT/
However there is a problem with one piece of the POM which I'll write
about in a follow up reply....
Thank You for doing this!!!
--Nikolaos
-Ben
On Mon, May 17, 2010 at 6:40 PM, Nikolaos Giannopoulos
<[email protected] <mailto:[email protected]>> wrote:
KR,
And that's pretty much what I was saying as far as releasing
early and often. While everyone can do what Freddy did/does
doesn't it make more sense to work with a release snapshot albeit
beta or whatever.
Honestly - if anyone - new or old - to stripes were to choose
between:
1) Door #1
- Checking out what may or may not be stable code from a trunk
- Pull together its dependencies
- Compile and package my own jar
- Upload it to my local version repository
- Update Stripes version in my project's M2 pom and
- Re-build my M2 project
-- VS. --
2) Door #2
- Update Stripes version in my project's M2 pom and
- Re-build my M2 project
What door do we expect - new or old - Stripes Developers to pick?
And not to say that I haven't elected Door #1 over the years
w.r.t. OTHER products - I have - MOST of the time b/c I had no
other choice but to do so to get a fix I desperately needed...
however of the times I choose to do so b/c I wanted to work /
play with the latest I too have been burnt before by not timing
the "its stable today" extraction and having all sorts of issues
and simply having to fall back to a working stable release with
only lost time and grief to show for it.
So to re-iterate KR's sentiment:
If 1.6 is stable, why don't label a stable version "beta 1"?
Surely releasing a beta is a good thing... NO?
--Nikolaos
KR wrote:
If 1.6 is stable, why don't label a stable version "beta 1"?
"Freddy Daoud" <[email protected]> <mailto:[email protected]> wrote in message
news:[email protected]...
I should have been more specific:
Case in point today the trunk is fine and quite "usable" as you put it
but tomorrow after some "next commit" it might not be the case...
I agree. What I did was take a snapshot of the trunk and called
it 1.6-SNAPSHOT, but I don't update it at every commit. I put
it in a Maven repo and just use that in my projects. I won't
update it unless something happens in the trunk that I need.
Like I said, this isn't for everyone. But for my purposes, it
fits the bill.
Cheers,
Freddy
------------------------------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/stripes-development
------------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
